How to Manage Scope of a Project: The Scope

Management Knowledge Area

Steve’s team is building a Hotel Management software.

Maggie submitted her software program that took care of guest registration when
they arrive at the reception.

Beth from the testing team took it up for testing and rejected the whole delivery.
Reason?

Maggie did not take care of the functionality that arriving guest who is a ‘Club
member’ had a different rate card to be applied.

“Different rate card? Where is this requirement written?” Maggie said in disbelief.
“I don’t know where is it written, but it was mentioned by someone during the

Requirement Clarification meeting with customer last month”, was Beth’s reply.
“If it is not written in the Use case,” said Maggie, “it doesn’t get into the code”.
“Hey, Special Guests use case captures user registration but I am not sure if it talks
about the rate card”, said Anil, a fellow developer.
“Then it is not part of the scope” Maggie said.
Beth shook her head.
So did Steve, the project manager, realizing that he had a problem on his hands.
Requirements were not documented and detailed properly, in spite of him conducting
regular Requirement Clarification meetings with the customer.

To manage scope, project manager needs to think about project activities required to
ensure that the project includes all the work required, and only the work required, to
complete the project successfully.

“only the work required” – is very important. In my own experience, we had to pay
dearly for over enthusiasm shown by developer (in one of the instances, I being the
one) by adding functionality that was ‘cool’ but was not documented in requirements.
Problems such as Gold plating and Scope creep in such cases can hurt team’s
schedule, productivity, and quality quite badly.
Why does this happen?

And more importantly how to make sure things like this will not happen on your
project?

This is what the processes in Scope management knowledge area address. Let us
look at them very briefly.
 Collecting Stakeholder Requirements
Three out of five research findings have reasons related to requirements –

 Unclear goals and objectives that change during the project (Coverdale Organization
research)
 Incomplete requirements (Chaos Report)
 Poor articulation of user requirements (OASIG Study)
Sample these findings from some of other sources –

 Failure to adequately identify, document and track requirements

 Poor or No Requirements
 Unclear goals and objectives
 Loose definition of project scope and management
 Vague requirements
They all indicate the all-important step in ensuring success of a project – collecting
the rightrequirements.
Note – A sample Software Requirements Template is linked at the bottom of
this post.
Requirements are basically the capabilities and qualities to be present in the
outcome of the project (product, service, or result) as given by the stakeholders.

Project and project scope is derived from requirements. Further WBS is created from
the scope. Then activities are identified from WBS. Costing and scheduling is done
based on requirements.

Now we can see the potential impact of not capturing requirements (stakeholder
needs) properly at this stage on the project. No matter how well the project is
executed and managed, incorrectly captured requirements can ruin the project.

What are the different types of requirements to be collected?

This is an important consideration for the project manager, and is largely dictated by
the industry. For many organizations (especially in software industry), usual
categorization is Business / Functional requirements and Non-functional
requirements (such as availability of system, performance, maintainability, response
time and so on).

For some, the categorization is Business requirements and Technical requirements –

former indicating what stakeholders want, and the latter indicating what project
should do to implement these stakeholders’ wants.

In general, there are 6 areas that can be looked at while collecting requirements.

This mind map outlines these requirement categories (click the image to open mind
map) –
 Figure 1: One of the ways to categorize requirements

At this stage of the project the documents that are already available are project
charter and stakeholder register.

Who already knows the requirements that you can collect from? The stakeholders.
So we need the stakeholder register and the stakeholder engagement plan to
understand who to approach for requirements elicitation and how to communicate.
Then we need business case document, any agreements that are in and of course
the scope management plan.

Recall the contents of project charter from Developing Project Charter project
management activity –
It contains, but not limited to,

 short description of the project,

 high level requirements
 assigned project manager who is authorized to come up with budget, resource planning,
decision on types of people based on skill set
 milestones
 ballpark budget figures
 any identified risks

High level requirements are available at this stage to start collecting detailed
requirements.
How are requirements gathered?
There are quite a few ways. Take a look at this mind map to get a hold on all of
them. Spend few minutes, we shall look into them individually in further posts. Start
with ‘Interviews’ bulb and move clockwise.

As a project manager it is not essential to try and use each of these techniques. The
ones to be used depend on the tailoring considerations based on various factors
such as existing requirement gathering practices in the organization, lessons learned
from previous projects, industry best practices, resource availability and so on.

Let us look at these in a bit detail in the next couple of lessons.

Figure: Some of the techniques used in collecting requirements

Recall the characteristics of a project –
 Definite start and end date
 Produces a specific benefit
 Progressively elaborated
The progressive elaborative nature of project means that not everything about
requirements is known upfront. It starts with high-level information that is required to
get started, and as project progresses you pick up more details and include them
into requirements.

What is requirements documentation

A project creates a product, service or result that satisfies customer’s business
needs. The requirements documentation identifies individual requirements and
describes how they map to these business needs. So, when these requirements are
implemented during project execution, business needs of customer are met.
Although requirements are progressively elaborated, they cannot be ambiguous
when baselined. Only baselined requirements are taken for implementation, and at
that point they need to be clear, complete, verifiable, and acceptable to stakeholders.

