Project Scope Definition
Project Scope definition
Upon successful completion of this module, you will learn to;
- Appreciate the progressive scope elaboration process
- Learn the tools and techniques used for scope definition
- Appreciate the agile approach to scope development
Effort required – 15 minutes
One of the key characteristics of projects is ‘Progressive elaboration’. Projects are progressively elaborated. When we request for proposal (RFI), the scope definition is at a very low level. The scope clarity increases as the project passes through the various stages. This lesson discusses the steps that will help to define the scope of the project with full coverage.
Recent paradigm shift in scope definition
Traditionally, the project management metrics of time, cost, scope and quality have been the most important factors in defining the success of a project. More recently, practitioners and scholars have determined that project success should also be measured with consideration toward achievement of the project objectives. That means, as a Project Manager, one should be aware and accountable of the implied objectives for which the project was undertaken by the key stakeholders.
As we can infer from the above paragraph, traditionally the role of every project team, headed by a project manager, would be to simply deliver the documented and agreed-upon scope, and the project’s success or failure would be determined by its adherence to, or deviation from, that documented and agreed-upon scope. Now on, it is not only just meeting the documented requirements, but also achievement of the intended business objectives which were used to justify the project.
This calls for aggressive scope exploration, both documented and implied.
At the beginning of new projects there is very little Information available about the project scope. The scope unfolds gradually, as the project progresses.
The following diagram depicts the natural progression of scope as the project progresses from the conceptualization to construction phase:
How to define scope?
Statement of Work (SOW)
Most popularly known as SOW, is a high-level description of the scope of the product or service to be delivered by the project. It is more like a wish list. When me and wife embarked on the project to construct our dream home, our statement of work was like;
“We want to construct our dream home in the place where our ancestors lived. The design of the house must look contemporary in style and at the same time the interior of the house must match with our traditional lifestyle”.
During pre-bid stage, the requirements are in the form of very high-level Statement of Work (SOW) and gets elaborated further as we move on to the subsequent phases of the project.
Plan to collect detailed requirements
First, there is planning for collecting the detailed requirements of the project, which means that identifying the key stakeholders from whom detailed requirements are to be elicited becomes the first step. Second, there is deciding the tools and techniques needed for eliciting the requirements. Commonly used tools include Meetings, Survey and questionnaires. (If one must interview a large group of stakeholders from different geographies, there will be a cost and time associated with this step, which must be factored into the project plan)
Collect the detailed requirements
At this stage, various project documents like the project charter, statement of work (SOW), project management plan, project documents and so on become good reference material to elicit the detailed requirements.
Scanning the environment in which the project will be performed will also reveal the requirements, as will scanning the environment in which the product will eventually operate. For example, constructing a building in an earthquake prone area has specific implied requirements to be met, as does digging for oil in Canada and the Middle East, and so on. For the dream home project, we insisted on two floors and double height to resist the summer heat.
Is this project similar to any of our past projects? If yes, those project documents can be great inputs to scope definition of the new project. For the dream home project, we liked one of the designs showed to us by our architect. We liked only the exterior. We had to change the design of the interior. Still it was better than starting from scratch.
Once we have enough confidence on the completeness of the requirements, it is time to define scope.
A well-defined scope document will state what will be included in the project as well as what will be excluded. Scope consist of both product scope and project scope.
What all should be there in the final product or service? The answer to this question lies in the product scope which is generally depicted in the form of a product breakdown structure (PBS). Here is the product breakdown structure of the dream home project.
This is at a very high level and can be decomposed further. For example, 1.6 Bedrooms can be further broken down into master bedroom and other four bedrooms. So is the case with bathrooms. As we can see, the product breakdown structure provides the breakup of the major deliverables of the product of the project.
Once the scope of the final deliverable is clear, then we focus on the ‘How to build it?’ This is the project scope, generally depicted as the Work Breakdown Structure (WBS) of the project. We always develop the Product Breakdown Structure (PBS) first and then move on to the development of the Work Breakdown Structure (WBS).
Work breakdown structure Superimposes the product breakdown structure with the engineering and management components required to build them. The diagram below shows a partially expanded work breakdown structure of the dream home project.
Work breakdown structures can be a tree structure or a list structure. In the example above, we used the tree structure. In short, whatever consumes time and money must be part of the WBS.
In order to help the actual doer of the work to do it right the first time, we need to provide additional information about the work packages, which are the lowest elements in the WBS. That’s where WBS dictionaries come in, providing additional details like:
- Narration of the work to be performed
- Quality standards to be followed etc.
- The finalized requirements document along with the solution, product breakdown structure and the work breakdown structure become the scope baseline. Once the scope is baselined, for any changes to it one has to follow the change management process of the organization.
- Scope definition is not a one-time activity, it is progressive. It starts with the asset idea and gets elaborated till the end of the project.
- Scope definition consists of requirements collection, analysis, approval and management.
- Identifying the parties from whom we need to collect the requirements is very critical. Collecting requirements from those who do not have the right knowledge or skill is easier, but can be risky, as it opens the door to rework and customer dissatisfaction in the later phases of the project.
- Requirements analysis needs to be done systematically, but is often overlooked. The collated raw requirements are considered as the scope, which is insufficient; the requirements analyst doesn’t always ask the right questions or doesn’t know how to ask them. Here, the 5 Why technique is a very effective tool to elicit correct requirements.
- The Scope Definition phase must be planned, executed, monitored and controlled correctly. It must be made a priority.
- Brainstorming, bench marking, affinity diagrams, value analysis and engineering, quality function deployment (QFD), mind mapping and alternatives analysis are some of the tools that will help during requirements elicitation, analysis and scope definition.
- Very often the customer knows only the problem. The project team/company should first try to understand the problem definition, and then articulate the solution.
- Analysts must not include requirements into the final scope if they are not fit for use. One must educate the customer about the risk.
- Early detection and correction of functional errors are easier to correct
- Once the scope is base lined, it must follow the change management procedure to incorporate further changes.
Project Management Body of Knowledge by PMI, USA