PMBOK Quick Implementation Guide:

Standard Introduction, Tips for Successful PMBOK

Managed Projects, FAQs, Mapping
Responsibilities, Terms and Definitions

Notice of Rights: Copyright © Daniel Lawson. All rights reserved. No part of this
book may be reproduced or transmitted in any form by any means, electronic,
mechanical, photocopying, recording, or otherwise, without the prior written
permission of the publisher.

Notice of Liability: The information in this book is distributed on an “As Is” basis
without warranty. While every precaution has been taken in the preparation of the
book, neither the author nor the publisher shall have any liability to any person or
entity with respect to any loss or damage caused or alleged to be caused directly
or indirectly by the instructions contained in this book or by the products
described in it.

Trademarks: Many of the designations used by manufacturers and sellers to

distinguish their products are claimed as trademarks. Where those designations
appear in this book, and the publisher was aware of a trademark claim, the
designations appear as requested by the owner of the trademark. All other
product names and services identified throughout this book are used in editorial
fashion only and for the benefit of such companies with no intention of
infringement of the trademark. No such use, or the use of any trade name, is
intended to convey endorsement or other affiliation with this book.

ITIL® is a Registered Community Trade Mark of OGC (Office of Government

Commerce, London, UK), and is Registered in the U.S. Patent and Trademark
Office.
 Write a Review and Receive a Bonus Emereo
eBook of Your Choice

Up to $99 RRP – Absolutely Free

If you recently bought this book we would love to hear from you – submit
a review of this title and you’ll receive an additional free ebook of your
choice from our catalog at http://www.emereo.org.

How Does it Work?

Submit your review of this title via the online store where you purchased
it. For example, to post a review on Amazon, just log in to your account
and click on the ‘Create Your Own Review’ button (under ‘Customer
Reviews’) on the relevant product page (you’ll find plenty of example
product reviews on Amazon). If you purchased from a different online
store, simply follow their procedures.

What Happens When I Submit my Review?

Once you have submitted your review, send us an email via
review@emereo.org, and include a link to your review and a link to the
free eBook you’d like as our thank-you (from http://www.emereo.org –
choose any book you like from the catalog, up to $99 RRP). You will then
receive a reply email back from us, complete with your bonus ebook
download link. It's that simple!
Project Management

TABLE OF CONTENTS

1 INTRODUCTION ............................................................................. 7
1.1 WHAT IS PROJECT MANAGEMENT? ................................................... 7
2 A WORLD WITHOUT PROJECT MANAGEMENT ............................ 9
3 INTRODUCING PMBOK............................................................... 13
4 ADDING THE PROJECT MANAGER TO THE MIX ........................ 15
5 MANAGING THE CLIMATE OF A PROJECT FOCUSED
ORGANIZATION................................................................................... 19
6 GROUPING THE PROJECT MANAGEMENT PROCESSES
TOGETHER............................................................................................. 23
6.1 INITIATING THE PROJECT .................................................................. 26
7 PLANNING THE PROJECT ............................................................ 29
7.1 EXECUTING THE PROJECT ................................................................ 31
7.2 MONITORING AND CONTROLLING THE PROJECT .............................. 32
7.3 CLOSING THE PROJECT ................................................................... 34
8 FRAMING PROJECT MANAGEMENT .......................................... 37
8.1 THE PROJECT PLAN AS AN INTEGRATION PRODUCT ........................... 40
8.1.1 Developing the Project Plan ....................................... 42
8.1.2 Executing the Project Plan .......................................... 46
8.1.3 Controlling Change to the Project Plan .................... 47
8.2 PUTTING A STAKE IN THE GROUND – PROJECT SCOPE ....................... 50
8.2.1 Igniting the Project ....................................................... 50
8.2.2 Creating the Stake ....................................................... 52
8.2.3 Defining the Boundary Limits ....................................... 53
8.2.4 Announcing the Claim................................................. 56
8.2.5 Fending Off the Claim Jumpers .................................. 58
8.3 CONQUERING TIME ........................................................................ 61
8.3.1 Defining the Activity ..................................................... 62
8.3.2 Which Came First, the Chicken Or the Egg............... 64
8.3.3 Hard-Boiled or Soft-Boiled............................................ 68
8.3.4 Scheduling..................................................................... 71

3
Project Management

8.3.5 Controlling the Schedule ............................................. 74

8.4 BANKING ON IT .............................................................................. 74
9 LEANING ON RESOURCES .......................................................... 77
9.1.1 Applying Cost................................................................ 77
9.1.2 Budgeting the Project .................................................. 79
9.1.3 Controlling Cost ............................................................ 80
9.2 MANAGING THE RIGHT STUFF .......................................................... 80
9.2.1 Quality is Planned ......................................................... 81
9.2.2 Quality is Watched ....................................................... 84
9.2.3 Quality is Controlled ..................................................... 84
9.3 WORKING WITH PEOPLE .................................................................. 87
9.3.1 Working Together.......................................................... 88
9.3.2 Finding the Right People.............................................. 90
9.3.3 Developing Team ......................................................... 91
9.4 OPENING UP THE LINES OF COMMUNICATION .................................. 93
9.4.1 Laying the Infrastructure .............................................. 94
9.4.2 Making the Connection .............................................. 96
9.4.3 Cleaning Up Static........................................................ 96
9.4.4 Ending the Connection ............................................... 98
9.5 BASE JUMPING A PROJECT.............................................................. 99
9.5.1 The More Risk, the Better the Experience ................ 100
9.5.2 Extreme Sports or Golf?.............................................. 103
9.5.3 Be Prepared ................................................................ 105
9.5.4 Taking the Jump ......................................................... 106
9.6 GOING SHOPPING ....................................................................... 107
9.6.1 Creating a Shopping List............................................ 108
9.6.2 Walking the Mall ......................................................... 110
9.6.3 Window Shopping ...................................................... 111
9.6.4 Finding the Right Store ............................................... 111
9.6.5 Making the Purchase ................................................. 112
9.6.6 Wrapping It Up ............................................................ 113
10 CONCLUDING PROJECT MANAGEMENT ................................ 115
11 COMPARING PROJECT MANAGEMENT FRAMEWORKS......... 117
12 APPLYING CLOUD COMPUTING TO PROJECT MANAGEMENT
121
12.1 BENEFITING FROM CLOUD COMPUTING .................................... 121
12.2 THE EASE OF LINKING (HYPERLINKS)........................................... 123

4
Project Management

12.3 SUBSCRIBING TO SUCCESS (BLOGGING).................................... 126

12.4 INTERFACING WITH THE PROJECT (MASHUPS) ............................. 128
12.5 EVERYONE IS A PROJECT MANAGER (OPEN SOURCE) ............... 130
12.6 TREATING THE PROJECT AS PARTS, NOT THE WHOLE (REUSE) ....... 133
12.7 TESTING THE LIMITS (PORTABILITY) .............................................. 135
13 THE PERSPECTIVES OF PROJECT MANAGEMENT .................... 137
13.1 A PROJECT AS INFORMATION ................................................... 138
13.2 A PROJECT AS WORKFLOW ...................................................... 140
13.3 A PROJECT AS PEOPLE ............................................................. 142
14 SUMMARIZING PROJECT MANAGEMENT ............................... 145
15 REFERENCES .............................................................................. 147

5
Project Management

6
Project Management

1 Introduction

1.1 What is Project Management?

The executive board has just convened and under

discussion for today's meeting is a proposal for a new
service. The board has been working for weeks on the
company's future goals and the business sectors have been
encouraged to find innovative ways to expand the
company's business offerings. An enterprising young
manager has suggested that given the current technology
trends and the company's capabilities that a new service
can be added to the business and provide the companies
product line over the web. By the end of the meeting, the
board is excited about the new venture and have given their
full approval. The young manager is has been given total
control over implementing the proposed service.
Unfortunately, the board had a few conditions and he's not
sure exactly how to proceed.

Speaking to his colleagues, they suggest that the first thing

to do is establish a project and start managing it. Whether
the young manager realized it, the project had started
without him. His friends are just encouraging him to
acknowledge the work as a project; that is the set of steps
necessary to bring a new product or service to the
organization. A project is temporary: it has a definitive
beginning and a definitive end. In this case, the beginning

7
Project Management

was the executive board's approval and the end is the

validation that the new service has been properly
implemented into the environment.

Companies work and that work using falls into one of two
categories: operations or projects. Both types of work
require people to perform, are constrained by resources,
and are planned, executed, and controlled. The difference
in the two are that while projects are temporary and unique,
operations are ongoing and repetitive. Operations typically
take over when the project ends. In the example above, the
new service will be implemented into the environment,
where the operations will continue to monitor the service
and make any improvements necessary.

Project management is a disciplined approach to

successfully handling these temporary endeavors. The
discipline encompasses knowledge, skills, tools, and
techniques. If the discipline is applied properly, the project
should meet the requirements behind the service or product
while balancing the demands on the project from
expectations and needs behind scope, time, cost, and
quality. Project management organizes the steps required
to move from point A to Point B..

8
Project Management

2 A World Without Project

Management
Projects are a natural occurrence to any business that
grows and expands its products, knowledge, or even its
physical representation. From as small as adding a new
room to the office building to creating a worldwide
campaign for the next great product, projects exists in many
forms within the walls of a company. Unfortunately, though
projects are nature course of business, project
management is not.

Project management focuses on more than the end result,

but also the journey getting there. Along the way, many
hurdles may have to be overcome. The Standish Group
reports that 31.1% of all projects will be canceled before
they are ever completed and that 52.7 of the projects that
are completed will cost 189% of the original estimate.1 In
2002, the National Audit Office and the Office of
Government and Commerce gave the following reasons for
project failures:
• Lack of a clear link between the project and the
organization's key strategic priorities.
• Lack of clear senior management and ministerial
ownership and leadership.
• Lack of effective engagement with stakeholders.
• Lack of skills and proven approach to project

9
Project Management

management and risk management

• Evaluation of proposals driven by initial price rather
than long-term value for money
• Too little attention paid to breaking development and
implementation into manageable steps
• Inadequate resources and skills to deliver the total
portfolio.

The large the project, the more time or budget involved, the
more opportunity there is to fail. Lawrence Cooper, CEO of
ITSM Canada, provides a practical realization to project
failures:
Project timelines beyond 6-12 months generally result in a
project going over budget and failure to deliver on the
promised benefits – detailed project planning is hard to do
beyond 6 months.
• Failed projects usually suffer from a lack of focus
and momentum after about the 5-6 month mark
• Poorly defined scope (and requirements) and scope
creep because of unclear goals objectives
• No change control to handle scope changes
• Lack of executive commitment and user interest due
to the long timelines involved
• Failure to communicate and act as a team
• The wrong skills or not enough of the right skills.2

The problem is not isolated to the projects or how

companies manage them. The persistence of project
failure also exists because of the people managing the

10
Project Management

projects. Peter Gammon, senior consultant to Contact to

Contract, offers the following points about project
managers:
• A 2003 survey with the Industry body INTELLECT
showed that of the companies interviewed, only 42%
of the project managers were accredited
• Of the companies interviewed, 48% use a “home
grown” methodology [of project management].
• Those who are accredited only use a part of the
theory and methodology in the workplace.
• Countries have local accreditation bodies (such as
Prince2 in the UK).
• There has traditionally not been a single global
standard for project management accreditation.
• Empirical observation suggests that most project
The fact remains that without a disciplined approach to
managing projects by capable people who can successfully
manage projects, a company has the potential to lose time,
money, effort, and possibly market value. Many companies
focus on their operations because it is self-evident that the
operations are the daily grind of doing business. And the
operations of a company are very important to maintain.
Unfortunately, they approach managing projects in the
same way as they do approach managing operations. In
many respects, the members of the project team are also
involved in maintaining the operations of the business, and
the work done on a project is covered on their job
description as “additional duties as required.”

11
Project Management

For a project to be successful, two components must be in

place: a discipline for managing the project and a person
who can properly apply the discipline.

12
Project Management

3 Introducing PMBOK
In 1969, five volunteers founded the Project Management
Institute (PMI) to set standards for project management,
conduct research in improving the way projects are
managed, and to provide the growing number of project
managers the opportunity to exchange knowledge and
educate themselves in the disciplines of project
management. Since then, PMI has been recognized by the
American National Standards Institute (ANSI) as an
accredited standards developer. One particular standard is
the Guide to the Project Management Book of Knowledge
(PMBOK Guide). The standard began in 1987 as an
attempt to dot and standardize the information and
practices of project management that has been generally
accepted by the community of project managers.

The PMBOK Guide breaks project management into 44

processes that loosely for into five basic process groups
and nine areas of knowledge. The PMBOK is
comprehensive enough to provide a general guide to
managing most project and flexible enough to be adapted
to specialized projects like construction or government
which encouraged development of standards specific to
those industries. The approach used by by PMBOK is
compatible with ISO 9000 and the Software Engineering
Institute's CMMI (Capability Maturity Model Integration).
The processes found within the PMBOK overlap and

13
Project Management

interact throughout the life of a project which is defined in

the five process groupings.

Projects are focused on creating deliverables: tangible

items which show the successful progress of the project.
It’s not enough to simply go to the store, one must return
with something. Deliverables play out the same concept:
showing the efforts of the work by the team. At the core of
creating deliverables is defining the work that needs to be
done to meet the deliverable. This is accomplished by
creating a Work Breakdown Structure (WBS). Attached to
the WBS is a schedule for the work to be done along with
the resources required to complete the work. Some of the
tasks found in the WBS may have some interdependence
with other tasks. Some share the same resources, even is
the timing of the tasks are farther apart. Essentially, the
project can be down into the deliverables, the WBS to meet
the deliverables, the schedule for doing the work defined by
the WBS, and the resources required to meet the schedule
and WBS. The only thing left on the project is managing
the execution of the schedule.

14
Project Management

4 Adding the Project

Manager to the Mix
For the discipline of project management to be properly
applied, someone has to be assigned the task of doing so.
This individual is referred to as the Project Manager.
Though professional project managers do exist, many of
the people managing projects are not project managers, but
individuals who have some management authority and are
usually a major stakeholder in the successful outcome of
the project. Unfortunately, the numbers of projects that can
be found in a company are at times much more than the
group of professional project managers available to take
them on. In these situations, companies usually assign a
professional project manager to those projects that would
have the greatest impact on the company if it succeeds or
fails, allowing non-professionals to on the lower risk
projects. In some cases, the body of professional project
managers serve as mentors to those who are not certified
as project managers.

PMI has two credential programs in project management: a

person can be a Project Management Professional (PMP)
or a Certified Associate in Project Management (CAPM).
The certified associate is an entry level certification into
project management and is designed for members of the
project team. Individuals have to apply to be a CAPM and
prerequisites demand a High School diploma, associate's

15
Project Management

degree or higher and either 1500 fours of professional

experience on a project management team or 23 hours of
formal PMI certified project management training.
Credentials require the passing of an exam based on
PMBOK.

Certification for PMP also requires an application. The

eligibility beyond the application can take two forms. The
first is an individual who has a High School diploma and an
associate's degree or equivalent, a minimum five years of
unique non-overlapping professional project management
experience with at least 7500 hours leading and directing
project tasks and 35 contact hours of formal PMI certified
PMP training. The second is an individual who has a a
bachelor's degree or equivalent, a minimum three years of
unique non-overlapping professional project management
experience with at least 4500 hours leading and directing
project tasks and 35 contact hours of formal PMI certified
PMP training.

Project Managers have a unique responsibility inside the

organization. They are responsible for changes to the
business, in whatever way that change takes. In
operational mode, the basic hierarchical structure of a
business is a number of employees in various departments
being managed by business managers who are responsible
for a specific part of the business that may or may not have
any understanding of other parts of the business and the
impact their departments have on the business as a whole.
The larger the company, the more layers of management

16
Project Management

that occur until the top executive managers who make the
decisions that directly impact the business. The Project
Manager typically takes direction from executive
management or at the very least ensures that the project is
in line with the guidance of the executive management.
They work mostly with middle manager to obtain the
resources necessary to execute the project, and typically
require the workforce to successfully implement the product
or service which is the focus of the project. The Project
Manager typically works outside the operations of the
business when working on a project, but they have to stay
in touch with the operational portion to comprehend how the
project will impact the operations or vice versa.

In should be noted that the Project Manager alone does not

successfully execute a project. Projects completed by a
team of professionals who come from the operational side
of the business are tasks to take guidance and assist the
Project Manager to minimize the risk of implementing the
project into the business operation. The knowledge, skills,
and passion of the project team are ultimately just as
important as the project manager and applying the
discipline of project management. Because of this, it is very
important to carefully consider the makeup of the project
team and ensure that right people are assigned to the
project. In addition to the core project team, there are
typically other individuals who will provide their knowledge
and skills as resources to the project as part of their own
part in the operations.

17
Project Management

18
Project Management

5 Managing the Climate of

a Project Focused
Organization
As already mentioned, a business can be described in
terms of projects and operations. The day-to-day activities
of the business usually focus on the operational aspects of
the business. This is the environment which a project must
be successful in. Remember that projects are temporary
while operations are not. Projects usually focus on
delivering change, while operations focus on maintaining
the status quo or at least providing some continuous
improvement.

Inside this environment, the project may be influenced or

impacted greatly by forces outside of the project. Since
many of the members of the project team have primary
responsibilities within the operations of the company, any
problem disrupting those operations will have a negative
impact on the project itself. Successful project
management begins and ends with agreement by those
individuals involved in the project or have the potential to be
impacted negatively or positively by the existence or the
result of the project. These individuals are called
stakeholders are minimally made up of the project
manager, the customer who will be using the product or
server at project end, the performing organization which will

19
Project Management

do the work, and the sponsor who is the individual or group

providing the necessary financial resources for the project.

The success of the project relies on the project team

identifying the stakeholders of the project and determining
any expectations they may have on the project. Managing
these expectations is just one of the major ways of ensuring
that the project is successful. Unfortunately, managing
expectations can be difficult because stakeholders may
have different expectations which can be in conflict with the
expectations of another stakeholder. Generally, most
differences are resolved in favor of the customer.

The organization itself can have a tremendous influence on

a project. Project-based organizations typically will have
systems in place that aid and address different aspects of
project management; for instance, the financial systems will
be designed to specifically handle the accounting, tracking,
and reporting on multiple projects happening at the same
time. Organizations not based on projects, such as
manufacturing, are not likely to have systems in place to aid
project management efforts, therefore placing the burden
directly on the shoulders of the project manager. The
project manager should be aware of the tools that the
organization will provide and how they can be used or not
used to aid the project.

The culture of the organization can impact the project on

many levels. Cultures are known because of their shared
beliefs, values, norms, and expectations which are usually

20
Project Management

represented in their process and procedures or their

response to authority, or other factors. Cultures that thrive
inside an aggressive or entrepreneurial organization are
more likely to take on projects that are highly innovative and
risky. An organization that encourages the participation of
all their employees may not work well with a project
manager who is very rigid and by the book about how
things are done in the project.

Even managerial styles can come into play. As a result,

project managers need to handle a variety of situations and
people types at all times. They may have to serve several
roles on the project. Though they are concerned with
producing results expected by stakeholders as a project
manager, they may also be responsible to lead the project
by establishing the direction of the project, aligning people,
motivating and inspiring the organization. Project
managers have a responsibility for ensuring the lines of
communication are open allow the exchange of information
to never stop. Most importantly, project managers have to
have skills in negotiating others into terms that are
agreement to all parties. They have to be problem solvers.
Project managers cannot allow themselves to be influenced
by the organization, but must be able to understand the
mechanics of the organization to be able to influence it
instead.

Still there are even forces outside of the organization that

may influence the project and its work. Organizations in the
health and government industries are highly regulated

21
Project Management

entities; any project from those organizations have to follow

