Project Scope Management

  • 27 April, 2022

This article is part of a series that discusses the ten (10) KNOWLEDGE AREAS of the PMBOK, with a practical approach and genuine business examples.

  1. Project Risk Management
    1. Project Risk Management: Part 1
    2. Project Risk Management: Part 2
  2. Project Schedule Management
  3. Project Scope Management
  4. Project Integration Management
  5. Project Cost Management
  6. Project Quality Management
  7. Project Resource Management
  8. Project Communications Management
  9. Project Procurement Management
  10. Project Stakeholder Management

Project Scope Management

In business, scope is, simply put, your client's wishes. Project Scope deals with stakeholders' expectations. Of course, we can only satisfy client and stakeholders if we also satisfy the rules of the game. If we are delivering products, we should abide by safety product standards, or if we provide services, we should abide by local, state, and federal regulations (defined in the PMBOK as EEF1). We should also follow guidelines that are aligned with our own organization values and practices (defined in the PMBOK as OPA2).

1EEF, ENTERPRISE ENVIRONMENTAL FACTORS:

  • External: government regulations, market and political conditions, industry standards, legal framework.
  • Internal: organization structure and culture, resources.

2 OPA, Organizational Process Assets:

  • Processes, policies, and procedures: internal guidelines of the company.
  • Corporate knowledge base: historical information, lessons learned, best-known ways

1. SCOPE CREEP

To learn about scope management, we can first discover what happens if there is none. Have you ever heard of scope creep? This term is used for scope that is added that was not considered as part of the original agreement, and that did not go through the proper scope change channels. Scope creep is the direct result of poor scope management. For example, if you end up adding features to a product to satisfy the client, it will have cost you resources; it will either have involved time, materials, or it could have affected the schedule. Things that are not planned are not easily controlled, so we may have sacrificed quality. The question is, why do we end up adding scope other than what was originally agreed? That is why scope management is so important.

Scope creep is certain to occur when any of the following happen:

  • Initial requirements are poorly defined, or worse, not defined at all.
  • False expectations (for example, promising an impossible speedy delivery date).
  • Lack of planning.
  • Informal communication channels (for example, a casual phone call with the client, without a written follow up).
  • Poor communication plan (for example, if many project team members have direct communication with the client and some do phone calls, some do emails, some do meetings...)
  • Project manager or team members skipping change control processes.

It is also true that scope creep is expected; projects change. What must improve is how we approach change.

2. Plan Scope Management

2.1 Scope Statement. Can you explain what the project is about in simple terms? The first step is to provide a scope statement, sometimes just simply known as a Scope of Work. This is usually in a narrative form and provided in a document so that it can be referenced as the project progresses or so that it can be provided to stakeholders. It should be simple in nature, but it should be thorough. Ask yourself if the narrative describes the following questions. We will use the replacement of a fire alarm system project as an example:

  • Why the work is being done, i.e., replacing a fire alarm system because the old one is obsolete.
  • The type of work, i.e., design and installation.
  • Who will do the work, i.e., The Company, no subcontractors.
  • The limits of the project, i.e., shall be turnover to the client by May 15th.
  • The area of operation, i.e., one (1) building, seven (7) floors.
  • If it will happen in phases, i.e., the first three floors will be commissioned, then the other floors.
  • The expected outcome, i.e., a certificate of occupancy from the authority having jurisdiction.
  • Major milestones, i.e., design, installation, commissioning, and final acceptance testing.
  • General assumptions, i.e., the building will be occupied while work is being done.
  • And exclusions, i.e., no civil work.

A good project manager will reach out to stakeholders to request sign-off of the scope statement. All should be onboard.

2.2 Requirements sources. Where are we supposed to look for requirements? This could be part of the same document that holds the scope statement. It should include any place that has project requirements:

  • Request for proposal, specifications, and/or scope of work document from client.
  • Local or state regulations (i.e., Building Code for the fire alarm example).
  • Company guidelines for this type of work.

2.3 Deliverables. The deliverables should be clear, transparent, and very well known by all agreeing parties. For example: shop drawings, product data sheets and calculations in design, and a fire alarm system that is code compliant and approved by the fire marshal.

