Scope Baseline

When a construction site is being built, the constructor raises a fence on the site defining the boundaries of the construction. This process of building a fence is called scoping. Scope management is the process of defining what work is required and then making sure all of that work – and only that work – is done. Scope management plan should include the detailed process of scope determination, its management, and its control. This needs to be planned in advance. The project manager must seek formal approval on a well-defined and clearly articulated scope. To identify scope, requirements must be gathered from all stakeholders. Gathering requirements from only a few stakeholders or only the sponsor might lead to the incorrect definition of scope.

Large projects require more time, efforts and resources to gather requirements and thus define scope is important. Scope definition helps us to make sure that we are doing all the work but only the work included in the scope management plan. Gold plating a project (adding extras) is not allowed. Changes in scope must take into consideration all the knowledge areas of project management such as time, cost, risk, quality, resources and customer satisfaction. Integrated change management process is required to approve changes to scope of a project. Continuous monitoring of scope is required to determine what is and is not included in the project.

Product Scope

Product Scope is nothing but “What customer wants?” An organization can execute another project to identify a product scope or it could be the part of requirements gathering of your project.

An example of product scope would be: On a project to build a new software application, the product scope is “a new workflow application that fulfills the requirements of our internal and external customers.” To determine if the project successfully achieved the product scope, the resulting application (the new product) is compared to the application requirements, which are recorded in the requirements documentation and the project scope statement for the project.

Project Scope

The project scope is the work the project will do to deliver the product of the project (i.e. the product scope). In the software application development example, the project scope is the work that is to be done to develop the software application. This work includes the planning, coordination, and management activities (such as meetings and reports) that ensure the product scope is achieved. These efforts are a part of the project management plan and are further a part of the scope management plan. At the end of the project or the phase, the completed work is compared against the scope baseline in the project management plan to determine if the scope has been successfully completed.

