Data & Business Reporting Systems (DBRS)

Determining your requirements (all your required business functions and gaps in existing systems). These should be categorised as:

• Essential
• Future essential
• Desirable
• Nice to have

Assessing potential systems against those requirements and in particular assessing whether they are met:

• Out of the box
• Through configuration
• Through development
• Through integration with a third-party solution

We are often brought into negotiations with a supplier after this has been finalised, yet we can add significant value at this stage, not least by controlling the “terms and conditions” that will apply at contract award. 

This is the first activity with the selected supplier, which sets the expectations between the parties. The aim is to gain as much specificity as possible, acknowledging that the detailed design phase goes to a much greater level.  

Key issues are:

• To ensure the scope ties back to the requirements. See Specification vs requirements
• Identify and document any agreed “gaps” against the original requirements (as time moves on and requirements change)
• Confirming what is out of the box vs through configuration vs through development vs through integration with a third-party solution
• This can and should form part of the main contract, but we do often see this phase started in haste without the right contractual protection. It is possible to pull it back under the wider arrangement, but this can be difficult

Detailed design is where the design of the new system is finalised. This essentially covers the contents of blueprinting/scoping, but to a much greater depth, enabling both parties to be able to understand their respective obligations.

It is important to see a detailed and comprehensive RACI matrix (Responsible/ Accountable/ Consulted/ Informed). 

A very common area of dispute comes from a lack of understanding on the part of the customer as to its obligations and “over-optimism” on the part of the implementer in this respect. 

This is where the solution is configured and developed (as applicable) in accordance with the detailed design. 

This may include developing custom modules, integrating with existing systems, and configuring the system to meet specific business requirements. 

Once built, the solution needs to be implemented. This involves deploying the new system, migrating data from existing systems, and training users on the new system. 

It is crucial to have a well-defined plan for data migration and user training to ensure a smooth transition. 

There are differing elements to testing, whether (for example): 

• Functional testing
• Load testing
• Penetration testing
• User acceptance testing 

It is important, yet often overlooked, to ensure that:

• It is clear which party is responsible for which elements
• How the acceptance criteria are to be set
• How testing will take place
• How achievement is determined
• What happens if there is a failure

Following successful acceptance testing, a date is agreed for go-live.

This is a short period of support immediately after go-live where typically the original team who built and implemented the solution remain on the project to monitor and deal with issues. 

We work with clients to ensure hypercare runs for an appropriate period of time, that the right people are made available for hypercare and that appropriate response and resolution targets are applied, together with appropriate consequences for any failures. 

Life isn’t perfect and systems never quite run perfectly!

Ongoing managed support is therefore an important part of the contracting process.

See IT services