Requirements are fundamental to project success. Without a well-defined set of requirements, the project has no chance to be successful--there will be no clarity as to exactly what has to be built, how to determine if it is successful or whether it meets the goals and objectives that prompted the project to be approved in the first place.
While most organizations recognize this importance, few of them do a good job of tracking requirements from end to end in a project--instead considering the requirements definition process as a standalone process that is relatively self-contained. In this article, I want to look at requirements as a more integrated part of the project process, as well as connecting them to the more strategic development of the organization.
Requirements capture and refinementLet’s start by considering requirements from a broader perspective. Some initiatives that an organization undertakes can be considered as true one-off events. These are the projects that begin in one part of the business in response to a unique challenge; the project is defined and executed, and then the work is complete, never to be considered again.
However, in many situations things are more complex--a project may release a new version of an existing product, an upgrade to an existing system, a refinement to a set of processes that are in use, etc. Alternatively, there may be other projects following this current one that will build on the work that is currently underway--even if those projects are not yet defined or planned.
In this second category, there will be requirements that are identified outside of the traditional requirements gathering and documentation process--product gaps will be identified in client meetings, process weaknesses will be identified during operations cycles, and even random water cooler conversations can result in ideas that could generate significant benefits. These are still requirements even if they aren’t immediately part of any requirements document, and they need to be treated as such.
That means that we need tools and processes to capture those ideas so that they can find their way into the pool of outstanding requirements. There are a number of tools available that can assist with this process of capturing, refining, categorizing and assigning these high level requirements.
While many organizations have access to these tools (or collaboration tools that serve a similar purpose), few are able to effectively manage these requirements from end to end. All of these ideas/high-level requirements should be reviewed, and if they are approved they should become part of the list of potential requirements for future releases. Further, if those requirements make it into the scope of a future release and are submitted for more detailed requirements documentation, there should be a connection to the person or people that identified the initial opportunity/problem/improvement so that:
- The person responsible for producing the detailed requirements can access a subject matter expert and ensure that there is no misinterpretation during the requirements development process.
- The person who generated the initial idea is aware that the request is being pursued.
- The organization can close off outstanding issues as the requirements that address those issues are executed and deployed.
In most organizations this connection simply doesn’t exist, leaving much of the requirement gathering and documentation process open to interpretation that inevitably results in partial and inaccurate solutions.
In-project requirements trackingThe tracking of requirements within projects is a little better understood and sometimes executed fairly well, although many organizations still fail to attempt this level of requirements tracking. The idea is that every solution element--process step, product feature, etc.--is tied to a requirement so that the project team understands exactly what the purpose of each product element is. This approach allows for validation of the requirements against the design:
- By ensuring that every requirement is tied to at least one feature in the solution design, we know that nothing has been missed—and that as long as the solution is built as designed, it will fulfill the requirements.
- By ensuring that every element of the solution design is tied back to at least one requirement element we can ensure that the solution doesn’t include any unnecessary or rogue features. If the solution is built in accordance with the design, it will be as efficient as possible (in terms of project execution and product/process structure).
This approach also assists us with testing and validation of the solution--we can use the mapping of features and design to assist us with test planning to ensure that no features are missed, and it also assists with troubleshooting problems that occur because we have a well-documented mapping of features and requirements.
In practice, this level of detail is frequently missed entirely, not because it is difficult (it really isn’t complicated, especially with the tools that are available today) but rather because it requires a level of cooperation between teams that is still not common. To complete this mapping successfully requires close collaboration between solution designers and business analysts, and these are still roles who frequently mistrust one another--especially in the application development world.
Agile development solves many of these problems by connecting developers directly with the product backlog, but in a more traditional project execution environment this is still the exception rather than the rule.
Bringing the two parts togetherIf an organization can bring the broader requirements capture and development process and the in-project mapping of requirements to features together, then the benefits can be even more dramatic. The most obvious gain is the ability to track features directly to business problems, making the analysis of proposed scope changes much simpler. If a project is falling behind schedule and the elimination of some scope items is being considered, the ability to trace a problem statement to feature will immediately reveal which issues will remain outstanding or only partially resolved; a business decision can thus be made with confidence of the impact.
Similarly, if a change is being requested by the business, then as soon as the analysis of which project elements are impacted is complete we will also know which business problems are being affected. A more appropriate decision can then be made around which is the best option to integrate the change.
One of the other advantages of this integrated approach is that because we will know exactly which business problems are solved by a particular release, we can advise the person or department that initially raised the problem when the resolution has occurred and allow them to verify the solution. This is also a way to identify and capture further improvement opportunities for future releases.
ConclusionRequirements tracking is not new as a concept, and the advancement in requirements management tools in recent years has made it much easier to implement within organizations. However, it is still not a standard part of project execution in many organizations and so the benefits are not being realized.
This is particularly painful given the relatively low level of investment that is required. For software vendors in particular, I believe that offering this level of tracking of requirements to features will be a differentiator from competition that will help them to win more business; while they may not be able to control the customer’s internal tracking of problems to requirements, they can at least set an example.
If your organization has not considered the concept of tracking requirements from source to conclusion, then my question is very simple--why not?
No comments:
Post a Comment