A major issue that contributes to cancelled projects is a failure to establish a shared vision of the final product at the beginning of the project. The reason for a new product or upgrade must be clearly understood before writing requirements, or divergent requirements will be written and important requirements will be missed. This vision must be provided to designers and developers before development to ensure what they develop is in agreement with the shared vision.

Creating a shared vision is a basic concept in product development that is often neglected. There is an old saying that expresses this: “Failure to plan, is a plan to fail.”

The scope of a product includes the vision along with the need to develop, upgrade, or procure a product or service; the goals and objectives of the customer and your company; information about the customers, users, and other stakeholders; and how the product will be developed or purchased, tested, deployed, used, maintained, and disposed at the end of its useful life. The scope must unequivocally define the product boundaries. A product with no boundaries will diverge, or as Yogi Berra said: “If you don’t know where you’re going, you’ll probably end up someplace else.”

Involving key stakeholders in scope definition will avoid battles that result from differing visions and different interpretations of what should be included or excluded in the product. Issues can be identified and resolved before investing scarce resources into the requirements writing effort. Spending time to resolve issues, get questions answered, reduce debates, and confirm assumptions will result in reducing the time to write requirements, as well as speeding up the requirements review and baseline process.

For more details on defining scope read our paper “Scope Magic“.

Scope Creep

One of the most frequent reasons for project failure is “scope creep”. Too often, the scope of the product development project changes in midstream as stakeholders think of new features to add.  One reason given for project cost or schedule overruns is a change in the agreed-to product scope without a corresponding change in cost or schedule. Change is inevitable. However, if new features are requested then the scope, which includes the cost and schedule, must be adjusted accordingly. Change is not free. Key stakeholders are often ignored until far too late in the process. By involving key stakeholders in product scope development and baseline, you will be able to minimize change. The ultimate payoff is reduced rework, reduced cost overruns, and reduced schedule slips.

Baselining Your Scope

Once product scope has been defined, it must be agreed to by all key stakeholders and formally baselined and controlled. Baselining your scope before writing your requirements puts your scope under configuration control and the resulting configuration control process. Any changes proposed to your product have to first go to the configuration control board, evaluated for feasibility and impacts to cost and schedule, and formally approved.

Baselining your scope and getting agreement from all key stakeholders before your team writes requirements and begins design ensures that everyone will clearly understand the system boundaries.  Having a baselined Scope keeps requirements writers from diverging, reduces requirements inconsistencies, and keeps the big picture in view. An agreed-to product scope contributes to better requirements resulting in a design that meets stakeholder expectations, and reduces requirements discrepancies found in testing.

The Scope Review

The Scope Review is the major lifecycle review where the scope is baselined.  It may be called different names like “Product Concept Review”, “System Concept Review”, 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 Scope 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 purpose of the Scope Review is to validate that the scope clearly reflects the needs and expectations of the stakeholders.  The Scope Review helps to:

1. Align stakeholders to a common vision
2. Determine validity of the scope
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. Ensure scope represents a feasible approach to meeting the need , goals, and objectives
8. Obtain concurrence of stakeholders

Scope Review Success Criteria

To successfully baseline your scope, you need to show:

1. The problem has been defined and the associated need for the product has been clearly identified.
2. Project and product goals and objectives are clearly defined and stated and are unambiguous and internally consistent.
3. Project and product boundaries have been clearly defined along with all interactions and interfaces with other organizations and systems.
4. The selected product lifecycle concepts satisfactorily meet the stakeholder expectations within the define drivers and constraints.
5. Alternative product lifecycle concepts have adequately considered the use of existing assets or products that could satisfy the product need, goals, and objectives.
6. The concept evaluation criteria to be used in candidate product concepts evaluation have been identified and prioritized.
7. The product is feasible. A 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. The cost and schedule estimates are credible and sufficient resources are available for project formulation.
9. The project has demonstrated compliance with applicable organizational requirements, standards, processes, and procedures.
10. The project has demonstrated compliance with applicable government regulations, requirements, standards, processes, and procedures.
11. To be determined (TBD) and to be resolved (TBR) items are clearly identified with acceptable plans and schedule  for their disposition.
12. Technical planning is sufficient to proceed to the next product lifecycle phase.
13. Risk and mitigation strategies have been identified and are acceptable based on technical risk assessments.
14. Software components meet the exit criteria defined in the organizations standards, processes, and procedures.

Risk Assessment

Are we ready to proceed to the next stage?  Meeting the above criteria is not black and white.  There will always be unknowns and some degree of risk.  You can’t assess and mitigate risk unless you have identified the risks associated with the defined Scope. 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 writing requirements.

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?
2. Have we missed or been unable to obtain a key stakeholder input? 
Missing stakeholder inputs can result in a failure to align stakeholders to a common vision and can result in missing requirements.
3. Have we missed a product lifecycle phase? 
Missing lifecycle phase can mean there are stakeholders missed as well as interfaces resulting in missing requirements.
4. Are there poorly defined or incomplete interfaces? 
Many product verification issues are a result of missing or undefined interfaces. Missing interfaces can also result in product boundary issues.
5. Are there areas of strong disagreement? If yes, then the stakeholders do not share a common vision.  Without a common vision, there can be conflicting requirements.
6. Are there too many unknowns? 
There are issues and associated risks that need to be resolved before a feasible concept can be identified and requirements written.
7. Are there assumptions that have not been confirmed with the project or stakeholder personnel? Unconfirmed or bad assumptions can lead to a concept that isn’t really valid and associated requirements may not be valid.
8. Are there technical issues? 
In order to achieve the desired functionality and performance, are the required technologies mature enough?
9. Are there schedule issues (e.g., overly optimistic)? 
It may be possible to develop the product, but can it be done within the required schedule?
10. Are there cost issues (e.g., budget too lean)? It may be possible to develop the product, but can it be done within the assigned budget?
11. Are there any resource issues?
 Are the necessary people, facilities, and equipment available to be assigned to this project?
12. Are there too many uncertainties and unknowns? 
If there are a lot of unanswered questions and missing knowledge, then the scope is incomplete and the project is not ready to go forward.

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 scope.  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.