the standards and regulations that impact their industry.
Every major business has some regulatory commitment to
maintain and those can influence. Globalization is a push
into doing business across national boundaries. As a
result, more projects have stakeholders from across the
globe. Implementing a product or service across multiple
nations must be in compliance to the laws and political
machinery of the nations involved. Additionally, the cultural
influences of the world outside of the workplace have an
impact on the project inside. The project manager and the
team have to handle all the influences impacting the project
from beginning to end.

22
Project Management

6 Grouping the Project

Management Processes
Together
PMBOK treats project management as a set of processes.
As processes, each set of activities have certain similar
characteristics to them, namely they all have inputs,
outputs, and the tools and techniques required. The
processes however are not typically performed one after
another but in conjunction with each other. In essence, the
project is a group of processes interacting with each other
all the time. At some stages of the project, some processes
are focused on more than others and the focus changes at
other stages of the process. The purpose of each process
within project management is to create a definable and
recognizable result. Processes fall into two categories.
Ultimately, a project is concerned with bringing a new
product or service to the environment, therefore one
category of project processes focus on those processes
that are most concerned with the specification and creation
of the product or service. The lifecycle of the product is
distinguishable from the lifecycle of the project. During the
life a product, several projects will be initiated and executed
for the benefit of the product. For instance, the
development of a new release in software may be an entire
project that is a small portion of the total life of the product.
Therefore, the likelihood of processes that focus on the

23
Project Management

success of the product is high and these product-oriented

processes are separate from the project management
processes.

The second category of processes are those that are strictly

concerned with describing and organizing the work required
by the project. The two sets of processes constantly work
congruently with each other. The difference is one set is
focused on managing the project, while the other focuses
on the product of the project itself when the project ends,
the project management processes will cease to continue,
while the product-oriented processes will still be in place.

The PMBOK organizes the project management processes

into five process groups. The groups follow the project life
cycle and consist of one or more of the 44 total processes
found in the PMBOK. The groups are:
• Initiate – the processes in this group are used to
recognize that a project of phase should begin and
gathers the commitment required to get it started.
• Plan – part of the project is to devise and maintain a
schedule of tasks and resources that are required to
fulfill the business need the project is about to
address. The processes in this group are used to
identify the plan and resources for that schedule.
• Executing – after creating a workable plan, the next
set of processes provide the methods for
coordinating the people and resources to execute
the project tasks.
• Controlling – Handling unexpected hurdles and

24
Project Management

keeping promises are two of the factors involved in

ensuring the project is a success. This grouping of
processes aids the project manager in ensuring the
project objectives are met by monitoring and
measuring the progress of the project.
• Closing – When the deliverables of the project are
complete, the last set of processes formalize the
acknowledgment that the project is complete and
brings it to an orderly end.

The results of one process group is the input to the next

group, though the processes are iterated. Though
everything is planned out early on in the project, a change
in requirements may require an update to the schedule later
on in the project. As such, the project management
processes are not single instance occurrences in the life
cycle of a project, but overlapping activities which happen
at varying degrees at every phase of the project.
Additionally, the process groupings not only define the flow
of the entire project life cycle, but also the general flow of
each of the phases in the project. For instance, before a
design document can be executed on, it must be “closed”
out by customer acceptance. Therefore, the closing
processes are utilized in some degree before leaving the
planning phase of the project. Fortunately, the customer
acceptance can serve to obtain commitment for execution
phase which is the focus of the initiate processes. The
advantage to reiterating the processes constantly
throughout the project phases ensures that any new
information impacting the project is handled appropriately

25
Project Management

and returns the focus of the process to meeting business

need.

6.1 Initiating the Project

Within a business there are a variety of ways in which a

project can be initiated. Some companies insist on having
a specific set of criteria established to determine whether a
project is a project. Others treat any change to the
environment as a project. Within IT companies, arguments
have ensued around the difference between project
management and change management, which is an IT
operational process for controlling changes to the
configuration of the IT infrastructure. Some companies do
not recognize projects that do not have a certified project
management professional leading them.

Despite the varying definition of a project for a company

may be, where the projects come from can also be
confusing. Projects need executive support, so some
people insists that true projects can only come from the top
levels of the company. Others stand that the most effective
projects stem from identifying problems by the workforce.
Still others will state that projects are results of marketing
innovative solutions to both the executives and the
workforce, like a middle manager. Some projects are
technical in nature, while others are business driven.
Organizational changes are usually projects or projects can

26
Project Management

have an element of all types. Some projects add to the

environment, while others take away.

The basic fact is that every consideration already stated is

valid and only shows the importance of understanding
project management but also the importance of initiating a
project appropriately. To initiate a project, one simply
needs a commitment by the organization to begin the next
phase of the project. The commitment should come from
the stakeholders, those individuals responsible for the
areas of business which are directly impacted by the results
of the project. For the most part, the stakeholders will
provide the necessary resources to successfully complete
the project; the resources can be finances, people,
information, equipment, or all of the above. If a department
can absorb the cost of the project and provide all the
resources, than a project can be initiate at the department
level. However, if more resources are required than the
department can provide, the proposal may need to go to the
next higher level. In some cases, a project may be initiated
simply to create a proper and comprehensive proposal for a
project at the executive management level.

27
Project Management

28
Project Management

7 Planning the Project

Projects generally involve doing something new in the
environment. In a business context, something new or
different typically translates into risk. Therefore, project
planning is of utmost importance. Most of the project
management processes can be found within the planning
process group. This does not indicate that the bulk of
project work is planning the e project, only the importance
of the work. The amount of planning required is
proportionate to the scope of the project, the risk associated
to the endeavor, and the usefulness of the information
developed inside the planning phase.

The processes within the Planning group are further

categorized as the core processes and the facilitating
processes. The core processes have clear dependencies
placed on them and have to be performed in the same
order on most projects. These processes may be iterated
several times during any phase of the project and include:
• Scope Planning – develop a written scope statement
to be used in future decisions related to the project.
• Scope Definition – divide the major project
deliverables into smaller, manageable components.
• Activity Definition – identify the activities required to
product each major project deliverable.
• Activity Sequencing – identify and document the
dependencies between activities.
• Activity Duration Estimating – creation of estimates

29
Project Management

for the number of work periods required to complete

individual activities.
• Schedule Development – create a project schedule
based on activity sequencing, activity duration, and
resource requirements.
• Resource Planning – determine what resources and
their quantities are required to perform activities.
Resources can be people, equipment and materials.
• Cost Estimating – develop an estimate of the
resource cost required to complete the project.
• Project Plan Development – use the results of the
preceding process to create a coherent and
consistent document.

The facilitating processes are used based on the nature of

the project. Some projects are no risk processes so some
of the risk management processes would not be used
compared to a highly aggressive and risky project.
However, these processes are not optional; they are simply
performed intermittently as the need arises.
• Quality Planning – identify and satisfy any relevant
quality standards.
• Organizational Planning – identify, document, and
assign project roles, responsibility and reporting
requirements.
• Staff Acquisition – obtain the appropriate human
resources needed for the project.
• Communications Planning – determine the
information and needs for communication of the
stakeholders, creating an understanding for who gets

30
Project Management

what information, when they will get the information,

and in what manner it will be conveyed.
• Risk Identification – determine the risks that will most
likely impact the project and document the
characteristics of the risks.
• Risk Quantification – evaluate the individual risks to
determine the range of possible project outcomes.
• Risk Response Development – determine the steps
for opportunities and responses to threats to the
project.
• Procurement Planning – determine what to procure
and when.
• Solicitation Planning – document product
requirements and identify potential sources.

7.1 Executing the Project

The bulk of project work is done under the Execution

process group. This is the time when the project team
takes what was detailed out in the planning phase and
executed according to design. Core and facilitating
processes exist within this process group also the process
Project Plan Execution being the only core process.

The facilitating processes include:

• Scope Verification – obtain formal acceptance of the
project scope.
• Quality Assurance – evaluate overall project
performance regularly to ensure that the project will

31
Project Management

meet the relevant quality standards.

• Team Development – develop skills of individuals
and groups to enhance project performance.
• Information Distribution – ensure that the necessary
information is available project stakeholders in a
timely manner.
• Solicitation – when appropriate, obtain quotations,
bids, offers, or proposals.
• Source Selection – choose from among potential
sellers.
• Contract Administration – manage relationships with
sellers.

7.2 Monitoring and Controlling the Project

During the execution of the process any number of things

could happen. The hopes of the project team are that the
planning performed before the execution was extensive
enough to identify and plan for all the hurdles that may
occur. In all likelihood, no matter how much planning was
done, something will always occur during execution. The
best a project manager can do is catching the problem
quickly and resolve. Therefore, the project's performance
should constantly be measured to identify variances from
the plan. These variances are entered into the control
processes in the nine processes areas. If the variances are
significant, adjustments are made to the plan. For instance,
if a finish date for an activity is missed, then any later

32
Project Management

dependence need to be pushed out or other plans put in

place to return to the planned schedule.

The core processes for the Process group, Controlling and

Monitoring include Performance Reporting and Overall
Change Control. Performance Reporting supports the
collection and dissemination of performance information.
This information typically takes the form of status reporting,
progress measurements, and forecasting. Ideally, the
areas that are measures are project dates, resource use,
and cost. The intent is identify if the project is on track and
if not, how far above or below the planned estimates.

The second core process is Overall Change Control.

Whenever the project is off track either by being under the
estimate or over the estimate, the project may need to be
adjusted. The need for a change is a possibility based on
the extent of the project planning performed. Some project
planners may make a single value estimate. Others create
a range for the estimate, creating a worst case and best
case estimate for time, money, and resources. In the
second estimate style, the variance may force a change if it
falls outside the estimate range. If a change is required, it
can have an impact on every future aspect of the project
just like ripple across water. Many aspects of the schedule,
the budget, or the resources may be hard coded to the plan
meaning that they cannot be changed. The planning
should have identified these situations and revisiting the
plan should adjust to meet these objectives.

33
Project Management

Facilitating processes serve to support the core processes.

They include:
• Scope Change Control – control change to project
scope.
• Schedule Control – control changes to the project
schedule.
• Cost Control – control changes to the project budget.
• Quality Control – monitor project results for
compliance to quality standards that apply and
identify methods for resolving noncompliance.
• Risk Response Control – respond to changes in risk
over the life of the project.

7.3 Closing the Project

Closing out the project involves two processes:

Administrative Closure and Contract Close-out.
Administrative Closure happens at the end of each project
phase and the end of the project to formally close out the
cycle of work. The purpose of this process is to generate,
gather, and disseminate information related to the cycle
being closed. The information will typically consist of
reporting on the work that has been done and the resources
that were used. The information is usually supplied to
business managers, human resources, or financial
accountants, as well as stakeholders.

A project typically starts with a contract, or a written

agreement describing the scope and deliverables of the

34
Project Management

project. Contract Close-out encompasses the activities

required to validate that the project has met the terms of the
written agreement. It allows the project manager to go back
to the customer and finalize any outstanding issues or
discoveries that may have risen out of the course of the
project but not resolved usually because the action would
have been outside the scope of the project.

35
Project Management

36
Project Management

8 Framing Project
Management
To this point, the project and the disciplines used to
manage the project have been discussed in terms of cycles,
both for the project phases and the life cycle of the process.
Core processes in the project cycle build on each other to
transform input into a workable result for the next phase of
the project. The core must be used on all projects.
Facilitating processes exist to support the core processes.
Although all the facilitating processes are utilized in a
project, their use is varied based on the situation at hand.

Many people would think that executing a project is simply

doing the work to create a deliverable and, though that this
is part of a project and the bulk of the effort for the project, it
is not all of what encompasses successfully completing the
project. There are nine areas of knowledge that are applied
to the discipline of project management, each covers a
portion of the necessary disciplines required to move a
project from beginning to end. The 44 processes utilized to
create the cycles are broken down into these nine
knowledge areas. They are:
• Project Integration Management handles the
coordination of key elements of the project. The
processes included in this area are project plan
development, project plan execution, and overall
change control.

37
Project Management

• Project Scope Management ensures that the work

required to successfully complete the project are
included in the project plan. Any work that is not
required for the success of the project is kept out of
the scope. The included processes are initiation,
scope planning, scope definition, scope verification,
and scope change control.
• Project Time Management ensures the timely
completion of the project. Activity definition, activity
sequencing, activity duration estimating, schedule
development, and schedule control are the
processes contained within this area.
• Project Cost Management ensures that the project is
completed within the approved budget. Contained in
this area are resource planning, cost estimating, cost
budgeting, and cost control.
• Project Quality Management ensures the project
meets the needs that the project intended to fulfill.
The knowledge area contains the processes of
quality planning, quality assurance, and quality
control.
• Project Human Resource Management makes
effective use of the people involved with the project.
Contained in the knowledge area are organizational
planning, staff acquisition, and team development.
• Project Communications Management ensures that
the generation, collection, dissemination, storage,
and disposition of information is performed in an
appropriate and timely manner. The included
processes are communications planning, information

38
Project Management

distribution, performance reporting, and

administrative closure.
• Project Risk Management focuses on those
processes that are used to identify, analyze, and
respond to risks to the project. The processes
contained in this knowledge area are risk
identification, risk quantification, risk response
development, and risk response control.
• Project Procurement Management assists in the
acquisition of goods and services from outside the
performing organization. The processes included
are procurement planning, solicitation planning,
solicitation, source selection, contract administration,
and contract close-out.

The knowledge required for managing projects are usually

specific to the project management discipline, however
sometimes overlap is found with other management
disciplines. General management focuses on the planning,
organization, staffing, execution, and control of the
operations. Many of the disciplines used in project
management are also found in general management
including organizational behavior, financial forecasting, and
planning techniques. Some projects are definable by the
industries that they are utilized. Called application areas,
the projects found within these areas have common
elements significant to related projects but not needed in all
projects. The applications areas are generally defined as
technical elements which are found in software
development, pharmaceuticals, and construction

39
Project Management

engineering projects; management elements found in

government contracting and new product development; and
industry groups such as automotive, chemicals, and
financial services.

The processes used by project management interact with

the processes within an individual knowledge area as well
as interact with the processes in other knowledge areas.
How or when the processes interact depend on the type of
project involved, the application area, the management
structure of the performing organization, and the constraints
and limitations on the project. Although the practice and
experience of project management have determined the
common trends of process interactions, the processes may
overlap or interact in ways that specified in any
documentation. The intention of any process description is
to provide the project manager and team enough
knowledge to discern when a process is being initiated.

8.1 The Project Plan as an Integration Product

The project manager's primary responsibility is to deliver

acceptable results to the customer in a timely and
affordable manner. To accomplish this, a great deal of
coordination of the project elements is required. Project
Integration Management provides the framework for this
coordination. The processes that make up this framework
assisting in the development, execution, and change of the
overall project plan.

40
Project Management

There are many processes found in project management

that deal with the specific planning of project components,
such as time, resources, and budget. The plans need to be
integrated together as a whole and then executed. As the
project progresses, events may occur that impact one or
more of the plans and they have to be reevaluated and
adjusted. When the individual plans are readjusted, the
overall project plan also needs to be adjusted.

While integration of the project processes is important,

several other integration activities are also required. A work
of the project must integrate with the ongoing operations of
the business. Operations will not halt or be slowed simply
because a project exists. Many business operations have
deadlines, quotas, and expectations placed on them. The
project cannot interfere with the fulfillment of those
operational objectives. Many operations have continual
improvement mechanisms in place, so the construct of the
operational state at the beginning of a project may be
different than the operational state at the end of project.
Staying abreast of any operational changes can be valuable
information for the success or failure of a project.
Sometimes, issues are identified that are not within the
scope of the project to resolve but once communicated, a
resolution is sought through another project or through the
operational improvement processes of the business.
Awareness of these actions is prudent for coordinating
project activities. Additionally, deliverables to the project
may be found: these are products that are necessary to the

41
Project Management

project but are outside of the scope of the project either

because they are assumed to already exist or because they
are performed by members outside of the body of
stakeholders. For example, an assessment of power
consumption may be the product of the electrical
engineering department and required by the project, but the
creation of the assessment is outside the boundaries of the
project. In this case, the project manager needs to
integrate the activities of the project to coincide with the
development of the assessment of an outside entity,
namely the electrical engineering department. Quality
assessment because of regulatory standards may require
the skills of a quality management professional, but the
assigned project work is only one task in the project. This
professional may not become a core team member for the
project, so the project manager has to coordinate with the
quality control department to ensure that the work is done in
a timely manner.

8.1.1 Developing the Project Plan

The major focus of the integration management processes

is the creation and maintenance of the project plan. The
project plan is a consistent and coherent document that
encompasses the outputs of the planning processes to
guide both project execution and project control. The
project plan is a living document, subject to change
throughout the life of the project. The goal of project
management is to identify a final project plan as quickly as

42
Project Management

possible and apply change control to the project plan to

manage how and when the plan is changed. The purpose
of the project plan is to guide project execution, document
project assumptions, document plan decisions with primary
paths and alternate paths if any, facilitate communication
with all stakeholders, define key management reviews, and
provide the baseline for measurement project effectiveness,
progress and control.

In addition to the outputs of other planning processes, the

development of the project plan can also include historical
information, organizational policies, constraints and
assumptions. Historical information is typically consulted
on during other planning processes and involves statistical
information, past project information, and other information
that may affect how the project proceeds. For instance,
budget constraints may be time stamped; that is, the project
has a certain amount of money for a set time but a different
amount after a specific date. This can impact how and
when money is spent on the project. Or this is the second
time this project has been initiated. The first attempt failed
and the project manager looks at the conditions of the failed
attempt to ensure the same mistakes are not repeated.

Every organization has formal and informal policies that

may affect the project. Many of these policies will come
from governing entities outside of the project that have
responsibilities related to the operational side of the
business. The more common governing entities are

43
Project Management

responsible for quality management, personnel

administration, and financial controls.

Assumptions and constraints are factors that affect the

project planning, execution, and outcome. Assumptions are
typically generated within the planning stage and should be
noted in all occurrences. For instance, the delivery date of
a resource is uncertain, so the project team assumes a
specific date for planning purposes. Assumptions are
considered to be true, real, or certain for the project plan.
As the project progresses, the assumptions may prove to
be false, unreal, or uncertain and the project plan is
impacted. There is an element of risk involved with
assumptions. Constraints are defined factors that limit the
project in some way. A budget is a constraint that limits the
amount of money spent. A time table limits the amount of
time given to complete the project. The scope of the project
constrains the work done by the project. Contracts provide
a number of constraints that must be incorporated into the
project and adhered to under all conditions.

The tools and techniques utilized for development of the

project plan include any number of methodologies available
for project planning, the skills and knowledge of the
stakeholders, and any adopted Project Management
Information System (PMIS) by the company. Many ways
for organizing and presenting project plans can be found
and many have the same common elements found in them.
PMBOK does not require any particular method be used to
develop, organize, or present a project plan be used; it

44
Project Management

does however identify those elements that have recognized

value to the project. Some of the elements promoted for
the final draft of a project plan include:
• Project charter
• Description of the approach or strategy for project
management
• Scope statement with project deliverables and
objectives
• Work Breakdown Structure (WBS)
• Cost estimates, scheduled start dates, and
responsibility assignments integrated with the WBS
• Performance measurements baselines, specifically
around cost and time
• Major milestones and target dates
• Key or required staff
• Key risks, including constraints and assumptions and
the responses planned for each
• Subsidiary management plans, i.e. scope, time,
budget, etc.
• Open issues and pending decisions
Also included could be the following supporting details:
• Additional information found during the planning
phase but does impact the planned scope of the
project
• Technical documentation such as requirements,
specifications, and designs
• Documentation of relevant standards and
regulations.

45
Project Management

8.1.2 Executing the Project Plan

The primary process of providing the project deliverables

and meeting project objectives will be performed in the
project plan execution process. The guide to project
execution is the final project plan and any supporting
details, organizational policies and/or procedures that need
to be followed, and as the project progresses, any
corrective action put into place to realign the project.

The execution of the project plan relies heavily on the team

