Professional Documents
Culture Documents
Planning Scope Management
Planning Scope Management
Bornasal
III-AMA
This planning step involves the creation of a scope management plan, which defines
the scope of the project and how it will be managed and controlled The PMBOK
describes it like this:
The Project Management Body of Knowledge (PMBOK) dictates that a scope management plan
be adopted as part of the overall project management plan. It can be a standalone document or
a section within the overall plan.
The four primary parts of a scope management plan that are produced during Scope
Management are:
1. Requirements
2. Scope Statement
3. Work Breakdown Structure
4. WBS Dictionary
Requirements
In this step, the requirements that the project must meet are assembled and
documented. The project team and stakeholders need to have a list of the requirements, from
all stakeholders, that the project must meet.
It tends to be highly specific to each industry. In the software development industry for
example, requirements are a major part of the process because there are so many of them
and they change constantly. Tracking them is so laborious that the use of a Requirements
Traceability Matrix is recommended. However, in the engineering industry the requirements
usually consist of meeting the design/construction standards of a few different organizations. A
simple list of the requirements is sufficient, just to make sure the project team is familiar with
them.
Scope Statement
This written statement defines the boundaries of the project. It contains the following
items:
There is no standard format, and long paragraphs and point form are often used together
in the same scope statement. It can also be formal or informal; the choice is up to the project
manager.
WBS Dictionary
The WBS is usually displayed in graphical form. As such, there is limited data that can be
displayed for each item. The so called “WBS dictionary” expands on each item.
1. Account code
2. Responsible organization
3. Quality requirements
4. Technical references
5. Acceptance criteria
6. Contracts and agreements
7. Milestone dates
8. Cost estimates
As is the case with the WBS, the last two items are technically part of other knowledge areas
but displaying them directly in a WBS is helpful and a widely adopted practice.
Terms of Reference
The official project scope statement is produced by the project manager and approved
by the project sponsor. Scope statements that predate the project, or are otherwise produced
outside the project, are not official project scope statements.
Often consultants and contractors are required to bid on a document which describes the scope
of the project. This statement is often called a “Terms of Reference” or a “statement of work.”
It is important not to confuse this with a scope statement. In fact, they can and often do contain
major oversights and irregularities from the scope as intended by the owner organization.
Scope Changes
As a general rule, unplanned changes to project scope should be minimized. That
being said, it is a frequent occurrence that a scope change makes sense. For example, the
addition of certain tasks now can save money later.
The further into a project, the greater the size of the scope changes will be. The size
and cost of rework will be greater and the many changes to work already completed will
require an incrementally greater effort.
Project managers should learn to develop strong business cases for scope changes.
Stakeholders will demand the appropriate analysis before they agree to it. The following tools
will assist in building a business case for scope changes:
Net Present Value analysis, to demonstrate long term value (life cycle vs. one time cost).
Value engineering, to investigate the underlying drivers of design features, so the design
can be enhanced.
Project managers play the lead role in planning, executing, monitoring, controlling and closing
projects. They are accountable for the entire project scope, project team, resources, and the
success or failure of the project. The project manager plays a primary role in the project, and is
responsible for its successful completion. The manager’s job is to ensure that the project
proceeds within the specified time frame and under the established budget, while achieving its
objectives. Project managers make sure that projects are given sufficient resources, while
managing relationships with contributors and stakeholders.
Project manager responsibilities
A project manager, with the help of their team, is charged with multiple responsibilities that span
the five project phases of a project life cycle (initiating, planning, executing, monitoring and
closing) below. The project management phases intersect with 10 knowledge areas. The
knowledge areas include integration, scope, time, cost, quality, human resources,
communication, risk procurement and stakeholder management.
Initiating phase
Planning phase
Executing
• Integration management: Monitoring and controlling the project work and managing any
necessary changes
• Scope management: Validating and controlling the scope of the project
• Time management: Controlling the scope of the project
• Costs management: Controlling project costs
• Quality management: Controlling the quality of deliverables
• Communications management: Controlling all team and stakeholder communications
• Procurement management: Controlling procurements
• Stakeholder management: Controlling stakeholder engagements
Closing
Project Scope is the work that needs to be accomplished to deliver a product, service,
or result with the specified features and functions. Scope refers to the detailed set of
deliverables or elements of a project; these deliverables are derived from a project's
requirements.
1. Planning: The process of getting an overview and defining the work that needs to be
done to achieve the deliverables is called Planning.
2. Controlling: The process of documenting, tracking, focusing on scope
disruption and also continually approving and disapproving the project changes through
controlling and monitoring process is called controlling.
3. Closing: The process that includes an examination of the project deliverables and an
assessment of the outcomes of the project against the original plan is the primary
function of Closing.
As projects are taken up to deliver a product, it is highly impossible to achieve the desired
objective of the project, if the project and product scope are not adequately explained. The two
most widely used terms in Project Management are Project Scope and Product Scope.
Define Scope
Scope is one of the major components of project management planning. The project
scope defines the boundaries of the project, that is, what is included and what is not.
Scope is also one of the primary areas of project distress. Project sponsors and
executives assume the scope broadly includes everything that is reasonable to produce the
deliverables, but project managers want to account for every resource and assume a scope
change when there are small overruns. When the parties do not want to confront the issues
regarding the project boundaries at the outset, it is a formula for problems.
The PMBOK defines scope as the process of developing a detailed description of the
project and product. This process is part of the planning process group, and the result is a
project scope statement.
Scope Statement
The length of the scope statement has no strict guideline. I believe it should be long
enough to limit the risk of scope change as much as possible, to a reasonable limit. Although
you can’t define the scope perfectly, when all stakeholders should have a good idea of the
project’s boundaries the scope statement is detailed enough.
1. Scope description
2. Deliverable(s) 3.Acceptance criteria
4. Scope exculsions.
5. Constraints.
6. Assumptions.
Scope Description
The scope statement must include a detailed description of the product, service, or result. This
statement is critical to project success and must describe the project in sufficient detail to allow
all stakeholders to draw clear boundaries around the project.
The primary work of the project is generally obvious and does not need to be specified in great
detail. For example, the scope statement for a subdivision development does not need to
spend time outlining the technical details of site grading, sewer installation and road paving.
This is the natural tendency, but it is better to focus on the boundaries of the project, such as
how far the grading will extend, who will determine the sewer sizes, expected environmental
monitoring, and the like. Constraints and assumptions make fantastic parts of a scope
statement, because they reduce project risk.
Deliverables
Deliverables include everything the project produces for external consumption, such as interim
reports, test results, and design details. They can also include internal products, but the
project scope statement should list the items that the project will produce for all stakeholders.
Sometimes the deliverables are not known or not well defined at the outset, but the obvious,
non-negotiable ones should be specified in the scope statement to make it clear what the
project is producing.
Acceptance Criteria
The scope statement should identify the criteria for acceptance of the project. Often there is
testing required to determine completeness, which can be written into the scope statement, or
a completion certificate can be issued. These are integral to the project and if not defined
explicitly with the scope, it can lead to problems.
If the organization has a single final authority, it might be prudent to state their name, timeline
for acceptance, and other criteria such as site visits, funding sign-offs, etc.
Scope Exclusions
It is a good idea to specifically exclude items that are not part of the project’s scope when they
are open to interpretation. In our subdivision development example, final utility hookups might
not have performed until well after the project is complete, but a landowner who is affected by
the utilities might not be aware of this. Thus, specifically excluding items can make the
difference between successful and unsuccessful projects, even if it isn’t intuitive when
brainstorming the complete project scope.
Constraints
All projects work within constraints, and stakeholders might not be aware of them. By
listing the constraints explicitly, the stakeholders can understand what has been assumed and
this can result in a listening ear when problems arise.
For example, a renovation project that will release fumes which might concern the
neighbors might plan for a fan and piping system to send the fumes a sufficient distance away.
It might be easy to say in the scope statement that the fan will send the fumes away, but if it
goes a bit further and describes the constraints, i.e. how far the residences are away, how
many windows there are, and how easily the fumes might travel, the stakeholders who read
the scope statement might understand if it ever becomes difficult to contain the fumes.
Assumptions
Similar to constraints, the assumptions provide background information that will allow
for stakeholders to understand when problems arise. Assumptions often fly under the radar,
particularly for experienced professionals. In our renovation project example, the project
manager will have to assume a certain size fan. If the fumes begin to leak
out of the building and get to the neighboring properties, problems could result. Stating the
assumption that a certain fan size will be sufficient would reduce project risk.
Scope Statements Reduce Risk
Scope statements are essentially exercises in risk reduction. It is important that the
boundaries of the project be defined in sufficient detail to reduce the risk of scope changes
throughout the project. If it is not possible to define certain areas of the project scope, the
uncertainties should be stated and contingencies included in the cost and/or schedule.
The PMBOK identifies four tools and techniques to writing a scope statement:
A work breakdown structure (WBS) is a document that breaks down all the work which needs to be
done in the project and then assigns all the tasks to the team members. It lists the deliverables that
need to be completed and their respective deadlines as well. You can use project management
software for this step of the process to assign and prioritize tasks which will make it easier to track
the entire progress of the project and avoid any unnecessary bottlenecks.
Ideally, the Work Breakdown Structure is drawn upin the form of a workshop with the
participation of a well-chosen group of participants during the project start phase. In complex
projects with many participants, a small number of relevant employees are selected. In order to
avoid lengthy and inefficient discussions, the number of participants should not exceed eight to
ten.
The first step in creating a Work Breakdown Structure is a complete list of all tasksto be
performed within the project in the form of work packages. This should not be done by one
person alone (e.g. the project manager) in a quiet room, but in a team. In practice, the
brainstorming or mind mapping method is suitable for this purpose.
Defined tasks are clustered according to subject areas or time schedule. The best
method for sorting depends on the project content and must be defined on a case-by-case
basis.
Following clustering, the identified tasks are summarized in work packages. From the
outset, it should be clear which granularity you want to use in order not to get lost in details
that have not been lost in this meta-plan.
If the work packages are defined in the form of headings and in their place in the hierarchy, it’s
time to get down to business: Who does what? The assignment of responsibilities to the work
packages takes place in the team with the technical experts. Each person in charge must make
a commitment to his or her task. And above all, they must have the necessary time and know-
how. Otherwise, the nomination of another employee must be considered.
The last step is the documentation of the Work Breakdown Structurecreated. In the course of
this, each subtask also receives a coding – the work package number. This ensures that there
is a fixed place in the Work Breakdown Structure and that the work packages are clearly
identified.
There are many possibilities for mapping. Whether as an Excel list, as a beautifully prepared
graphical chart or as a simple post-it image on a whiteboard – everyone can decide for
themselves on the most suitable presentation method. The necessity of maintenance, which is
necessary in every project, should not be ignored.
Tip: Every revision of the Work Breakdown Structure must be versioned in order to avoid the
haunting of several different project plans from the outset.
The finished Work Breakdown Structure is then stored in a central location and
distributed to the project team members. Across-check with the project goals is helpful for
quality assurance of the content of the project structure plan. Are all goals achieved when all
work packages have been completed? If so, the claim to completeness is given. A subsequent
inclusion of work packages is of course always possible, but care should be taken right from
the start not to overlook anything.
Validate Scope
Validating the scope refers to formalizing the acceptance of project deliverables. It refers to the
acceptance of the deliverables once they are delivered, not the common misconception of
acceptance of what the deliverables will be (which falls under Define Scope within the Planning
process group). In contrast, Validate Scope falls within the Monitoring and Controlling process
group.
It is remarkably easy to spend countless hours, weeks, or months completing a project only to
have a stakeholder at the project sponsor level decide that something should have been done
differently or additional work should be done. Sometimes that can even happen weeks or
months down the road. This is a surprisingly common scenario, and to avoid it the project
management body of knowledge includes the Validate Scope process.
It is irrelevant what format the scope validation is in, or how long it is, or how it looks. The
important criteria are whether the project deliverables are accepted, who accepted them, and
under what conditions, so that the project can move on or close without fear of cost and
schedule overruns when stakeholders dust off their inbox. As a minimum, an email saying the
deliverable is accepted is usually satisfactory, as long as it comes from the right person within
the organization who has no potential to be overruled.
During the stakeholder analysis within the planning phase, each stakeholder should have been
identified as requiring approval or disapproval of the deliverables. Their concerns should also
have been identified. Thus, upon submission of the project deliverables the project manager
must re-visit this list to ensure all the approvals are obtained and project criteria met. A
reasonable review period is normally required, and follow up is often necessary to ensure the
project can proceed without taking on too much risk from previous phases.
The project sponsor is a special stakeholder. It is important that the project sponsor approve
and “sign off” on project deliverables. Letting project sponsors avoid decisions for extended
periods of time presents a major risk to the project, especially since humans tend to delay
approval (and communication) on things they are not completely satisfied with.
Quite often stakeholders will require changes, or worse yet they do not accept the deliverable
outright and send the project back to the drawing board.
This is an unfortunate situation. To avoid it, the project manager should be aware of the
stakeholders and manage their expectations throughout the project. Communication is
essential. At the project outset the stakeholders should each communicate their requirements
and each should receive regular updates throughout the project. This falls under the Project
In the PMBOK, the Control Quality process outputs “verified deliverables,” which become an
input to Validate Scope. Thus, verified deliverables refers to products that meet the
requirements, and validated deliverables refers to those that are accepted by the customer.
submission of any deliverable, you perform internal quality checks to determine if the product
meets the requirements. This is called quality control. Validate Scope, on the other hand,
refers to the acceptance of the deliverable by the customer.
Control Scope
Scope is one of the main sources of project issues. Improper definition and control of what work
is, and is not, part of the project can result in huge project management headaches later on. In
the Project Management Body of Knowledge, scope control is a major part of the Monitoring
and Controlling process group.
Scope Creep
When tasks get added to the project in an ad hoc fashion without the proper adjustments to
schedule, cost, or resources, the result is called scope creep. It often seems like small tasks
can be absorbed by a large project, but collectively they become one of the biggest reasons for
project failure, and project managers identify this as one of their biggest project management
challenges. Over time scope creep grows like a cancer that, if unchecked, can consume the
project and doom it to failure.
If the scope statement is insufficiently detailed, it will not be clear to the project team (or outside
individuals) what work is or is not included within the project. Worse, other individuals that are
not stakeholders in the project decide to use the people or resources, or other projects that have
budget/schedule issues feed off the project through time sheet and expense exaggerations.
A common problem is that stakeholder’s requirements are in conflict with one another and the
project manager does not actively manage each stakeholder’s expectations. For example, the
project sponsor for a hydroelectric dam prefers to keep the project cost finite but the
environmental regulators require more mitigation than expected. Most (if not all) projects have
“opposing” stakeholders that, if not actively managed, will result in scope creep.
Most projects err on the low side when estimating schedule, cost, and resources (due to
competing for the work or satisfying a client, etc.), but then err on the high side when making
decisions regarding the completion of deliverables (to create the highest quality product). Not
allocating enough time, cost, or resources can result in scope creep. If the error is large there
will be a clear need to deal with the consequences, but often small variances are not addressed.
It is very easy to assume another task will be completed early and cover the variance, but this is
very seldom the case. If this strategy is adopted, it needs to be actively managed to ensure
another task actually does finish ahead of schedule.
5. External factors
The organization perfoming the project can experience minor shifts in business strategy. The
project acceptance criteria can be tweeked in ways that seem insignificant to an external party.
Technology can change the project techniques and processes. These and many more issues
can affect projects negatively and produce scope creep.
Scope Change
In general, changes in scope during project execution should be avoided. However, in the real
world scope change is a reality that is difficult to eliminate altogether. For complex engineering
projects it is impossible to predict every design issue at the outset. Inevitably many different
things come up in which a small additional upfront cost can reduce the project budget later on,
and it would be shortsighted to avoid the investigation of those issues.
For these reasons, scope change is a fact of life on megaprojects. The project sponsor /
funding authority must recognize and be sympathetic to the many issues involved. In this case
it is advisable for the project team to ensure a sufficient contingency within each task (or the
entire project) which is dependent on the level of estimating that has been done.
For small projects, however, it is desirable to eliminate, or at least minimize, scope changes
during project execution.
The PMBOK advises the use of variance analysis as a Tool and Technique of Scope
Control. This means that at any given time, the project manager should know two things:
Schedule variance (SV). The monetary value that represents how far ahead/behind schedule
the project is. SV = EV – PV.
Cost variance (CV). The monetary value that represents how far above/below budget the
project is. CV = EV – AC.
EV = Earned Value. The relative completion of each task (EV = % complete x Task budget)
PV = Planned Value. The planned completion of each task (PV = expected % complete based
on task start and end dates x Task budget)
The two variances can be expressed in percentages, which give you a better idea of how big
the variance is relative to the overall size of the project.
Schedule Performance Index (SPI): The ratio of how much has been completed versus how
much should have been completed by now. SPI = SV / EV.
Cost Performance Index (CPI): The ratio of how much the project should have cost versus
how much it actually has. CPI = EV / PV.
Each of these factors need to be calculated on a task by task basis and summed to determine
the overall project result.
It is advisable that the project team knows these values as well, since they tend to be in the best
position to make up any differences.
References:
https://www.cio.com/article/3224865/what-is-a-project-manager-the-lead-role-for-project-success
https://kissflow.com/project/project-scope-management/
https://www.simplilearn.com/project-scope-management-importance-rar89-article
Control Scope (projectengineer.net)