Fast PMP Exam Preparation for Working Professionals!

Shivshanker Shenoy
PMP
www.PMExamSmartNotes.com
Copyright notice
Copyright© 2013 by PMExamSmartNotes.com.
All rights reserved.
Feel free to email, tweet, blog, and pass this ebook around the web ... but please don’t alter any of its contents when you do. Thanks!

Notice of Liability
The author and publisher have made every effort to ensure the accuracy of the information herein. However, the information contained
in this book is given without warranty, either express or implied. Neither the author nor PMExamSmartNotes.com will be held liable for
any damages to be caused directly or indirectly either by the instructions contained in this book, or by the software or hardware products
described herein.

Acknowledgements
All the images used in this study guide are available under Creative Commons license and credit is mentioned below
individual images.

Trademark Notice
PMI is a registered trademark and service mark of the Project Management Institute, Inc.
PMP and CAPM is a registered certification mark of the Project Management Institute, Inc.
PMBOK is a registered trademark of the Project Management Institute, Inc.
Foreword
Whenever you had to study a 'heavy' book, did you wish for a simpler guide just to get the gist of the subject?
Something like a crash-course guide that you could go through and get a handle on the stuff?

I always thought about and looked for such resources whenever I had to study a new subject (the reason I love
Wikipedia). It was a similar feeling I had when I took up PMBOK book to study.

And when I was in a position to prepare a short guide, there was no time to waste.

So here is this guide in front of you. The very fact that you have decided to read this would mean that you might be
one of these –

(a) seriously preparing for PMP® or CAPM® exam

(b) performing the duties of a project manager (project practitioner)
(c) simply curious to know about a systematic way of project management

You will not be disappointed.

Even the basic form of the foundation guide came to well over 200 pages, so I decided to split it into modules. One
covering project management basics and one each for the 10 knowledge areas, so you can pick up the one you wish
to understand and run through it easily.
This guide, of course, comes to you free of cost. The only aim of this guide is to provide you with a quick and succinct
account of project management concepts from PMBOK.

For all the details of concepts highlighted in this book, do visit www.PMExamSmartNotes.com blog. It will make your
exam preparation a breeze, I promise!

PS: This study guide is best viewed in 100% (or 1:1) resolution. Zooming out beyond this may slightly blur some of
visual representations.

Before moving to the content, I would like to take a moment to recommend a fast-track study resource I have used, which -

1. ...saves you a ton of time on PMP or CAPM exam study

2. ...lets you study anytime, anywhere – while traveling, eating, waiting in the queue …you get the idea. Learn on PC or on
your smartphone!
3. …fulfils the mandatory requirement to appear for the exam: 35hr project management education. This alone is
your return on investment!
4. …saves you money as compared to contact classes out there that can cost as much as $2000+!

I am talking about PMPrepCast by Cornelius Fichtner!. You can view couple of sample chapters at Exam Resources section on
the blog. I do get a small commission if you use this link to purchase, but it doesn’t increase your purchase price. If you don’t
want to give the commission it’s perfectly fine but I still highly recommend this study resource, and the direct link you can use
is http://www.project-management-prepcast.com.

Thank you in advance, should you decide to invest in this study resource through this link! Click on the image below.
 Click here to check if you are entitled for a discount!

Ace the exam!

Shiv Shenoy
Table of contents
Plan Scope Management ........................................................................................................................................................................................................... 10
Gold plating ................................................................................................................................................................................................................................... 11
Scope creep ................................................................................................................................................................................................................................... 13

Collecting project and product Requirements..................................................................................................................................................................... 15

Requirements Traceability Matrix (RTM) ............................................................................................................................................................................ 16

What is the difference between Requirements and Scope ............................................................................................................................................ 17

Defining Scope of the project .................................................................................................................................................................................................. 19

Difference between Project Charter and Project Scope Statement ............................................................................................................................ 19

What is Rolling Wave planning? ............................................................................................................................................................................................. 24