2.4 Change Control. How will change be managed in the project? There should be a communication plan as part of the project determining how people interact within the project, including how to approach the change control board (which could be one for the company, one for the project, or it could be the project manager). Anyways, the key to change control is documentation and proactive communication. If everyone agrees to the scope statement, then it is a good start to begin monitoring how scope changes.

3. Collect requirements

If you have defined your project requirement sources, then this is an easy step. The most important thing here is to be THOROUGH. A requirements compliance matrix comes in very handy at this stage: a template where all requirements and any criteria that influences the project can be gathered in. Be sure to include all specifications and wishes from the client, and any other statements that will influence the final product or service.

Requirement compilance matrix entry example

Figure 1. Requirements compliance matrix entry example

The person who prepares the document is the originator. It is always good practice to have another set of eyes check the work, which is the role of the checker. Then the project manager should be the one approving the set of requirements. The same person can play separate roles, depending on the project.

4. Define Scope

At this stage, with all criteria in one place, we can verify our original scope of work statement. You can already see if there is reason for change: There could be reasons for scope additions that would require to undergo the change control process, even before formally "starting" the project. Additionally, there are things that we cannot or should not provide, but that were part of the specifications or client wishes. We should provide a non-compliance reason and expectations should be managed accordingly.

Now we are ready to create what is called an approved scope baseline. From here on, scope progress and deliverables will be measured against the approved scope baseline.

This is also the perfect opportunity to start thinking about project team specific tasks, but first, we need to create a WBS.

5. Create WBS

A WBS, Work Breakdown Structure, is one of the most important tools that we have in project management, yet it is usually neglected or not well understood. Think about dividing all your project scope in work packets or buckets. For example, let us go back to the Fire Alarm System project. There are many activities involved in your company providing this product. Are battery calculations part of the same work as installing a smoke detector? This is where a WBS comes in handy. We could start by diving the project in Engineering, Installation and Commissioning work buckets. This could be enough, it all depends on how complex the project is, but we can certainly keep subdividing and categorizing. Let us see an example:

Create WBS

The usefulness of dividing your work in buckets or distinct realms is that now it is easy to locate specific tasks, and to assign responsible parties. For example, in Engineering, at the 15%, you know that you expect to produce a sequence of operations and a coversheet. These two elements can become specific tasks: create coversheet of the project, publish a sequence of operations of the system. These specific tasks can be assigned to a project team member, i.e., the project designer.

6. Validate Scope

The requirements compliance matrix should be a living document, meaning, a requirements compliance matrix is prepared at the beginning of the project, but as the project progresses, it should be part of the scope management plan and quality control plan to check the product or deliverables against what is required by the client and by your organization.

Every time a deliverable is produced, it should be reviewed against the requirements and scope baseline before submitting to the client. Are we satisfying what we promised? You will start realizing that delivering products as agreed on time and on budget seems simple, but it is a challenge.

Enroll in our PMP Certification Training Course today to gain a solid understanding of project scope management.


7. Control Scope

This is part of the monitoring and control phase of all knowledge areas. Things change, and that is not intrinsically bad, but change does require that we have good practices in place that include traceability and communication. If scope changes, then we need to initiate a process where new scope is approved, and we should update our scope baseline with the additions of modifications.

In our fire alarm system example, if the client decides to change all fire alarm devices from red color to white, then we need to check what is in our scope baseline: what came from the specifications and documents provided by the client (the client's wishes) what is allowed by regulations and, finally, what we promised. If the client specifications call for red devices, then we know this is a change originated by the client. If regulations allow the use of white devices, then you can initiate a change control process that would notify the client of this additional scope that might entail, depending on the progress of the project: returning red devices, acquiring new white devices, and all impacts associated with cost of procurement, installation, and schedule delays - the project baseline might be affected. If you need to stick with the original project deadline, then you might need expedited costs and additional resources to comply.

Life will certainly be easier if you had good scope management and if you had an approved written scope baseline to begin with.
About the Author: Alejandro Uribe

Alejandro Uribe got his strong process approach from Industrial Engineering (B.A.), his vocation in Construction Management (M.S. from NYU), and his real passion in Fire Protection (P.E.), where he continues to provide complex solutions to Fortune 500 Companies and critical federal projects. Alejandro is currently an engineering manager at M.C. Dean, a prime contractor, where is the supervisor and technical lead for a team of over 12 engineers, and is responsible for creating and maintaining processes, including knowledge management and project management foundations

Blogs you might also like