Capability: Fusion Delivery Methodology

Requirement discovery – paving the way to project success

Posted on: 9 August 2023
Requirement discovery – paving the way to project success

Focussing on outcomes is essential to the success of any project. What does the project need to achieve? It sounds like an obvious question, but time and again we see vague notions of what the outcomes are. Procuring a technology system isn’t the end of the process. It needs to be designed, structured, implemented and have a plan put in place for its ongoing success post go-live. How will the people using the new system be trained? What, ultimately, will success look like? A robust requirement discovery phase of the project helps both parties to understand one another and outline the objectives of the project.

At CACI, we utilise our proprietary FUSION project delivery methodology with all of our customers and for our internal projects. This helps us to keep work on track, whilst further enabling us to continually learn from project implementation to continuously improve our own processes. Spending that time early in the lifecycle of the project to fully understand what it is you need to achieve enables us to set clear goals and create a point of reference for the remainder of the project.

Here we can establish what success will look like, creating a baseline of requirements and their acceptance criteria for sign off.

Requirement discovery building knowledge and insight

The success of any project is underpinned by the people involved. Getting both teams together so that they can build knowledge and insight of how each other works is invaluable in putting in place the groundwork for a successful project.

The definition of success and acceptance criteria created during the requirement discovery phase of the project acts as a reference point for the rest of the project. The requirements laid out at this stage are designed to establish what you need from the project, not describe the solution. It is important, therefore, to prioritise your requirements, understand what you want to achieve and set out your acceptance criteria at this stage. Who needs to do what, by when? What will tick your boxes in order to advance the project?

The involvement of key roles such as the project sponsor are vital in ensuring buy-in from key personnel and following up on your requirements to ensure that they are appropriately managed.

This isn’t just about managing the change in technology that you’re experiencing, there’s the human element to consider, too. We covered this in our previous blog about change management, but it’s worth reiterating since the requirement discovery phase further enables discussion around the tangible impact to the people who are affected by the change. Getting buy-in from everyone early in the project is good practice and the discovery phase is vital in building that knowledge and insight that will facilitate a smoother change management process when the (agreed upon) time is right.

The importance of epics in requirement discovery

Epics are an important way of breaking down a larger body of work, such as a software implementation, into user stories that work towards the intended outcome of the overarching project. This helps both teams to break their work down whilst continually working towards the bigger picture.

CACI helps customers in creating these, since they enable us to focus on your outcomes, putting them front and centre of the project. We’re providing the solution, but your required outcomes are bespoke to you. Creating epics enables us to focus on this during the process of delivering your solution.

The creation of epics also enables us to come back to your requirements and how we intend to achieve them. With the overarching project broken down into smaller sprints of work, it enables us to focus on the delivery of key requirements across the project.

How CACI can help you deliver the outcomes you need

The purpose of the discovery phase is to build insight and understanding between our team and yours. Reading requirements on a tender is one thing, but how will they look in reality? We aim to embed our team within yours, which is why discovery is so important. This enables us to tailor the solution to your needs, with your required outcomes at the forefront of the project implementation.

We’ve seen all manner of projects in our time. Most have gone well, but we’ve also been involved in projects where shortcuts have been taken and the project has been executed without the involvement of those who will be most impacted by the project: that is to say, those who will be using the solution day in, day out.

Discovery is such an important step in the project. It enables us to create an agreed path forwards against set deliverables, acting as a point of reference as the project advances. The project lifecycle can be difficult to manage, but by breaking it down and understanding what you need the solution to deliver, it makes it easier to pinpoint where things are veering off course.

Our team of project managers have seen it all before, across a multitude of industries. Selecting a technology provider and their solution is one thing, but what happens next is so important to the solution being successful for you. We always strive to place your outcomes first, to ensure that the solution and the project work to deliver what you need.

Learn more about CACI’s requirement discovery, see our brochure here.

A Voyage of Discovery

Posted on: 10 May 2023
A Voyage of Discovery

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.