The format and level of detailing of requirements depends on the nature of project
and is left to the discretion of stakeholders and project management team. Some
may have just description of requirements listed per business priority. Some may
have elaborate structure, attachments etc.

In software industry, Requirements Documentation is sometimes called as Software

Requirements Specifications.

Some of the parts of requirements documentation are –

 Business needs detailed from the project charter

 business and project objectives
 business rules
 Stakeholder requirements
 stakeholder communication and reporting needs
 Solution requirements
 functional requirements – behavior of the product
 non-functional requirements such as performance, safety, security, government or
industry compliance needs, reliability, ease of use, maintainability. These are the
inherent expectations from the product.
 standards and compliance (industry, domain, government) requirements
 product support and training needs
 quality needs and reporting needs
 Project requirements – performance, safety so on. Includes acceptance criteria.
 Transition needs (to production, support and/or operations)
 Assumptions and constraints
Consider our earlier example of Landscaping project that Kathy was managing. The
business need is to build a jogger’s garden, blending nature’s feel and functional
needs of jogging track.
To satisfy this business need, one of the functional requirements would be to have
jogging track, which is a spray-coated anti-slip rubber runway, with rebound value of
24%.
Non-functional requirements would be that it is environmental-friendly and should
last at least 5 years.

What is Requirements Traceability Matrix (RTM)

RTM is second document created in this process. It is the way in which baselined
requirements are linked across different baselined data, such as use case, design,
test plan and test case. This document will ensure that various activities of the
project work fulfill the business needs, and that none of the business needs go
missing from implementation.

A sample requirements traceability matrix would be –

Figure: A sample Requirements Traceability Matrix

If you manage Software projects and need a quick start-up document, you can
download a simple Software Requirements Template: MSDoc version or PDF
version. This is based on IEEE recommendation for Software Requirements
Specifications. For non-software projects this document may need some tweaking
specific to the industry.
Usually the requirements are collected in less than ideal ways in organizations.
Reasons are many – from customer’s inability to provide access to real stakeholders
(end users) to lack of awareness about tools and techniques, to lack of support in the
organizational process assets. What has been your experience with gathering
requirements for any of your project? Let me know in Comments below.

How to Collect Requirements – Part 1

Acme Hospitals wanted to build a patient health data management system. Alpha
Software Solutions got the project and put Dean in charge of the project as project
manager. Dean got the project charter, got hold of stakeholder register and started of
on collecting requirements.

Dean first figured out that he needs to talk to health data entry operators, doctors,
lab technicians, healthcare facility chiefs, third party data providers, healthcare
standard database providers, insurance company data keepers, HIPAA compliance
verifiers, patients, and their kins – all stakeholders in this project – to understand
more about the data, and how is it required to be captured, stored, transferred and
archived.
Dean executed some of the tools and techniques from the mind map below –

Figure: Some of the tools of collect requirements process

Interviews
His first step is to interview carefully selected set of people to understand how this
data is captured and consumed. He decided to meet them one-on-one. He prepared
a predetermined set of questions for each type of stakeholders that he is going to
meet.
Brain storming with focus groups
Next, Dean decided to talk to a focus group of doctors to understand things like
what kind of time they can spare to provide examination data of their patients, how is
this data being provided currently, and what can be the best format for their own
consumption. He needed to understand different challenges faced by doctors across
geographies and medical disciplines dealing with healthcare data and he had to
moderate the discussion.

Facilitating stakeholders to arrive at requirements

Further, Dean decided to conduct a facilitated workshop of insurance company
data keepers, healthcare standard data providers and HIPAA compliance verifiers –
to figure out the challenges of data storage, security, transmission and archival. This
was a cross-functional group and they had some difference of opinion concerning
the security of data, and Dean needed to understand them.
His other intention was to make them feel better about working with each other, so
when he gets to integrate the systems he will get their cooperation as well as
collaboration among themselves. During the course of the workshop he figured out
some inherent challenges that none of the parties by themselves were aware of.

Group techniques
Brainstorming – Dean decided to employ couple of group creativity techniques. He
first got a group of hospital data entry staff and the lab technicians to understand the
common, basic data format they can agree to have. They brainstormed for several
sessions of hour and a half each over three days, and at the end of it Dean had a
bunch of alternative data formats.
Nominal group technique is where a group of stakeholders are allowed to generate
ideas silently. Then listed ideas are discussed as a group, voted and prioritized. The
top ideas are then considered for action. This is a facilitator driven group decision
making technique.
 Figure 2: Nominal group technique for quick decision making by the team
Idea/mind mapping
…is a way to facilitate idea flow while capturing them as a mind map. You will see
several mind maps on this blog to represent an idea easily. Mind maps help mind
understand information quickly and recall it easily.

Dean collected all the ideas received from previous interactions with the
stakeholders and created several mind maps – of data formats, archival strategies,
and data transfer mechanism. Seeing them using a top-down approach helped him
refine some of the better ideas, and see the pros and cons of all ideas at one go.

Affinity diagrams
Dictionary meaning of affinity, “a natural attraction or feeling of kinship” itself
describes what this stands for. When you have a large bunch of ideas this method is
used to categorize them.

 Write an idea each on a card (or on a PostIt sticky note)

 Go through each, look at each of the cards and see if it looks related to another idea
 Combine similar looking ideas together till all cards are used up
