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. 

Collect requirements  

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.   

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 this blog post my focus is to explain how to define the project scope, hence, we will limit our discussions to scope definition and the role of WBS in scope definition.  Please stay tuned for future posts on how to develop a detailed WBS.) 

 WBS dictionary  

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 
• Successors 
• Predecessors 
• 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.  

For convenience, here is a summary of the key points I elucidated in this post:  

• 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, benchmarking, 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 baselined, it must follow the change management procedure to incorporate further changes.  

I hope this was helpful in laying out the groundwork of how to build an effective project scope, and why it matters. I will be addressing the question of How to Build an effective WBS in future posts. Do let me know in the comments if you have any questions or suggestions. Thank You! 

References:
Project Management Body of Knowledge by PMI, USA