Author: Ekta Mehta

A month into live operation of your new system and everything could not be running more smoothly. The solution went in on time and within the original budget and quickly delivered benefit, fulfilling the needs and expectations of your business and IT. Everyone was clear from the outset about what needed to be achieved and why.

Panacea, perhaps, but as a solutions supplier, we want this outcome as much as you, our customer. There are many reasons IT projects succeed or fail, some of which are unpredictable, but what practical measures can you take to give us all the best possible chance of a great outcome?

A key measure of success of solution delivery is that the requirements it set out to meet were indeed met. This sounds obvious, but if the requirements laying this foundation were unclear or incomplete, it is unlikely that the solution delivered on them, or that consensus was reached that work was complete. It is no wonder that the Government Digital Service (GDS) stipulates “define user needs” as the first point for consideration in their Technology Code of Practice.

For CACI as a solution supplier, it would be superb if we embarked on a major project where all requirements were fully defined, with clear, testable acceptance criteria and supporting specifications were in place. We could focus our efforts entirely on design, build and testing. But let’s get real: this rarely happens. Eliciting, analysing, validating and documenting a full, detailed baseline of functional and non-functional requirements effectively, is a time-consuming activity. It has dependencies on skilled business analysts and subject matter experts from the business, and technical and security teams who may not be available ahead of procurement or the project mobilising.

CACI’s FUSION delivery methodology recognises this reality by proposing a structured approach through our Shape step. CACI can support these activities as much as you need to build a strong foundation and achieve success together.

To hit the ground running once a supplier is appointed, what practical measures can be taken by you ahead of project mobilisation, when time and specialist skills may be in short supply, to research and define your users’ needs?

Start with the Afters

You should ensure there is a clear definition of the benefits that the solution aspires to deliver. These may reflect pain points the solution is intended to address or additional gains that will be achieved.

There needs to be consensus on these drivers at a business level and with your key stakeholders who will be engaged in delivery.

Having this in place will help provide some shape to the requirements and inform prioritisation. Without it, there may be a lack of clarity on what the solution should be setting out to achieve, which in turn will disrupt delivery both for your organisation and the supplier, once appointed.

Breadth before Depth

It is sensible to appoint a single owner for the business and IT requirements, often called a product owner, and ensure they are fully supported to fulfil that remit. This might involve access to business analysts and subject matter experts (SMEs) on technical aspects and business operations.

They should first establish that the breadth of requirements is complete before the more time-consuming elaboration on the depth (detail). This will help you track where the scope has been defined and where work still needs to be done.

One approach is to take a top-down view, first identifying the major groups of requirements, for example, by breaking it down into epics:

Take each epic a step further by identifying users’ functional needs, such as through defining user stories: “As a [actor], I need to [do something], so that I can [achieve something]”, and adding these to the epics. Just one line per user story is sufficient at this stage.

The system will also need to comply with the organisation’s technical and security standards. Furthermore, there may be other aspects requiring the new solution to “be” something, rather than perform a function. For example, it may need to be available between specific hours, have a certain technical capability or comply with a security standard. These are known as non-functional requirements (NFRs).

If the new “to be” solution is replacing an old “as is” one, you need to ensure that you fully understand all aspects of what the “as is” system achieves and ensure that these are reflected in the “to be” requirements, or that there is agreement as to which elements will not be in scope.

Elicitation of requirements merits an article in its own right, but may involve workshops, interviews, surveys and document reviews. The Chartered Institute for IT (BCS) provides a framework and certification for requirements engineering, which includes such techniques.

Once a working set of requirements has been established, these need to be cross-checked to:

• Identify and resolve any conflicts
• Remove duplicates
• Ensure they are accurate, consistent and understandable

Reviewing that requirements are aligned to the benefits the solution is seeking to achieve, and prioritising accordingly, ensures they will deliver against the business goals.

Now is a great time to agree a baseline for your requirements, since the scope has been fully defined and therefore amendments can be controlled through a change management process. You are also in a strong position to engage with a supplier on detailed implementation plans to deliver the solution.

Diving Deeper

Each requirement needs further elaboration to establish its depth, completing its definition:

• Supporting assets, such as technical specifications, policies, standards, process maps and business rules definitions, are available and can be referenced from the requirement
• Clear, testable acceptance criteria define the evidence used to assess that the requirement has been successfully met

A full requirements catalogue can quickly resemble a database rather than a single document. When implementing Cygnum solutions, CACI use Jira and QMetry to model requirements, collaborate, link assets together and manage processes such as approvals, change and traceability through testing.

If you cannot clarify requirements to this extent ahead of engaging with a supplier, the exercise needs to be accounted for in the implementation plan. CACI recognise the value to customers and the delivery team in collaborating on this, as this assures a shared understanding of requirements. The Shape step of CACI’s FUSION delivery methodology explicitly provisions for this activity under the Discover phase.

Once complete, you have a solid foundation for solution design and delivery. It would be prudent to re-baseline to reflect this milestone, such that there is a clear distinction between what was agreed at the time and subsequent change.

Better Outcomes

We believe that defect-free delivery to you is achievable when your requirements are clear, accurate and complete. Before handing a solution over to you for acceptance, we run system test cases against your acceptance criteria and evidence the results, providing full, objective traceability that your requirements have been met.

Your time should be focused on value-add activities, such as user acceptance testing against your business processes.

Celebrating a successful, on-time transition into live service is the outcome we all want to achieve and is distinctly more likely when a structured approach is adopted.