Once completed, these categories can be used to create cause-and-effect diagrams.

The term Affinity diagram was devised by Jiro Kawakita, so this technique is also
known as KJ method.

Multi-criteria decision analysis (MCDA)

This is an Operations Research tool that helps you evaluate multiple conflicting
criteria to arrive at a decision. This involves representing problem in criterion space
or decision space, generating non-dominated solutions (where all criteria carry equal
weightage) and selecting the suitable solution.
Decision making as a team
These are used when many alternatives are available on a particular requirement
and you need to decide on one based on inputs from collective intelligence of
stakeholders. These are also called collaborative decision making techniques.
The main advantage of this method is – when individuals make decision they are
influenced by their liking, risk taking appetite and abilities, whereas when a group
takes decision it is more practical and not influenced by individuals characteristics.

Figure: Some of the techniques of collecting requirements

Dean is at a stage of requirement collection where he has about 3 different data
transfer mechanisms ideated by stakeholders. He needs to find a consensus on one
of them and move on. He gets hold of the stakeholders and runs through each of
these data transfer mechanism, their advantages and disadvantages, costs and
benefits.
The group will arrive at a decision based on one of the following ways –

Unanimity
…where everyone in the group decides on any one of the alternatives.

Majority
…is when more than 50% of the participants will vote in favor of any one of the
ideas.

Plurality
…is when the option with largest number of votes is selected, even if a majority
(more than 50%) is not achieved.

Dictatorship
…one of the participant stakeholders decides about which alternative to go with. No
questions asked. If head of the organization was to express ‘strong view’ in favor of
one of the alternatives, others in the group may not feel like going against it.

What is the difference between majority and plurality?

It is quite simple. Dean had 3 alternatives. Alternative#1 got 25% votes, alternative#2
got 40% and alternative#3 got 35%. Although there is no clear majority and none of
them got more than 50% votes, alternative#2 wins because it has the most number
of votes. This is the decision by plurality.

Understanding requirements using questionnaires and surveys

These are predefined set of questions targeted for a broader audience. This
method is useful in scenarios where –
 decision is required in quick time
 statistical analysis is sufficient to arrive at a conclusion
In our example, Dean decided to find out the best time for data replication across
servers and for backup with central server. He prepared surveys for different groups
of stakeholders, each of which is designed to unfold the pattern of slack time around
the way hospitals work.
When he got the surveys results he found that 9pm to 11pm is a slot with least
amount of work was happening and could be a better slot for automated data
replication across servers and data backup.
Observing people in action
This is another very useful requirement collection mechanism. This is typically
employed when the target stakeholders cannot communicate the requirements
clearly, or the system is complex and needs to be studied while people are
using it.
In this method you just observe people working with the system and record
requirements. Sometimes you could be a ‘participant observer‘ and understand the
requirements by actually doing things.

Creating prototypes
This method is employed when requirements are not clearly thought out by the
customer and/or the system being created is unique and has not been done before.

A simple working model with basic functionality is created and shown to stakeholders
to analyze and experiment. Based on their inputs it is further developed. This
process of iterative development is stopped when the requirements are understood
in sufficient details, a way is figured out to test the system once it is developed. Once
prototyping reaches its conclusion, team would move to the design phase.

Prototyping uses ‘progressive elaboration’ way to unearth unknowns in the

envisioned system.

Benchmarking
This indicates the practice of comparing another project of similar type and nature
from the past to the current one to identify processes or practices, or even to find
better ways to do things.

Context diagrams
These are visual representation of the system, its interaction with external systems
and users. This helps identify any missing business scenarios for which
requirements were not written.

Document analysis
This is about studying existing available documents and identifying requirements.
Documents such as legal requirements, system use cases, design documents,
proposals, current process flows, issue logs, user documentation and so on are used
for this analysis.
 How to Define Scope for Your Project?
Now that we have collected requirements, let us see how to define scope….
from… requirements.
Yes! Requirements are the first input to this process, which is the output of Collect
Requirements process.

By defining scope we are basically developing a detailed description of the project

and product that it creates.

You can download a sample project scope statement template at the end of
this post.
Exam pointer: The easiest way to remember sequence of process (exam requires
you to remember the sequence) is to understand how they are related. To
understand how does output of one process become input of the other.
For instance,

 You plan strategies to collect requirements and manage scope,

 then talk to stakeholders and collect requirements,
 using them define the scope of the project,
 then break down the scope into tasks so you can assign them to people,
 further, you verify their work to see if scope is met,
 and ensure that people do not work on something out of scope
With this you have logically deduce all processes of Project Scope Management
Knowledge Area!
To define scope we would need the plan that explains how to manage scope, and
the Project charter that has the high level information – such as project description,
high-level business needs, applicable standards, and acceptance criteria.

How do we define scope?

You already know the power and usefulness of expert judgment. It is about utilizing
available expertise – either of someone internal in the organization or an expert from
outside – to identify the project scope.
Analysis is done in order to understand the scope better. Analysis can employ
several mechanisms such as –

 product breakdown – study components of product

 system analysis – study interacting entities to understand system better
 value engineering – understand value defined as ratio of function to cost, as a pre-
