Chapter5|Project Planning: Scope & WBS Marchewka

THE SCOPE MANAGEMENT PLAN.

As project managers we often find that we suddenly have so many people who want to help us succeed in our
project. They may show an interest, have many ideas for improvements and what they consider minor changes
that can be made to improve the project. This is actually one of the greatest dangers to a project. Remember
the triple constraint?

Scope is a key constraint and if it changes it has a big impact on the project. As project managers we have to
manage the project scope on a constant basis. You will have stakeholders, managers, users, team members
and so many others all wanting you to make seemingly minor changes to your project on almost a daily basis.
They don't realize that the minor changes they want are actually scope changes to the project and will affect
the schedule, cost or quality of the project. The best way to manage these requests is by having w well thought
out and written Scope Management Plan.

A project’s scope defines all the work, activities, and deliverables that the project team must provide in order
for the project to achieve its MOV. The scope management plan provides a valuable set of stages for
managing the project scope.

Diagram of the Scope Management Plan:

Step 1: Plan Scope Management

The Scope Management Plan defines and documents how the project and product scope will be defined,
verified and changed if necessary. It is an important part of the Scope Management Plan because it defines
how the organization will manage the scope of a project and defines various aspects of the Scope Management
Plan. Some of the information that should be contained in the approach is:
1. Who has scope management responsibility and authority (i.e. project manager or Another)
2. How the scope of the project is defined
3. How and when the project scope is measured and verified
4. How changes in scope are conducted
5. Who is responsible for final acceptance of project scope (i.e. sponsor or Another)

Roles and responsibilities should be defined in all component plans but this is especially true in the Scope
Management Plan. This is because project scope is easy to lose track of if not managed properly and things
like scope creep may occur and throw the project completely off course. If roles and responsibilities are clearly
defined, the project team and stakeholders are able to understand their part of ensuring that project scope is
defined and remains on track throughout the project.

1|P a g e
Chapter5|Project Planning: Scope & WBS Marchewka

Step 2: Collect Requirements

This is an iterative stage in the Project Lifecycle. It focuses on engaging customers/users/other stakeholders
in order to define their needs. It entails planning how the project team will work with the customer, client or
users to define the scope of the project. There is no one-size-fits-all method to collecting project requirements
from stakeholders. Some will be more forthcoming, specific, and opinionated, while others will prefer to take
a back seat and leave it up to “the experts” aka your team.

Before you start speaking to the stakeholders, think about:

₋ Requirements you already have from the brief or statement of work (SOW)
₋ Information you need to move forward
₋ How the information you collect will help your team and the project
₋ Whether there’s any confusion about established project requirements
₋ Project goals and what they might look like in reality
₋ Who to speak to get the right answers ie key stakeholders / lead users etc.

Once you know what information you need to move forward, you can start collecting requirements from key
stakeholders. The approach taken when collecting the project requirements may be based upon the
SDLC approach adopted by the PM. Some common methods include interviews; workshops;
brainstorming; focus groups; surveys; and observation. The more conversations you have with stakeholders,
the deeper you will dig into what their expectations of success are. Documenting requirements in a way that
is accessible to everyone and easy to track and manage is key.

Format stakeholder responses in a readable, shareable format that everyone on the team can access at any time.
You can keep referring back to these requirements throughout the project to ensure you are on track or to
change any fluid requirements.

Step 3: Define Scope

The PM and the project team try to gain enough information about the project and the product to develop a
detailed plan. The first stage is to define the scope boundary i.e. establishing what is and what is not, part of
the project work to be completed by the project team. The statement of work (SOW) is then generated; this
is a narrative description of the product, service or system, setting out the business needs, specific requirements
and the expectations for the project.

Developing a scope statement is a more detailed version of the scope boundary that documents the project
sponsor’s needs and expectations and sets out the project deliverables i.e. tangible and verifiable work
product.

