The Problem

One of the most frequent reasons for project failure is “scope and requirements creep”. Too often, the scope of a product development project changes in midstream as stakeholders think of new features to add.  This change, more often than not, results in new requirements being added to the requirement set.    We recognize that change is inevitable; however, if the scope of the project changes, new requirements will be added and if new requirements are added, the project schedule and budget often must be increased, otherwise, you face risks of overruns and rework.

An effective way to combat scope and requirements creep is to actively engage your key stakeholders in scope and requirements development and baseline activities.  Through stakeholder participation and engagement, you will be able to minimize the adverse impacts of change. The payoff?  Reduced rework, reduced cost overruns, and reduced schedule slips. See our previous blog on the importance of baselining scope before writing requirements.

Baselining Your Requirements

Once your requirements have been defined based on the baselined scope, they must be agreed to by all key stakeholders and formally baselined and controlled.  Baselining your requirements before design puts your requirements under configuration control and the resulting configuration control process. Any changes proposed to your requirements then must go to the configuration control board who will evaluate each change for feasibility; impacts to cost, schedule, and risk; validate the change against the baselined scope, and formally approve/reject the change.

Baselining your requirements and getting agreement from all key stakeholders before your team begins design ensures that everyone will clearly understand what the designers are expected to implement with their design.  Having a baselined set of requirements keeps designers from diverging, reduces design inconsistencies, and keeps the big picture in view. An agreed-to set of product requirements contributes to a design that meets stakeholder expectations, and reduces discrepancies found during testing, verification and system validation.

Another key consideration is that the baselined requirements represent a contract between the organization that is responsible for development and the stakeholders.   The contract may be formal as is the case for external customers or informal which is often the case for internal customers.  In either case there is an expectation that you will provide a product or system as defined in the contract represented by the baselined set of requirements.

The Requirements Review

The Requirements Review is the major lifecycle review where the requirements are baselined.  It is often called the “System Requirements Review (SRR)” or may be referred to as a “gate review”.  Looking at major reviews as gate reviews rather than milestone reviews is very important.  A milestone review is triggered by schedule, while a gate review is knowledge-based – “Has the work been done to define the information needed at this stage of the product development lifecycle?”  The review only occurs if that work has been done and the information needed has been defined.

While called the Requirements Review, often the review involves several project management and systems engineering deliverables at various stages of maturity.  These deliverables can include project plans (cost, schedule, work breakdown structure, etc.), systems engineering management plans, integration plans, verification and validation plans, lifecycle concept documents, etc.

The Requirements Review evaluates whether the requirements defined for the system are responsive to the higher level organizational requirements and ensures the preliminary project plan and requirements will satisfy the mission defined during the scope definition activities.

The Requirements Review helps to:

1. Validate that the requirements meet the intent of the stakeholder needs baselined during the Scope Review
2. Ensure the requirements represents a feasible approach to meeting the need , goals, and objectives
3. Ensure alignment with system-of-interest parent documents
4. Identify problems and risks
5. Find helpful suggestions
6. Ensure that everyone has the same expectations of the system-of-interest
7. Obtain concurrence of stakeholders

Before the Requirements Review

Do not base line a bad set of requirements!!!  Bad requirements going into a review is a waste of time.  Requirements need to be in best possible shape before you schedule the Requirements Review.  Remember bad requirements result a bad product and waste precious resources to correct.  The cost to fix a problem caused by bad requirements increases almost exponentially as you progress through the product lifecycle.

Before the Requirements Review, you need to make sure your requirements are ready for the review.

One key consideration is whether or not your requirements are complete enough to have a review.  To help with this determination see our blog: “How do you know when your requirements are complete?”

Another key consideration concerns the quality of your requirements. As stated above, you don’t want to baseline poorly written, defective requirements.  Before you schedule the Requirements Review, we recommend you first assess the quality of your requirements per the “Checklist for Good Requirements” that we provide in our classes. (Send me an email at info@argondigital.com and I will send you a copy of the checklist.)

If your requirements are not ready to be baselined, then do not schedule the Requirements Review!  It is better to postpone the review rather than having the review and then having to pay for a follow-on delta review later.  Nothing is gained by baselining an incomplete or defective set of requirements.

Requirements Review Success Criteria

To successfully baseline your requirements, you need to show:

1. Risk and mitigation strategies have been identified and are acceptable based on technical risk assessments.
2. Technical planning is sufficient to proceed to the product design lifecycle phase.
3. To be determined (TBD) and to be resolved (TBR) items are clearly identified with acceptable plans and schedule  for their disposition.
4. The project has demonstrated compliance with applicable government regulations, requirements, standards, processes, and procedures.
5. The project has demonstrated compliance with applicable organizational requirements, standards, processes, and procedures.  See our blog “Layers of Requirements above the System Layer”
6. The cost and schedule estimates are credible and sufficient resources are available for project formulation.  The project cost estimates have been updated to include verification and system validation activities with a credible margin.
7. The product is defined by the requirements is feasible. A design concept has been identified that is technically feasible. A rough cost estimate is within an acceptable cost range. The product can be delivered within the defined schedule.
8. Major risks have been identified and technically assessed, and viable mitigation strategies have been defined.
9. A preliminary verification and system validation method has been identified for each requirement and approaches have been determined for how requirements will be verified and validated. See our paper “Thinking Ahead to Verification and Validation”.
10. Interfaces with external entities and between major internal elements have been identified.
11. The project uses a sound process for the allocation and control of requirements throughout all levels, and a plan has been defined to complete the requirements definition at lower levels within schedule constraints.
12. Attributes to help implement and manage your requirements have been defined for each requirement.  See our 3-part blog: “Requirement Attributes”
13. The maturity of the requirements definition and associated plans is sufficient to begin design.
14. The requirements defined for the product/system are responsive to the parent requirements and represent achievable capabilities (functional, performance, quality).
15. Software requirements meet the exit criteria defined in the organizations standards, processes, and procedures

Risk Assessment

Are we ready to proceed to the next stage, the Design phase of the project?  Meeting the above criteria does not mitigate all risks.  You can’t assess and mitigate risk unless you have identified the risks associated with your requirements. You can use the following questions to help identify risks.  A ”YES” answer indicates risk.  If too many “yes” answers, the project may need to postpone writing requirements and the team may need to rethink the whole project.  If some “yes” answers but a risk mitigation plan can be formulated to address the issues, then the project can proceed with design.

1. Do we have product boundary questions? 
Is it clear what is in scope and not in scope? Have all the interfaces (product and project) been identified and defined?
2. Have we missed or been unable to obtain a key stakeholder input? 
Missing stakeholder inputs can result in missing requirements.
3. Have we missed a product lifecycle phase? 
Missing lifecycle phase can mean there are stakeholders missed resulting in missing requirements.
4. Are there poorly defined or incomplete interfaces? 
Many product verification issues are a result of missing or undefined interfaces as well as missing interface requirements.
5. Are there assumptions that have not been confirmed with the project or stakeholder personnel? Bad assumptions can lead to requirements that may not be valid.
6. Are there technical issues? 
In order to achieve the desired functionality and performance as stated in the requirements, are the required technologies mature enough?
7. Are there schedule issues (e.g., overly optimistic)? 
It may be possible to meet the requirements, but can it be done within the required schedule?
8. Are there cost issues (e.g., budget too lean)? It may be possible to meet the requirements, but can it be done within the assigned budget?
9. Does the budget and schedule allow for verification and system validation activities? Is there sufficient margin to allow for contingencies (and rework)?
10. Are there any resource issues?
Are the necessary people, facilities, and equipment available to be assigned to this project?
11. Are there too many uncertainties? 
If there are a lot of unanswered questions and missing knowledge, then the requirements may be incomplete and the project is not ready to go forward to design. When there are a lot of TBDs or TBRs, missing other related requirements, or missing attributes, the requirement set is incomplete and may not be ready to be baselined.
12. Is the requirement set subject to change? Indicators include cases where stakeholders do not agree with the requirements, key stakeholders have not reviewed the requirements, there are to many uncertainties as discussed above, or higher level requirements or regulations or standards are in the process of being revised.   If requirements are volatile and subject to change, there is risk to your project.   If stakeholders disagree and do not share a common vision, there can be conflicting requirements.  If this is the case, you may need to go back and rethink the scope.

Making the baseline decision

The outcome of the Requirements Review is a decision to baseline the requirements.  Making this decision is not easy.   To help make this decision see our blog: “How do I know when my requirements are sufficient?”

To help ensure you will deliver a winning product, – products that deliver what is needed, within budget, on time, and with the necessary quality; you need to allocate the time needed to document and baseline your requirements.  Failure to do so is a major reason why projects fail!

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.