manufacturing activity
 value analysis – analyzing value of existing product to reduce unnecessary costs
Alternatives are generated to help us figure out different ways of achieving the same
work, at the benefit of reduced cost or labor.

For instance, laying synthetic anti-slip jogging track is a precision work. Kathy, the
project manager, could either decide to get some experts come in and lay it out. Or
she could look at training her own team and get the work done. She can decide
which alternative works based from cost, effort, and schedule perspective.
Get key stakeholders together and brainstorm to make sure that team is producing
the deliverable that really meets customer’s cross-functional needs.

This can be done by writing down quantifiable goals while conducting these
sessions.Then you can use them during QA cycle to validate deliverables against the
requirements.

Prototype development in Software projects is one such example.

Scope document
This document describes in detail the project’s deliverables and the work
required to create these deliverables. This is the master document as far as
assessment of project work is concerned, and used throughout the life of the project.
We have seen that it builds on the project charter and requirements documents.
Here is a look at the contents of project scope statement.
 Figure 2: Contents of project scope document
It appears at times that project charter and scope statement contain similar
information. The distinction between the two is in the fact that project charter is a
high-level document and scope statement contains very detailed information, albeit
on some of the common topics such as project description and so on.

A clearer distinction between topics covered in Project Charter and

Project Scope Document
Download a sample Project Scope Statement Template here: MSDoc
version or PDF version .
During this project management activity few other project documents get
updated such as –
 stakeholder register – while defining scope you may discover additional stakeholders.
 requirements documentation – requirements are progressively elaborated. When you
look at project charter and requirements and define scope, you may discover some more
details and/or missing requirements.
 requirements traceability matrix
 scope management plan – remember that any changes to the plans are done using
change controls. More details in Control Scope process .
Defining project Scope is an important and critical project management activity of
project management. If not done properly this may mean the difference between
project success and failure. I have been guilty of not doing a good job at this at the
beginning of my career as project manager.

One of which is not identifying additional stakeholders and thus missing out on their
inputs during scoping phase.

What are some of the lessons you have learned during project scoping exercise?

How to Create Work Breakdown Structure (WBS)

From Project Scope
The next logical step after defining scope is to identify smaller chunks of work from
the requirements. These chunks of work are called work packages. These are self-
contained, measurable pieces of scope that can be cost-estimated and scheduled.
Later in this post you will see that there will be control-accountsassociated with
work packages to get a hierarchical view of cost and schedule.
As an example, your organization’s accounts department can calculate the cost for
implementing Accounts Payable module of the accounting package your team is
building for the customer.

Now the question is,

Why do we really need a Work Breakdown Structure

Scope is a coarse much grained piece of requirement to assign to a team member.
This needs to be broken down into smaller pieces, and is done as a hierarchical
structure, where each level of the hierarchy breaks deliverables into more accurate
and measurable chunks. And this is called Work Breakdown Structure, or WBS in
short.
Many a times even this level of granularity is not good enough to assign to team
member for work. For this we have Define Activities process. The lowest level of
WBS is called work package.
There is another advantage of creating WBS. With this structure you ensure that all
of the requirements are guaranteed to be delivered to customer.
How?
Consider this. The next step after creating WBS is to break it down into tasks (or
activities) that can be assigned to team members to work on. Thus WBS is an
essential link between scope and corresponding tasks. Completing all of these
activities will mean that all of work packages, and hence all of the requirements are
delivered.
WBS lets you organize your deliverables into logical units of work.

Whats needed?
Take a pause and guess the what would you need for this project management
activity.

If you guessed (and I am reasonably sure that you did) the plan to manage scope,
requirements documentation and project scope document – you’d be perfectly
right! While the first one tells us how to go about creating work breakdown structure,
next two give us inputs about the actual work that needs to be categorized into a
structure.
You could also use templates in the organization and sample work breakdown
structure from earlier similar projects as reference.

The ‘How’ of it
How would you break down work form monolithic pieces of scope? By separating
project deliverables into smaller, more manageable components – by decomposing
them.
Decomposition breaks scope into work packages. Work packages are further
broken into activities in Define Activities process.
Scope is broken down into multiple hierarchical levels, each one successively
breaking the scope into level that is more granular. Scope can be broken
down based on deliverables – for example, in Kathy’s landscaping project first level
might be broken based on deliverables such as Parks, Common areas and
Walkways. Next level being a bit more granular.
Let us take an example and a sample WBS. We saw few posts earlier about Kathy’s
project of landscaping the gated community project. Here is one way she could
create WBS is:
 Figure 1: Sample WBS using major deliverables
What is ‘100% rule’?
A completed WBS represents all the deliverables of the project – including the
outcome of project management activities, such as documents and plans. If you are
at the leaf node of the structure (one that does not have further child nodes) and roll
up all of the nodes into their parent, and roll up parents into their parents, till all the
way up – it would cover ALL of the work that project team ever does. Hence this
technique ensures that team does only requirements related work, nothing more,
nothing less. This is called ‘100% rule’.
Another way of breaking down scope is based on project phases, such as design,
development, testing, user-acceptance and so on for a software project.
Keep in mind not to break scope into work packages that are too fine-grained. Work
packages should be coarse-grained enough so that you can assign control-account
identifiers to them and calculate cost and benefit numbers at work package level.

