Who’d have thought it?

Managing requirements for a project can get complex. And mismanagement of the requirements may cause projects to fail. It may even lead to legal action against vendors.

This happens more than you think.

Most ICT projects fail because the requirements are mismanaged.

For example, they’re not well understood, are incomplete or ambiguous. Of course, there’s the dreaded scope creep that project managers want to avoid.

To make it worse, even when requirements are implemented, often they’re not tested properly.

A traceability matrix can help prevent this. That’s because it allows you to track the lifecycle of requirements as they evolve during the project.

And that means helping projects deliver their goals.

Most projects have to cater for evolving and changing requirements

Why?

Because people rarely get their list of requirements right and complete at the beginning. And because projects can take months or even years to finish.

What really happens during a project is that, at each project phase gate, the requirements evolve as they’re refined, technology-tested and future-proofed.

Because projects are subject to budgets, decisions are always being made as to what can and cannot be included during each phase of the project.

And, often, there are moving targets throughout the project. For example, two floors of the building are no longer to be included in the solution, and no-one knows whether the third floor is to be included.

Even though these may cause the scope to shift in real-time, the project needs to proceed regardless.

So what does a project look like when it’s aligned with the way requirements evolve?

A good project manager will freeze (baseline) the requirements list as soon as possible.

For small projects, that may be feasible.

But larger and longer projects proceed through phases, and each phase has the potential for requirements to evolve.

Here’s what can happen during each project phase:

Requirements definition phase

Version 1 of the requirements is created, reviewed and signed-off.

High-level design phase

Vendors come together to create the high-level design for the project, which may involve civil construction, communications networks, security capabilities, back-up systems, electricians, and software and hardware experts.

As the high-level design unfolds, it’s often found that certain requirements can’t be designed into the solution because they’re not feasible given all the technical synergies. You see, the people who created the requirements, weren’t technical people, so they didn’t know this.

Hence, version 2 of the requirements is created. And the vendors use that for their pricing of the detailed design, which goes to the project sponsor.

Detailed design phase

The subject-matter expert vendors return to create the detailed design.

As they progress, they have to interpret the requirements in a very exacting manner and make design decisions that may not be what the project sponsor really intended. Well, the requirements were originally vague and the wording imprecise and inconsistent, so the vendors do their best to interpret them.

When they run their design by the sponsor, the realisation hits that the requirements weren’t quite complete and precise enough. Hence, version 3 of the requirements is created.

As more of the design unfolds, moving targets cause it to change, hence version 4 of the requirements. This in turn causes budget problems which affect choices for the solution. Hence, version 5 of the requirements is created.

Final pricing for the project is then submitted by the vendors to the sponsor.

Implementation phase

Now the sponsor realises that the project is going over-budget because of the extra work needed to keep refining the requirements and their design.To meet the deadlines, requirements have to be cut or delayed. Hence, version 6 of the requirements is created. The designs and scope are adjusted to meet the budget and schedule, and the solution is finally implemented as per version 6 of the requirements.

Testing phase

Each vendor typically unit-tests its part of the solution, then hopefully collaborates with the others on holistic system testing.

Then the project sponsor’s team does user-acceptance testing. Even at this stage, the sponsor may find that the solution doesn’t quite operate how they wanted because, well, everyone forgot about the operational rules. The technologies aren’t meeting the performance and operational behaviours needed. And there’s no way the system is going live until they do, of course.

Hence, version 7 of the requirements unfolds and possibly the whole cycle repeats. Regression testing then makes sure every requirement is implemented and thoroughly tested.

Deployment phase

Finally the system goes live. It took more time and energy to deliver than anyone expected!

The reality is that requirements have to evolve for many reasons. A project manager needs tools to manage that evolution.

Project gates cause delays and headaches for project sponsors, vendors and project managers

Everyone wants the project to succeed.

But the reality of budget limitations, moving targets that cause scope change, unrealistic schedules, staff transition, inexperience, and requirements evolution result in making projects more complex than imagined.

Typically, a project has multiple gates it has to pass before being allowed to proceed.

Each gate involves corporate review and approval of the schedule, resources and budget. These gate reviews take time.

During that time, things happen, such as staff transition and technology changes; for example, a key piece of hardware required for the solution is made obsolete, affecting the cost and requirements. Often the project manager transitions out of the project at the end of a phase. Where’s the continuity? It’s often lost between phases.

Lack of clarity regarding requirements means challenges for vendors

The vendors just want to do the best job they can. But each is hampered by the multitude of vendors involved, the need for significant collaboration between vendors and stakeholders, as well as the evolution of the requirements.

For instance, ‘what’s the latest source of truth regarding requirements?’ they continually ask.

‘Which requirements are still valid in this phase?’ ‘Which aren’t?’

‘What’s the latest version of the requirements?’

And so on.

The traceability matrix is your projects’ saviour

