Reynalaine V.

Bornasal
III-AMA

1. Planning Scope management

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:

▪ Description of the deliverables

▪ End result or product
▪ Justification for the project
▪ Should attempt to answer seven questions: Who? What? When? Where? Why? How?
and How Many?
As you can see, it should be more than a broad outline of the project. It should contain
enough information to assist people in the interpretation of future scope changes. It should
also ensure that all stakeholders are familiar with the scope.

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.

Work Breakdown Structure

The Work Breakdown Structure (WBS) is the list of tasks which compose the project. It
seems simple, but it’s the foundation upon which most project management tools are based,
thus it is critically important if the project is to be adequately planned and controlled. In fact, it
is so important that the Project Management Institute has published a separate manual as part
of the standard, called the Practice Standard for Work Breakdown Structures.

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.

In some industries a scope change is used as an opportunity to make more profit.

Even for reputable consultants and contractors, a project is underbid knowing that the terms of
reference are poor and lucrative scope changes are inevitable. This usually comes from poor
planning or loopholes in agreements.

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.

2. Project Manager plays the lead role

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

• Integration management: Developing a project charter

• Stakeholder management: Identifying stakeholders

Planning phase

• Integration management: Developing a project management plan

• Scope management: Defining and managing scope, creating a work breakdown
structure (WBS), and requirements gathering
• Time management: Planning, defining, and developing schedules, activities, estimating
resources and activity durations
• Costs management: Planning and estimating costs, and determining budgets
• Quality management: Planning and identifying quality requirements
• Human Resource management: Planning and identifying human resource needs
• Communications management: Planning communications
• Risk management: Planning for and identifying potential risks, performing qualitative
and quantitative risk analysis, and planning risk mitigation strategies
• Procurement management: Planning for and identifying required procurements
Stakeholder management: Planning for stakeholder expectations

Executing

• Integration management: Directing managing all work

for the project
• Quality management: Performing all aspects of
managing quality
• Human resource management: Selecting, developing, and
managing the project team
 • Communications management: Managing all aspects of
communications
• Procurement management: Take action on securing
necessary procurements
• Stakeholder management: Managing all stakeholder
expectations

Monitoring and controlling

• 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

Integration management: Closing all phases of the project

Procurement management: Closing all project procurements

3. Defining Scope Management

Whatisprojectscopemanagement?
Project scope management is a process that helps in determining and documenting the list of all
the project goals, tasks, deliverables, deadlines, and budget as a part of the planning process.
In project management, it is common for a big project to have modifications along the way. With
the scope in the project management defined right in the beginning, it becomes much easier for
teams to manage and make the required changes.

What is Project Scope?

Project scope is the work required to output a project’s deliverable. Change happens,
and project scope management includes the process to manage scope changes and make
sure the project will still come in on time and within budget. Scope is often defined by a work
breakdown structure, and changes should take place only through formal change control
procedures.

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.

Project Scope Management consists of three processes namely:

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.

1. Product Scope: Product scope can be defined as the features or characteristics of a

product regardless of the design, function or parts, and the critical point is that product
scope refers to the actual tangible product that is finally produced.
2. Project Scope: In contrast to product scope, project scope focuses on the various
steps taken to deliver a product. Project scope can include, things like assembly lines,
budgets, staff training, and supply chains and personnel allocations.

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.

Scope should be defined to an extent that provides a good indication of when

scope creep is
happening. Also, consider external processes or system interfaces that are affected by the
project, organizational or geographic boundaries, or process workflow between business units.

A good project scope statement contains:

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.
How to Write a Scope Statement?

The PMBOK identifies four tools and techniques to writing a scope statement:

1. Expert Judgment. It is indeed a huge advantage to have resident experts to consult

when defining a project scope. Subject matter experts can identify the expected pitfalls
and potential issues that can be defined at the project planning stage, and their input is
invaluable.
2. Product Analysis. Focus on the deliverables. What do they look like? How
long/high/wide/strong/capable must they be? What functions will they have, and how
must they perform under various conditions?
3. Alternatives Generation. Determining alternative products and services can be
extremely eye opening. This can identify different approaches to performing the work,
which can be instrumental in defining the scope.
4. Facilitated Workshops. When you have many grey project boundaries (or worse,
conflicting ones), consulting the project stakeholders and putting them together in one
room or conference call can be essential to defining the project scope.

4. Creating Work Breakdown Structure

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.

The Work Breakdown Structure (WBS) is an important element of the Scope Management
process, and the PMI® places great emphasis on this aspect—many project managers often
skip this step, which leads to inaccurate planning. The WBS provides the project manager and
the team with the opportunity to break down a high-level scope statement into smaller,
manageable units of work, called work packages. The resulting WBS should provide a complete
list of all work packages required to complete the project. The table below shows the Inputs,
Tools and Techniques, and Outputs of the Create Work Breakdown Structure process.
Developing a Work Breakdown Structure

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 6 steps to the Work Breakdown Structure in detail

1) List of all tasks

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.

2) The tasks clusters

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.

3) Define work packages

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.

4) Assignment of responsibilities to the work packages

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.

5) Define start and end dates of work packages

Once the responsibilities have been determined, the work packages are timed by
defining the start and end dates. It is important to consider where the priorities lie and which
work packages are interdependent. Which activities must take place one after the other, which
can be parallelized and which are perhaps not so important and can therefore be postponed?
6) Documentation of the created Work Breakdown Structure and assignment of unique
work package numbers

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 completed Work Breakdown Structure

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.

5. Validating and controlling scope

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.
How Should It Look?

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.

Who Accepted Them?

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.

What if they are not Accepted?

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

Stakeholder Management and Project Communications Management knowledge areas, but

clearly if these two knowledge areas are not sufficiently addressed, the Validate Scope process
is impacted.

If the schedule, cost, or other project plans are impacted, the project will require changes. This
is part of the Project Integration Management knowledge area.

Validate vs. Verify

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.

In plain terms, this means that before

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.

Scope creep can result from:

1.Poorly documented scope

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.

2.Poor requirements definition

If the project’s requirements are not sufficiently defined the project team can be susceptible to
“gold plating,” i.e. increasing the quality level above that envisioned by the project plan and
adding the corresponding cost and time to the project.

3.Poor communication between stakeholders

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.

4.Underestimating project work

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.

How to Control Scope Change

It can be prudent to establish acceptable parameters for scope changes with the project
sponsor at the project planning stage. Once this is established, the scope statement should be
inspected and verified weekly by the project manager.

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.

The other three variables in these equations are:

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)

AC = Actual Cost. The actual cost of each task.

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)

Validate Scope (projectengineer.net)