You get help from experts for this project management activity. This is in fact
not isolated from decomposition because expertise in the subject help you judge
information and break scope into WBS in a right manner. If project manager does not
possess the necessary technical expertise then someone from the organization or an
expert outside the organization is approached and her services are sought for
creating WBS.
In some cases you could send an appropriate person for training on the subject
matter so they get the knowledge and insight necessary to break scope down into
work packages.

In certain industries, like Kathy’s landscaping project, there might be industry specific
templates that can be used to create work breakdown structure.
What do you produce with this project management activity?

Scope baseline.
A baseline is an authorized point of reference of a project artifact. Scope baseline
contains –

 Project scope document

 Work Breakdown Structure
 Related information for each of the lowest components in WBS (dictionary)
Scope baseline is a component of project management plan. Whenever there is a
change to scope, this baseline is to be updated AFTER a corresponding change
request is approved using change control process.

Let us look at these constituents bit closely.

Project scope document includes information such as project description, major

deliverables, milestones, assumptions, cost figures, constraints and so on.
Work Breakdown Structure or WBS. We have seen that WBS can be structured by
project phases or by major deliverables. The example above shows WBS by
deliverables. Each node of this structure is independently verifiable.
Level of decomposition is governed by complexity of the deliverables. Some
deliverables may need only one level while some others may need multiple.

Though most common type is a hierarchical organizational structure, the WBS can
be represented as a fishbone diagram, or simple outline, or some other method that
is convenient.

Additional work package information – each work package has a corresponding

additional information section. It contains all the information required to do work such
as code of account identifier, description, responsible organization, resources
required, milestone, cost estimates, quality requirements, acceptance criteria. Just
the work package without WBS dictionary is not very useful.
During this project management activity, requirements documentation and project
scope documents can also be updated.

WBS is a baselined document, and any changes to it will require change request to
be raised and run through change control process. These are the outputs of Create
WBS process. Let us look at couple concepts you need to understand about WBS.

What is Rolling Wave planning?

At times, some of the deliverables would not have enough details to be able to break
down into work packages. In such cases, details are left out from the WBS exercise
till more details are known. When sufficient details are available, WBS for them are
created. This is known as rolling wave planning.
Mammoth Construction Company was not clear about what theme should chosen for
common walk ways, and waiting for the inputs from marketing research department.
Hence during initially WBS exercise Kathy skipped this requirement, and kept a
placeholder (refer to the figure above).
What is a control account?
Control account represents a node in WBS hierarchy at which scope, budget, actual
cost of work and schedule can be calculated and compared to the earned value to
measure project performance. (more on earned value in Control Scope process).
Control account has a unique id assigned to one or more work packages in the WBS
hierarchy where cost, schedule and resource information of that work package is
calculated. This unique identifier comes from organization’s code of accounts, and is
used by organization’s accounting system.

For instance, if you had a control account at node “2.2 Community park” in the figure
above, the accounts department would use a unique identifier to calculate schedule
and cost for all the work that goes into constructing the community park.

As a rule, one control account can have any number of work packages, while a work
package is associated with only one control account. They share one-to-many
relationship.

Figure 3: One
control account can have multiple work packages, but a work package is part of only
one control account.

Project document updates

Most probable document to be updated during this process is requirement
documents.

Exam pointer: WBS is a baselined document, and any changes to it will require
change request to be raised and run through change control process.

Points to consider while ‘WBSing’

 Make them delivery-oriented. Do not include any administrative or other types of work
that does not go towards satisfying customer requirements.
 Do not get too detailed. If possible do not try to break them to the extent where you can
assign them. This will create a too large WBS structure, that needs constant
maintenance each time there is some change to the task or new ones are discovered.
There is a separate process for that . Keep the level of clarity at a bit high level where
you have a logical chunk. Else you will end up spending lot of time and going back and
forth between high level scope and low level tasks.
 Do not get too broad. If you keep the detailing at high level, you end up spending more
time during Define Activities process again doing some level of breaking down to task
level.
 Focus on ‘what customer will get’ rather than ‘what a team member will work
on’.When you are done with the structure each node of your structure should indicate
what the customer will get. And not what is that a team member will work on. Level of
detailing in WBS should be ‘customer facing’.
Creating WBS is an exhaustive as well as satisfying exercise for the project
manager. When you cross this stage you will feel more in control of the project.

Validate the Scope of Project Deliverable

Your team tells you that the deliverables are complete and Quality control team
certifies delivery to be good.

Who decides when deliverables are truly complete?

The customer, or project sponsor.

Validate Scope is the process in which validated deliverables are compared against
scope baseline to decide whether team has produced what was planned and
documented. This is a process of formal acceptance of completed delivery by the
customer.

What’s needed to validate project scope?

Quite simple – you compare completed and tested deliverable against
requirements documentation.
This contains the product and project requirements, the technical and non-functional
requirements, and acceptance criteria for each of them. Compared
using requirements traceability matrix. This is the way to trace each of the test
cases, activities, work packages all the way back to the documented requirements.
Now to understand how this is done we need the project management plan. In
particular, scope management plan and the scope baseline.

How is this done?