₋ Project orientated scope – supported by the project lifecycle (PLC) and includes the business case;
project plan etc. Part of the overall project schedule and budget and their role is to ensure that the project
processes are completed so that the product/system achieved the project’s MOV and objectives. They
provide tangible evidence to the project’s progress. Also it provides a baseline in terms of performance
and quality control to work from as they require approval before the next stage begins. Deliverable
structure chart (DSC) may be used to create project-orientated deliverables.

2|P a g e
Chapter5|Project Planning: Scope & WBS Marchewka

Example of a Deliverable Structure Chart

₋ Product orientated scope – focuses on identifying the features and functionality of the product/system
to be developed. A useful tool for refining the scope boundary and defining what the system must do is
a modelling tool called a context level, data flow diagram (DFD). A DFD is a process model that depicts
a high-level representation of the system. It shows the main processes (i.e., a circle or rounded rectangle
that represents the system as a whole) and all the inflows and outflows of data and information between
the system and its external entities.

Example of a Data Flow Diagram (DFD

Another tool that may be used to refine the scope boundary and define what the systems must do is a
Use case diagram.

3|P a g e
Chapter5|Project Planning: Scope & WBS Marchewka

Example of a Use Case Diagram

Step 4: Create the WBS

The WBS breaks project deliverables down into more manageable pieces which allows a better understand of
the work to be performed. It helps to develop the project plan and links the project’s scope to the schedule
and budget. The WBS provides a framework for developing a tactical plan to structure the project work. It
involves breaking the work up into smaller more manageable units of work called work packages. It also
includes project milestones i.e. a significant event that provides evidence that a deliverable has been
completed or that a phase is formally over e.g. formal acceptance of an interface by sponsor. The intent here
is that once all work packages have been completed, the scope of the project is satisfied. That is why the WBS
is such a key component of the scope management plan.

Since project scope can become complex and difficult to understand, the WBS is a tool used to ensure
simplicity and understanding throughout the project lifecycle. The WBS may be included as part of the Scope
Management Plan or as an Appendix to the plan. Once the project deliverables and activities have been
defined the next step in developing the project plan ie the schedule and budget is calculated to estimate each
activity’s duration and assign resources to each activity.

Step 5: Validate Scope

Scope verification is the process the project team uses to verify that the project deliverables meet the
requirements established in the scope baseline. It is important as it ensure that there is a formal acceptance
process in place for these deliverables. This is an extremely important part of scope management. Scope
verification must be done throughout the project’s lifecycle, not simply once at the end of the project. By

4|P a g e
Chapter5|Project Planning: Scope & WBS Marchewka

verifying scope in this manner, the project team can help avoid added costs and schedule delays associated
with performing work that does not contribute to meeting the scope of the project

This process includes:

1. Verification of MOV
2. Documentation of all deliverables
3. Specification of quality standards
4. Identification of milestones
5. Review and acceptance

Step 6: Control Scope

Scope Control is the process of continually measuring the project’s progress against the scope baseline and
determining any variances between the two. It also acting on those variances when necessary. This stage is
also concerned with managing actual changes to the project’s scope as and when they occur to ensure than
any changes to the project’s scope will be beneficial. It is about understanding and managing your triple
constraint.

Scope creep is possibly the greatest hazard to any project’s success. This is where uncontrolled scope changes
are proposed and added to the project and work begins to spiral out of control. Scope Control is a necessary
part of the Scope Management Plan because well-planned scope control practices, along with a well-defined
scope baseline, can prevent scope creep from occurring and improve the likelihood of a successful
project. Scope control is also concerned with:

 Scope grope – inability to define project scope

 Scope leap – a fundamental and significant change in the project scope
 Scope creep – adding various bells and whistles to the project scope

Scope change control procedures should be in place and help the PM keep in control of the project and help
the project team stay focused on the MOV of the project. The different procedures that can be in place to make
changes to the scope include the scope change request form and the scope change request log.

5|P a g e