The planning and definition processes for the scope are:

  • Plan Scope Management; output Scope Management Plan (covered in the Mind Map under “Develop Management Plans”.
  • Collect Requirements; output: requirements documentation + requirements traceability matrix.
  • Define Scope; output: project scope statement.
  • Create WBS; outputs: WBS and WBS Dictionnary.

Collect Requirements

Stakeholders of a project play a very critical role in providing project requirements. Requirements are the need for any project or a product. Requirements should be able to fulfill the stated objectives. Requirements should not be included just because someone wants it. Requirements may be related to Quality, the business process, regulatory requirements, compliance, project management, among others. All of the requirements (including products and process) are taken into consideration by the Collect Requirements Process. The initiating phase involves defining the high-level requirements of the project and product during the project charter phase. The Collect Requirements process goes into the details of seeking additional and more specific inputs on those requirements and any related supposition from all stakeholders. Any miss in gathering these requirements may result in the failure of the project or may result in many changes or may even result in conflicts throughout the project journey. Hence, this process of collect requirements is critical. Identification of project stakeholders is the first step before collecting requirements. You can use a stakeholder register to record this information.

The next step is to collect requirements from stakeholders. Do you think, it will be that easy to collect requirements? For certain projects, there could be multiple hundreds of stakeholders. Likewise, even the methods required for collecting those requirements may be different for different stakeholders. The project manager needs to engage devoted effort to collect all the requirements before work is initiated on the project. If this is not done appropriately, a large number of changes are required on the project leading to high cost and high efforts. Reviewing historical information and lessons learned could be involved in the effort of collecting requirements. The project manager makes a conscious choice to choose the most appropriate technique for the project and the stakeholders. Identification of risks during the risk management process could also use the same techniques of collecting requirements process.

Tools & Techniques.

  • Expert Judgement: 

It is a very common input. It is the input from individuals or groups specialized knowledge or training in:

Business analysis – so they will know how to drill down for business analysis

Requirements elicitation – so they can extract the implied needs from the customer, as well as the stated needs

Requirements analysis – so they can make sense of what they uncover

Requirements documentation – so they can record the list of requirements

Project requirements in previous similar projects – so they can apply a “reasonableness check” to the requirements and perhaps even suggest missed requirements.

Diagramming techniques – so they can present the information in a meaningful way 

Facilitation – so they can assist stakeholders and the team to work together efficiently, and 

Conflict management – so they can help prevent the stakeholders fighting over requirements.

On a medium to large scale project it is extremely unlikely that you will find one individual with all of these skills, so you will need to choose people as required to make sure all your bases are covered.

And a huge tip here. As you proceed through each of these processes and benefit from the lessons learned from previous projects, please make sure that the team records lessons learned from this project, for the benefit of future projects. And the second big tip is — don’t wait until the end of the project to record the lessons learned. Record them as you go because in the end you will have forgotten them or misremembered them, and people with important lessons will have left the team.

  • Data Gathering:

It is a bunch of data gathering Tools & Techniques. These include:

Brainstorming: It is a way of extracting information from a group by using techniques to generate and filter ideas. For example, on several projects, I have used De Bono’s “thinking hats” system.

Interviews: This is usually one or more interviews talking directly with stakeholders, individually, and asking questions from a script. As well as extracting information, this technique is also useful for detecting and eliminating misinformation. And when used correctly — especially one-on-one – it helps reduce fear in the subject, especially when the information is confidential or potentially harmful. This way you can elicit information that would not be revealed in an open forum.

Focus Group: Unlike an interview, a focus group is intended to get people talking together and interacting. And in this case, there should be a moderator or facilitator, who just sets the ground rules and keeps the conversion headed in the right direction. This tool works best when all the people in the group are familiar with the proposed product, service, or result, and its business need, along with subject matter experts.

Questionnaires and Surveys: Questionnaires and surveys are of use when you need input from a large number of people, and or they are physically far apart, and it would be too inefficient to interview them or bring them together for workshops. Sometimes the results from questionnaires and surveys can be further refined in by interviews of small groups.

Benchmarking: The final data gathering is benchmarking. Whenever you see the work “benchmarking”, always think of comparing similar things. In this case, you can compare the required products, services or results, with other similar offerings in the marketplace – or even within the same organization — to see if the requirements could be improved.

  • Data Analysis:

The next input is Data analysis, and in particular, Document analysis.

This is used to analyze existing documents to find clues about the requirements. 

By this stage, we should have a lot of data. Some useful, and some not. We need to sort it out, filter it in some way and end up with a definitive list. 

  • Decision making:

The three techniques suggested for this are voting, Autocratic decision making and Multicriteria decision analysis.

Autocratic decision making: Autocratic decision making means that one person makes all the decisions.

Multicriteria decision analysis: Multicriteria decision analysis is an attempt to simplify the process, where various criteria are listed and ranked in a matrix.

Voting: This is a common method for allowing a group to make the decisions, even if there is a level of disagreement within the group.

And within this technique there are 3 common versions:

Unanimity: This means that the motion is passed only if everyone in the group is in agreement.

Majority: This means that the option is selected if more than 50% of the members of the group agree. It helps to a group with an uneven number of members, so avoid a tie. Or a senior member may be appointed to have the “casting vote” where there is a 50-50 split.

Plurality: This means that the option is selected if the largest group is in agreement, even if the largest group is 50% or less. This doesn’t make sense if you have just 2 options unless voters are allowed to abstain. An example of the plurality is where you have 10 voters and 3 options. 4 vote for option 1, 3 for option 2, and 3 for option 3. Option 1 would be chosen because 4 is the largest group, but it is less than a majority (which would require 6 votes or more).

  • Data representation:

Two suggested possibilities are:

Affinity diagrams: Which enable similar ideas to be clustered into groups, and 

Mind mapping: Which brings clarity to similarities and differences in proposed ideas.

  • Interpersonal and team skills, including:

Nominal group technique: It is a structured form of brainstorming, which enables suggestions to be ranked.

Observation/conversation: This is also known as “job shadowing” because basically, it is similar to spying on people as they do their work. It’s a useful technique when people are either unwilling or unable to describe their duties. Again it’s easy to understand, but again it is hard to see how this fits in with Requirements Gathering.

Facilitation: “Facilitation is used with focused sessions that bring key stakeholders together to define product requirements. Workshops can be used to quickly define cross-functional requirements and reconcile stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.” (PMBoK Guide p145) Please check out page 145 because it gives 3 examples of facilitation: “Joint application design/development, Quality function deployment, and User Stories. These are well explained in the PMBOK Guide, so I can’t really add anything to them, however, they appear quite frequently in the exam.

  • Context diagrams:

A context diagram is a diagrammatic representation of ahigh-level product scope, within the business context. It shows how “actors”, which means people and other systems interact with the product.

  • Prototypes:

A prototype was originally a small-scale working model of the final product, and is obviously vastly cheaper to produce, and it enables a number of problems to be detected early in the project, to enable the product to be redesigned. It’s also a great opportunity for stakeholders to get a “taste” of the final product, and might stimulate more ideas.

Nowadays a computer generated 3D model can remove the need for building a model, or of course if you need a physical model, it can often be 3D printed.

Project Scope Statement

Project scope statement is primarily an output of Define Scope Process. Development of project scope statement is a time-consuming activity and may require multiple stakeholder participation including experts from outside the organization. The project manager avoids including the following two things while defining the project scope statement:

The scope that is not approved: Project manager should identify areas where people requested scope but it was not approved to be included in the project.

The scope that is not needed: Project manager should clarify areas where the scope could easily be misunderstood. Scope baseline is a combination of project scope statement and WBS and WBS dictionary. Scope baseline is a part of the project management plan.

Project Scope statement can include:

  • Product Scope

  • Project Scope

  • Deliverables

  • Acceptance criteria of the product

  • Out of scope activities

  • Constraints and assumptions

Create Work Breakdown Structure (WBS)

All projects (large and small) require a WBS. It is a required element in project management. A WBS shows the complete scope of the project broken down into manageable deliverables. A project will take longer than the scheduled time if a WBS is not available. Project managers may also miss out on certain important activities without the WBS. Thus, without a WBS, the project can be negatively impacted. Most project managers make a list of activities as actionable. This may result in overlooking some deliverables. Additionally, a list can be cumbersome and does not allow the project manager to clearly break down a large project into small appropriate pieces. People do not get an understanding of the project by looking at the list. A list is created by one individual. Looking at the list, people do not know who has created the list. These are some of the major drawbacks of creating a list of activities. A WBS on the other hand has enormous advantages. Using a WBS, no actionable is missed. A project manager can easily break down the work into work packages, and the WBS shows how the work packages are drilled down. A WBS is created with input from stakeholders and the team. This automatically helps in seeking their buy-in and thus leads an improvement in their performance. Creation of WBS is a process that allows the team to walk through the project in their minds and thus improve the project plan.

Thus, the execution of the project is much easier and less risky. The involvement of people increase and all feel that the project is more achievable. A WBS shows a complete hierarchy of the project, making it easier to see how one deliverable relates to another. This is a sample WBS. This WBS is on Development of a Clean, sustainable and complete lighting system for use in developing nations. Most commonly, the project title goes at the top of the WBS. The first level is typically the same as the project lifecycle (for example, for the project WBS described here, Method for integrating energy, develop rugged and robust casing, develop a long life, high capacity storage system, develop a light system, develop an inexpensive product and do not reinvent the basic components). The later levels break the project into smaller pieces. Such decomposition continues until the project manager reaches the level appropriate to manage the project. It’s important to note that the WBS is NOT a corporate organizational structure though it looks like one. It has a different function that allows you to break down a seemingly overwhelming project into pieces you can plan, organize, manage and control. The creation of WBS is a top-down effort. It involves decomposing the deliverables, and the work required to produce them, into smaller pieces called work packages.

Following are the rules to be followed for creating a WBS:

  • A team is involved in creating a WBS

  • The first level is completed before proceeding any further in creating the WBS

  • Each level of WBS is a sub-level (a smaller piece) of the level above 

  • The entire project can be understood by looking at all the levels of a WBS

  • WBS does not include deliverables other than the project

A deliverable is considered to be a work package when:

  • It can be estimated (both realistically and confidently)

  • It can be completed quickly

  • It can be completed without interruption (without the need for more information)

  • Maybe outsourced or contracted out

WBS levels are numbered at a later stage. Work packages are distinguished in the WBS using the identification numbers assigned after completion of the WBS. This is an example of using a numbering system for WBS. Conerning the term “control account”: for some projects, the costs are not managed at a work package level. Instead, they are managed at a higher level in WBS, called the control account. As the planning process progresses, the team breaks down the work packages from the WBS into activities that are required to produce the work packages. Note that this further breakdown of WBS into an activity list is done as a part of the time management process of Define Activities. The team uses the project scope statement, WBS, and the WBS dictionary to help define which activities are required to produce the deliverables. The foundation of any project is “WBS”. After the creation of WBS, everything that occurs in planning is related to WBS. WBS Dictionary For each work package, a WBS dictionary provides a description of work to be done. Benefits of WBS dictionary include avoiding scope creep and providing a clear description of the deliverable. The output of Create WBS process is a WBS dictionary.

A WBS dictionary can have multiple uses: It informs when work package is going to start, thus acting as a work authorization system Schedule milestone, acceptance criteria and other information about the work package are included in a WBS dictionary. It can be used as a control mechanism of what work is done. The stakeholders have an increased understanding of the efforts involved in a work package with a WBS dictionary Scope Baseline The final, approved version of certain pieces of a project management plan is termed as a baseline. In scope management, baselines are the WBS, WBS dictionary and the scope statement. All of these need to be approved by the management and stakeholders before beginning the work. These baselines help in comparing the progress of the project to where the baseline says it should be. For any deviations from the scope baseline, a change request is needed. This change request goes through performing Integrated Change Control and if approved, gets added to the scope statement, WBS and WBS dictionary. Any other components or documents involved also need to be updated. Meeting the requirements and the scope baseline are the measures of success of a project.