members of the project and any key individuals required to
support the product or service that the project is affecting.
As such, skill and knowledge related to the product or
services is typically the most important requirement for
successful execution. To ensure that the proper staffing is
in place at any given time of the project, a work
authorization system may be involved. This form procedure
ensures that the right people are working the project at the
right time by fulfilling written authorizations. The
authorization typically includes the required skills and
knowledge, the work to be done, and the time and cost
limitations in place for the activity.

To properly execute the project plans, general management

skills may be required, such as leadership, communication,
and negotiating. These skills will definitely be required by
the project manager, but may also be necessary for the
team members of the project. In many situations, team
members may be tasked with activities that will be

46
Project Management

performed away from any of the other team members in

parallel to the activities assigned to those team members.
Status review meetings provide an opportunity for the
project team to communicate with each other on the
progress of their assigned tasks, to communicate any
issues and risks that may have been identified, or to
declare any dependencies that need to be fulfilled.

Project team members may be asked to update any

existing project management information systems that may
require project progress information. Depending on the
system and the work involved, the task of updating the
system may fall on the project manager to complete. The
execution of the project plan lead to either work results or
change requests. Either the activities identified by the
project plan produced the result intended or they didn't.
Many times, the expectation of the work results are
unfulfilled because of a change of assumptions, constraints,
issue, or misinformation. The result may require a change
to the project which is initiated by the creation of a change
request.

8.1.3 Controlling Change to the Project Plan

Changes to the project plan have to be coordinated and

controls to minimize the impact of the change to the entire
project. In most projects, change will be present, therefore
it is prudent for the project manager to plan for change and
establish controls from the very beginning of the project on

47
Project Management

how and when changes will be made to the project plan.

The requirement of change control is rooted in:
• The necessity of maintaining performance baselines.
Every change should be reflected in the project plan,
but only changes in scope will change the
performance baselines established.
• The possibility of changes to product scope forcing a
change to project scope and minimizing the impact
of such as change.
• Coordinating changes across knowledge areas: a
change in schedule may impact cost, risk, quality,
and staffing.

Overall change control utilizes the project plan as the basis

for its work. The process is initiated by performance reports
and change requests. Typically, a formal, documented set
of procedures for controlling change is already in place for
use by the project. If not, the project team may have to
develop one. Many change control systems apply a formal
review and approve procedure and the opportunity for
stakeholders to approve or reject a change request. Most
change control systems have the ability to handle
emergencies; these are changes that need to be approved
and executed but cannot wait for formal review of the
change request. Some systems will even allow for
“automatic” approvals for certain predefined changes. All
changes must be properly and completely documented.

Configuration management is used by change control as a

documented procedure for applying technical and

48
Project Management

administrative direction and monitoring. The purpose of

configuration management form a project perspective is
that it identifies and documents the functional and physical
characteristics of an item or system, controls the changes
to such characteristics, record and report any changes
made, and audit the items or systems to verify requirement
conformity. It is important to note a change control process
may exist within the operational aspect of the business as
well as the project management aspect. Sometimes, the
process is different for both but they use the same change
control system. Sometimes the process utilizes completely
different systems that need to talk to each other. Any some
instances such as configuration management require that
both systems provide the necessary output of changes to
the appropriate parties.

Change control may utilize performance measurement, the

project management information system, and additional
planning as tools and techniques for ensure success for
controlling change. Change request going through the
overall change control process typically result into updates
to the project plan, corrective action and/or an exercise
called lessons learned which identifies the causes of project
variances and the reasons for actions resolving or
mitigating the variance.

49
Project Management

8.2 Putting a Stake in the Ground – Project

Scope

One of the hardest components of a project to maintain is

project scope. The scope of the project details all the work
required by the project to deliver and only the work
required. Unfortunately, influences from business culture,
social cultures, issues, risks, and discoveries will be
constantly at play. Because many of the project team
members will be working within the operational side of the
business, they will see or hear of activities, technologies, or
decisions that may impact the project. They may pressured
to do additional work to incorporate ideas, concepts,
activities, or even technologies, or feel that the
incorporation is necessary themselves and take it on. The
problem is that anything that changes the intended
execution of the project plan is a change that most be
controlled properly. The result is actively preventing these
influences from impacting the project plan or graciously
accepting the influences through change control.

8.2.1 Igniting the Project

The scope of the project essentially shields the project from

outside influences and change control is the gate where
those influences are allowed to enter. As a result, scope
protects the integrity of the project and ensures its success
within the context of its predefined requirements,
deliverables, and constraints. Scope is typically the very

50
Project Management

first step in initiating formal acceptance of a project. When

projects are authorized, they are typically associated with a
basic scope statement. Though some work may be
necessary to define the scope more, the project can be
recognized in general terms. Many projects are a result of
one of more reasons: the most common are a demand in
the market, a new business need. A customer request, a
technological advance, or a legal requirement. In initiating
a project, some description of the expected product or
service is provided that is mapped to the reasons already
mentioned as well as how the product and service apply to
fulfilling the strategic plans of the business. Information
aiding the selection of the project may be included, such as
financial return, market share, public perception and more.

Many companies have some method for selecting project.

Those methods usually fall into two categories. The
company may select projects based on benefit analysis,
generally using comparative approaches, scoring models,
benefit contribution, or economic models. The method
using benefit measurement is typically used one the
companies has several projects being proposed and have
to choose some over others. However, some companies
base their decisions not on the comparative benefits of the
projects proposed, but on the definable improvements to
the current operational environment. These proposed
improvements are typically the result of intense
mathematical models using programming algorithms to
promote optimization opportunities for the business. Some
businesses use a combination of both methods. In some

51
Project Management

cases, project initiation requires the use of expert judgment

from different parties. These experts may be found in other
departments, outside consultants, professional and
technical associations, or industry groups.

The goal of initiating a project is to have agreement for the

project. Once the project is agreed to, a project charter is
created that formally recognizes the project's existence and
includes the business need that the project is addressing as
well as the description of the product or service that will be
the primary result of the project. A project manager is
identified and assigned to the project and basic constraints
and assumptions are generated. The initiation process is
used not only at the beginning of the project but also the
beginning of each project phase.

8.2.2 Creating the Stake

The key deliverable of project scope planning is a written

scope statement, a document that serve as the basis for
future project decisions with specific criteria to determine if
the project of phase has been completed successfully. For
most projects, the components of the scope statement are
already present and the document just needs to be written.
The inputs to the planning the scope is the description of
the product or service, the project charter, constraints and
assumptions.

Several tools and techniques assist in creating the scope

statement. The first is any product analysis that allows a
52
Project Management

greater understanding of the product or service which the

project will deliver. These techniques can include anything
from systems engineering analysis to analysis for value or
function, or more. The point is to understand the product or
service sufficiently to address the boundaries required to
deliver it.

Obtaining a benefit/cost analysis provides the estimated

outlays and returns of various project alternatives as well as
the relative desirability of those alternatives. These
alternatives are typically generated through numerous
general management approaches including brainstorming
and lateral thinking.

The scope statement should include directly or by

referencing other document the justification for the project,
a brief summary describing the product, a list of all
deliverables expected from the project, and the objectives
of the project. In addition to the scope statement, any
supporting details related to the scope and its development
should remain accessible as well as a plan for managing
scope throughout the project.

8.2.3 Defining the Boundary Limits

When creating the scope statement, a list of project

deliverables were created. Some projects have huge
deliverables or more than the usual number of deliverables,
both situations requiring that major project deliverables be
broken into smaller, more manageable components of the

53
Project Management

project. The purpose of this breakdown is to improve the

accuracy for estimating cost, time, and resources, define a
better baseline for performance measuring, and to facilitate
clear assignments of responsibility. The need to define the
scope into smaller components is critical to the success of
the project.

To assist in defining the scope are the scope statement, the

constraints and assumptions already obtained on the
project, any historical information and the outputs of
process in other knowledge areas to identify the possible
impact on the project scope definition?

At this point, the project manager may begin looking at

templates for the work breakdown structure or the WBS
from a previous project. Though each project is unique,
WBSs are often reused for deliverables that are similar to
some extent. Especially for manufacturing or development
industries, many projects may have similar enough
activities that a template can be used. However, a template
should not be used to take a short cut in developing the
scope and project plan of a project, but to be used a guide
to ensure that many of the steps required for a particular
type of project is included.

The real work of defining scope is the breaking down of the

project deliverables into manageable components. The
process for this activity is called decomposition. The first
step is to identify the major elements of the project. These
usually are the project deliverables and the project

54
Project Management

management tasks. They may be further broken down to

reflect the different phases of the project. If an adequate
estimate for time and cost can be applied to the different
deliverables at this time, then provide those estimates.

The third step is to identify the elements of the deliverable.

These elements should be described in terms of tangible,
verifiable results to properly facilitate measuring
performance. For each element, apply a cost and time
estimate to it if possible.

After creating the deliverable and its elements, the

correctness of the decomposition needs to be verified.
Some questions to ask during the verification step are:
• Are the lower level elements both necessary and
sufficient for completion of the decomposed item?
• Is each item clear and complete in its definition?
• Can each item be appropriately scheduled,
budgeted, and assigned?

At the end of the decomposition, a complete work

breakdown structure is available. The WBS serves as a
deliverable-oriented grouping of project elements that
defines the detailed scope of the project. Activities not in
the WBS are not part of the scope of the project. The WBS
is not a presentation method; however, the WBS is
sometimes presented in a readable form like a chart or
unstructured activity list.

55
Project Management

Each item in the WBS is typically assigned a unique

identifier and collectively known as a code of accounts.
Groupings of items at the lowest levels of the WBS are
called work packages. The purpose of the identifier and
work packages are to provide a consistent method of
identifying items in future communications. Along with the
identifier, each work element should have a description
attached to it. These descriptions are collected into a
WBS dictionary. The entire WBS now becomes a project
result for scope verification.

8.2.4 Announcing the Claim

To this point the project team has been working to

understand the real scope of the project or phase. They
have identified what is supposed to be done through the
project and how it will be done. They have provided the
cost, time, and resource estimates they believe are
necessary to complete the project successfully. The format
they have used to organize and communicate this
information are the scope statement and the WBS. Now is
the time to ensure that the other stakeholders agree.

The scope verification process is the avenue to obtain

formal acceptance of the project scope. In later parts of the
project, it is the process used to obtain acceptance that the
scope has been fulfilled. If the project is terminated
prematurely, the scope verification process will establish
and document the level and extent of completion already
made on the project.
56
Project Management

Sometimes scope verification is confused with quality

control since both are concerned with the end result of a
project. However, they are not the same. Acceptance of
the work result is the concern of scope verification while the
correctness of the work result is the concern of quality
control.

To initiate the scope verification process, the project work

must have created a result either fully complete or partially
complete. Initially, the result is the scope statement and the
WBS, but later the result is a product from executing the
project plan. Along with the products coming out of the
execution phase, documents describing the products
should be included for review. These descriptions can take
the forms of technical documentation, drawings,
specifications, plans, etc. and vary from one application
area to the next.

Together, the product and the supporting documentation

will inspected by the stakeholders. The inspection may
require any form of measuring, examining, and testing the
product. Most stakeholders are looking to determine if the
product conforms to the initial requirements presented at
the beginning of the project. Inspections can happen at any
time during the project and though the project manager may
have scheduled some inspections within the project plan,
unplanned inspections may be asked for. The term
“inspection” is often replaced by calling the activity reviews,
product reviews, audits, or walk-throughs. In some

57
Project Management

application areas, these different terms have different

meanings with very specific agendas attached to them.

The purpose of the inspection and the scope verification

process in which it occurs is the formal acceptance of the
work result. Sometimes, the acceptance is conditional
especially on product that are partially completed at the end
of a phase.

8.2.5 Fending Off the Claim Jumpers

As the project proceeds, several influences may appear

that threaten the scope of the project. Discovery of a
similar project with a slightly different scope from another
area of the business may result in the merging of the work
of the two projects. Identifying a needed resource or
improvement in the operational side may encourage the
operational side to attempt to have the project perform the
work instead of utilizing the resources and operational
budget. Changes in priority on the operational side may
change the already limited resources and budget available
to the project. Changes in strategic direction may change
the direction of the project or new partnerships created on
the operational side of the business may introduce new
stakeholders to the project who have different expectations
or agendas. Even the individuals who are part of the
project team may come to the project with their own
agendas and expectations of what the project must do.

58
Project Management

These influences are not always negative but they do need

to be controlled. The means for that control is the scope
change control process. The process is concerned with
three primary objectives:
1. Determining when and how scope changes have
occurred.
2. Ensuring the factors that are changing scope are
influenced sufficiently to have the changes be
beneficial to the project.
3. Managing the actual change in scope when and if
they occur so that they are properly integrated with
the other control processes handling time, cost,
quality, etc.

Scope change control starts with the WBS, performance

reports, change requests, and the scope management plan.
The WBS defines the baseline to the project's scope. Any
changes to the WBS whether intentional or not is a potential
change to the scope of the project, specifically in the area
of adding or removing activities. Performance reporting on
the project or the interim product may identify issues that
need to be addressed. Change requests can happen in a
variety of ways and from any direction. Most change
requests occur because of an external event like a change
in regulations, an error or omission to defining the product
or the project, or a value adding change to the environment
such as new technologies are now available which will
reduce costs if taken advantage.
To change the scope, the project will use whatever system
they have in place to control scope changes. The system is

59
Project Management

usually described in the scope management plan and is the

set of procedures used to manage scope changes properly.
The system defines the paperwork necessary, the tracking
systems that need to be used, and the approval levels for
authorizing changes to the scope. The scope change
control system should be integrated into the overall change
control system as well as any systems that are in place to
control product scope. If the project is a result of a contract,
the scope change control system must comply with any
contractual provisions that are relevant.

Many times a potential change in scope is the result of an

identified variance in performance reporting. Or
performance reporting may be able to identify the
magnitude of any variance on a proposed change in scope.
Either way, the use of performance measurement can be a
helpful tool to determine the success and validity of creating
a change in scope. At the very least, changes in scope
may impact what is being measured or how it is being
interpreted. Scope changes may require changes to the
WBS or the previous analysis of alternative approaches.

The result of changing scope requires the appropriate

modifications to the original agreed-upon scope as defined
by the WBS with the adjustments to cost, time, quality, or
resources that may apply. Scope changes are always fed
back through the planning processes and the appropriate
technical and planning documents are updated. The
stakeholders are notified of scope changes. Any corrective
actions required to ensure that project performance stays in

60
Project Management

line with the project plan is taken and the lessons learned
identifying the cause of variance in performance and the
reasoning behind the corrective action should be
documented.

8.3 Conquering Time

One of the defining characteristics of a project is that it is

temporary: a project has a definite start date and a
definitive end date. Though the exact dates may be
negotiable, it is clear that time is a limited resource for the
project. To successfully manage a project within that limit,
project time management is a knowledge area that is
consistently and effectively utilized throughout the life cycle
of the project.

The PMBOK processes found within the knowledge area of

project time management includes activity definition, activity
sequencing, activity duration estimating, schedule
development, and schedule control. Using these
processes, the project team determines that specific
activities that are required to produce the desired project
deliverables. These activities will typically have some
interdependencies attached to them; that is, one activity
may require that another activity be finished before it is
started. Additionally, the project team will determine the
number of work periods required to complete the individual
activities. A work period may be represented in hours,
days, weeks, or even months but is consistent throughout

61
Project Management

the project. All this information is now compiled into a

schedule to be used by the project manager to build the
WBS and resultant project plan.

The processes found within time management are

sometimes so tightly linked that the individual processes
are difficult to distinguish when performing, especially on
smaller project. They can be performed by a single
individual who is probably fulfilling the process
requirements for all the processes simultaneously.
However, the processes for activity sequencing, activity
duration estimating, and schedule development are distinct
processes using different tools and techniques for each.

8.3.1 Defining the Activity

The first step in time management is determining what

needs to be done. The process activity definition focuses
on identifying and documenting the specific activities
required producing the deliverables of the project. The
work done through this process is very similar to the work
done in defining the scope, the change is the perspective
used: time.

To start defining the activities, the process uses the WBS,

the scope statement, historical information relevant to the
project, constraints and assumptions. Decomposition is
used to subdivide the project elements into smaller more
manageable components. When decomposition was used
in defining the scope, the goal was to breakdown the
62
Project Management

project into deliverables or tangible items that could be

delivered. Decomposition from the perspective of time
management breaks down the deliverables into activities or
action steps required to produce the deliverables. In some
application areas, the WBS and the activity list are
concurrently developed. During decomposition, templates
may be available to determine the action steps required
especially in situations where a deliverable is similar to
another deliverable on another project.

The results of activity definition is the activity list and any

supporting detail. The activity list is an extension of the
WBS. From a project perspective, there is a distinction
between work and activity. For instance in an IT project for
a help desk, a defined work item may be be acquire power.
The activities required to acquire power may include
assessing current power capabilities, creating work orders
for new or changes in outlets, negotiating with power
company, fulfilling on work orders, testing power
capabilities, etc. The list of activities provide greater detail
for completing the work described in the WBS. In other
terms, the WBS defines what needs to be done while the
activity list defines how it is done. Especially for large
projects, communicating the project in terms of activity lists
is not seen, though those lists are used to clearly define the
progress of the work required. In developing the activity
lists, the project team may identify additional deliverables
that need to be added to the WBS or clarification or
corrections to the descriptions found in the WBS. These

63
Project Management

updates are often called refinements and occur most often

when the project includes new or unproven technology.

8.3.2 Which Came First, the Chicken Or the Egg

Once the activity list has been generated, the project team
needs to determine the order in which the activities are
performed and when they need to be performed to meet
project objectives. The activity sequencing process focuses
the effort to identify and document the dependencies
between activities. The process is either done manually or
through the aid of a computer.

To start the process, the project team will need the activity
list, the product description, the constraints and
assumptions. They will also require a list or understanding
of the dependencies on the project. There are three
categories of dependencies that the project team will deal
with, mandatory, discretionary, and external.

Mandatory dependencies are inherent in the work being

done. Physical limitations are primary examples of
mandatory requirements. If the project was to build a
house, completing the roof cannot be done before the walls
are put up. Therefore the roof has a dependency on the
walls and it is mandatory because it has to happen.
Mandatory requirements are also called hard logic.

Discretionary dependencies are placed on an activity by the

project team. This dependency describes a situation where
64
Project Management

a set of activities can be performed in any sequence, but

the project team desires a specific sequence to be utilized.
The reasoning behind the decision may be a result of
determining best practices in an application area or some
unusual aspect of the project where the specified sequence
becomes more desirable. The use of discretionary
dependencies should be limited because it will limit the
scheduling options later. These types of dependencies are
often referred to as preferred logic, preferential logic, or soft
logic.

External dependencies occur when project activities have

some requirement on non-project activities. A software
development project is depending on the delivery and setup
of hardware. A construction project requires an
environmental hearing on a location before site preparation
can begin. These dependencies are noted in the activity list
and used during scheduling.

There are several methods for determining and presenting

activity sequences. The first method is called precedence
diagramming (PDM). It constructs a project network
diagram connecting nodes, or activities, with arrows to
show dependencies. Most project management software
packages use this method. The method defines four
dependency relationships:
• Finish-to-start is the most common logical
relationship and describes the relationship where
one activity must finish before the next activity is
started.

65
Project Management

• Finish-to-finish describes situations where one

activity must finish before another activity can finish.
This is common when parallel work is being done
like modules in a software package. There is no
dependencies between the modules to require one
being done before the other, but since the modules
all make up the software package, they all must be
completed before the package is complete.
• Start-to-start relationships describe situations where
one activity must start before the next activity can
start. There are few times when this relationship is
used. A basic example of this is driving a car.
Before actually driving out of the driveway, the
ignition of the car must be started. Without starting
the car, the next activity cannot even be started.
Using the Finish-to-start relationship can also be
applied here and is sometimes more desirable when
using a project management software package
because unexpected results may be produced later
on.
• Start-to-finish is the rarest logical relationship defined
and typically only by professional scheduling
engineers. The relationship described calls for an
activity to start before the next activity can end. This
is a very precise calculation. One of the simplest
examples is the school lunch bell. Most people
would say that lunch began when the school lunch
bell rings. But in the perspective of the classroom,
when the school bell rings, class ends. From the
second viewpoint, it is the start of the school bell that