What is Control Account? ......................................................................................................................................................................................................... 25

Creating Work Breakdown Structure .................................................................................................................................................................................... 23

Validating project Scope ........................................................................................................................................................................................................... 27

Controlling Scope on the project ............................................................................................................................................................................................ 29

Anatomy of Change .................................................................................................................................................................................................................... 30

Image credit: pixienicki
Image credit: pixienicki
PMBOK® defines Project Scope Management knowledge area as "processes 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.

Planning to manage
Scope
This is where the project management activity to collect,
define and manage scope is defined. You may be using
existing practices from defined templates or a best
practice from another project taken from organizational
process assets.

Scope management plan addresses questions like who

has the authority and responsibility for scope
management, how is scope defined, how is it measured,
what is the change process, and who accepts
deliverables and verifies scope. Image credit: bk1bennett
You would have noticed that Scope management processes have two distinct words – requirements and scope – as
in Collect Requirements and Define Scope.

Scope management plan, the output of previous project management activity ensures that the project contains all the
work that needs to be done, nothing more, nothing less.

Second part is as important as first part. Any effort put to do something outside of the scope is a waste of time,
resources, and may even upset customer. Project manager has to constantly keep a tab on the work, and course-
correct whenever team veers off the 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 an internet-based hotel room booking system.

An over-enthusiastic developer decides that it is 'cool' to display all the

luxurious amenities of 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 may 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 drive

Image credit: Linus Henning

customer to book the room in the shortest possible time on the website. 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.

Team adds features that it thinks helps users, instead of sticking to what is defined in the 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 internet-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 in a slide show manner.
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 requests, 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 the effort as he now
knows about another API! Looks good on his resume! But now it does not compile, strangely. He investigates 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 the schedule. Project manager faces 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

affects project constraints.

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.
Image credit: alcebal2002
Collecting Project and
Product Requirements
How do you identify and document what customer wants?

This project management activity 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.

Take a moment and Google up reasons for project failure. Image credit: l i f e c a t c h e r
What is the common reason you find?

Articulated in different words and meaning the same - lack of clarity on requirements.

Ulad Shauchenka analyzed various failed projects and wrote the book 'Why Projects Fail'. He writes about some of the
findings from research surveys. Three out of five research findings are 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 right requirements.

What are the different types of requirements to be collected?

This is an important consideration for the project manager. 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, 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.
What is Requirements Traceability Matrix (RTM)?

Requirements Traceability Matrix is a way to link requirements to deliverables that implement requirements.
In this matrix 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: Sample Requirements Traceability Matrix

What is the difference between Requirements
and Scope?
This question may confuse people even after working in the project
management role for years. We have an elaborate project management
activity where requirements are collected using various tools and
techniques, but why is there another project management activity that
talks about scope?

The difference is simple.

Requirements define the product behavior. They indicate what is that

users want from the product.

A carpenter needs to be able to drill 2-inch holes. This is the requirement. He

needs a drill-bit that can drill 2-inch holes.

Scope indicates the activities that need to be done in order to achieve

the requirements.

Scope is about figuring out what goes into creating the drill-bit that has a
diameter of 2-inches, and the acceptable tolerance limits.
Image credit: aperture_lag
Scope can achieve partial set of requirements when the requirements are implemented across multiple phases or
iterations (if you are using Agile methodology) by scoping part of requirements in each phase/iteration.

For instance, in Kathy's Joggers' Garden project, the requirement was to create a garden with a jogging/walking track.
In the first phase of the project she decides to scope the landscaping part. In the second phase she scopes planting of
saplings, and fixing water sprinklers. In the third phase she scopes laying of jogging tracks. Thus, one requirement is
completed across three phases by scoping in part of the requirement in each.

In short, requirement is outward facing - specified by customer/business; and scope is inward facing - to be
implemented by the project to satisfy requirements.

You understand customer’s business requirements

and then turn them into project scope.

Defining Scope for