For medium-to-large projects, project managers need mechanisms to safely guide the precious requirements list through its evolution, throughout every phase of the project.

They need a continuity thread within, and across, each phase of the project.

Often, projects will have a different project manager for each phase. This results in knowledge deficits and the need to recapture that knowledge.

At Frame, we’ve found traceability matrices invaluable because, for project sponsors, project managers and vendors, they address the concerns raised above.

We use a traceability matrix at each phase to track different aspects related to a requirement. We also use a scoping table to show which requirement and version is the current source of truth for that phase.

So what is a traceability matrix?

In short, the traceability matrix tracks the lifecycle of each and every requirement as it evolves through each phase of a project. It assists with governance, visibility, future upgrades and, most importantly, continuity.

It is a table, with columns representing requirement attributes at a particular phase, and rows representing each requirement, its unique identifier and name.

Typical Design phase matrix example

For the Design phase, the matrix would consist of the following columns:

Design document reference: the source of the design documents for the requirement. This points you to the evidence that this requirement has been designed completely.

User acceptance test: the tests required to verify the requirement is met; for example, performance and recovery tests. This tells you what testing this design needs to ensure it works.

Business rule reference: the business rules or policies that need to be met in order to implement this requirement. This tells you what business or operational rules will be affected and how.

Typical Implementation phase matrix example

For the Implementation phase, the matrix would consist of the following columns:

Implementation reference: the document, activity, person that verifies the implementation done. This proves to you that the requirement has been implemented.

Testing reference: the test scenario in the user-acceptance test plan, a reference to the vendor’s test results and the type of testing that needs to be performed for this requirement (functional, non-functional, positive, negative, performance, stress). This proves to you that this requirement will be user-acceptance and vendor tested.

Typical Testing phase matrix example

For the Testing phase, the matrix would consist of the following columns:

UAT tested reference: whether the requirement was tested and how. If not, then why not. This proves to you that the requirement was tested.

Tracing reference: the trace back to the test case details and outcomes of the testing. This provides the written evidence that this requirement was thoroughly tested.

Scoping table to support fast and furious evolution

If requirements are undergoing significant evolution, then a scoping table is needed for each phase.

For example, a Testing phase scoping table would consist of the following columns:

Unique number and name of requirement

Will it be tested during UAT? Yes or No (see Rationale column)

The type of testing it will undergo: functional, non-functional, performance, stress, failover, recovery, post-production validation

Rationale if No: why is it not being tested? Reasons could be: it is out of scope as per the budget decision during the implementation phase, or an explanation as to why it is only undergoing functional testing and not non-functional testing.

You can’t manage a project effectively without a traceability matrix

For the project manager and vendors, requirements management presents significant difficulties and increased complexity throughout the project.

All stakeholders need a means to contain that complexity and manage the evolution of those requirements.

Also, the project sponsor needs a means to ensure that the requirements are governed appropriately.

The traceability matrix enables these benefits.

Using a traceability matrix ensures that nothing is forgotten – each and every requirement is designed, implemented and thoroughly tested.

And if requirements are evolving, the scoping table ensures that all vendors know what the current source of truth is which mitigates mistakes.

While the matrix is vital to the outcome, there’s a significant, hidden benefit: the process of collaboration and regular peer reviews amongst stakeholders ensures the matrix is correct.

Looking to the future, when systems are upgraded, the matrix becomes invaluable in helping the next project manager and vendors understand the make-up of the solution and what needs to be maintained.

The traceability process and matrix contribute to ensuring that the critical aspects of the project’s solution are properly implemented and tested, and that appropriate decisions are made to proceed with going live (deploying the solution).

Continuity is a vital need for long-term projects

The traceability matrix enables continuity even in the face of staff changes such as the project manager leaving the project. Often, instead of the information being documented in a traceability matrix, it’s kept in the project manager’s head — the last place a project sponsor wants it to be when the project manager leaves.

So the traceability matrix is a documented, living record of requirements evolution for a project. Any person , at any time, can quickly garner significant knowledge about the project by skimming its traceability matrix.

Can this process be automated?

Yes, there are wonderful software tools that can easily do this tracking for a project as the requirements unfold.

But, often, companies don’t have such tools nor the budget for them, nor do they understand the value of them. That’s why it’s a good idea to know how to do this manually.

Keep your project requirements in check with a traceability matrix

Many ICT project failures are the result of inadequate gathering, tracking, evolution, analysis and management of requirements. Requirements must be allowed to evolve in a structured and controlled way in response to the realities of a project’s progress.

The heart and soul of a project is continuity of knowledge with regard to how time affects each requirement as it evolves throughout each project phase.

Don’t let requirements management get in the way of you delivering the best project solution possible.

Give the traceability matrix a try and you’ll be able to track and manage the evolution of your requirements, to increase your project success rates and reduce costly overruns.