66
Project Management

ends the teaching of the class.

Another method for sequencing activities is the arrow

diagramming method (ADM). Similar to the PDM in that it
uses arrows connecting codes to describe dependencies,
the ADM only uses finish-to-start relationships and as such
has become the technique of choice in some application
areas. To handle other logical relationships, the creation of
dummy activities may be required. Neither PDM nor ADM
allow for sequential activities that loop such as software
testing, or conditional activities such as updates to the
design if inspection discovers an error. To handle project
that handle these situations, a method is available called
conditional diagramming.

Of course, some activities of a project may be similar to the

activities performed on a previous project and have become
templates. For activity sequencing, these standardized
activities are referred to as network templates, subnets, or
fragments. These subnets are particularly useful for
duplicate activities within a project such as building floors in
a high rise building, or clinical trials at a pharmaceutical
company, or developing several modules of a software
package.

The primary result of the activity sequencing process is the

project network diagram. The diagram is a schematic
representation of the projects activities and the logical
dependencies between them. The diagram is accompanied
by a summary narrative to describe the sequencing

67
Project Management

approach and descriptions of any unusual sequences. Out

of the sequencing work, updates to the original activity list
may have been identified which may also require updates
to the WBS. The project team must not update the WBS
directly without first updating the activity list.

8.3.3 Hard-Boiled or Soft-Boiled

To this point, the project team has determined the activities

that are required to produce the deliverable and the
sequence required of those activities. The next step is to
determine how much time will be required to perform each
activity. To do this involves the activity duration estimating
process. The person on the project with the most
experience in the nature of the work typically does the
estimating.
The estimation is done based in work periods, whether it is
hours, days, weeks, or months. The work period must be
consistent throughout the project. The most common work
period is the day, but the decision on duration should be
based on the type of work required. If most of the activities
involved take only a few minutes to perform, than a shorter
duration may be required. In estimating the duration, the
project team needs to take into consideration elapsed time.
For example, while painting may take a day, it requires 48
hours to fully dry. That means the total duration for the
activity is actually three days. However, the day of the
week in which the activity is performed or weekend and
holidays may have an impact on how the duration is

68
Project Management

perceived. If painting is scheduled for a Friday and no work

is done until the following Monday, though the duration is
three calendar days, the reality is one business day. Most
project management scheduling programs handle these
types of problems automatically. Whatever, the case,
specific notes should be included to explain any timing
considerations. For instance, an activity such as obtain
quote may require 15 minutes of effort from the project
team to contact a contractor but the duration estimate is
four days to allow time for the contractor to schedule a visit,
created and deliver an estimate.

To begin estimating the duration of the activities, the activity

lists is required, along with the constraints and assumptions
already developed on the project. Historical information
should be included from previous projects and commercial
duration estimating databases which provide standard
recommendations or policies such as how long paint should
dry or how long a government agency takes to respond to a
request. The experience that the individual project team
members bring provide historical information to the project.
Additionally, resources requirements and capabilities are
necessary because they both can impact the duration of the
activity. Generally speaking, if an activity can be done in
four days by one person, it can be done by two people in
two days. Also one person working half-time will take twice
as long as another person working full-time.

The capabilities of the resources also will impact the activity

duration. Given everything being equal except experience,

69
Project Management

someone during the activity required for the last ten years is
more likely to perform faster than a person who has done
the same work for only one year. This is one of the reasons
that some projects include in estimating duration a worst
case and best case duration to the project. A worst case
duration is the longest expected time required to complete
the work while the best case is the shortest. Though both
estimates may be available, the project manager usually
manages to a mean of the two.

The tools and techniques used to estimate duration start

with expert judgment. This is the reason for having team
members assigned to the project who will be executing the
project as well. When they create the estimate, they are
declaring a commitment to the duration. When the amount
of detailed information about the project is limited,
analogous, or top-down, estimating is performed. This
method uses the actual duration of a previous, similar
activity as the basis from creating an estimate for the
current project. Analogous estimating is most successful
when the previous activities are similar in actuality and not
just in appearance and the individuals preparing the
estimates have the expertise required. Another method for
estimating is simulations. This method allows the project
team to enter numerous assumptions which are used to
calculate multiple durations. The most common form of
simulation is the Monte Carlo Analysis.

The end of the process produces the estimates of activity

duration. As mentioned before, durations are typically

70
Project Management

delivered as a range of possible results: for instance 2

weeks plus/minus 2 days to indicate the activity will be done
in no less than 8 days and no more than 12. Sometimes
probability estimates are provided: for instance 15 %
probability that an activity will take more than 2 weeks
leaving an 85% chance that it will take less. In addition to
the actual estimates, any assumptions used to create the
durations should be included as well as potential updates to
the activity list which may have been found.

8.3.4 Scheduling

The next step is to schedule the activities using a calendar.

Typically done by the project manager with the aid of the
project team, the start and end dates for each of the project
activities is determined. To initiate building the schedule,
the necessarily inputs are the project network diagram, the
activity duration estimates, resource requirements, resource
pool descriptions especially with shared resources,
calendars, constraints and assumptions, and leads and lags
times. Inside the constraints, two major categories have an
impact on scheduling: imposed dates by the company, the
stakeholders, of the contract, and key events or milestones
which when scheduled cannot be changed without
changing expectations. Lead and lag times are also
important to consider. Lead times are often required to
allow for preparation before performing an activity. Lag
times are generally the time between two activities, such as
the wait time between ordering and installing equipment.

71
Project Management

Scheduling is most often done using mathematical analysis

which calculates the early and late start and finish dates
theoretically for all project activities without considering
resource limitations. The dates derived from mathematical
analysis are not the schedule but rather the time which the
activities should be scheduled given resource limitations
and other constraints. Several mathematical analysis
techniques exist:
• Critical Path Method (CPM) calculates a single
deterministic start and finish date based on the
sequential network logic and a single duration
estimate. The purpose of CPM is to determine which
activities have the least flexibility in regards to
scheduling.
• Graphical Evaluation and Review Technique (GERT)
utilizes probability in both network logic and activity
duration estimates to determine the best schedule.
• Program Evaluation and Review Technique (PERT)
uses sequential network logic and a weighted
average duration estimate to calculate project
duration.
• A special case of mathematical analysis is found with
duration compression which looks for ways to
shorten the project schedule without changing
project scope. It includes techniques like crashing
which analysis the trade-offs between costs and
schedule to identify where to obtain the greatest
amount of time compressions for the least amount of
cost. Fest tracking is another technique which looks
at performing tasks in parallel which would normally

72
Project Management

be done in sequential order. Crashing sometimes

results in increased cost while fast tracking can lead
to rework and increased risk.
Simulation can be used to create a recommended schedule
like mathematical analysis. Any of the methods mentioned
typically provides a preliminary schedule without applying
any knowledge about resource availability, capabilities, or
constraints. Resource leveling heuristics are applied to the
schedule to handle resource constraints. Resource leveling
often creates project durations that are longer than the
preliminary schedule.

Many of the project management software packages

provide the functions to perform mathematical analysis and
resource leveling. The result of the effort is the project
schedule with the planned start date and expected finish
date of every activity within the project. The project
schedule is considered preliminary until all the resources
assignments have been confirmed. The project schedule
can be represented in summary form as a master schedule
or in detail .Though it is usually found in tabular form,
presentations usually find the project schedule shown
graphically using project network diagrams with assigned
dated, bar charts showing the start and end dates
(sometimes called Gantt charts), milestone charts which
focus only on key deliverables, or time scale network
diagrams which are a combination of the project network
diagram and bar charts.

73
Project Management

Also included with the project schedule are any supporting

detail, the plan for managing the schedule and any updates
to the resource requirements?

8.3.5 Controlling the Schedule

Schedule control is a process very similar to the control

scope change process but from a duration estimate
perspective. The same inputs are used and similar outputs
are generated. The same tools and techniques are used,
except the use of the schedule change control system.
Because it should be linked into the same overall change
control system as scope management, it may have the
same system.

8.4 Banking On It

The project team has formulated the scope of the project

determining what the deliverables will be and the general
work requirements of those deliverables. The deliverables
were assessed to determine the activities required to
product them and estimates were provided to each of the
activities for the duration the effort. Out of the work, the
project team has a work breakdown structure and a project
schedule. In much the same way that the project is given a
limited time frame to complete the work, the project also is
provided a budget. Project cost management is the
knowledge areas consisting of processes utilized to
determine and management cost on the project. The

74
Project Management

primary concern of the cost management is the cost

resources for completing project activities; however not at
the expense of increased cost elsewhere. Though quality
management is concerned with the correctness of the
deliverable, the costs associated with producing a quality
deliverable should be addressed at the beginning of the
project. For example, engineering projects that limit the
number of design reviews may reduce project costs but
increase operational costs. This is often referred to as life-
cycle costing.

Cost management for a project is typically balanced with

the processes for cost management for the entire business.
In some companies, many of the mechanisms for predicting
and analyzing the financial performance of a product are
done outside of the project; in others, project cost
management. Stakeholders may measure costs in different
ways and at different time, forcing the project to understand
the information requirements of the stakeholders for
reporting purposes.

Project cost management deals with resource planning,

cost estimation, cost budgeting, and cost controls. In some
projects, these areas are often viewed as a single process,
but each has different tools and techniques used to
complete the work.

75
Project Management

76
Project Management

9 Leaning on Resources
To complete a project, physical resources are necessary
whether they are in the form of people, equipment, or
materials. Identifying the resources required and the
quantity needed is the focus of resource planning. Planning
for resources start with the WBS, historical information, the
scope statement and policies of the organization
referencing staffing, rental and purchase guidelines.
Additionally, any description of the resources that are
potentially available. This description is commonly called
the resource pool description and it varies from project to
project and even throughout the project. For instance, the
pool may consist of software developers for an application
project at the beginning a project, but later on have more
detail to only include Java programmers.

The primary tool used for resource planning is expert

judgment which can come from the project team members,
other units in the company, consultants, professional and
technical associations and industry groups. The purpose of
resource planning is the creation of resource requirements.

9.1.1 Applying Cost

Having identified the resource requirements, the project

team can develop an approximation of the costs required to
complete the project activities. For projects working under

77
Project Management

a contract, a distinction exists between cost estimation and

pricing. Cost estimating produces an assessment of the
quantitative result, how much it will cost the performing
organization to provide the product and service. Pricing, on
the other hand, is a business decision on how much the
performing organization will charge for the product of
service. Some issues have been opened because project
cost estimation was done after contract negotiation and
therefore, the pricing is lower than the estimate. Other
times, the project cost estimate forced the pricing up too
high for the product of service to be sold. Ultimately, the
goal of the project is to deliver a quality product or service
in the shortest amount of time and at the lowest cost
possible.

To begin cost estimation, the project team should have

access to the WBS, the resource requirements, the activity
duration estimates, historical information. A chart of
accounts is required that describes the coding structure for
reporting financial information to the company's ledger.
Finally, the resource rates for personnel, equipment, and
materials are needed by the project team. If the actual
rates are not known, than the rates themselves have to be
estimated.

The project team uses all these resources to begin

estimating the cost for each activity. The team can use
analogous estimating by looking at the actual costs used in
a previous, similar project. This method of estimation is
generally less costly to utilize but also less accurate.

78
Project Management

Another method is parametric modeling which uses project

characteristics in a mathematical model to predict costs.
The cost and accuracy of parametric models vary but are
more reliable when the historical information creating the
model are accurate, the parameters used are quantifiable,
and the same model can be used for small projects and
large projects. Bottom-up estimation estimates the
individual work items and then summarizes the individual
estimates to obtain the project total.

No matter the method used, the result eventually will be a

cost estimate for the project. The estimate reflects the
likely costs of the required resources. All resources that will
be charged to the project must be estimated and will
include, but not limited to, labor. Materials, supplies, and
even special considerations like inflation or cost reserve.
Costs should be represented using a consistent expression,
normally units of currency. However other units may be
used like staff hours or staff days but ultimately need to be
expressed in units of currency. Along with the cost
estimate any supporting documentation for understanding
the estimate s and a plan for managing costs should be
included.

9.1.2 Budgeting the Project

While estimating costs for the activities may identify the

likely expenses for the project, a budget involves
distributing a financial pool across the work items. Cost
budgeting establishes a cost baseline for measurement

79
Project Management

project performance. Cost estimates, the WBS, and the

project schedule are used to create the cost baseline, which
is a time-phased budget used to measure and monitor cost
performance on the project.

9.1.3 Controlling Cost

As with scope and time, controlling costs are very similar as

a process. A cost change control system should be in pace
which interacts with the overall change control system.
Changes in cost may impact scope, time and resources.

9.2 Managing the Right Stuff

Unfortunately, project may be started and completed, but

are not successful. The project may have been done on
time and according to budget and still fail. As far as
managing the project, the team was successful, but the
product or service that it delivers does not satisfy the needs
expected. Essentially, the tangible aspects of the project
were delivered, but the intangible aspects were not. What
was missing from project like this was a balanced focus on
quality management.

Project Quality Management from the PMBOK is

compatible with ISO 9000 and 10000 series of standards
and guidelines. Using these series as the basis for
describing quality management, PMBOK quality
management is compatible with proprietary approaches like

80
Project Management

Deming, Juran, Crosby, and others and non-proprietary

approaches like Total Quality Management (TQM),
Continuous Improvement, Lean Six Sigma, and others.
Project quality management addresses both the
management of the project and the product. Failure to
meet quality requirements in either area can have serious
consequences for the stakeholders. Current quality
management disciplines complement PMBOK project
quality management disciplines. Both recognize the
opportunity of customer satisfaction through conformance
to specification and fitness for use, management
responsibility, processes within phases, and the importance
of avoiding mistakes over correcting them.

Quality is “the totality of characteristics of an entity that bear

its ability to satisfy stated or implied needs.” Putting this
definition into the context of a project, the goal of project
quality management is to turn all implied needs into stated
needs through project scope management. One important
concept for project teams is the difference between quality
and grade. Grade often speaks to the functional use of a
product, so a product with low functionality may have a low
grade and still be a quality product.

9.2.1 Quality is Planned

The most important part of project quality management is

understanding the relevant quality standards that could
impact the project and putting plans into place that will meet
those standards. Quality standards can apply to the

81
Project Management

project, the disciplines of project management, the

reporting, the product and other deliverables. Essentially,
every aspect of the project and the work done inside of the
project. One tenet of quality management is that quality is
planned in, not inspected in.

The first requirement for planning quality is the

understanding the quality policy which describes “the
overall intentions and directions of as organization with
regard to quality, as formally expressed by top
management.” The quality policy of the performing
organization is automatically adopted for the project. If the
performing organization does not have a formal policy, the
project team will have to develop one. If the project is being
performed by multiple organizations, a quality policy that
encompasses the intentions and directions of all the
organizations will need to be developed.

Other inputs to quality planning are the scope statement,

the product description, standard and regulations, and
outputs from other processes. With these inputs the
planning can start. The benefit of meeting requirements for
quality is typically less rework, which typically leads to
higher productivity, lower costs, and increased satisfaction
to the stakeholder. The cost of meeting requirements is the
expense spent undertaking the activities of quality
management. A benefit/cost analysis will assist the project
is justifying the quality management activities on the
project.

82
Project Management

To measure performance to quality, the project may start

with benchmarking; comparing the project practices that are
being done or planned to be done with the practices of
other projects to generate ideas for improvement and
provide a standard to measure from. Understanding how
elements within a project or deliverables relate can provide
information on where quality issues may occur.
Flowcharting provides a number of ways to create this
understanding. Cause-and-effect diagrams show how
various elements can cause an effect, or problem. These
diagrams are also referred to as Ishikawa diagrams or
fishbone diagrams. System or process flowcharts also
show how various elements interrelate. An analytical
technique called design of experiments are often used to
understand different quality issues or potentials for the
product. The technique use assists in identifying the
variables that have the most impact on the quality of the
overall outcome.

The goal of quality planning is to identify where the potential

risks to quality will acquire and place plans around ensuring
the quality of the project and the product. The prime result
of quality planning is the documentation addressing the
methods used to control assures and improves quality on
the project. Included with the plan are operational
definitions which document what something is and how it is
measured by the quality control process. These very
specific documents are sometimes referred to as metrics.
Supporting documentation may be included to the plan and

83
Project Management

the definitions: one supporting document may be

numerous checklists to be used on the project.

9.2.2 Quality is Watched

The quality system created or utilized by the project team

will have systematic activities involved to bring confidence
to the project and stakeholders that relevant quality
standards are being met. These activities will be performed
throughout the life of the project. In many instances, a
Quality Assurance Department will be performing the work,
or they could be providing governance over ensuring that
the project team does the work.

Project Quality Assurance begins with the quality

management plan, the operational definitions, and results to
quality control measurements. Those inputs are used
during quality audits to the project and the products of the
project. Improvements to quality from the audits are
identified and communicated. Those improvements exist to
increase the effectiveness and efficiency of the project.
Those improvements typically go through the control
change process to be implemented.

9.2.3 Quality is Controlled

Monitoring the specific project results for compliance with

relevant quality standards is the function of quality control.
The process also identifies ways to eliminate the sources of
unsatisfactory results. The results of the project

84
Project Management

encompass both product results in the form of deliverables

and management results in the form of cost and schedule
performance. The project team should have a working
understanding of the statistical methods used in quality
control, such as sampling and probability. Additionally, they
should understand the differences of:
• Prevention and inspection – keeping errors out of the
process versus out of the hands of the customer.
• Attribute sampling and variable sampling – results
conforming absolute adherence versus degree of
adherence.
• Special causes and random causes – unusual
events versus normal process variation.
• Tolerances and control limits – acceptable result
versus controlled result.

Both product and project results are used with the quality
management plan and operational definitions to initiate the
quality control process. The process utilizes a number of
tools and techniques to perform the necessary work. One
of the simplest techniques is inspection over the work
result. By measuring, examining, and testing the result, the
individual or group inspecting the result can identify the
characteristics that are most satisfactory and ask pertinent
questions on the whole or specific parts of the result.

Mathematical analysis can be performed and presented in

the form of control charts, pareto diagrams, statistical
sampling and flowcharting. Each of these methods have
advantages over the other for displaying different types of

85
Project Management

information. Control charts are appropriate for showing

results over time and are used to determine if a process
such as cost or scheduling are in control. Pareto diagrams
are histograms and used typically to identify the frequency
of occurrences. Statistical sampling is a method for
inspecting a portion of a large population to identify major
characteristics of the whole populations. Samplings can be
made up of the customer base, a whole of requested
changes, or any large pool of results related to the project
or product. Flowcharting is used to identify the causes of
problems.

Trend analysis is another mathematical techniques used to

provide forecasting information on quality performance.
Using historical data, the analysis is used to identify where
potential problems may occur in the future and allow the
opportunity to correct. Trend analysis can be used to
forecast technical performance of the product as well as
cost and schedule performance of the project.

The results of quality control are in the form of quality

improvements, acceptance decisions, and completed
checklists. These results are typically used to make
adjustments to the process or force additional action to
rework an item. Rework is the frequent cause of delays in
schedule and going over budget especially when
unanticipated. The goal of the project team is to minimize
the amount of rework required on a project.

86
Project Management

9.3 Working with People

Despite the work involved with scope, schedules, budgets,

and quality, the core of the project involves working with
people. The intention of project human resource
management is to effectively use the people assigned to
the project, including sponsors, customers, individual
contributors, and external representatives. The knowledge
area encompasses the processes of organizational
planning, staff acquisition, and team development.

