Scope Management
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.
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 incorrect definition of scope.
Large projects require more time, effort and resources to gather requirements and thus defining the scope is important.
Scope definition helps us 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 be taken 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. Integrated Change Management includes updating of Change Request Form by Change Originator and also tracking the change on Change Control Register.
Change Request Form
Change Control Register
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 fulfils 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 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.
SCOPE MANAGEMENT PLAN
Scope management plan contains – scope planning, execution and control. Scope management is created as a part of Project Management Planning process and it is not included as a separate scope management process. Scope management plan tries to answer:
- How will the scope be achieved by the project?
- The tools required to accomplish the project scope
- The enterprise environmental factors required for accomplishing project scope
- The organizational process assets required
- How the scope is managed and controlled throughout the project?
Organizations should have templates, forms, or standards for scope management. These are critical for any project. Scope management plan may have topics that can be standardized for the organization, however, every scope management plan is unique. The project manager uses the scope management plan as a baseline to guide and measure the project until closing. As discussed earlier, scope management plan is a part of project management plan.
Like other knowledge areas, a scope management plan may not be developed at one time. However, it could be developed in stages, or iterated during project planning. The project manager first determines how to define the scope. Once the project is completely planned, the project manager has enough information to decide how the scope will be executed and controlled. These decisions then become part of the scope management plan. The project manager can use another aspect of iteration. In this iteration, the later parts of project planning, such as the Human Resources planning process, can add a new scope to the process, thereby changing the scope management plan.
A project manager is required to have a good understanding of the project scope to create a scope management plan. It is a major mistake to work on a project before the product and project scope are identified. Creating a scope management plan is a required part of project management.
SCOPE MANAGEMENT PROCESS
Scope management process can be described as:
- Determine Requirements: The project charter describes project’s business case. The project manager should ensure that all requirements support the project’s business case.
- Needs of the stakeholders should be taken into consideration while defining product and project scope.
- Work Breakdown Structure (WBS) to be used to break the scope into smaller and more manageable pieces.
- Scope management process should be created from the customer’s viewpoint.
- Scope performance is to be measured and adjusted as needed during the course of the project.
Saying “NO” could become inevitable to avoid allowing unnecessary activities on the project because unnecessary scope adds cost, time and efforts on the project which is not required.
COLLECT REQUIREMENTS
Stakeholders of a project play a very critical role in providing project requirements. Requirements are the need of 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 project and the stakeholders. Identification of risks during the risk management process could also use the same techniques of collecting requirements process.
REVIEWING HISTORICAL RECORDS
Historical records and lessons learned are very critical for the project team that helps in gaining understanding of what were the requirements on similar projects and thus, help identify relevant processes. It also helps a new person understand expectations from the respective teams. Lessons learned from other projects may highlight common mistakes done by other project managers in defining the area of scope to ensure such requirements are not missed on current projects.
INTERVIEWING
This technique may also be called as “expert interviewing”. Various methods of interviews could be conducted by the project manager with project stakeholders to identify their requirements for the product or the process. The interviews can be conducted as one-on-one, emails, phone calls, group setting, letters or any other method.
FOCUS GROUP
In a focus group, the moderator or the facilitator plays a key role to gather inputs and thoughts that helps get the opinions and requirements for the product or an aspect of the project from a specific set of stakeholders or subject matter experts.
FACILITATED WORKSHOPS
The process of bringing together the individuals / stakeholders of different perspectives to define the requirements of the product or service is called as facilitated workshops.
BRAINSTORMING
The method of brainstorming strives for “group think”. It really does not just mean a meeting with people to discuss ideas or seeking individual thoughts. Brainstorming helps produce large number of ideas in a short period of time. A participant of the brainstorming session can share an idea of determining the scope. That idea generates an idea from another participant which leads to yet another idea, and so on.
The participants of a brainstorming session can vary. Individuals from different functions, backgrounds and perspectives can benefit the brainstorming session in a great way. The participants need not be just the individuals from the organization, they could be from outside the organization as well.
NOMINAL GROUP TECHNIQUE
This technique is done in continuation to the brainstorming meeting where the ranking of the most powerful ideas is done by the meeting participants.
DELPHI TECHNIQUE
This is a consensus technique with a difference. In this technique, the participants do not meet each other. A request for information is sent to the experts and their participation details are kept anonymous. Their responses are compiled, and the results are sent to back to them for further review until a final consensus is reached.
MIND MAPS
A mind map diagram is used to generate ideas and classify them into logical groups. It is a tool used to visually organize the information. Many ideas are connected directly to the central core idea, and other ideas branch out from these.
AFFINITY DIAGRAMS
The ideas generated from any other requirements gathering techniques are grouped by similarities in this technique. A title is given to each group of requirements.
Affinity Diagram Example
QUESTIONNAIRES AND SURVEYS
A questionnaire is designed to seek responses from respondents. The benefit of questionnaires and surveys is that it can be sent out to a large group.
OBSERVATIONS
Observation technique involves watching a potential user of a product at work.
PROTOTYPES
A model of the proposed product is a prototype. Stakeholders are presented the prototype to seek feedback. Multiple versions of prototype may be created till all the requirements are captured, the model is finalized and approved.
GROUP DECISION-MAKING
There are multiple ways to make decisions in a group. Requesting inputs from all stakeholders may result is generating multiple ideas. These ideas may lead to confusion and may also lead to conflicts. They need to be reviewed, analyzed, approved or rejected and prioritized before recording them in project documents. A unanimous agreement on a requirement from the group makes the decision making easy. A single person making a decision for the entire group is known as dictatorship technique. This has an advantage of quick decision making, however, also has a disadvantage of other stakeholders not agreeing in decision making done by the individual.
In group decision-making there are many conflicting opinions. In these situations, groups may take a majority approach. In this technique, the group takes a decision which is supported by more than half of the members. In case there is no majority support, the group may go with the decision of largest number of supporters. This is known as plurality technique. There is another technique known as the consensus approach. In this technique, the decision is made which is acceptable for the group. In case if there are certain members of the group who did not support the decision, they will willingly accept that most members of the group support.
REQUIREMENTS DOCUMENTATION
One’s the team collect all requirements, it is time to document them. The documentation should be clear and unambiguous. This documentation is an output of Collect Requirements Process.
If the representation of information is not done appropriately, the collected requirements may be misunderstood. Hence, it is advisable to NOT assume that the collected requirements will meet the objectives. Thus, it is important to ask the stakeholders if the collected requirements would be meeting the stated objectives. This helps ensure that the right requirements are collected and end output will be acceptable.
BALANCING STAKEHOLDER REQUIREMENTS
Balancing stakeholder requirements involve prioritizing requirements. It also involves resolving any conflicts between them. It is an important aspect of Collect Requirements Process. The project manager has to ensure that the requirements are met within the stated project objectives. If the requirements cannot be met, then the project manager needs to identify options to adjust the competing demands of scope, time, cost, quality, resources, risk, and customer satisfaction.
Balancing stakeholder requirements is not limited to the Collect Requirements Process, it goes beyond this. At a later stage in the project, it is identified that certain stakeholder requirements do not match those of the project or those of other stakeholders. In this situation, a conflict may arise between stakeholders. Thus, the project manager may need to balance the requirements against the interests of the project and resolve any conflicts.
Clear project objectives are a prerequisite for balancing stakeholder requirements. Another prerequisite is to identify and prioritize ALL the requirements from ALL of the stakeholders during Collect Requirements Process. If these prerequisites are not met, balancing stakeholder requirements is an impossible task.
RESOLVING COMPETING REQUIREMENTS
Each department of the organization has their own interest in the project. For example, the risk team may slow down the pace of the project if they identify any risk and the operations team would have an interest of completing the project faster. Having an amicable solution for both departments is crucial.
These issues are complex and an intervention from management is required to resolve them. While resolving competing requirements, the project manager should identify which of the competing requirements resonate with the project business case. A thorough review of project charter, the scope statement and constraints will also be important factors in this regard.
Any project request that does not relate to the objectives of the project should be rejected. If the requirement is related to the reasons the project was initiated but it does not fall within the project charter, this request should also be rejected. Change requests related to the project charter need to be discussed with project sponsor for approval. When considering constraints, if the most important constraint is cost, then any requirements that would increase the cost would not likely to be accepted. Those that contain the cost (without serious impact on other project constraints) would more likely be accepted. Requests that do not fall within these guidelines can become part of a future project instead.
REQUIREMENTS MANAGEMENT PLAN
Requirements Management Plan is an output of Collect Requirements process. The plan answers the questions such as:
- Which are the methods used to identify requirements?
- What analysis is required for identified requirements?
- How will the requirements be prioritize?
- How would the requirements be managed?
- How would the requirements be tracked?
- What is required out of requirements traceability matrix?
REQUIREMENTS TRACEABILITY MATRIX
In large projects, if the requirements are not documented well, there is likelihood that they may be lost. Determining requirements can involve one requirement leading to more refined requirements and clarifications. This can make it difficult for the project manager and the project team to remember where the requirements came from. Objectives of the project may not be met if these reasons for requirements are missed. Requirements Traceability Matrix is another output of Collect Requirements Process. The matrix is used throughout the project in analyzing proposed changes to product or project scope. The matrix helps in linking requirements to the objectives and/or other requirements to ensure the strategic goals are accomplished.
Requirements Traceability Matrix
DEFINE SCOPE
The product and project scope is determined using inputs from the requirements document (created in Collect Requirements Process), project charter, additional information about project risks, assumptions, constraints, among others. This process is concerned with what is included and is not included in the project and its deliverables.
Project planning is not a one-time process. A project cannot be planned right at the start and kept as it is. Planning is an iterative process. Project Manager continues to follow the Project Management Planning process when the requirements have been determined. This information is used to identify the schedule and the budget. This schedule and budget may meet the expectations of the management or sponsor. If they don’t, the project manager needs to review all the constraints of the project and needs to maintain equilibrium of the requirements (scope) against the budget and schedule. The project manager needs to create options for meeting the scope, time, and cost objectives of the project and help management make a decision. Compressing the schedule, identifying alternative ways to perform work on the project, or adjusting budget or the scope are some of the tasks to be completed by project manager while creating these options. A realistic schedule and budget that can achieve project’s scope is the result of this exercise.
PRODUCT ANALYSIS
Analysis of the objectives and description of the product as stated by the customer and the sponsor is the purpose of Product Analysis. The output of this analysis is identification of tangible deliverables.
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 avoid including the following two things while defining the project scope statement:
- 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.
- 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 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.
List of Activities as Actionables Example
Most project managers make a list of activities as actionables. 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.
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 considerable 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)
- May be 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. For some projects, the costs are not managed at a work package level. Instead, they are managed at 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 creation of WBS, everything that occurs in planning is related to WBS. The project has a hierarchy and WBS is a graphical picture of that hierarchy. WBS identifies all the deliverables to be completed. The activity is not a part of the project if it is not in the WBS. The project is built on the foundation of a WBS. WBS is extremely important on a project. It should exist for every project. It ensures that the project team is thinking through all aspects of the project. Additionally, it can be reused for other projects too and it does NOT show dependencies.
The project manager decomposes the project using a WBS. The term “deconstruction” and “decomposition” are the same. This diagram indicates the relationship of the components of a WBS.
Relationship between WBS Components
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 clear description of the deliverable. 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
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 perform 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.
VERIFY SCOPE
The process of keeping the project on-track in terms of the approved scope by frequent discussions between customer or sponsor and seeking their acceptance on completed deliverables.
The inputs to Verify scope are:
- Inputs from Perform Quality Control process – validated deliverables
- Scope statement, WBS and WBS dictionary
- Requirements Traceability Matrix
- Requirements documentation
The outputs of Verify scope are:
- Accepted deliverables
- Change requests
- Updates to the project documents
Verify scope process can be done at the end of each process phase. It can also be done as a part of monitoring and controlling throughout the project.
Verify scope process provides a formal acceptance by the customer of interim deliverables whereas Close project or phase is to get final acceptance or sign-off from the customer for the project or phase as a whole.
CONTROL SCOPE
Measuring the scope performance (for project and/or product) and managing scope baseline changes are two major deliverables of Control Scope process. A project manager needs to control scope frequently to ensure that the scope is being completed as per plan. The project needs to be properly managed using the Control Scope process.
Two components required for Control Scope Process are Scope Baseline from project management plan and current completed work on the project. Requirements documentation and Requirements traceability matrix can also be helpful in Control Scope process. A project manager identifies if there are any deviations against the baseline. A corrective or preventive action is recommended in case deviations exist. Change request originates in case any changes are required. The project manager needs to identify and perform Integrated Change Control process and subsequently update the required documents.
Control Scope process believes in a proactive approach. A project manager’s primary job is to control the project to meet the baselines as per the project management plan. Changing scope without following the Change Management process is not advisable.
IO4PM™
