Académique Documents
Professionnel Documents
Culture Documents
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 –
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.
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,
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.
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.
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 –
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.
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.
The term Affinity diagram was devised by Jiro Kawakita, so this technique is also
known as KJ method.
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.
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.
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.
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,
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.
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.
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?
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 –
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.
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.
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.
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.
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.
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.
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.
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.
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.
In this context there are two ways in which team may end up doing more than what
is scoped.
Who knows the end user’s needs better than the customer?
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.
Scope creep.
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.
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.
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.
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.
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’.
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.
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®.
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.