Much has been writing about dealing with people inside the
business world. Books can be found to handle general
management skills of leadership, communication, and
negotiation. Or motivational books describing the
differences and techniques of delegating, coaching,
mentoring, or motivating individuals. If a person is looking
for ways to build teams, manage conflict, or group
dynamics, they can find it. Even subjects like performance
appraisals, recruitment, retention, labor relations, regulation
compliance, and other administration skills have sufficient
resources on the shelves. All of this material is applicable
to project management with caution. Many of these books
focus on building long-term, ongoing relationships in the
business community. Projects are naturally temporary, so
relationships are typically new and in place for a finite
period of time. The nature and number of people assigned
to the project vary and not always consistent with the size
of the project. Many of the administration duties of human
resources are the direct responsibility of the project team,

87
Project Management

though they need to be aware of the requirements to

ensure compliance.

9.3.1 Working Together

Project human resources management begins by

understanding the relationships between people.
Organizational planning assists in identifying, documenting,
and assigning project roles, responsibilities and reporting
relationships. Those assignments may be to individuals or
to groups who are either a part of the performing
organization or external to it. Most of the work of
organizational planning is done in the early stages of the
project, though changes to the team may occur in the later
stages. The project's organizational structure will have a
direct impact on the communication requirements on the
project and therefore organizational planning is tightly
linked with communications planning.

A number of items are required for successful

organizational planning, the first being the project
interfaces. Three types are interfaces typically exist on a
project: organizational. Technical, and interpersonal.
Organizational interfaces are the reporting relationships
among different organizational units. These reporting
relationships may be formal or informal. The reporting
requirements may consist of formal, structured and detailed
reports provided with some determined frequency or a
notification of an event. Understanding these interfaces will
assist in understanding the potential reporting structures of

88
Project Management

the project as well as stakeholders. Technical interfaces

define the working interfaces between technical disciplines,
essentially establishing how the operational side of the
business work together. Similar relationships may be
duplicated within the project. Interpersonal interfaces focus
on the relationships between the individual members
working on the project.

With the project interfaces, the project utilizes the staffing

requirements which include what skills are required and
when, templates, stakeholder analysis and constraints. For
organizational planning the constraints may take the form of
the organizational structure of the performing organization,
contractual agreements with unions or other employee
groups, the preferences of the project management team,
or even the expected staff assignments. Many companies
have a number of policies, guidelines, and procedures in
place to support project human resources, as well as the
general body of knowledge related to organizational theory.

The principle objective of organizational planning is the

assignments of roles and responsibilities. These
assignments may vary over time, though most assignments
will be made to members of the project team who are
actively working the project and should not change during
the project. Project roles are and responsibilities are
closely connected to the project scope definition; a
Responsibility Assignment Matrix (RAM) is often used to
show the relationship.

89
Project Management

To manage the assignments, a staffing management plan is

created. Particular attention should be made to describe
how project team members are to be released when they
are no longer required on the project. Along with the plan
may be a graphical display of the reporting structure used
on the project. This display is typically in the form of an
organizational chart. Any supporting detail for determining
the assignments, the plan, or the reporting structure should
be included as well.

9.3.2 Finding the Right People

One of the easiest and hardest activities on a project may

be finding the right people to be on the project team. This
is partially due to the realistic certainty that the “best”
people are not available. So whoever is assigned to the
project must be able to meet project requirements.
Unfortunately, a constraint may be in place to force the
assignment of a single option for a particular spot on the
project team. Though in many companies, the assignments
are typically given to people who have been on projects
before, so a strong working relationship may already be in
place for the majority of the project team.

To acquire the proper staff, a project manager typically

must communicate the staffing requirements to the
appropriate managers, either human resource for all or
individual department heads. In some cases, a choice
needs to be made from a pool of staff resources. TO make
this choice, the project manager and business manager will

90
Project Management

usually look at previous experience, personal interests,

characteristics and availability. In some instances, the right
person needs to be recruited.

The techniques used to acquire staff range from pre-

assignment to negotiating to procurement. Pre-
assignments are typical of a competitive proposal where
specific individuals were promised to be part of the project.
Negotiation may be required with the business manager to
obtain the right person at the right time. If a person cannot
be found within the performing organization to fulfill some
portion of the project requirements, the project may have to
look at external resources to hire or contract in.

Whatever the method for acquiring staff, the end result will
be project staff assigned to every activities found into the
project plan. Many projects will create a directory of the
project team.

9.3.3 Developing Team

The intent behind developing a team is to improve the

individual contributions of stakeholders and their ability to
work as a team. Individual development servers the team
while team development service the project. In matrix
organizations team development can sometimes be difficult
since the individual team members are accountable to a
functional manager and a project manager at the same
time. In these situations, effective management of the dual

91
Project Management

reporting relationship is a critical success factor for the

project.

Team development begins with the project staff, the project

plan, the staff management plan, performance reports, and
external feedback. To develop the team, the initial step
may be to train the individuals or group to enhance the
skills, knowledge, and capabilities in order to properly fulfill
the activity requirements of the project. Working with the
group, team-building activities may be used to have the
group recognize and utilize the individual strengths of the
team members. The purpose of team-building in this sense
is to improve team performance. Some projects require
team members who are located throughout the global, with
little or no potential for the team to be physically located
together as a team. Especially for large projects,
collocation may be a necessary requirement to have the
majority of the team working together. Even on smaller
projects where members tend to do their duties at their
desk or on the floor, it can prove beneficial to have the team
meet in a conference room periodically to focus on the
project.

One development tool that can be sometimes overlooked

on projects is a system for rewarding and recognizing
individual and group contributions. Typically, if such a
system exists it is utilized at the end of a project, however
some benefit may be obtained by using it at the end of each
phase, especially on large or complex projects. Many
companies already have a system in place for the

92
Project Management

operational portion of the business and are adopted for

project management. Sometimes, these systems are
inappropriate or difficult to fit into the project management
model. Therefore, some companies have adopted separate
systems for project management use.

The intent of team building is to improve performance on

the project. Improvements in individual skills allow a person
to complete activities more effectively. Improvements in
team behaviors allow the team to focus on the technical
activities of the project. Improvements in both areas help to
identify and develop better practices for project
management. Additionally, focus on individual and team
development also provides awareness to sufficiently
provide information for performance appraisals.

9.4 Opening up the Lines of Communication

In addition to the activities required to manage a project and

to produce a product through the project, the most
important aspect to a project is the communication structure
that it uses. Throughout the life of the project, information
is being generated, collected, stored, disseminated, and
disposed of constantly. A project is successful because of
the critical links between people, ideas, and information.
Every person involved in the project must be able to send
and receive information in the language of project
management.

93
Project Management

Project communication management incorporates the

processes of communication planning, information
distribution, performance reporting, and administrative
closure. In incorporates all general information and
education associated with building effective communication
skills used by general business models. The actual
implementation of a communication structure on a project
may be influenced by the cultural, technical, and behavioral
aspects of the communication practices already found in
the performing organization or its customer.

9.4.1 Laying the Infrastructure

Communications planning involves identifying and

understanding the needs of the stakeholders in the areas of
information and communication: who needs what when
and how should it be presented. The need for
communication is self-evident for project work, the
information needs and the method for distributing that
information may differ from one project to the next.
Compiling the individual needs of the stakeholders will
provide the basic requirements for communication on the
project. The requirements will focus on the type and format
of the information requirements with an analysis of the
value of that information. The value applied can be used to
determine how project resources are used: if the
communication contributes to the success of the project,
resources will be provided, but where the contribution will
lead to failure of the project, resources will be denied.

94
Project Management

The technologies or methods available to transfer

information is a critical component to project success,
especially in cases where new technologies are used and
the stakeholders are not yet “trained” in its use. Some of
the considerations for the technology used are the
immediacy of the information need, the availability of the
technology, the expected project staffing, and the length of
the project. Depending on these considerations, the project
may adopt an extensively constructed avenue to
communicate information or they may simply supply
presentation materials to a board meeting.

The result is a comprehensive communication plan which

includes:
• A collection and filing structure for storing
information.
• A distribution structure detailing who will get
information and how.
• A description of the information to be distributed, like
status reports, data, schedules, technical
documentation, etc. The description will include the
format used, the content expectations, the level of
detail and the conventions and definitions used.
• Production schedules for when the different types of
communications will be produced.
• Methods for accessing information between
scheduled communications.
• A method for updating or refining the
communications management plan...

95
Project Management

9.4.2 Making the Connection

Once the communication plan is in place, the next

requirement on the project is to ensure the right information
is to the right people at the right time. This includes
following the communication plan as well as handling
unexpected requests for information. The process of
information distribution handles the dissemination of
information on the project.

The most important component of information distribution is

the effective communication skill of the person responsible
for managing communications. This skill will ensure that
the information being communicated is clear, concise, and
fulfills the requirements of all parties involved. They will
also utilize the appropriate system for delivering the
information. Two tools may be used for communications:
the information retrieval system and the information
distribution system. The first is a passive approach for
sharing information that used any variety of mediums. The
second is an active method of sending information to
appropriate parties using several possible methods.

The primary result of information distribution is the creation,

sharing, and storage of project records.

9.4.3 Cleaning Up Static

The greatest piece of information for the project to have and

to share is its performance record. Whether reporting

96
Project Management

where the project is (status), what it has accomplished

(progress), or predicting future events in status and
progress (forecast), the information has great interests to all
persons involved in the project. Essentially it answers the
question of project value to the business. Performance
reporting includes the process activities required to collect
and distribute information related to performance on the
project.

Using the project plan as a basis, performance reporting

looks at the work results. Are the deliverables fully or
partially completed? Is the project on time, ahead of
schedule, or behind schedule? Are the project costs in line
or above or below budget? Are there any issues currently
present that need to be resolved at this time?

Some of the tools used to define the performance of the

project are performance reviews, variance analysis, trend
analysis, and earned value analysis. Earned value analysis
is the most commonly used form of performance
measuring. It used the scope, cost, and schedule of the
project to determine the measure and calculates three key
values for each activity in the project.
• The budgeted cost of work scheduled (BCWS)
identifies the portion of the approved cost estimate
planned to be spent during any given period, or the
estimated cost of performing the activity.
• The actual cost of work performed (ACWP) identifies
the total direct and indirect costs attributed to the
performed work in any given period, or the actual

97
Project Management

cost of performing the activity.

• The budget cost of work performed (BCWP), or
earned value, is a percentage of the total budget
equal to the percentage of the work actually
completed. So how much money was spent to
perform a specific amount of work.
The three values above are used in combination to identify
cost variance (CV), schedule variance (SV), and cost
performance index (CPI). These measurements explain
how far off of budget and schedule the project through CV
and SV measurements. The CPI measurement is used to
forecast project cost at completion. Some application areas
use another measurement to forecast project completion
date called schedule performance index (SPI).

The performance reports are delivered using whatever

system was described in the communication plan. In
addition, improvements or corrective actions may have
been identified which need to go through the change control
process.

9.4.4 Ending the Connection

At either the end of a project phase or the end of a project,

the process for administrative closure will be called. The
purpose of this process is to complete any administrative
work that may be required by the project. It begins with
verifying and documenting project results with the intent to
obtain formal acceptance of the project deliverables by the
sponsor, client, or customer. The process entails collecting
98
Project Management

all pertinent project records, ensuring that they reflect the

final specification of the deliverables, the analysis of project
success and effectiveness, and making the information
available as well as archiving it for future use.
Administrative closure works best when it is done
throughout the project to end phases, and is considered
poorly done when the entirety of the project close is done at
the end of the project.

The chief inputs to the administrative closure are the

performance measurement and the documentation
pertinent to the deliverables or the product of the project.
Other documentation may be available. At the end of the
administrative closure process, the project team will have
formal acceptance of the product of the project or phase,
the project documents will be indexed and archived, and
any lessons learned from the project will be documented
and communicated.

9.5 Base Jumping a Project

With any endeavor, a number of concerns and issues may

be introduced that cause doubt on the success of the
endeavor. For a project, these are items that question
whether a particular deliverable or activity can be delivered
as intended in the time frame or budget allotted to it, or
using the resources assigned to it. At the end, any issue to
this effect is considered a risk to the project and risks can
be managed. Project risk management is the PMBOK

99
Project Management

knowledge area that concerns itself with identifying,

analyzing and responding to risk.

With any endeavor that has risk associated with it, the key
to success is first understand the risk and then to prepare
for it. For the most part risk is not eliminated, but by
planning for it, the impact of the risk can be avoided or
mitigated to prevent severe impact to the project. Project
risk management involves the following processes: risk
identification, risk quantification, risk response
development, and risk response control.

9.5.1 The More Risk, the Better the Experience

Identifying and understanding risk to the project is the goal

of risk identification. It is not a one-time process for the
project but is done consistently throughout the project
whenever the ability of the activity to be performed as
intended with the associated cost, schedule, and resources
is questioned. The risks identified can be internal or
external in relation to the project. Internal risks are those
that the project team can impact or control. External risks
are beyond the immediate control and influence of the
project team. Though any time a performance of the
project is questioned, not all the concerns behind the
question will become risks. Risks are in the strictest sense
only those items that have the possibility to causing harm or
loss to the project or the product of the project. From a
project management perspective, risk management
broadens its scope to include those items that can help or
100
Project Management

aid the project or product of the project. Project risk is

found in both opportunities and threats. The reasoning
behind viewing opportunities as risks is rooted in the
possibility portion of the risk definition. For instance, an
opportunity to utilize new technology that was not
introduced when defining the scope may reduce the time
required to complete the project by weeks and improve the
quality of the product, but with an increase of the budget by
10%. Where the opportunity shows up as positively for time
and quality, there is a risk to scope and cost. More work is
required to justify any changes to the project.

Because of the project perspective to introduce

opportunities as well as threats as risks, the people
involved with the project should be encouraged to identify
as many potential risks as possible to the project. To aid in
discovering risks, the team may use the description of the
product, the outputs of other planning processes specifically
the WBS, cost and duration estimates, staffing plan, and
procurement management plan. Historical information may
serve to identify risks as well as plans to handle the risk.

Some of the tools used by the project team to identify and

document the characteristics of risks are checklists,
flowcharts, and even interviews with various stakeholders
and experts. At the end of the process, the project team
will has a list of potential risk events, the symptoms of risk
and the sources of risk. Potential risk events are discrete
occurrences that may affect the project. A project member
leaving the team is a potential risk event. If the probability

101
Project Management

of occurrence or magnitude of loss is relatively high, these

risk events should be added to the sources of risk. Most
potential risk events are never application area specific,
though a list of common risk events can usually be
identified for each application area. Descriptions of
potential risk events should include estimates for the
probability that the risk will occur, the alternative outcomes
of the event, the expected timing of the event, and the
anticipated frequency. Potential risk events identified early
in the project may have broader descriptions applied to
them, so it is prudent to provide more detail to them later in
the project.

The source of risk is categories of possible risk events. The

distinction between potential and possible can be hazy at
times. The importance is actually how the risk is managed.
Possible risks event are more like to happen, have a
greater magnitude of loss if it ever does happen, or it is an
immediate concern of one or more of the stakeholders that
has to be addressed. The list of sources should be
comprehensive. Common sources of risk include:
• changes in requirements
• design errors, omissions, and misunderstandings
• poorly defined or understood roles and
responsibilities
• poor estimates
• insufficient skill in staff
Descriptions for the sources of risks should include the
probability of occurrence, the range of possible outcomes,
expected timing, and frequency of the risk.

102
Project Management

In addition to the potential risk events and the sources of

risk, the process should identify triggers, or risk symptoms.
These are indirect manifestations of actual risk events. For
example, a key member being involved in an accident may
cause a strain on the schedule.

9.5.2 Extreme Sports or Golf?

Having identified all the risks associated to the project isn't

enough to manage that risk. Each risk required some form
of evaluation to assess whether the risk warrants a
response outside of the normal course of a project. This is
risk quantification. Someone who is parachuting for the first
time will recognize the risk of the chute not opening. This is
the same risk that an experienced jumper has, but the
process is no different for the new or the experienced
person: both need to ensure that the chute is properly
packed. A number of factors may be used to evaluate and
ascertain any warranted responses. Some of the factors
may include:
• Opportunities and threats that interact in
unanticipated ways, e.g. new technology saves time
but costs more.
• A single risk event having multiple effects on the
project.
• Opportunities for one stakeholder may prove to be a
threat to another.
• Techniques used creating a false impression of
precision and reliability.
103
Project Management

One of the key inputs to risk quantification is the tolerance

to risk that the stakeholders have. Different organizations
and different individuals can have different tolerances for
risk. For instance, a very profitable company will be more
willing to spend more money on a project than a company
that is breaking even. Some companies classify budget
overruns and schedule delays differently causing a certain
percentage overrun to be high risk for one and low risk for
the other. A company trying to take market share from its
competitors may be willing to spend more to introduce a
new technology to the product. Whatever the reason for
the tolerance, it serves as a filter to the quantification of
risk.

Using those tolerances, the sources of risk, the potential

risk events, cost estimates, and the activity duration
estimates, the project team will attempt to evaluate and
quantify the risks. One method for quantifying a risk is to
apply an expected monetary value. This takes into account
the probability of the risk event as well as an estimate for
the monetary gain or loss of the event. Both tangibles and
intangibles should be represented in the earned monetary
value. In addition to this method, the project team may use
statistical sums, simulation, decision trees and expert
judgment to understand and quantify the risk.

There are typically to paths coming out of the risk

quantification process: choosing to pursue a particular

104
Project Management

opportunity or respond to a particular risk, and ignore an

opportunity or accept a risk.

9.5.3 Be Prepared

Responding to risk fall into three possible actions:

avoidance, mitigation, and acceptance. Avoidance is the
actions takes to eliminate the risk, most notably by
eliminating the cause. Not all risk can be eliminated. In
these cases, the next set of actions focus on reducing the
risk by reducing the probability of occurrence. The purpose
of mitigation is to impact the expected monetary value of
the risk. When the risk cannot be eliminated or the
mitigated, the next action is to accept the risk as is.
Acceptance can become active such as putting a
contingency plan in place, or passive like taken on higher
costs if the risk occurs. The risk response development
process assists in building the steps for taking on
opportunities and responding to threats.

Taking the outputs of the risk quantification process,

development of the responses to opportunities and threats
are created. In some cases, the responses may require the
procurement of goods or services from outside of the
project organization, specifically when the risks are
associated with a particular technology. Often,
procurement simply changes one risk to another, a
technology solution to a risk that requires procuring a
specific type of equipment, may mitigate the immediate risk,
but create another risk to the project costs.
105
Project Management

Another appropriate response is the creation of contingency

plans or strategic alternatives. Contingency planning
involves defining what steps will be taken if and when a risk
event occurs. To prevent or avoid risks, alternate strategies
may be utilized, such as spending more time in the design
phase to decrease the number of changes that happen
during development. In some cases, risks will require some
insurance or bonding as a response. This is particular
response is appropriate when there is a substantial
expected monetary value and the probability of occurrence
is likely to high and the cost of having the insurance
outweighs the cost of not.

All responses to risk will be documented in the risk

management plan as well as additional procedures for
handling risks that are identified later in the project. The
documented risk responses may serve as inputs to other
processes in project management. Contingency plans are
organized appropriately to allow for quick access if a
covered risk occurs. As a measure to offset the cost of risk
to the schedule or budget, a financial or time reserve may
be created. Sometimes, a reserve is specific to a category
of risk with multiple reserves defined to handle more than
one category. For some risk responses, contractual
agreements may need to be in place.

9.5.4 Taking the Jump

106
Project Management

Risk response control executes the risk management plan

to appropriately respond to risk events during the project. If
changes happen during the project, the potential for risk
exists and the cycle of identifying, quantifying, and
responding to that risk is initiated again. The risk response
control processes take the plan, the actual risk events, and
any additional identification of risks can executes the
responses. In some cases, the responses are not as
effective as planned or a new risk appears that needs
immediate response. In these situations, workarounds may
be employed which are unplanned responses to risk events
that immediately reduces the impact of the risk on the
project. Even with workarounds in place or when one is not
appropriate, additional risk response development may be
required.