Inspection is simply the exercise of comparing validated deliverables to
requirementsusing acceptance criteria and confirming whether deliverables are
satisfactory to the customer. In different industries, this is called by different names
such as product walk-through, product review, or audit.
The second one is few decision-making techniques that we saw in the project
management activity for collection project requirements.
Since customer is verifying validated deliverables, the what you get in this project
management activity is accepted deliverables. These are signed off by the
customer or project sponsor. This formal acceptance and acknowledgement is
essential and part of Close Project or Phase process.
Many customers accept deliverable even when they find some deviations, if they
decide that they are not life-threatening. They may be okay with fixing the deviations
as part of subsequent delivery. In such cases, as the rule goes, first a change
request is raised and documented. Hence, change requests are the second output
of this process.
When customer finds some deviation in the deliverables project documents (such as
the ones that keep track of scope deviation) are updated.

What if customer finds major gaps in deliverables as compared to the requirements

and rejects the whole delivery?

Chances are you have witnessed such instances. I know I have. In such cases we
go back to the same exercise of raising change request, running through change
control board, re-planning the work, reworking the schedule, updating baselines and
getting on with changes. The reasons for deviations and type of project contract will
decide whether customer will bear the cost of these changes or the performing
organization.

When scope is controlled regularly effectively, validating scope of completed work

deliverables with customer should be fairly painless.

Many teams involve customer in the process of managing scope to keep them ‘in the
know’ and look for early signs of scope slippage.

This is a great practice especially when customer ties milestone releases to business
events such as product showcase events or industry trade conferences. Cost-of-
failure in such cases are much higher. Also, this practice is a good ‘manage
stakeholder expectations’ exercise that you can implement.

How To Control Scope In Your Project?

Controlling the project scope is the a project management activity of monitoring the
status of the project, finding whether the deliverables meet documented
requirements, and managing changes to project scope baseline.

Before we go further let us quickly recall what is meant by Scope Baseline.

Scope baseline refers to the documented and agreed upon deliverables expected
from the project. Typically scope baseline consists of – Scope Statement of the
project, Work Breakdown Structure of this scope, and details of the components of
WBS.

Recall from Work Breakdown Structure related lesson that WBS is typically a
hierarchical representation of unit of work. This unit of work decomposed from high
level requirements and at a bit higher level of complexity and context than individual
tasks that can be assigned to people.
What do you need to control scope?
First thing to look at is the project management plan, specifically the scope
baseline, which is the ‘expected scope’ against which implemented scope of the
project is compared and variance is calculated. If there is a deviation then project
manager needs to plan corrective or preventive actions by running change request
through change control board.
Other information we use from project management plan are requirements
management plan, scope management plan, change management plan and
configuration management plan. These documents tell us how to go about managing
changes to requirements and scope, managing any changes to the baselined
documents, and process to update configurable items, respectively. Control Scope
process can also spring up surprises and you may discover other changes such as
changed requirements, thereby affecting other subsidiary plans as well.
What is meant by ‘configurable item’?
In brief, configurable items are documents (or project artifacts such as design,
artwork, spreadsheets, and source code) that are versioned. This means any
changes to them are made by authorized people on the team, and in consultation
with the required team members and/or other stakeholders and by using change
control process.

These documents are kept in an access-controlled environment, using systems that

allow multiple people to make changes to the same document without overwriting
each other’s modifications. Configuration management plan defines these items and
the process of controlling changes to these artifacts. When there is an approved
change to a configurable item it is versioned and re-baselined.

We may need to go back and refer to requirements

documentation and requirement traceability matrix – in order to verify whether
deliverables indeed satisfy the documented requirements or there are any
deviations.
Next, we will need to know how are we doing on the project execution, which is the
performance related data, such as how many deliverables have started, what stages
of development are they are at, how many change requests are received and which
deliverables are completed.

Lastly, the policies, procedures, templates and guidelines set by the organization to
control scope, as well as any templates already available will help us control scope
better.

How do you control scope?

By comparing project’s current state of scope against the baselined scope
information, and finding differences. If and when a variation is found, a corrective or
preventive action is identified. Any change will require project manager (or any
stakeholder) decide whether preventive or corrective action is necessary and to raise
a change request. When a change request is approved by change control board, it is
taken up for implementation by making necessary changes to schedule and
recreating scope and schedule baselines.
Let us pause here for a moment and look at what really happens when a change is
discovered.

We have seen that changes to scope can happen for different reasons – scope
creep, gold plating or customer request. There are certain changes that are so small
that project manager (or project management team) finds no impact on any of project
constraints by implementing them. In which case, change control process is not
necessary.

Side effects..
The first one is – change requests. You or customer may find many things incorrect
and such ‘complaints’ are documented and ran through change control board. These
are used to implement corrective or preventive actions and to manage scope
variance. Change requests could also be raised due to scope changes specifically
requested by the customer.
Subsidiary management plans such as scope management plan as the project
management activity itself provides feedback on how we’d planned to do it earlier.
So you update project management plan with this information.

And in the process, along with scope baseline we may update cost baseline and
schedule baseline as well as performance measurement baseline.

If the impact of the change is huge then we may even end up making updates to
project documents such as requirements documents and requirement traceability
matrix.

