A common problem we see on new projects is people jump into writing requirements without first answering the question “Why are we doing what we are doing?”  Many challenged projects (e.g., over budget, behind schedule, not meeting quality standards) can trace their difficulties to the very beginning of the project where there was a failure to define the problem that the project was expected to solve or the opportunity the project was to exploit.

When a new project begins, it is imperative that the project manager and the entire project team have a clear understanding of the problem/opportunity.  In other words, the “Why are we doing what we are doing?” question needs to be answered and clearly communicated.

So where to start?

You start with the stakeholders.  Identify the key stakeholders who are involved in the problem or opportunity and solicit their input to understand their expectations.  Determine who is most affected by or has a stake in the project?  Who are the project champions?  Who are the customers?  Who are the other stakeholders that are affected by the project (positively or negatively)?  Who are the stakeholders that are responsible for one of the life-cycle support services (testing, manufacturing, transportation, maintenance, disposal, etc.)?

Focus on the Problem

Once you have the stakeholders identified, you can then focus on the problem or opportunity…the “Why are we doing what we are doing?”

Work with your stakeholders, especially the project champion, and develop a clear statement of the problem/opportunity.  Moreover, determine how each stakeholder is impacted by the problem or who will benefit by pursuing the opportunity.  By doing this, you are defining the current “as is” state.  You will also obtain an understanding of the stakeholders expectations of the desired future “to be” state.  From this you can then define the “gap” between the “as is” and “to be” states.  With the gaps identified, you can then work with the stakeholders to define what they would view as an acceptable solution to the problem/threat or a realization of the opportunity as compared to the current “as is” state.  What benefits or return on investment do they expect as a result of the project? As part of this effort you also seek to understand how the stakeholders define success.

Understanding the problem/opportunity and knowing the stakeholder expectations for the outcome is key to setting your project up for success.  Failing to do so, well…you probably already know what happens.

See also my blog: What problem are you trying to solve?

Define the Need statement

Armed with the knowledge and understanding of “Why are we doing what we are doing?” you are ready to develop the “Need” statement.    The Need statement, derived from the problem assessment or opportunity analysis, will provide a clear vision for your team and the stakeholders and is a good way to ensure your project stays on track.

A word of caution – the Need for a project is not “to develop such-and-such product” or “deliver XYZ solution”.  Example…WRONG:  “…to implement a new sales order application”, “combine employee training record databases”, or “develop a new scientific instrument”.  Rather, the Need statement is intended to communicate the WHY behind a project or product.  Example…RIGHT:  “…increase order-to-cash processing efficiency,” “provide a more effective way to manage employee training records,” or “…provide better results while reducing the complexity and cost of conducting experiments”.

Once the Need statement is agreed upon, put it in writing and communicate it to everyone on your team and to all the stakeholders.  With the problem understood and a clear Need statement defined you can now complete the definition of the other components of Scope.  These components include goals and objectives, drivers and constraints, external interfaces, assumptions, dependencies, limitations and exclusions, and risks.  Scope also includes using scenarios, stories, use cases to define at least one feasible system concept that will meet the Need, goals, and objectives within the defined drivers and constraints and limitations and exclusions.

The following papers available on our web site provide more detail on scope definition:

• Delivering Quality Products That Meet Customer Expectations (.pdf 57kB)
• Scope Magic (.pdf 265kB)

We also have another blog on developing scope: Baseline Your Scope Before Writing Requirements

Note: this blog was also the subject of our quarterly newsletter.  Click here to read the newsletter if you haven’t seen it.

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