9.6 Going Shopping

For some projects, equipment and materials requirements

make the need for procurement processes to be in placed
to acquire the appropriate goods and services for sources
outside of the performing organization. The knowledge
area includes the processes of procurement planning,
solicitation planning, solicitation, source selection, contract
administration, and contract close-out.

107
Project Management

9.6.1 Creating a Shopping List

Procurement planning identifies the needs of the project

which are best fulfilled by the acquisition of products and
services from outside of the project organization. The
process contains steps for deciding whether to procure,
how to procure, what to procure, how much, and when to
procure. When the decision to procure a product or service
is made, the processes from solicitation planning to contract
close-out will be used for each product or service to be
procured outside of the performing organization. If the
project or service can be obtained from within the
performing organization, the processes will not be utilized.

To starting planning for the procurement of products and

services, the project team will utilize the scope statement
and the product description to understand the needs of the
project. If a formal contracting group exists for procurement
activities, the procedures for interacting with the group will
be accessed. If no group exists the project team will need
the skill and expertise required to support procurement
activities. Market conditions can influence procurement
decisions as they describe what is available, from whom,
and under what terms and conditions. Other constraints
and assumptions that have been found throughout the
project management processes may also impact
procurement decisions.

To continue the decision making process, the use of make-

or-buy analysis may be utilized. This is a general
108
Project Management

management technique used to determine if the building of

a particular product will be more cost effective than actually
procuring the product. Some projects may be utilized to
procure items for the growth of operations that is clearly
outside of the intentional scope of the project. For instance,
the rental of a large piece of equipment for construction
projects may be the typical procedure for the e performing
organization, however recent increases in its use may force
a business decision to procure the equipment.

Procurement can include purchase, lease, renting, or

donation. In some instances, contractual agreements are
required. Most contracts fall into one of three categories:
fixed price, cost reimbursable, and unit price contracts. If
the procurement of a product or service involves a fixed
total price for a well-defined product, the contract is
considered fixed price. How well the product is defined will
reduce the risk associated with the purchase. Cost
reimbursable contracts involve payments to the total price.
The costs are classified as direct and indirect costs: direct
costs are those incurred for the direct benefit of the project
and indirect costs, or overhead, are the costs of doing
business. Unit price contracts provided for payments based
on a preset price per unit of service or product. The total
value of the contract is based on the quantities obtained.

The result of procurement planning is the procurement

management plan and the statements of work. The
statement of work (SOW) provides sufficient detail of the

109
Project Management

item to be procured for the prospective sellers to determine

their capabilities for providing the item.

9.6.2 Walking the Mall

When the procurement needs of the project have been

determined and the statements of work created, the next
step is to prepare to find potential providers. This typically
involves using standard forms to create contracts, bid
documents, and descriptions. Different procurement
documents exist and may be used:
• Invitation for Bid (IFB) requests sellers to provide a
price for the procurement item.
• Request for Proposal (RFP) asks for an explanation
of the services provided with the pricing.
• Request for Quotation (RFQ) are similar to IFBs.
• Invitation for Negotiation are similar to RFPs
• Contractor Initial Response is to identify interested
sellers.

Along with the procurement documents, the need for

evaluation criteria from which to determine the right
proposal is required. Evaluations can be objective or
subjective and are typically a part of the procurement
documents. Some criteria may include an understanding
of need, overall cost, technical capability, management
approach, and financial capability.

110
Project Management

9.6.3 Window Shopping

The project team typically will provide some time for

proposals to be made by sellers. The time allotted should
be defined by the project plan. Some organizations have
lists on prospective sellers that may be used. If these lists
are not available, the project team will need to create one
and in doing so perform some research to obtain the
credibility of potential sellers.

To solicit prospective sellers, the project team may

advertise their need. They may also directly invite
perspective sellers. In some instances, bidder conferences
may be called. These are meetings designed to ensure
that prospective sellers have a clear, common
understanding the procurement before the creation of any
proposals. The intention of all solicitation activities is to
increase the number of proposals to the procurement item.
In some cases, a limit is applied to the number of proposals
which are accepted.

9.6.4 Finding the Right Store

Source selection provides the methods for receive

proposals, applying the evaluation criteria, and choosing
the right seller. The process is not always easy. Price may
be a determinant for most items off-the-shelf, but the lowest
price may not be sufficient if the item cannot be delivered
on time. Many proposals have to be balanced between
technical approach and price. The more technical the
111
Project Management

approach, the more costly the item. For critical products,

multiple sources may be necessary.

In determining the appropriate seller, a screening system

may be in place to identify the most potential of the
proposals while a weighting system attempts to quantify the
proposals. In the end, most purchases require some form
of contract negotiation. The contracts will be used to
ensure that the procurement items are delivered within cost
and per the pricing negotiated.

9.6.5 Making the Purchase

Contracts sign for the procurement items and now the

project team has assurances in place to have the services,
the equipment, and materials in place to successfully
execute the project. Making sure that the seller meets the
contractual requirements detailed in these documents is the
work of contract administration. For some companies, this
work is performing by a central department. For large
projects, the key purpose for contract administration is the
management of interfaces between multiple suppliers.
However, contracts are managed or why, the project team
must understand the legal nature of the contractual
relationships in place to be acutely aware of the legal
implications of the actions taken when administration the
contract.

Contract administration is used in conjunction with other

project management processes to cover some of the
112
Project Management

requirements of effectively executing a project with

contracts. Project execution authorizes any work required
by outside contractors at the appropriate time in the project.
To monitor contractor cost, schedule, and technical
performance, the performance reporting process is utilized.
Quality control assists in inspecting and verifying the
adequacy of the product and services from the contractor.
Nay changes involving the contract are handled through the
change control process. To manage payment schedules
requires financial management.

Throughout the process, correspondence, contract

changes, and payment requests are the output expected of
the process.

9.6.6 Wrapping It Up

Contract close-out is a similar process to administrative

closure as it involves product verification and administrative
close-out. The difference is that this process focuses on
the completion of the contract and may consist of specific
procedures that handle the legalities that exist. The intent
of the process is obtaining formal acceptance of
completion. In many cases, the supplier may also have a
contract close-out procedure that they need to follow.
Working with the supplier in this matter will speed up the
effort.

113
Project Management

114
Project Management

10 Concluding Project
Management
Project management from the perspective of PMBOK is an
extensive and comprehensive set of processes that cover
most situations and concerns experienced on a project.
For specific application areas, slight differences may be
found during the execution of the project management
disciplines. The use of templates and historical information
will serve to increase the effectiveness and efficiency of the
project in numerous processes.

For organizations which expect to handle projects in the

long term, it is advisable to create an infrastructure to assist
in managing and collaborating on project as well as to
create historical documentation. Certification of individuals
serving as project managers and even those expected to be
on project teams is equally desirable.

115
Project Management

116
Project Management

11 Comparing Project
Management Frameworks
PMBOK is not the only project management framework
though it is an internationally recognized standard. A
number of other frameworks are available and some are
gaining popularity in the business world: of not is the
United Kingdom recognized PRINCE2 (Projects IN
Controlled Environments). PRINCE2 is an open method
for projects that are driven by business case rather than
customer requirement driven. The framework does not
claim to be complete and focuses on key risk areas only.
This is a definite departure from the comprehensive
PMBOK. Another difference is PRINCE2's focus as
implementation methodology rather than the whole project
methodology.

PRINCE2 creates a framework based on the life cycle of a

project. The method recognizes that project management
processes can be found at the project level and the stage
(phase) level... There are eight major processes in the
framework from “Starting up a Project” to “Closing a
Project.” Six focus on the life cycle while two, “Directing a
Project” and “Managing stage Boundaries,” are used
throughout the project. The eight processes are supported
by 45 sub-processes. This is comparable to PMBOK's five
process areas and 44 processes. The actual correlation
between the two frameworks is below:

117
Project Management

PMBOK PRINCE2
Initiating Starting Up
Directing
Managing Stage Boundaries
Planning Initiating
Planning
Managing Stage Boundaries
Executing Managing Product Delivery
Directing
Controlling Controlling a Stage
Directing
Closing Managing Stage Boundaries

PRINCE2 is document heavy with descriptions to 33

standard management “products.” There is no notable
difference from the “products” of PMBOK.

PMBOK focuses on the foundations of project

management, separating the discipline into nine knowledge
areas. PRINCE2 has eight components making up the
framework. The similarities are:

PMBOK Knowledge PRINCE2 Components

Areas
Integration Management Combined Processes and
Components Change Control
Scope Management Plans
Time Management Business Case
Cost Management
Quality Management Quality

118
Project Management

Configuration Management
Risk Management Risk
Communication Controls
Management
Human Resource Organization
Management
Procurement Not covered
Management

Two obvious differences are present with PRINCE2. It

uses Configuration Management as a way to manage
assets. The assets include the products of the project as
well as products (deliverables) from the project.
Additionally, procurement management is missing.

PRINCE2 has its strengths. The organization of the project

is highly defined with roles and responsibilities clearly laid
out. Ownership and accountability is with the project team
and project boards (owners), rather than a collection of
stakeholders. The process structure is integrated and clear
in its flow. It fits into ISO 9000 Quality Management
System and is consistent with SEIs Capability Maturity
Model Level 5.

Though differences exist between PMBOK and PRINCE2,

benefits are achieved through the use of both. PRINCE2
has a methodology structure that is easier to implement.
That implementation should be done inside the knowledge
of PMBOK, even using a certified PMP. Using the key
components and techniques from PRINCE2, PMBOK can

119
Project Management

be used to add depth to the implementation and for

additional techniques. The result is a project management
program that addresses the practices of a global community
of project managers.

120
Project Management

12 Applying Cloud
Computing to Project
Management
12.1 Benefiting from Cloud Computing

The benefits of cloud computing fall into quicker

implementations and lower costs while providing greater
scalability, adaptability, and reliability to the environment.
Especially in terms of web applications, a solution can be
available at any time in any location on the planet by any
person. As use of the application increases or decreases,
the cloud solution adjusts accordingly.

The previous pages attempted to show the benefits of

project management applied to cloud computing. The
following pages will explore the benefits of cloud computing
to project management. Some of the ideas explored here
have solutions found within the cloud environment,
especially in Independent Software Environments (IDEs)
used for software development. Cloud computing solutions
exploit a number of distinct technologies.
• Virtualization is a technique used to create an
abstract rendering of a physical component. For
instance, storage volumes can be virtualized. With a
virtual volume, the storage capacity can be
increased, partitioned without partitioning the
physical drive, or merging the volume with other
121
Project Management

storage devices to create a single large volume.

Virtualization allows for increased scalability,
reliability, and portability to occur.
• Web 2.0 is a perspective change for how to use the
web. Often referred to as a technology, Web 2.0
provides a number of options that make web
applications just as rich as desktop applications.
• Open source is a concept supporting total
collaboration between developer and user. Often
attributed to application development, the concept is
also applicable to any number of solutions where
user knowledge is utilized extensively to generate
the product that the user is concurrently using. The
idea ultimately encourages development in
production.

Seven benefits are available to project management when

adapting cloud computing capabilities:
• The ability to interlink distinct components together
as a complete whole. For instance, linking activity
with cost, time, risks, quality, and resources. Many
project management solutions already do this to
some extent; however, with cloud computing the
options can be expanded to include historical
information, feedback, and particular notes.
• To support communication specifically with
stakeholders requiring performance reports, the use
of subscription services allow distribution of
information to have greater potential and
customizable by the stakeholders themselves.

122
Project Management

• Many aspects of project management can be

present at any given time and with an application,
the possibility of an interface that allows each aspect
to deliver is highly probable with web applications.
• One of the risks to project management is ensuring
that all the right players are involved in the project to
ensure that everything that needs to be done on the
project has been planned. With cloud computing,
participation by all parties is possible.
• The core tenet of cloud computing is the ability to
focus on components as parts of the whole allowing
an individual component to be added, removed,
expanded, and reused without impact the whole.
• The capabilities of the web allow portability. First of
all, a web application can be accessed anywhere, at
anytime, by anyone with only a browser and a
connection to the Internet. Second, with the
business logic of the application on an Internet
server, nothing is lost between multiple users.
• A main drive of web applications and cloud
computing is improved, richer user experience.
Improving the experience of individuals on a project
will encourage communication, productivity, and
morale.

12.2 The Ease of Linking (Hyperlinks)

Looking at the construction of the web, one will see a series

of documents in place, basically organized through the URL

123
Project Management

hierarchy, and with some programming scripts to provide

some interest. Though all of these components make up
an effective website and web application, the one construct
that makes the web the web has always been the ability to
hyperlink. Hyperlinks are connections from an original page
to a source document. By clinking on a hyperlink, a user
can be moved from one page to another with just one click.
By hovering over the link, information can be made
available to the user. Through searches, multiple
hyperlinks can be generated on a single page based on
relevancy for the users to peruse.

Hyperlinks can be used to transform basic pieces of data

into rich volumes of information by creating relationships.
In the back end of an application a database is usually
found that holds data and created relationships with that
basic data, such as a person's name and their job position.
Using the web and hyperlinks, building relationships can be
expanded to incorporate multiple databases. So in addition
to a name and a job position, the person's personal profile
and the job description for the position can be connected.
This connection can be presented as links in a single page
or the full or partial renderings of the sources can be
presented.

There are several perspectives that are prevalent in project

management, each with some level of importance to the
users. But the perspectives all rely on the need to
understand the relationships with different pieces of data.
Most project management solutions handle the basic

124
Project Management

relationships, such as the relationship between activity,

cost, schedule, and resources. Some solutions even
provide notes for referencing. However with hyper linking,
any document or parts of a document can be referenced
allowing risks and risk responses. Contractual terms,
historical information, procurement proposals and supplier
information, quality requirements, and the like can be linked
to a single activity. By having the activity show all related
information pertaining to it, all participants on the project
can better understand and manage the work expected. The
greatest aspect of this solution is that the information can
exist in multiple databases and separated locations.

Even connections with existing and past projects can be

made. In situations where similar project are performed,
like building a house with similar designs, connections can
be made very easily. Why make these connections? Each
constructed building can have its unique attributes:
location, features, options, even contractors can be
different. Using the designs as the starting point, a
construction company can identify and compare the
differences between buildings using the same design. The
opportunities available are to assist in understanding
requirements, risks, and unplanned threats to a particular
project. For instance by referencing contractors familiar
with the design, a replacement contractor can be found
quickly if the original supplier is unable to do the job.

What is linked and to what extent the linkages are made is

left only to the imagination of the performing organization.

125
Project Management

12.3 Subscribing to Success (Blogging)

Imagine compiling information into the next status report,

categorizing it and posting it out to the web. Without any
extra effort, a notification of the report is sent to every
stakeholder interested in the project. Within minutes,
responses to the report start to show up in the next day, all
the responses are compiled for the project team meeting to
review and answer. The situation just provided is just one
of the ways blogs can assist in project management. Blogs
utilize a subscription web service to ensure that people who
want to be informed are. Used by a number of columnists,
professional and amateur, on the web, a blog is a
mechanism used to post information; with logic to identify
who is interested in the information for a notice to be sent.
The identity of interested parties was provided by the
people themselves when they “subscribed” to the blog.
Since a blog is basically a web page, the format of the
report can include anything that a typical web page can
include.

Imagine again that the project is going along nicely.

Coming into work early, the computer is turned on and
waiting for you is a list of all the project activities that are
currently being performed, the one that were completed the
previous day, and the ones that are late are highlighted. As
a project manager, the list includes all the activities of the
project. As a project team member, the list includes only
those which are assigned to them or have a dependency

126
Project Management

on. The mechanism used to compile this information from a

project plan is the same used by blogs.

At the heart of the blogging feature is the RSS technology.

Really Simple Syndication (RSS) allow a person to
subscribe to a web page so that when it changes, they are
notified. The technology is not attached to the webpage
though, but to the link between the user and the web page.
A RSS feed allows these links to exist. Aside from
blogging, the RSS technology has made another significant
contribution: permalinks, or permanent links. With the
permalink feature, users can link to other user’s websites,
link to individual comments on a page, use “trackbacks” to
other links to the page by other others, or respond to those
other links, thus creating a two-way link. In project
management, permalinks can provided a variety of
associations between items. For instance, dependencies
within a project can use permalinks to make two way
associations possible, so that the project team can identify
the activities and their dependencies, both dependent upon
as well as depended for.

Hyperlinks provided a way to show one way relationships

between two items. RSS has allowed two way associations
to be made. The use of RSS in blogging solutions has
provided a new platform for gaining information within
business. For project management, it’s a simple way of
keeping stakeholders informed of what is going on with the
project.

127
Project Management

12.4 Interfacing with the Project (Mashups)

During project management, the number of items to be

monitored and controlled is considerable. For the project
manager, the concerns to be watchful of include:
• Is the scope of the project intact? What are the
current issues impacting scope?
• Are we on schedule? What's late? What is about to
start? What is about to finish? What issues are
impacting the schedule?
• Are we in budget? Where are we about to go over?
What threats are present impacting project costs?
• Who is supposed to be performing activities on the
project today? Are all the equipment and materials
required available? What issues do we have against
resources?
• What is the next milestone? How close are we?
• When the next meeting? What information needs to
be communicated?
• What risks are important to monitor today?
This is just a sampling of what the project manager is
looking at for the day, or the week. And they are not alone.
Though the focus of the information may be different, the
project team members and the stakeholders are looking at
similar information. Unfortunately, the information that any
person is looking at is typically located in several locations.
In order to get the information, the source needs to be
retrieved and scanned to find the information.

128
Project Management

Using a project management engine as a web application,

the information from these multiple sources can be
retrieved, compiled, and presented to the user in a single
interface. The technique used to make this possible is
commonly referred to as a “mashups.” They are web
applications designed to allow the user to customize their
web interface to allow multiple sources of information to be
presented at the same time. With the ability to customize
the interface, the user can determine what information
needs to be displayed at any given time. Each user could
have a different interface to the project, one specifically
designed by them to meet their information concerns.

To allow mashups to work, the application developer simply

needs to link the source of the information to the
application. Some translation may be required to build
relationships and associations, but once the information is
readable and the criteria is set for how it is read it is ready.
At that point, the source becomes a component in the list of
components available for the user, like a catalog. The
developer can also create relationships between multiple
sets of data; for instance, mapping the project plans to the
risk responses to change requests. Each piece of data is
found in different sources, but is combined to show in the
user's interface of the project.

129
Project Management

12.5 Everyone is a Project Manager (Open

Source)

One of the constraints of the tools used for project

management is that they are built for use by project
managers. Though nothing is wrong in this, it does alienate
other people who are not familiar with project management
needs and concerns. In some cases, these people are
simply involved to provide resources to the project.
Unfortunately, they are being asked to use these tools. And
even with project managers, one characteristic starts
coming into play: the behaviors of the individual start to
change to accommodate the tool. This characteristic
always becomes a problem. Extreme adversity towards
changing behaviors will result in the tool not being used at
all. Modest adversity often leads to not using it to its fullest
capabilities or incorrectly.

Though the initial focus is on a project management tool,

the same characteristic can be found inside a project.
Many projects claim to fail because of lack of teamwork,
communication, and understanding. Though these reasons
are valid, the more likely source of failed projects is forced
behavior changes. When an individual or group is forced to
behave contrary to their nature or experience, resistance
starts to appear. If the resistance is coming from one or
two individuals on a project because they are new to project
management, concerns with project failure will not come up,
though a risk may be present. But when the behaviors of

130
Project Management

the entire team are being asked to change, the probability

of failure increases.

An easy solution to this problem is readily available:

encouraged participation in every aspect of the project and
the project management tool. The philosophy behind this
solution is “open sourcing” the project or tool. How is this
done? Starting with the project, it means making the
project plan a truly living project. In many project
management situations, the individual contributions to the
project plan are made and compiled by the project
manager. The organization of the project plan is completed
by the project manager and reviewed with the project team
during a meeting when the plan is distributed.
Collaboration is controlled and input to the plan before,
during, and after is often filtered. This is the traditional
method of project planning. However, what if the project
plan is located in a central location that everyone updates.
As people update, feedback is provided on specific entries
detailing requirements, dependencies, risks, or questions.
The critical components of the plan are quickly identified
and agreed upon by the team. The organization of the plan
may be directed by the project manager, but everyone has
a say in its construction. And when the plan is complete,
the collaboration continues with change controls in place.
Eventually, the project plan will be complete and have a
richer quality to them than typically available through
traditional means. And the trend of open sources has
shown that the work is done in far less time than the

131
Project Management

traditional method because the collaborative component

has improved.

The same method can be applied to the project

management tool. By allowing users to input their needs
into the project management tool, eventually a tool is
available for use by all users, not just project managers.
The core of the tool or the project does not change, just the
behavior changes to match that of the project management
team. Such changes to behavior characteristics within an
application required extensive budgets to build and
maintain customized applications, some of which were
never fully used by the users. In the cloud, the application
is developed as it’s being used as and at a far less
investment than traditionally required.

The underlining theme behind open sourcing is

collaboration at any time for anything. The theme continues
during project execution. Traditionally, when a problem
arises during the performance of an activity, the performing
party notifies the project manager and the two may attempt
to find a resolution. Other team members may get involved
at the request of the performing party or the project
manager, but the group looking at the problem is still
restricted. In a collaborative environment, everyone has the
opportunity to be involved. In most cases, the problem will
be resolved faster with a better, more creative solution and
in project management; the risks involved are minimized to
the greatest extent. Some people may claim that the old
adage “too many cooks in the kitchen...” but the truth is, in

132
Project Management

the largest, most prestigious kitchens of the world, there are

always more than one cook.

12.6 Treating the Project as Parts, not the

Whole (Reuse)

With mashups, different components could be used to

create a user interface. The constructs of these
components had to be designed and developed, but once
done could be used by anyone. Variables set in the
components could be changed by the user to allow for
further focus on the information retrieved. With blogs and
other RSS feeds, users can identify the parts of the project
that they want to be regularly informed. The number of
feeds available may reach the hundreds, but the user only
wants one or two that suits their needs. The concept of
reusing predefined components is prevalent in web design
and cloud computing. It provides the development of a
particular product to be completed much quicker, at far less
cost, and fewer risks.

Especially for organizations that perform projects of a

similar nature repeatedly, such as building a house, or
application, or a prototype, the concept of reusing project
plans is an attractive notion. PMBOK even encourages the
use of historical information and templates to create the
necessary documentation on a project. But every project is
unique, so some care has to be made to ensure that
adoption of historical information is not made blindly. This

133
Project Management

does not mean that reuse capabilities cannot be

encouraged.

Separating a project into its core deliverables, a project can

be split into components. Each component will have its
basic relationships, requirements, dependencies, and risks
defined. These interactions will exist internally to the
components as well as the external interactions identified.
By having multiple components available, a project team
can identify the components that are required for the project
and add it. Changes to the component for a specific project
can be noted and used as historical data for the next project
without changing the core component. Thinking of the
project as a product, the ability to reuse components
provides a cheaper, quicker product to market than
recreation from scratch. By breaking projects down into
reusable components, the technique is now more scalable,
flexible, and reliable than traditional methods.

How does cloud computing support this endeavor. By

using links, entire components can be added to a project
plan with the click of a mouse. In minutes, the majority of a
project can be created with all the relationships and
pertinent information intact. At this time, cloud computing
solutions allow business applications to be built in a matter
of minutes using components already available. The
concept is the same, using the project as the basis for the
application. Referring to the relationships is not restricted
to the relationships between information, and also the
processes of project management. The different

134
Project Management

components can include the various tools used by project

management, like a change control system, or risk
response system, or project monitoring systems, or
performance reporting. Normally these systems are not
interrelated. In web applications, the business logic can
stay where it exists, however the presentation layer can
show information, workflow, and indicators to be used
actively by the project team and stakeholders.

12.7 Testing the Limits (Portability)

Portability is a great advantage to any endeavor. Using the

web as the basis for building, monitoring, and executing a
project, portability is automatically provided. Using a
browser and a connection to the Internet, a user can access
a project from any location in the world, at any time. In
many situations, the performing party is executing on the
project several tasks defined by the project at any given
times. Many tasks, especially in manufacturing and
construction, require not being readily accessible to the
project plan to update the situation. So the performing
party waits to the end of the day to update the project plan
and any related materials. This is particularly valid when
the software used to update the project plan is sitting on the
computer at the office. However if the performing party had
a hand held device able to connect to the Internet like a
phone, they could make an update to the project plan on
the spot.

135
Project Management

The concept of portability is a simple one. More importantly

are the benefits that appear by using a web-based project
management. Many project management programs are
very expensive and providing a license to every member of
a project management team may not be a cost effective
solution. Many project managers have filled the gap by
taking status updates from member s and updating the plan
themselves. However, everyone typically has access to a
browser allowing them to update the plan as members of
the project team. This potentially reduces the
administrative work performed by the project manager while
also significantly reducing the cost of licensing of the tools.
In cloud computing solutions, the usage is typically
monitored and charged, so a company may have several
full time project members with a couple of dozen part time
members. Traditionally, everyone had one full license
despite the usage. With a cloud solution, the usage of the
members can be added up and charged. So inactive
members would not prove to be an additional cost to
license for the company.

136
Project Management

13 The Perspectives of
Project Management
When looking at project management, many perspectives
can be taken. The first sets of perspectives are those by
the participants of the project. Each role on the project has
a different perspective, or interest in the project. Executive
management is often interested solely in the success or
failure of the project and how the project impacts the
strategy of the company. They tend to focus on details
related scope and risk with a broad overview of other areas.
Stakeholders tend to look at the impact o f the project on
the operations of the company. Their focus is on status on
the budget, the schedule, and the resources of the project.
The supplies and contractors are looking for what needs to
be done and when. Project team members focused on the
deliverables and what they need to do make it happen. The
project manager has concerns in every area, but their focus
tends to stay within the boundaries of control and
communication.

In the same way that roles can provide different

perspectives found on a project, the individual assignments
of a person can also control perspective. Just looking at
executive management for instance, the CEO may be
interested in overall success of the project while the CFO
focuses their interest on the financial success and the CIO
is focused on the success of the schedule. Especially on

137
Project Management

large projects, a single individual may be immediately

concerned with a single aspect of the project based on their
participation.

Acknowledging the different perspectives is imperative to

successful negotiating the way a project will work. Making
an attempt to understand the requirements from these
perspectives provide useful information for determining the
methods used to run a project. Meeting the needs of all
these perspectives will be a difficult undertaking and highly
discouraged. However, there are three general
perspectives that may be useful in identifying or building a
project management tool:
• Project management as information
• Project management as workflow
• Project management as people

13.1 A Project as Information

Creating a project requires the collection, organization,

generation, and distribution of a tremendous amount of
information. Historical data is used to assist decision
making along with analysis of other sets of information.
The scope of the project is typically a compilation of inputs
from several sources to define, expand, or constrict
accordingly. The work breakdown structure, activities, cost
and schedule estimates are all used to build a proper
project plan. With all this data come the constraints,

138
Project Management

assumptions, risks, regulatory requirements that can be

applied to individual items on the project plan.

A project generates a lot of information, one of the greatest

feats for a project is organization that information in such a
way that any particular piece of information is readily found
and available. Many of the tools used to house the data
may not only be in separate locations but be under
separate rules for identifying and organization. One
financial tool may focus on account codes as the basis for
querying, while the change control system is using a unique
identifier. How the two tools are connected typically
requires a change in one of the tools. In a web solution, the
connection is made outside of the two tools and displaying
the information from both in a single page. T

The key is through vitalizing the organization of the

information. From a web application perspective, it does
not matter where or how the information is stored or
managed. Through virtualization, an entire filing system
can be created to retrieve information. Because of its
digital nature, the information does not need to be
physically moved to be in the filing system, as the system
makes a note of where it is located. When a person
retrieves the information, the system simple goes to the
location of the information and pulls it for view. In addition,
a web form could be filled out by a user and several
databases could be updated using the information provided.

139
Project Management

13.2 A Project as Workflow

A project is a series of processes that are used and reused.

The high level flow of work is initiate, plan, execute, control,
and close which describes the phases and the work done
inside the phases. Particularly during the execute and
control phases, any number of processes may be initiated,
for instance risk management. Specifically, an activity
identifies a potential risk during its execution. The risk
needs to be evaluated and quantified. At the same time, a
workaround may be performed. Risk management and
project execution are working simultaneously. After the risk
is quantified, a response is created. The effort handling the
risk has just gone through three processes. The response
itself has forced a change to the project, requiring the use
of the change control processes. At this point, the impact of
the risk and its response now has been routed through the
appropriate aspects of the project: scope management,
cost management, time management, quality management,
resource management, and the like. Each of these areas
will undertake their processes to determine the impact and
change the project appropriately. As the risk response
goes through these knowledge areas, some control and
monitoring needs to be in effect until the overall change is
approved. Once approved, the change is executed and the
project continues.

The example used above shows the flow of work through

nearly half of the 44 processes of PMBOK the actual time it
took to execute all these processes could be a couple of

140
Project Management

days a maybe just a few minutes depending on the problem

and its impact. Project management is simply a series of
workflows to handle different situations. The example
above showed the flow through the processes. For each
process as a set of roles and responsibilities. Another
workflow perspective is the flow of work through roles.
Same situation: a risk is found by an executing party,
communicated to the project manager and a workaround
initiated by the executing party. The project manager with
the information available identifies the risk, quantifies, and
creates a response, or send the information to an “expert”
to do that work. When the work is done, the project
manager sends the risk response to the appropriate
stakeholders to obtain feedback on impact to cost,
schedule, resources, and the like. At the same time, they
may notify all the stakeholders of the problem. Once the
stakeholders finish their evaluation, the change control
system is updated with approvals. The change request is
now sent back to the performing a party or another party
based on the nature of the response to have the change
executed.

The execution of the project even has a workflow element

rendered by the dependencies of the project activities.
Execute one activity which initiates the next, which initiates
the next until all the activities are completed. Sometimes,
an activity will initiate two or more additional activities.
Sometimes multiple activities need to be completed before
a particular activity is initiate. Each activity may have a
different performing party required to execute. Sometimes

141
Project Management

the performing party may be an individual or a group of

individuals.

A project is a myriad of possible workflows. Controlling and

monitoring the work through the project is one of the
primary responsibilities of the project manager and in many
cases, having a handling on managing the work through
multiple workflows is essential. Web-based project
management is one way to identify, manage, and control
workflows present on the project. Through connecting
multiple systems together as well as predefining interested
parties, the initiation of work can provide the necessary
updates, record generations, notifications, and triggers to
move the work as well as track it.

13.3 A Project as People

Despite all the plans, reports, and supporting

documentation required by project management, the results
are still dependent on people. Though there are a number
of tools, techniques, and processes available for identifying
what to do and how to do it, the work is still executed by
people. Tapping into people is essential for the success of
a project.

Web-based solutions allow people to tap into the project,

each other, and themselves. The same solutions allow for
the project to tap into the people. In the end, the
experience becomes a richer, more exciting adventure for

142
Project Management

collaboration and excellence. Whatever the methods, the

use of a web solution for project management allows for
greater productivity, reliability, and greater gains because of
the potential growth of the project team and associated
stakeholder.

143
Project Management

144
Project Management

14 Summarizing Project
Management
Project management based on PMBOK is a disciplined
approach to manage project: temporary endeavors focused
on producing a new and unique product of service. The
PMBOK identifies 44 processes essential to project
management success. The processes are viewed in two
ways: as process areas or knowledge areas. Five
processes areas acknowledge the life cycle flow of projects
from the initial creation of the project; to planning the costs,
schedules, resources, and risks of the project; to executing
the plan; to controlling that the plan is executed properly
and handling any disruptions; to finally closing the project
due to completion or failure.

The nine knowledge areas focus on the disciplines of

project management: project integration, project scope,
procurement, communications, project closure, and project
management of cost, time, staff, risk, and quality. The
processes are iterative requiring their use several times
during the project. They are also integrated with
relationships found across the entire spectrum. PMBOK
makes the complex issues of project management easier.

For cloud computing solutions, the use of project

management it creating, expanding and changing those
solutions provides greater control over the business

145
Project Management

concerns of using these solutions. Luckily, project

management is compatible with other standard that may
already be in place for any solution providers. For IT
infrastructures, PMBOK works well with ITIL. For
application development, PMBOK works well with agile
methods.

While project management can aid web-based solutions,

the same solutions can serve to benefit project
management. The different technologies and features
allow better organization of information, better
communication, and greater understanding of the project at
any given time.

146
Project Management

15 References
Cooper, Lawrence. Implementing ITIL using the PMBOK
Guide in Four Repeatable Steps. 2006: Global
Knowledge.
http://images.globalknowledge.com/wwwimages/whitepaper
pdf/WP_Cooper_PM_ITIL.pdf

Duncan, William R. A Guide to the Project Management

Body or Knowledge. 1996: PMI.
http://www.unipi.gr/akad_tmhm/biom_dioik_tech/files/pmbo
k.pdf

Wojcik, Dr. Ronald J. PMBOK Approach Insights for

Software Development Projects. Pragmatic! Solutions.
http://www.pragmatic--
solutions.com/attachments/2006WhitePaper-PMBOK.pdf

Gammon, Peter. PMBOK – Making it Work. 2006:

Contact to ContRact. http://www.proms-
g.bcs.org/histevents/pdfs/psg0503%20-%20PMBOK.pdf

McVearry, Kenneth A. What is the PMBOK and What Can

It Do For Me? Osmose Utilities Services.
http://www.gisdevelopment.net/proceedings/gita/2005/pape
rs/43.pdf

Johnson, Matt. Fostering a Good Project Environment

through Your Project's Culture and Communications – Its

147
Project Management

Critical Components for Success.

http://pmiwic.org/presentations/Your%20Project's%20Cultur
e%20and%20Communications-
Its%20Critical%20Components%20for%20Success_r2.pdf

Budiman, Linda. Complimentary Relationship Between ITIL

and PMBOK. CSC.
http://www.pmiwdc.org/files/presentations/presentation2008
08Chantilly.pdf

Cooper, Lawrence. ITIL V3 and the PMBOK – Distinct but

Complementary. 2008: Global Knowledge.
http://images.globalknowledge.com/wwwimages/whitepaper
pdf/WP_Cooper_ITILV3PMBOK_Q21.pdf

Blend Approach of IT Service Management and PMBOK for

Application Support Project.
http://hosteddocs.ittoolbox.com/GT120505.pdf

Koch, Alan S. Are Agile Methods Compatible with the

PMBOK? January 6, 2004: Pittsburgh Project
Management Institute.
http://www.pittsburghpmi.org/documents/meetings/presenta
tions/AgileManifesto-PMBOK.pdf

Udo, Nathalie and Koppensteiner, Sonja. Will Agile

Development Change The Way We Manage Software
Projects? 2003: Projectway, LLC.
http://www.assistpoint.com/paper_agilevspmbok.pdf

148
Project Management

Agile Processes.
http://www.objectmentor.com/resources/articles/agileProces
s.pdf

ccpace. Agile Project Management.

http://www.ccpace.com/Resources/documents/AgileProject
Management.pdf

Siegeluab, Jay M. How PRINCE2 Can Complement

PMBOK and Your PMP. January 8, 2004:
PMI/Westchester Chapter.
http://www.pmiwestchester.org/downloads/Prince2PMBOK.
pdf

Wideman, R, Max. Comparing PRINCE2 with PMBoK.

2002: AEW Services.
http://www.maxwideman.com/papers/comparing/comparing.
pdf

Wikipedia. Project Management Institute (PMI).

http://en.wikipedia.org/wiki/Project_Management_Institute

Wikipedia. Project Management Professional.

http://en.wikipedia.org/wiki/Project_Management_Professio
nal

149
Project Management

INDEX*

A
acceptance 56-8, 105
activities
next 65-6
non-project 65
activity definition 38, 61, 63
activity duration 30, 38, 61-2, 68-70
activity duration estimates 70-2, 78, 104
activity list 63-5, 68-9, 71
activity sequencing 30, 38, 61-2, 67
ADM (arrow diagramming method) 67
agendas 58
Agile Project Management 149
agreement 19, 21, 34-5, 52
American National Standards Institute (ANSI) 13
analysis
benefit/cost 53, 82
earned value 97
mathematical 72-3, 85
trend 86, 97
ANSI (American National Standards Institute) 13
application 16, 121, 123-4, 129, 132-4
application areas 39-40, 57, 63, 65, 67, 102, 115
Applying Cost 4, 77
approach, disciplined 8, 11, 145
arrow diagramming method (ADM) 67
assessment 42, 78
assets 119
assignments 88-90, 137
assumptions 43-5, 47, 52, 54, 62, 64, 69-71, 108
authorizations 46

B
bar charts 73
blogging 4, 126-7
blogs 126-7, 133
board 7
browser 123, 135-6
budget 10, 33, 38, 41, 44-5, 58, 74, 79-80, 86-7, 97-9, 101, 106,
128, 132, 137
budget cost 98
building 67, 71, 87, 94, 105, 109, 125, 133, 135, 138

150
Project Management

business 7, 9, 11, 16-17, 19, 22, 24, 26-7, 41, 43, 49-52, 58, 75,
93, 97, 109 [2]
business decision 78, 109
business logic 123, 135
business managers 16, 34, 90-1
business operations 17, 41
business work 89
business world 87, 117

C
calendars 71
capabilities 69, 73, 92, 110, 123
power 63
CAPM (Certified Associate in Project Management) 15
Certified Associate in Project Management (CAPM) 15
certified PMP training 16
certified project management training 16
change control 10, 33, 37, 43, 48-50, 131
change control process 49, 98, 113, 140
change control system 48-9, 60, 74, 80, 135, 139, 141
change requests 47-9, 59, 129, 141
changes, potential 59-60
chute 103
class 66-7
Closing a Project 117
closure, administrative 34, 39, 94, 98-9, 113
cloud computing 4, 121, 123, 133
benefits of 121
cloud computing solutions 134, 136, 145
collaboration 131-2
commitment 24-5, 27, 70
common work period 68
communication, scheduled 95
communication plan 96, 98
communication skills, effective 94, 96
companies 2, 7, 9-11, 15-16, 19, 26, 44, 51, 71, 75, 77, 89-90, 92-
3, 104, 112, 136-7
companies work 8
Comparing Project 117
completion 55-6, 98, 113, 145
compliance 22, 34, 84, 88
components 12, 29, 52-4, 62, 95-6, 118, 123-4, 129, 131, 133-4
Computing to Project Management 121
concept 14, 50, 81, 122, 133-4, 136

151
Project Management

Concluding Project 115

connections 4, 96, 98, 123-5, 135, 139
constraints 40, 43-5, 47, 50, 52, 54, 62, 64, 69, 71-3, 89-90, 108,
130, 138
resource 73
construction 13, 39, 123, 131, 135
contingency plans 105-6
contract 11, 34, 39, 44, 60, 71, 78, 91, 107-10, 112-13
contract administration 39, 107, 112
Contract Close-out 34-5
contractors 69, 113, 125, 137
contractual agreements 89, 106, 109
contributions 91, 94, 127, 131
control changes 34
control charts 85-6
control product scope 60
control workflows 142
Controlling 3, 32-3, 74, 118, 142
controlling change 3, 26, 47-9
Controlling Cost 4, 80
Cooper 147-8
coordination 37, 40
core processes 29, 31, 33-4, 37
core project team 17
corrective actions 46, 49, 60-1, 98
correctness 55, 57, 75
cost 8-9, 27, 33, 38, 45, 55-6, 59-60, 72, 77-80, 85-6, 97, 101,
105-6, 109-10, 136, 145 [10]
associated 100
budgeted 97
direct 109
estimated 97
estimating 54, 79
increased 73, 75
indirect 97, 109
likely 79
lower 82, 121
lowest 78
managing 79
measure 75
operational 75
cost baseline 79-80
cost budgeting 38, 75, 79
cost change control system 80