How scope change is implemented

1. Someone on the team or any of the stakeholders discovers a need for change of scope
2. Project manager documents the change (this step is mandatory).
3. This change request is then presented to Change Control Board through Perform
Integrated Change Control process. Project manager may in parallel assess impact of
change on project objectives so as to help make a decision during change control
meetings.
4. If the change is approved, then the impact on project constraints such as schedule,
scope, and cost are assessed in detail. This is where variance analysis comes into
play.
5. New work is planned as per the findings from variance analysis.
6. Scope baseline is updated to create new baseline, and distributed to the team. All further
development effort will refer to this new baseline. Previous baseline becomes obsolete
when a new baseline is created.
Changes are then taken up for implementation as per the revised schedule.
 Figure: Anatomy of implementing change in project scope

Gold plating Versus Scope creep

Scope management plan ensures that the project contains all the work that needs to
be done, and not anything else.
Here second part is as important as first part. Any effort put to do something other
than the scope, is a waste of time, resources, and it may even upset customer.
Project manager needs to continuously keep a tab on the work and course-correct
whenever team starts doing work out of defined scope.

In this context there are two ways in which team may end up doing more than what
is scoped.

Gold plating and Scope creep

Consider the example of a web-based hotel room booking system.
An over-enthusiastic developer decides that it is ‘cool’ to display an additional page
with luxurious amenities in the hotel just before committing a room booking
transaction by the guest. This additional work takes him two more days of
implementation effort. QA team does not have a requirement to really test this
feature, so they just test by themselves and deliver the product.
When customer looks at the product she is surprised to see this additional ‘feature’.
She knows that the most important goal for business is to make customer book the
room in the shortest possible time on the website. Any additional ‘delay’ results in
cart abandonment 15% of the times. And this ‘cool’ feature defeats that business
objective.

She rejects the deliverable as it violates their business rule.

What is happening here?

Team is gold plating the scope.
Gold plating happens when undefined and accepted scope is added into the
deliverables, often with a good intention, thereby deviating from scope baseline.

Who knows the end user’s needs better than the customer?

Let us look at another example.

You have delivered room booking module of the web-based hotel room booking
system to customer. Team has started working on the next module – integration with
rental cab, laundry service and flight booking systems. Mid way through this,
customer comes back with a request, to make a simple change to the module just
delivered. She wants you to show a photo of the room on the room-booking web
page.
The change is simple and small. You already have the photo of the room in the
database. Even the file location information is already loaded in the page scope
when you are showing the web page. You decide to make the change without
changing any schedule. After all it is just a couple of hours of work.
Customer then asks you to show few more photos of the room, instead of one – and
show it as a slide-show. Simple change, again. There is a third party library available
to show the slide show. All you need to do is make a call to that API – two lines of
additional code. May be couple of more hour of work, considering unit testing effort.
Again, no change request raised, and no changes done to the schedule.
The developer finds that the library method call is not returning correctly, and he
looks into the API’s code. Simple problem there, and he ventures out to correct it. It
has taken him a day more, but it is worth it as he has learned about another API!
Looks good on his resume. But now it does not compile, strangely. So he does some
investigation and finds a compatibility issue. He looks for an alternate third party
library that provides photo slide-show feature. He does not inform project manager
about all this.

Before you know a simple change has turned into a major change and eaten a week
from your schedule. You now have a serious threat of getting on the critical path and
delaying the project.

What is happening here?

Scope creep.

A simple, seemingly harmless change snowballs into a big change that

impacts project constraints resulting in scope creep.
Gold plating and Scope creep are two major threats during project execution phase.
They come in subtly and can cause havoc on project constraints. As a project
manager you need to be extra careful about not letting this happen on your project.

Summary of Project Scope Management

Planning for Managing Project Scope
You would have noticed that Scope management processes have two distinct words
– requirements and scope – as in Collect Requirements and Define Scope.

What is the difference between Requirements and Scope?

Well, Requirements are capabilities that are required to be present in the product,
service or result that project is supposed to produce in order to satisfy a formal
agreement (which could be a Contract). Whereas Scope consists of the activities
that need to be done in order to achieve the requirements.

In short, requirement is outward facing – specified by customer/business;

and scope is inward facing – to be provided by the project. You understand
customer’s business requirements and turn them into project scope. This means that
we derive scope from requirements.

That is why after collecting requirements we define the scope of the project (PMI
defines these two processes in this order). However, in strict practical sense these
processes overlap in ways that is unique for the project.
Planning for managing project scope involves creating a plan that outlines how
scope is to be defined, controlled and managed throughout the project.

Figure: Flow from requirements to scope to WBS to activities

Stakeholders provide requirements, which are turned into project scope, which
further are divided into Work Breakdown Structure (WBS), which them are broken
down further into activities. Project Scope Management knowledge area covers the
flow till WBS.

You would need project management plan (with their subsidiary plans) and Project
charter (contains high-level business needs giving you some sort of context to help
come up with scope creation and management plan). Apart from these you can
make use of available templates from older similar projects in the organization.

One of the ways to create scope management plan is by involving experts in the
organization, or outside the organization. These people have the necessary
knowledge, experience and foresight to guide you about the approach.
You would meet with senior team members, project sponsor, people from Project
Management Office (PMO) and customer will help understand more about product
and project scope, the challenges involved in collecting and managing them.

