You are now ready to start working on the Scope of your project.
The Scope of a project answers the questions "What" will you actually do, and "Where" will you do it. Also, it begins to cover "How" you will do your project by collecting Stakeholder Expectations. There are logical steps toward managing the Scope of your project, and we will dig into those steps on this page.
First a short step back. Your Project Charter should contain a Statement of Work (SOW). This is a narrative description of products, services, or results to be delivered by the project. The SOW tends to be a high level description as is necessary to get the project started. However, "Scope" is defined as the sum of all the products, services and results to be provided as a project. Scope is much more detailed as is necessary to plan and control your project.
So how do we get from Statement of Work (SOW) in the Charter to the Project Scope Statement which you will use to manage the project?
Here is the list of steps. These will be described more fully, below.
1) Collect Stakeholder Requirements
2) Define the Scope in a Scope Statement
3) Create a Work Breakdown Structure
Here are the details.
1) Collect Stakeholder Requirements:
Useful definitions may be found on this page.
In preparing your Stakeholder Register, you already began to collect Stakeholder Expectations and Needs; together called Requirements. Needs apply specifically to the content of the SOW and therefore connect the SOW to the Stakeholders. Here is an example. In a project to build a new Emergency ward for a hospital, one Stakeholder had the Expectation that emergency services would not be interrupted. His Need was that the new ward would have 50 chairs in the Waiting Room. As an Information Technology example, a Stakeholder has the need for on-line monitoring and the expectation that all ordered materials will arrive on time.
As your project's Requirements are collected, they should be entered onto your Stakeholder Register. Click here to see some tools for collecting requirements. For product oriented projects, you may also use a Requirements Traceability Matrix which is a grid that links product requirements from their origin to the deliverables that satisfy them.
At this point you are only collecting requirements. Try not to judge the requirement, or edit it, or prioitrize it more than is necessary for clarity. For more information on collecting requirements click here.
A word of caution! Stakeholders will bring you their perceived requirements. Click to see what that can lead to! For a discussion on perceptions, click here.
2) The next step is to take everything you now know about the 'What' and the 'Where' of your project and define the Scope in a written Project Scope Statement. This statement will consist of several paragraphs that bring together Stakeholder Requirements (Needs and Expectations).
You will want to make the Scope Statement very clear. One of the most common reasons projects fail is lack of clarity regarding expected outcomes. It is crucial that all your Key Stakeholders have a clear, common, and detailed understanding of the Project Scope. This will help you avoid Scope Changes and Scope Creep as your project progresses. Just as important, you want to ensure your Project Scope Statement clearly indicates what is NOT included (what is Excluded). Auxiliary activities like documents, start-ups, testing, training, and clean up might or might not be included in your project.
It is possible some Stakeholders' requirements might be mutually exclusive. In that case, conduct a meeting with the affected Stakeholders to resolve the conflict before moving forward. This link (click here) brings you to helpful techniques for resolving conflict. Scroll down on this page [ Click here ] for other useful tools to reconcile stakeholder requirements.
A very useful tool for demonstrating planned Scope is a Structured Walkthrough (SWT). An SWT is an orderly walk and talk through the Scope using drawings or (better) mock ups) so your Stakeholders can clearly see what is being discussed. This tool provides the opportunity to identify and remedy misunderstandings in a visual way. If you are considering alternate solutions, then SWT's of the alternates will help Stakeholders make a decision on one alternate.
When you have drafted a Scope Statement, get a sign-off from your Key Stakeholders (those in Classification A on your Power-Interest Grid). Don't be surprised if it takes more than one draft before a consensus is reached. This is an important document so it is worth the time to clearly describe what you will do (or get done), and where it will happen.