152
Project Management

cost controls 38, 75

cost estimates 79-80, 97, 104
cost estimation 75, 78
cost limitations 46
cost management 75, 140
Project 38
cost performance index (CPI) 98
cost reserve 79
cost resources 75
cost variance (CV) 98
CPI (cost performance index) 98
CPM (Critical Path Method) 72
crashing 72-3
creation 23, 29, 42, 47, 67, 77, 96, 106, 111
Critical Path Method (CPM) 72
Cultures 20-1
currency, units of 79
customize 129
CV (cost variance) 98
cycles 34, 37, 107

D
databases, multiple 124-5
date, forecast project completion 98
decomposition 54-5, 62-3
definitions, operational 83-5
degree 16, 25, 85
deliverables 14, 25, 34, 41, 50, 53-5, 62-3, 74, 82-3, 85, 97, 99,
119, 137
departments 16, 27, 52, 112
electrical engineering 42
dependencies 29, 47, 64-7, 126-7, 131, 134, 141
discretionary 64-5
descriptions 51-2, 56-7, 63, 68, 77, 95, 101-2, 110, 118
designations 2
development 23, 40, 42-4, 53, 105-6, 122, 133
diagrams 67, 83
pareto 85-6
project network 65, 67, 71, 73
time scale network 73
differences 8, 20, 24, 26, 81, 85, 87, 113, 115, 117-19, 125
Directing a Project 117
direction 17, 21, 58-9
disciplines 8, 12, 37, 39, 118

153
Project Management

disciplines of project management 13, 15, 17, 37, 39, 82, 115, 145
document project assumptions 43
duration 68-71, 74

E
effectiveness, measurement project 43
effort 11, 14, 37, 64, 69, 73-4, 113
aid project management 20
endeavor 29, 99-100, 134-5
entities 2, 42-3, 81
environment 8, 19, 23, 26-7, 29, 59, 121
en.wikipedia.org/wiki/Project 149
equipment 27, 30, 77-8, 105, 107, 109, 112, 128
estimates 9, 29-30, 33, 55, 69-71, 74, 78-9, 102, 104
evaluation criteria 110-11
events 41, 85, 88, 97, 102, 104
execute 17, 24, 46, 107, 112, 140-1
execution 14, 32, 39-40, 44, 46-7, 115, 140-1
expectations 8, 20, 41, 47, 58
experience 4, 40, 68-9, 91, 100, 123, 130, 142
unique non-overlapping professional project management 16
extent 33, 54, 56, 122, 125
External risks 100

F
factors 21, 25, 44, 59, 103
finish 65-6, 72, 128
flow 25, 119, 140-1
flowcharting 83, 85-6
forecast project cost 98
forecasting information 86
formal acceptance 31, 56, 58, 98-9
formal PMI, contact hours of 16
format 56, 94-5, 126
framework 40, 117-18
Framing Project 37
FRAMING PROJECT MANAGEMENT 3

G
GERT (Graphical Evaluation and Review Technique) 72
Global Knowledge 147-8
goal 7, 42, 52, 62, 78, 81, 83, 86, 100
Good Project Environment 147
goods 39, 105, 107

154
Project Management

grade 81
Graphical Evaluation and Review Technique (GERT) 72
group 15, 20, 23-5, 32, 85, 88, 92, 108, 130, 132, 142
grouping 3, 23, 25
guidance 17
guide 13, 42, 46, 54, 147
guide project execution 43

H
High School 15-16
historical information 43, 54, 62, 69, 77-9, 101, 115, 122, 125, 133
hours 16, 61, 68
human resources 30, 34, 87, 89-90
hyperlinks 4, 123-4, 127

I
identifier 56
IFBs (Invitation for Bid) 110
impacting project costs 128
implementation 10, 94, 119-20
improvements 8, 51, 58, 83-4, 93, 98
individuals 15, 17, 19, 27, 32, 58, 70, 87-8, 91-2, 104, 115, 123,
130, 142
information 2, 5, 13, 21, 25, 27, 29-34, 38, 41, 43, 45, 93-7, 124-
9, 133-5, 138-9, 141 [7]
accessing 95
compiling 126
disseminate 34
distribute 97
financial 78
performance 33
pertinent 134
post 126
project progress 47
retrieve 139
right 96
sending 96
sharing 96
statistical 43
storing 95
supplier 125
transfer 95
information aiding 51
information distribution 94, 96, 122

155
Project Management

information distribution system 96

information retrieval system 96
inspection 57-8, 67, 85
insurance 106
Integration Management, Project 37
Integration Product 3, 40
intentions 2, 40, 82, 87, 111
interact 40, 103
interfaces 88-9, 112, 123, 129
Internet 123, 135
Invitation for Bid (IFBs) 110
items 14, 49, 55-6, 63, 86, 88, 99-100, 110-12, 127-8, 139
defined work 63
ITIL 146, 148

J
job position 124

K
knowledge 8-9, 13, 17, 37, 39-40, 44, 46, 73, 89, 92, 119, 147
knowledge areas 37-40, 48, 54, 61, 74, 87, 107, 118, 140, 145

L
Lawrence 147-8
liability 2
license 136
life cycle 25, 37, 61, 117
lifecycle 23
limited resources 58, 61
links 93, 124, 127, 129, 134
list 53, 63-4, 101-2, 111, 126, 129
location 65, 121, 125, 128, 131, 135, 139
logical relationships 66-7
loss 2, 100, 102, 104

M
magnitude 60, 102
management 9, 16, 37, 39, 81, 112, 115, 145, 149
configuration 48-9, 119
executive 17, 137
Project Communications 38
management cost 74
manager, young 7
managers, professional project 15

156
Project Management

Managing Stage Boundaries 118

mashups 4, 128-9, 133
meeting 7, 111, 128, 131, 138
meeting project objectives 46
members 11, 15, 19, 42, 89, 92, 136
time project 136
methods, traditional 131-2, 134
minutes 68-9, 126, 134, 141
misinformation 47
mitigation 105
model 79
modules 66-7
monetary value, expected 104-6
money 11, 33, 43-4, 98, 104
monitor contractor cost 113
monitor cost performance 80
monitor project results 34
Most project management scheduling programs 69
Most project management software packages 65
Most project management solutions 124

N
network logic 72
sequential 72

O
operational state 41
operations 8, 11, 17, 19, 39, 41, 109, 137
organization 3, 7, 16, 19-22, 27, 39, 43, 77, 82, 104, 111, 115,
119, 131, 133, 138-9 [1]
performing 19, 39-40, 78, 82, 88-9, 91, 94, 107-9, 125
organizational planning 30, 38, 87-9

P
pages, single 124, 139
parties 21, 49, 52, 96, 123, 126, 141-2
executing 141
performing 132, 135, 141-2
payments 109
pdf 147-9
PDM 65, 67
performance 39, 54, 59-61, 80, 93-4, 97, 100, 113, 132, 135
permalinks 127
person 2, 12, 15, 68-70, 87, 91, 93, 96-7, 103, 121, 124, 127-8,

157
Project Management

137, 139
right 91
perspectives 62-3, 66, 115, 124, 137-8
workflow 141
Perspectives of Project Management 137
PERSPECTIVES of PROJECT MANAGEMENT 5
PERT (Program Evaluation and Review Technique) 72
phases 25, 27, 29, 37, 55-6, 58, 81, 92, 99, 117, 140
project of 24, 52
Pittsburgh Project Management Institute 148
planning 3, 29, 32-3, 39, 41, 49, 52, 77, 82, 100, 108, 118, 145
planning phase 25, 29, 31, 45
planning processes 42-3, 60, 101
PMBOK 3, 13, 16, 23-4, 44, 80, 99, 115, 117-19, 133, 140, 145-9
PMBOK Approach Insights for Software Development Projects 147
PMBOK Guide 13, 147
PMBOK Guide breaks project management 13
PMBOK quality management 80
PMI (Project Management Institute) 13, 15, 147, 149
PMIS (Project Management Information System) 44, 47, 49
PMP (Project Management Professional) 15-16, 149
policies, organizational 43, 46
portability 5, 122-3, 135-6
potential risk events 101-4
power 63
preassignment 91
price 110-11
fixed 109
pricing 78, 110, 112
PRINCE2 117-19, 149
probability 71-2, 85, 101-2, 104-6, 131
problem 10, 32, 50, 69, 83, 86, 130-2, 141
process group 24-5, 31, 33
processes, facilitating 29-31, 37
procure 31, 108-9
procurement 91, 105, 108-11, 145
procurement documents 110
procurement items 110-12
procurement management 119
Project 39
procurement planning 39, 107-9
product 2, 7-9, 17, 19, 22-4, 41-2, 46, 51-3, 57-9, 74-5, 80-6, 99-
101, 108-9, 112-13, 118-19, 133-4 [5]
expected 51

158
Project Management

interim 59
quicker 134
unique 145
well-defined 109
product names 2
product-oriented processes 24
product scope 48
product verification 113
productivity 82, 123, 143
Program Evaluation and Review Technique (PERT) 72
project
application 77
breaking 134
complex 92
construction 65, 109
engineering 40, 75
failed 10, 130
large 63, 79, 92, 112, 138
living 131
lower risk 15
managing 11, 15, 39
multiple 20
quality management disciplines complement PMBOK 81
selecting 51
specialized 13
support 89
way 13
project activities 41, 65, 71-2, 77, 126, 141
completing 75
project alternatives 53
Project-based organizations 20
project boards 119
project budget 34
project charter 52
project closure 145
project components 41
project constrains 44
project control 42
project cost estimate 78
project cost estimation 78
project cost management 74-5
project costs 75, 97, 105
project cycle 37
project decisions 52

159
Project Management

project deliverables 29, 45-6, 53-4, 61, 98

project details 50
project documents 99
project durations 72-3
project elements 40, 55, 62
project execution 42, 46, 113, 132, 140
project failures 9-10, 130
project information 43
project initiation 52
project integration 145
Project Integration Management 40
project interfaces 88-9
project level 117
project life cycle 24-5
project management 3-23, 25-33, 35-57, 59-67, 69-71, 73-80, 82-
5, 87-93, 95-100, 102-4, 106, 108-9, 114-24, 126-8, 130-8,
140-7 [1]
benefit 146
certified 26
understanding 27
web-based 136, 142
138
project management accreditation 11
Project Management Agile Processes 149
project management aid 101
project management application areas 58
project management approach 68, 112
project management assumptions 139
Project Management Body 147
Project Management Book of Knowledge 13
project management collaboration 143
Project Management Copyright 2
Project Management Critical Components for Success 148
project management days 141
Project Management Deming 81
project management distribution 39
project management engine 129
Project Management Facilitating processes 34
PROJECT MANAGEMENT FRAMEWORKS 4, 117
project management information 86
Project Management Information System (PMIS) 44, 47, 49
Project Management Information System, adopted 44
project management information systems 47, 49
Project Management Institute, see PMI

160
Project Management

project management interact 40

project management item 110
project management model 93
project management opportunity 105
project management perspective 100
project management processes 3, 24-5, 29, 108, 112, 117
Project Management Professional (PMP) 15-16, 149
project management programs 120, 136
Project Management Project communication management 94
project management relationships 125
project management requirements 113
Project Management Risk response control executes 107
Project Management Scheduling 72
project management situations 131
project management software packages 66, 73
project management solutions 122
project management success 24, 145
Project Management TABLE of CONTENTS 3
project management team 16, 89, 132, 136
project management tool 130-2, 138
Project Management Using 129
Project Management.pdf 149
project managers 3-4, 11, 13, 15-17, 19-22, 25, 32, 40, 42-3, 46-
7, 70-1, 90-1, 128, 130-2, 136-7, 141-2 [8]
project member 101
project methodology 117
project monitoring systems 135
project objectives 25, 64
project organization 105, 108
project outcomes 31
project performance 31-2, 60
project perspective 49, 63, 101
project phases 25, 34, 37, 52, 98
project plan 3, 38, 40-50, 54, 57, 61-2, 91-2, 97, 111, 127, 129,
131, 134-5, 138-9
final 42, 46
project plan development 37
project plan execution 37
project plan execution process 46
project planners 33
project planning 10, 29, 33, 44, 131
project practices 83
project processes 41
project processes focus 23

161
Project Management

Project Quality Assurance 84

project quality management 80-1
project requirements 90-1
project resources 94
project results 56, 84-5, 98
project risk 101
project risk management 99-100
project roles 30, 89
assigning 88
project schedule 30, 34, 72-4, 80
project scope 3, 31, 34, 48, 50, 56, 145
changing 72
project scope definition 54, 89
project scope management 38, 81
project scope planning 52
project staff 91-2
project staffing, expected 95
project stakeholders 32
project success 95, 99
project tasks 16, 24
project team 17, 19-20, 31-2, 47-8, 61, 63-5, 68-71, 74, 77-8, 81-
2, 84-7, 89-91, 99-101, 104, 111-12, 134-6 [11]
project team meeting 126
project team members 47, 50, 69, 77, 90, 126, 128, 137
project team uses 78
project time management 61
project timelines 10
project value 97
project variances 49
project work 57, 94
assigned 42
bulk of 29, 31
projects activities 67
projects claim 130
Project's Culture and Communications 147
project's existence 52
project's performance 32
projects stem, effective 26
Projectway 148
publisher 2

Q
quality 4, 8, 48, 59-60, 75, 81-4, 87, 101, 118, 122, 131, 145
quality control 38, 57, 84-6, 113

162
Project Management

quality control process 83, 85

quality management 42, 44, 75, 80, 82, 118, 140
Project 38
quality management activities 82
quality management plan 84-5
Quality Management System 119
quality planning 38, 82-3
quality policy 82
quality standards, relevant 30, 32, 81, 84

R
RAM (Responsibility Assignment Matrix) 89
Really Simple Syndication, see RSS
relationships 32, 65-6, 87-90, 124-5, 129, 134, 145
reporting 88, 92
reliability 103, 121-2, 143
Request for Proposal (RFP) 110
Request for Quotation (RFQ) 110
resistance 130
resource cost 30
resource estimates 56
resource leveling 73
resource limitations 72
resource management
human 87, 119
Project Human 38
resource planning 38, 75, 77
resource pool descriptions 71, 77
resource requirements 30, 71, 74, 77-8
resources 4, 8, 14, 17, 24, 27, 30, 33-4, 41, 44, 54, 58, 60, 77-80,
94, 99-100 [9]
responses 21, 31, 45, 103, 105-7, 126, 140-1
responsibilities 21, 30, 43, 54, 88-9, 102, 119, 141
Responsibility Assignment Matrix (RAM) 89
reusing project plans 133
review, formal 48
rework 73, 82, 86
RFP (Request for Proposal) 110
RFQ (Request for Quotation) 110
risk events 102-4, 106-7
risk identification 39, 100, 107
risk management 100, 119, 140
Project 39
risk management plan 106-7

163
Project Management

risk quantification 39, 100, 103-4

risk quantification process 104-5
risk responses 106, 125, 129, 140-1
risk symptoms 101, 103
risks 4, 17, 29, 31, 34, 39, 44, 47-8, 50, 99-107, 109, 122-3, 125,
130-4, 139-41, 145 [3]
covered 106
handling 106
high 104
increased 73
low 104
potential 83, 101, 140
required staff Key 45
sources of 101-4
understanding 100
risks event 102
roof 64
RSS (Really Simple Syndication) 127, 133
RSS technology 127

S
sampling, statistical 85-6
schedule 3, 14, 24-5, 33, 48, 62, 69, 71-4, 86-7, 95, 97-8, 100,
103, 106, 128, 137 [4]
preliminary 73
schedule change control system 74
schedule control 38, 61, 74
schedule development 38, 61-2
schedule estimates 138
schedule performance 85-6
schedule performance index (SPI) 98
schedule variance (SV) 98
scheduling 3, 65, 71-2, 86
scope 8, 10, 29, 34-5, 38, 41-2, 44-5, 48, 50-6, 58-60, 62, 74, 80,
87, 100-1, 137-8 [2]
changing 59-60
project's 59
scope change control 38, 59
scope change control system 60
scope changes 59-60
scope management 74, 140
scope management plan 59-60
Scope Management Time Management Cost Management 118
scope planning 38

164
Project Management

scope statement 29, 52-4, 56-7, 62, 77, 82, 108

scope verification 38, 56-7
scope verification process 56-8
sellers 2, 32, 110-12
prospective 110-11
sequence 65, 68
Service Management and PMBOK for Application Support Project
148
services 2, 7-8, 17, 22-3, 39, 46, 51-3, 78, 80, 105, 107-10, 112-
13, 145
new 7-8
product of 78
simulation 70, 73, 104
skills 8-10, 17, 21, 32, 42, 44, 46, 89, 92-3, 96, 108
Software Development Projects 65
software package 66-7
Software Projects 148
solicitation planning 39, 107-8
solutions 121-2, 125, 131, 142, 145-7
web-based 142, 146
sources 84, 102, 107, 124, 128-9, 138
multiple 112, 129
sourcing, open 131-2
SPI (schedule performance index) 98
staff 90-1, 102, 145
stakeholders 9, 15, 19-22, 27, 30, 34, 42-4, 48, 56-8, 75, 81-2, 94-
5, 101-4, 122, 126-8, 141 [8]
standards 13, 22, 45, 80-1
start 7, 62, 64, 66, 71, 73, 82-3, 128, 130
Starting up a Project 117
statement, project management Scope 45
structure 88, 90, 95
organizational 88-9
subnets 67
Successful project management 19
Summarizing Project 145
supplier 113, 125
SV (schedule variance) 98
systems 20, 47-9, 53, 59-60, 74, 83, 92-3, 96, 98, 135, 139

T
tap 142
tasks 14-15, 17, 24, 42, 47, 55, 135
team 14, 17, 22, 40, 78, 80, 87-8, 91-3, 101, 131

165
Project Management

team development 38, 87, 92-3

matrix organizations 91
team development service 91
team members 46-7, 70, 91-2, 132
teamwork 130
technologies 50, 64, 95, 105, 122, 127, 146
new 59, 95, 101, 103-4
templates 54, 63, 67, 89, 115, 133
network 67
tepaper pdf/WP 147-8
theme 132
threats 31, 101, 103, 105, 128
time management 62, 140
Project 38
tolerances 104
tools 8, 20, 23, 44, 49, 52, 60, 62, 70, 74-5, 85, 96-7, 101, 130-2,
135-6, 139 [1]
Total Quality Management (TQM) 81
TQM (Total Quality Management) 81
track 33, 142
trademarks 2

U
unit price contracts 109
updates 25, 47, 49, 67-8, 74, 131, 135-6, 142
usage 136
users 122, 124, 127, 129, 132-3, 135, 139
uses project characteristics 79

V
variances 32-3, 49, 60-1

W
walls 9, 64
WBS (Work Breakdown Structure) 14, 45, 54-7, 59-60, 62-3, 68,
74, 77-8, 80, 101, 138
web 7, 122-4, 126, 135
web applications 121-4, 129, 135
web page 126-7
Wikipedia 149
work 7-8, 14, 20-1, 24, 34, 37-8, 46-8, 50-1, 62-3, 68-70, 74-5,
84-5, 97-8, 109-10, 112-13, 140-2 [15]
work authorization system 46
work breakdown structure 14, 54, 74, 138

166
Project Management

complete 55
objectives 45
Work Breakdown Structure, see WBS
work element 56
work packages 56
workarounds 107, 140-1
workflow element 141
workflows 5, 135, 138, 140-2
multiple 142
workforce 17, 26
workplace 11, 22

167