This project management activity produces a plan to collect and manage, and then
control changes to project scope.

This plan describes the approach to be used to define detailed scope, to create Work
Breakdown Structure. It also describes the process to validate scope with the
customer and the techniques to control scope so that unwanted features do not get
into the product.

This project management exercise produces another plan apart from the Scope
management plan. That is, the Requirements management plan.

What is Requirements Management Plan?

It is important to outline which of the tools and techniques are used for the current
project to collect business requirements. It is also necessary to outline how they
these requirements are documented, analyzed and how changes are authorized,
managed and communicated to stakeholders throughout the project.

If project is planned to be performed in phases as discussed in an earlier lesson, the

relationship between phases also determines how requirements are managed. The
level of detailing to be done upfront might be less if phases are iterative than if
phases are sequential.

All this information is captured in a document called requirements management

plan. This document also captures the process by which requirements are
prioritized, and traced to deliverables.

Collect Project Requirements

How do you identify and document what customer wants, in other words, project
requirements?

This process description answers this question with some neat tools and techniques.
Bear in mind that this is one of the crucial processes in a project, because unless
right requirements are captured properly the deliverables cannot be guaranteed to
satisfy customer.

Define Project and Product Scope

Once you know what customer needs, this process helps you add clarity to project
and product requirements by detailing the requirements.
Define Work Breakdown Structure
..or WBS, is a critical process in arriving at project scope from customer
requirements.

This process is all about breaking down the monolith. Project deliverables are broken
into smaller activities that can be easily managed, tracked, implemented and tested.

The Create WBS process contains an in-built mechanism to ensure that the
team actually implements all of the requirements. This is termed as 100% rule.
A completed WBS represents all the deliverables of the project – including the
outcome of project management activities, such as documents and plans. If you are
at the leaf node of the WBS structure (one that does not have further child nodes)
and roll up all of the nodes into their parent, and roll up parents into their parents, till
all the way up – it would cover ALL of the work that project team ever does. Hence
this technique ensures that team does only requirements related work, nothing more,
nothing less. This is called ‘100% rule’.

Validate that Deliverables Meet Scope

When a deliverable arrives, you will have to verify them against the requirements.
Customer acceptance is dependent on how well finished deliverables adhere to the
defined scope.

The first team that does this, informally, is the development team itself. If you are
talking about software project, then the team does this using primarily using unit
tests and integration tests.

The quality team does this by systematically going over the test cases and also by
performing various types of tests such as load tests, performance tests, functional
tests, system tests, usability tests, and finally acceptance tests.

Control Modifications to Scope (More or Less than planned)

This is a crucial process in Scope management, to manage changes to project and
product scope. Controlling scope is also a preventive or course-corrective exercise
to ensure that team produces only what customer wants, nothing more or less. This
is where change requests are generated too.
Although these processes appear to be nicely sequenced, in real project
environment these processes overlap with each other, and with other processes
from other knowledge areas in ways that are unique to that project.

Some of the processes are done at regular intervals when needed, some on a daily
basis, and some just once in a phase.
 Project Scope Versus Product Scope
Knowing the difference between product scope and project scope is vital, and can
be confusing.
Dictionary meaning of Project is “an individual or collaborative enterprise planned
and designed to achieve an aim”.

Product is defined as “a good, idea, method, information, object, or service that is the
end result of a process and serves as a need or want satisfier”.

Keeping these definitions in mind, let us look at scope of project and scope of
product from the perspective of PMBOK®.

Scope of a Product refers to the features, characteristics and functions of the

product, service or result.
When you look to scope the product, you will think from end user’s perspective, and
plan for all the features that are useful to end user. Outcome of a project is a
product, service, or result.

If you are selling 2 inch drill-bits, you are actually making a product that gives end
users 2 inch holes.
Project scope refers to all the needs to be addressed in order to create the
product, service or result.
The 10 knowledge areas, 5 process groups, 49 processes (as of PMBOK 6th version
guide) – they all aim to help accomplish the work that produces the product (or
service, or result).

Let us see example of Green Landscapes Inc. that is contracted to design and
implement the landscape of the gated community Mammoth Construction Company
is building.

Dan from Mammoth tells Kathy at Green Landscapes that he wants to have 12 acres
of land to be landscaped. They are constructing nine buildings in the area
interspaced by landscaping. Dan wants to have a walking/jogging park, a Chinese
herbal garden, an all-seasons themed park and greens all around. Dan tells
Kathy what he wants.
…this is product scope.
Now, Kathy figures out how is this to be done, what is required in order to create this
landscaping. She works out the resources (machinery, people with different skillset,
tools). She identifies all activities to be performed, dependencies they share and
then creates schedule. She works out the costing part. The communications part.
The risks, and risk responses. Procurements, quality aspects and so on.
…this is project scope.
Project Scope Management knowledge area ensures that the project contains all the
work that is required to build the product, and not anything else. Second part is as
important as first part. Any effort put to produce something other than the scope – is
a waste of time and resources, and may even upset customer. Project manager
needs to keep a tab on project work throughout and course-correct whenever team
veers off the defined scope.