the project
Once you know what customer needs, this project
management activity helps you add clarity to
project and product requirements by detailing the
requirements.

Image credit: timbergman

Now that we have collected requirements, let us see how to define scope from… requirements.

Yes! Requirements, which are the output of Collect Requirements process, are the first input to this process.
A clearer distinction of topics covered in Project Charter and Project Scope Statement

Project charter Project scope statement

Purpose of the project Project scope description (in PMBOK 5th edition this is
accepted to be progressively elaborated, like in Agile
practices)
Project objectives and success criteria to measure Acceptance criteria
them
High-level requirements Deliverables
High-level project description Exclusions
High-level project risks Constraints
Summary milestone list Assumptions
Summary of budget available
List of key stakeholders (may not cover everyone)
Project approval requirements
Assigned project manager, her level of authority and
responsibilities
Name and authority of person authorizing Project
charter

The outcome, as you can guess, is updating project documents 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 scope of the project is an important and critical project management activity. 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.

Creating Work
Breakdown Structure of
deliverables
This project management activity is all about breaking
down the monolith. Project deliverables are broken into
smaller activities that can be easily managed, tracked,
implemented and tested.

The next logical step after defining scope is identifying Image credit: Ardonik
small 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.
Later in this lesson you will see that there are control-accounts associated with work packages to get a hierarchical
view of cost and schedule. For instance, 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.

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 breaking it down into tasks (or activities) that can be assigned to
team members to work on. Hence WBS is an essential link between scope and corresponding tasks. Completing all of
the activities will mean that all of work packages, and hence all of the requirements are implemented.

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: One control account can have many work packages, but a work package is part of only one control account.
What care should you take while creating WBS?

 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 project management activity for that (Define Activities). 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 project management activity 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.
Validating deliverable to make sure Scope is met
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.

Your team says that the deliverables are complete

and Quality control team certifies delivery to be
good. However, who decides when deliverables
are really complete?

Customer, or project sponsor.

Validate Scope is the project management activity

in which verified deliverables are compared
against scope baseline to decide whether team
has produced what was planned and
documented. This is a project management
activity of formal acceptance of completed
delivery by the customer.

Image credit: Official U.S. Navy

Imagery

What if customer found major gaps in deliverables as compared to the requirements and
rejected the whole delivery?
I am sure you would have witnessed such instances. I know I have. In such cases we go back to the same exercise of
raising change request, running through Perform Integrated Change Control process, re-planning the work, reworking
the schedule, updating baselines and getting on with fixes. The reasons for deviations and type of project contract will
decide whether customer will bear the cost of these fixes or the performing organization.

When Control Scope project management activity is performed

regularly with good effect, Validate Scope project management
activity should be relatively painless. Many teams involve
customer in Control Scope project management activity 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.

Has your Validate Scope project management activity with

customer been a pleasant exercise?

Controlling Scope on
project
Image credit: Watt_Dabney
This too is a crucial project management activity in Scope management. Controlling scope is 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 they 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.

With this you have logically deduced all six processes of Project Scope Management Knowledge Area!

Controlling scope is the project management activity of monitoring the status of the project to find 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. The components
of scope baseline are - Project Scope Statement, Work Breakdown Structure (WBS) and WBS dictionary.

Recall from Create WBS lesson that WBS is typically a hierarchical representation of work packages. Work package is a
unit of work decomposed from high-level project scope.

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

Anatomy of Change
a) Someone on the team or any of the stakeholders discovers a need for change looking at current project progress

b) Project manager documents the change (this step

is mandatory).

c) 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.

d) 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.

e) New work is planned as per the findings from

variance analysis.
f) Scope baseline - WBS, WBS dictionary, scope statement - 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.

g) Changes are then taken up for implementation as per the revised schedule.
 Fast PMP Exam Preparation for Working Professionals!

Download FREE eBooks for other Knowledge Areas from the blog!

Connect with Shiv at LinkedIn and on PMESN at Facebook, Google+ and Twitter.