Most project managers know the importance of requirements management. Without a solid foundation and grounding in the subject, requirements management quickly turns towards the complex and difficult side.
Why Manage Requirements?
In the final analysis, all projects are completely driven by requirements. Requirements are usually not cast in stone. Stakeholders gather insights and more knowledge of their true needs with time. This means that they can change their minds about requirements, no matter how late in the game. Requirements should therefore be managed proactively in anticipation of change.
However, if requirement definitions are not set up properly in the first place, expect that the quality of delivery will suffer, along with more schedule delays than imagined, and a big drain on the budget.
Broad project requirements help to establish a baseline for objectives. Subsequent change requests would thus require approval by the right authority; a change control board is usually set up to investigate and approve changes to requirements. The objective of baselining is not to prevent or discourage changes, but to ensure that approved changes are relevant and deserve the priorities assigned to them.
The simplest way for project managers to reduce the probability of missing critical requirements is to hold requirements review sessions to ensure that stakeholders understand the requirements and that any ambiguities, inconsistencies and omissions are identified and addressed to facilitate requirements approval or sign-off.
However, when inaccurate requirements are in play, team members end up reworking those activities multiple times. The only sensible course of action is to deliver requirements up front in an accurate manner. That way team members will be able to immediately identify any missing components early in the project lifecycle.
It’s vitally important to employ tools designed to assess requirement quality at the beginning of the project. These tools will help to identify any requirements that are vague or missing early enough to improve the changes of success for the project. Even simple tools like guidelines and checklists can solve major problems later on. You may also consider automated tools, depending on your level of technical expertise.
The Good, the Bad and the Ugly of Requirements Management
Good Requirements
Requirements that meet the “good” standard are ones that anyone can easily evaluate to quickly and clearly determine that all the needs have been accurately met by the project.
The common criteria used by project teams to properly evaluate requirements is as follows:
Verifiable: Ensure that all deliverables are able to be evaluated to ensure they have met all necessary requirements. Verification techniques such as modelling, analysis, review by experts, simulations, and demonstrations or testing.
Testable: Requirements are able to be assessed using the most basic of all criteria. This includes quantitative measurement like “pass or fail.”
Traceable: Requirements should be tagged to specific sources. Examples are compliance requirements, best practices, industry standards, and use cases.
Clarity: All statements should be presented in unambiguous ways so the cannot be interpreted differently by different team members.
Bad Requirements
Bad requirements are marked by their incompleteness and lack of clarity. They are hard to understand and implement. They generally possess these characteristics:
Inconsistency: Without clarity, you’ll find requirements that are in conflict with other requirements! This is very frustrating because there’s no way that either one will ever be satisfied.
Non-valid: These are requirements that team members simply cannot understand. They will never be able to accurately assess or approve non-valid requirements.
Non-ranked: These requirements have not been correctly prioritised. Without proper ranking, it’s difficult for team members to be able to assess them properly.
The risk to the project not meeting the clients expectations is not something that will ever be entirely removed. However, having a specific criteria upon which to benchmark a project is a great way to reduce this risk.
Risks fall into two main categories. Systemic risk is inherent to the nature of the work and cannot be avoided. The non-systemic risk is a bit different and relates from the activities in the project itself. One of the greatest of all non-systemic risks is that of bad requirements management.
Teams that wish to reduce the risk of the project not meeting the clients expectations substantially are best served by establishing specific requirements in the initial stages. Common goals like being “on time and on budget” while maintaining a high level of quality will require dedication from teams members who have eliminated as much non-systemic risk as possible.
When you’re next involved in a project where requirements come up in a discussion, always pay careful attention to the good, the bad, and the ugly that could result without proper due care and attention.
