Your project’s family tree

Business user: How do I get the system to do x?

Project manager: Ah, x wasn’t in the requirements

Business: Yes it was

Project manager: It’s not in the requirements specification you signed off

Business: But we talked about it in the very first meeting….


Does this sound like a familiar conversation? It’s one I have heard many times over the years. The bigger and longer the project, the more often I hear the conversation. It all boils down to requirements traceability. It’s a bit like tracking your project’s family tree. You need to know the ancestors or origins of every single requirement. And it’s a lot more important than just avoiding a few arguments with the business.


The first reason this is important is about benefits. Fundamentally, the benefits are what your project is set up to deliver. By delivering the requirements you deliver the benefits and each requirement should be traceable back to the benefit. If it doesn’t help deliver the benefit or it’s not a necessary control or step towards that benefit, why are we delivering it? This gives the project manager the ability to challenge each requirement. To argue whether or not it must be delivered. To understand the value of the requirement.


The second reason is about costing the project. Until you have a full set of requirements linked to the benefits, you can’t properly cost the project. And the requirements traceability matrix is a great tool to help identify gaps in requirements. If you need to do that there, doesn’t that require something else over here? So it helps with ensuring the completeness and efficacy of the project and its design.


The third reason is testing. You are testing whether the solution delivers against the requirement. It is the requirement that determines the tests and the expected results. Without properly documented, traceable requirements you can’t know the full extent of testing required.


The business has to play its part here, not as in the Dilbert cartoon below

Dibert requirementsThey have to be fully engaged and participate in the requirements definition.The project team should document, understand and  challenge the requirements but they are owned by the business. In a systems environment there may be some technical requirements that the business doesn’t own or understand (often called non-functional requirements) that are part of enabling the system to run in the environment to the required performance, integrity, security and availability. But those aside, this is the business’ show.

And that’s where the traceability comes into it’s own. The longer a project goes on, the more memories become confused and people forget where or why a requirement originated. If you start out with a proper requirements traceability process in place such problems will pretty much go away. It also gives you a solid basis for change control over the requirements and getting them signed off.

A Guide to EPM cover

Solid, business owned, traceable requirements are a cornerstone for any project. If you want more tips on managing your projects more effectively sign up for my free guide. Click here or on the image.

Leave a Reply

Your email address will not be published. Required fields are marked *