05 Successful Projects PDF

A Project
Managers
Guide to
Successful
Projects
Aligned
with
®
PMBOK
Guide 3rd
Edition
Sturgeon Publishing
Sturgeon Publishing Brent W. Knapp, PMP
.....
Preface
PREFACE
....................................................
Dear Reader -
The Project Management Excellence Center, Inc., is excited to have published this
book titled “A Project Managers Guide to Managing Successful Projects”. We believe it
is the first of its kind in the field of project management.
Just as the Project Management Institute is committed to establishing measurable
standards for the project management professional, The Project Management
Excellence Center, Inc. is happy to help assist professionals with the knowledge
needed to meet those standards.
This book assumes you have at least read “A Guide to the Project Management Body
of Knowledge” (PMBOK®) and have some general project management skills. We
highly recommend that you obtain the PMBOK® if you do not currently have a copy.
COPYRIGHT INFORMATION
....................................................
All rights reserved. Copyright 2005, The Project Management Excellence Center, Inc.
No part of this publication may be stored in a retrieval system, transmitted, or
reproduced in any way, including but not limited to photocopy, photographs, magnetic,
or other record, without the prior agreement and written permission of the publisher.
The author and publisher have made their best efforts to prepare this book. The author
and publisher make no representation or warranties of any kind with regards to the
completeness or accuracy of the contents herein and accepts no liability of any kind,
including but not limited to performance, merchantability, fitness for any particular
purpose or any losses or damages of any kind caused or alleged to be caused directly
or indirectly from this book.
Trademarks: The Project Management Excellence Center, Inc., has attempted
throughout this book to distinguish proprietary trademarks from descriptive terms by
following the capitalization style used by the manufacturer.
A Project Managers Guide to Managing Successful Projects Preface

Published by: Sturgeon Publishing - http://www.sturgeonpublishing.com
Email: publishing@sturgeonpublishing.com
www.pmptools.com publishing division welcome corrections and comments on its

documents. In addition to comments, please send comments on typographical,
formatting, or other errors. Simply make a copy of the relevant page, mark the error,
and send it to The Project Management Excellence Center, Inc., Publishing Division,
Post Office Box 30291, Phoenix, Arizona 85032, or email at
publishing@sturgeonpublishing.com.
Books and testing materials are available at special quantity discounts to use as
premiums and sales promotions, or for corporate training programs, as well as other
educational programs. For more information, please write the Business Manager at
publishing@sturgeonpublishing.com.
Printed in the United States of America. No part of this work may be reproduced or
transmitted in any form or by any means, electronic, manual, photocopying, recording,
or by any information storage and retrieval systems, without prior written permission of
the publisher.
ISBN 0-9726656-7-6 (paperback)
Preface A Project Managers Guide to Managing Successful Projects

.....
Table of Contents
Table of Contents
Chapter 1 - Introduction
Introduction ............................................................................................ 1
Chapter 2 - Understanding Project Management

Project Management Is a Process ......................................................... 6
Determining Who a Project Affects ........................................................ 7
Stakeholder Review ............................................................................... 8
Where Do Projects Come From? ........................................................... 9
Establish and Refine Objectives Based on Needs ............................... 10
Requirements: Functional and Technical ............................................. 11
Requirements Definition Challenges .................................................... 12
Requirements Documentation.............................................................. 12
Chapter 3 - Project Management Foundations

Change Management........................................................................... 15
Planned Change Management ............................................................ 16
Change Control .................................................................................... 17
Estimating Fundamentals..................................................................... 18
Project Estimating ................................................................................ 19
The Work Breakdown Structure - Overview ......................................... 20
Task - vs. Product-Oriented WBS ........................................................ 23
The Work Package............................................................................... 24
The Control Account ............................................................................ 25
Project Charter ..................................................................................... 26
Scheduling with the WBS or Task List: Precedence Diagram.............. 26
Basics of Critical Path Analysis ............................................................ 27
Critical Path Analysis ........................................................................... 29
Effective Scheduling............................................................................. 31
Effective Scheduling - Exercise............................................................ 32
Schedule Acceleration: ........................................................................ 32
Scheduling Issues ................................................................................ 34
Input to Cost Estimates ........................................................................ 34
Joining Schedule and Cost Estimates.................................................. 35
Evaluating Status and Change............................................................. 36
Life Cycle Costs ................................................................................... 37
Cost Management ................................................................................ 38
A Project Managers Guide to Managing Successful Projects Table of Contents

Chapter 4 - Project Implementation
Staffing Considerations ........................................................................ 41
Establishing Responsibility................................................................... 42
Recruiting the Team ............................................................................. 43
Resource Allocation ............................................................................. 44
Resource Leveling ............................................................................... 44
Risk Issues ........................................................................................... 45
Managing Risk ..................................................................................... 46
Risk in Scheduling - PERT ................................................................... 47
Risk Tools ............................................................................................ 48
Evaluation and Control ......................................................................... 49
Earned Value ....................................................................................... 50
Earned Value Fundamentals................................................................ 51
Project Progress................................................................................... 54
Types of Organizations ........................................................................ 55
Team Structure and Communication.................................................... 59
Managing Borrowed Resources ........................................................... 59
Team Structure Alternatives................................................................. 60
Team Member Roles............................................................................ 61
Communication Tools .......................................................................... 62
The Project Manager's Authority .......................................................... 63
Deploying Authority .............................................................................. 64
Building Authority and Influence........................................................... 65
Who and What Define Success ........................................................... 66
Personal Closeout ................................................................................ 67
Implementing Effective Reward Systems............................................. 68
Chapter 5 - Project Close-Out

Administrative Closeout ....................................................................... 69
Contract Closeout ................................................................................ 70
Scope Verification ................................................................................ 71
Organizational ...................................................................................... 71
Project Management in the Business Environment.............................. 72
Lessons Learned.................................................................................. 73
Appendix A - Project Management Tools

Appendix A .......................................................................................... 75
Table of Contents A Project Managers Guide to Managing Successful Projects

INTRODUC TION
...................................
1
.....
By reading this book “A Project Managers Guide to Managing Successful Projects”, you
have taken a lasting step in getting a solid understanding of project management methods.
This book will help you gain hands-on experience in proven project management methods
and discover valuable, flexible tools that you can use immediately to ensure the success of
any project in any organization.
After reading this book you will be provided with a broad review of the concepts and
practices used in managing projects effectively in today's business environment. It covers
the basic concepts of the five essential project management processes, defining
requirements, schedules, risk management, and change control. Participants gain an
understanding of how the project management processes are used during the phases of a
project to build a better, more effective project plan.
On completion of this book, you will be able to:
• Define the elements of an effective project charter
• Identify and develop all the elements of a team charter
• Identify the elements of the triple constraint
• Develop a project scope
• Understand the different types of estimates
• Determine strategies for handling change requests
• Learn how to identify, quantify, and manage risk
• Develop, monitor and control schedules
• Understand the importance of a project closeout process
With this book you will get a solid understanding of project management methods. Gain
practical experience in proven project management techniques and discover a wealth of
valuable, flexible tools that you can use immediately to ensure the success of any project in
any organization.
Managing Projects gives you the foundation, experience, techniques and tools to manage
each stage of the project life cycle, work within organizational and cost constraints, set goals
tied directly to stakeholder needs, get the most from your project management team, and
use state-of-the-art project management tools to get the work done on time and within
budget.
A Project Managers Guide to Managing Successful Projects Introduction 1-1

INTRODUCTION
1
Covering the entire project life cycle, this book is built around the latest insights from the
Project Management Institute’s “A Guide to the Project Management Body of Knowledge
(PMBOK® Guide)”, which incorporates information critical to project success.
You’ll learn project management skills through a broad array of practical experiences that
can immediately be applied to your job. This approach yields a comprehensive project
management experience, including the early stages of defining project requirements,
developing work breakdown structures, project change control and closeout.
This book will open the door to more efficient project implementation.
COURSE OBJECTIVES
Introduction to Project Management

• What are "projects"?
• Why project management?
• The project life cycle
• Influences on a project
• Key stakeholders
• Project management process groups
• Project manager responsibilities
Project Initiation
• Understanding the role of senior management
• Needs Assessment
• Project selection
• Benefit/cost ratio
• Present value and net present value
• Building SMART objectives
• Developing Requirements
• Project charters
• Project Requirements Document
• Project Planning
1-2 A Project Managers Guide to Managing Successful Projects

.....
INTRODUCTION
Scope planning
• The work breakdown structure
• Estimating
• Schedule Planning
• Network Diagrams - CPM
• Speeding up the Schedule
• Project Management Planning Software
• Cost Planning
• Responsibility Matrix
• Resource Loading and Leveling
• Risk Planning
• Procurement Planning
• Communication and quality planning
Project Implementation
• Baselines
• Developing the project team
• Organizations and team structures
• Managing change
• Managing Risk
• Performance reporting
• Reserves
• Assessing and monitoring project performance
• Earned value
• Sunk costs
Project Closeout
• Scope verification and customer acceptance
• Administrative and contractual closure
• Transferring lessons learned to future projects
A Project Managers Guide to Managing Successful Projects Introduction 1-3

INTRODUCTION
1

U NDERSTANDING P ROJECT M ANAGEMENT
...................................
2
.....
e
Co
T im
st
Quality
Resources
Scope
Before we get into any discussion on project management, we need a common definition of
a project. It is a unique effort with limited resources aimed at a specific objective within a
time constraint. The essence of a project is captured here. It is called the triple constraint.
The triple constraint of project management embodies what all good projects are. They
involve Time, Requirements and Resources. Time is the deadline aspect of our projects.
Requirements, or scope are the deliverables that the project will produce. And resources
include the people and materials that we are committing to the effort.
The scope side represents the agreed-upon project work and requirements, the cost side
represents the total dollar cost of the project, and the time side represents the project
duration. Inside the triangle, resources refer to the people and equipment in use on the
project and quality to how close the project is to satisfying client expectations.
A Project Managers Guide to Managing Successful Projects 2-5

UNDERSTANDING PROJECT MANAGEMENT
2 Project Management Is a Process
What the figure shows is that there is a clear relationship between the scope of a project,
how long the project will take, and how much it will cost. If the scope of a project is
increased once we have established estimates for time and cost, the only way to maintain
the same relationship is for us to increase time and cost.
If time and cost are kept the same, then the other two components suffer. Either resources
are overworked, which may lead to causalities, or quality is reduced, which may lead to
unsatisfied clients. Commonly, both may happen.
PROJECT MANAGEMENT IS A PROCESS

....................................................
Project management is a process which contains a series of actions, changes, or functions
in order to bring about a result. This process is iterative nature.
Assess Project
Affirms Validity
Needs
NO YES
Continue Establish
Project Plan
Implement
Control Project
Project
Assess Project
Progress
Close out
Project

.....
Determining Who a Project Affects
To serve the triple constraint, we need to manage. We manage the entire cycle of the
process, not just the implementation. And it is important to understand that projects have
iterative cycles; they are not entirely linear.
Let me also offer some insight here on the five planning processes as identified by PMI®—
initiating, planning, executing, controlling and closing. As with the processes in this diagram,
the PMI® processes are iterative. The cycles or iterations in both processes may predicate
change.
A major part of our job is to understand and communicate when and where the change is,
improving our ability to manage. Projects must be reassessed continually as they evolve.
Customers, project managers and organizations all generate change (in scope, resources,
schedules, approaches) throughout the life of a project. Note one other thing. Project
managers in best practice organizations are involved in needs assessments, which we will
talk about shortly. If you are not involved that early in your organization, you are probably
coming in at the second step of the process, even if you are doing it at mid-project. At some
point, project managers need to validate that the project makes good business sense. That
is serving the customer.
DETERMINING WHO A PROJECT AFFECTS

....................................................
STAKEHOLDERS
• Who uses it?
• Who gets the output?
• Who provides the input?
• Who has oversight responsibility?
• Who has related responsibilities?
• Who gets the rewards?
• Who suffers the penalties?
Stakeholders in any given project are legion. And the real challenge is that any of them have
the potential to cause us, the project managers, much grief. They can make life wonderful or
inordinately challenging. The trick is to anticipate the challenging participants early so that

2 Stakeholder Review
they do not catch you off-guard. The other trick is to find the hidden allies within an
organization.
As the project manager, before you are pressed into service on a project, you need to know
whom you will serve. These are the questions that get you started. These are not idle
questions, either. Since competing stakeholders may have competing interests, the project
manager has to know whose needs take precedence. To make this happen on your
projects, you need to work on a master list of who you have to serve; and in some cases,
who you have to serve and in what order.
STAKEHOLDER REVIEW
....................................................
Stakeholder influence is the major reason a project succeeds or fails. I have often heard of
new project managers complain that they did not receive the support they needed to deliver
a project on time, on budget, or to the desired performance level. I later discovered they
had overlooked a key stakeholder or did not identify their stakeholders at all. Managing
stakeholders requires planning, organizing, motivating, directing, and controlling in the
same way they manage a project. In fact, stakeholder management can be thought of as a
project within the project.
A stakeholder is anyone who has a vested interest in the project. Typically, the stakeholders
for most projects will include the project team members, functional managers, other
corporate managers of business or financial groups, the customer, and the end users. Look
also to outside agencies for stakeholders especially if law or special-interest groups regulate
your project.
Some organizational managers do not fit the strict notion of vested interest but still feel they
are stakeholders. The successful project manager will determine who these players are
and include them in his stakeholder management plan. Usually, the unidentified
stakeholder or would-be stakeholders can undermine a project before the project manager
is even aware of a problem.
Identifying the project stakeholders is important, but it is absolutely critical that you discover
their position, that is, whether they are for or against the project and why. A simple
worksheet is located in the Appendix to assist in this process. See Appendix A, Tool 2.

.....
Where Do Projects Come From?
Using the worksheet, identify the stakeholders and check the appropriate column to show if
they are for, neutral toward, or against the project. The next step is to determine the reason
for their position and their strengths and weaknesses relative to their influence on the
project. With this information, the project team can develop a strategy for moving the
stakeholders to a positive position.
The following is a list of steps in the stakeholder management process. The steps for
analyzing stakeholders should be a project team effort. Managing the process is the project
manager’s responsibility.
• Identify stakeholders
• Determine stakeholders’ positions on the project
• Determine the stakeholders’ agenda
• Assess stakeholder strengths and weaknesses relative to their influence on the
project.
• Identify strategy to move stakeholders to a positive position on the project.
• Predict stakeholder reaction to the strategy.
• Implement the stakeholder management strategy
The above list is simple in notion but difficult to implement successfully unless you are
politically aware of the corporate culture and possess effective interpersonal skills. It is
imperative, however for you to manage your stakeholders. Your project successes will
improve significantly if you do.
WHERE DO PROJECTS COME FROM?

....................................................
• Needs - something required or wanted; a requisite
• Internal sources whether individual or organizational
• External influences, such as customers, socioeconomic influences and the
marketplace
You just read about who is driving the project. Now we need to know what their needs are.
Every project is created in response to an individual or organization’s needs. There are
internal sources—management, co-workers, and end users. There are Organizational
sources, like an organization’s attempts to change internal efficiencies. There are also

2 Establish and Refine Objectives Based on Needs
external sources of needs like government regulation, the shifts in the economy and the
marketplace. Many of us, if not most of us have been affected by the cultural influences of
recent technological advances.
Needs for the key stakeholders MUST be addressed for a project to be successful. And
then, they need to be documented. Documentation is key.
ESTABLISH AND REFINE OBJECTIVES BASED ON NEEDS

....................................................
• Determine whose objectives are valid
• Establish a SMART objective
Specific
Measurable
Agreed to
Realistic
Time constrained
• Review the objectives with the key stakeholders
Needs drive objectives. We need it. We will aim for it. And if you do not have your customer
and sponsor in agreement on the objectives, there is a serious problem.
The first bullet is often the most difficult. The key is to identify who takes priority in your
organization. Can any stakeholder objectives be dismissed entirely?
If the valid project objective was to pave an Interstate highway, a smart objective would be
more specific. Pave 10 miles of Interstate Highway 10 from mile marker 150 - 160 using the
standard Arizona Department of Transportation process at a cost not to exceed $600,000 by
the end of the month. It is measurable. We concur on what constitutes acceptable road-
paving performance in terms of thickness, strength, look and feel. It is all agreed to by all of
the parties involved, and is actually achievable. That is a SMART objective. What if I said I
needed it done by the end of the week? It would still meet the other criteria, but would not be
realistic. If I said we had a budget of $45,000? It is something any sane contractor would not
agree to.
I understand what many of you are thinking and saying quietly -- I do not even get to set the
project objective. While that may be true, if no one has ever set the objective for the project,

.....
Requirements: Functional and Technical
it still needs to be done. Even at mid-project. We need an objective to know where we are
supposed to be going.
REQUIREMENTS: FUNCTIONAL AND TECHNICAL

....................................................
Functional
• Nontechnical
• What it is, how it works, and what it does
• Understandable
• Customer oriented
Technical
• Detailed
• Physical dimensions
• Performance specifications
• Project team oriented
From needs to objectives, from objectives to functional requirements, and from the
functional to the technical.
The key here is to understand that each step in the process means a leap of faith. Your
printer breaks down and a need has arisen. You should know that needs arise and we
recognize them. Then, we articulate them as objectives. The objective is to get a new
printer. Repair might have been sufficient. The functional requirement? I need a new printer
that works. A used printer could have done the job just as well. Then we go from the
functional to the technical...a HP Color Laser Printer. I may need a printer of that quality. Or
I may just need a cheap printer. Going from the functional to the technical requires expertise
and agreement.
The process again...and this is important: Needs arise. They are recognized, then
articulated...first as functional and then as technical requirements.

2 Requirements Definition Challenges
REQUIREMENTS DEFINITION CHALLENGES

....................................................
• Levels of detail
• Levels of information - internal and external
• Controlling change
• Traceability
After you know what the requirements are, you need to know the environment in which they
will function. And the concerns here are legion. Too much or too little detail. Too much? No
flexibility impedes team creativity/energy, likely to be ignored. Too little/loose? Inconsistent
deliverables, lack of direction for the team, may be ignored. How do we overcome these
problems? We bring the implementers into the definition process as practical, and we
document.
Part of the challenge is to ensure the right level of detail from all of the parties, in all of the
right areas. That is where documentation comes into play (see Appendix A, Tool 3). This
creates a common history and a common framework for how the project can and will evolve.
REQUIREMENTS DOCUMENTATION
....................................................
Documentation is a critical element. You can ask all the questions in the world, but if not
documented properly, all the resulting information will be forgotten or lost. You must ensure
that you are documenting the information in a way that is satisfactory both to you and to
your customer, because the customer will need to approve that documentation as it
ultimately turns out.
Customer relations is an important component of documentation. Who is going to be
responsible for what? What is the chain of command that will exist within the project and
between the project organization and the customer organization? Contract negotiations are
also important. You will need to get documentation for those negotiations—who is getting
what, who promised what to whom. Resource allocations are also important. Sometimes
customers want to know who specifically will be working on their project, and in what
capacities. We must ensure that we give them that information or that we know what their
expectations are.

.....
Requirements Documentation
There is an element of personal growth and development as well. When you document
things, you find out what you do not know. You learn what you need to find out about. It can
be a scary experience—documenting all this information is often a lesson in what we cannot
accomplish and what we cannot do.
(See Appendix A, Tool 4 to view a Basic Requirements Checklist.) As you go through the
checklist, think about which of these are open, unanswered questions with your existing
customers on your current projects.

2 Requirements Documentation

P ROJECT M ANAGEMENT F OUNDATIONS
...................................
3
.....
There are several types of baselines: technical, schedule, and cost. The Requirements drive
the schedule and the overall cost of the project. Cost, schedule, and requirements form the
baseline. That is the measure against which they will judge a project manager’s
performance. Different organizations handle different types of baselines differently.
Do not get pulled into a situation where one type of baseline takes precedence, although in
most organizations it will. Schedule takes precedence over cost. Requirements take
precedence over schedule. For all intents and purposes, they are equal. Once the sponsor
and the customer have concurred on their application, they are equal.
Why is the agreed upon baseline so critical? Because it is the arbiter of what the project is
and what the project is not. If our project is to procure and install 100 workstations around
the office, and that is all the project is supposed to include, the project does not include
updating the computer wiring in the process. It does not include refurbishing the desks.
While in theory those additional projects may make sense as adjunct work, they represent
change. And the baseline establishes what is a change and what is not.
CHANGE MANAGEMENT
....................................................
• External events
• Errors and omissions
• Value-added changes
Where do changes come from? Virtually anywhere and everywhere. As a project manager,
we need to anticipate what will cause change. In change management, a key challenge is
ascribing responsibility, because customers often do not want to pay for change and
organizations are generally somewhat resistant to change. Thus, change can become a
major point of contention. These three drivers represent the causes of most scope changes.
Very few changes are clear, simple, easy-to-follow, order-driven changes. Most are more
subtle. A problem surfaces. Someone neglected an element of the requirement. An

PROJECT MANAGEMENT FOUNDATIONS
3 Planned Change Management
opportunity arises that is too good to pass up. Good change management means there are
points of contact and hopefully processes installed to follow.
One organization that I know in Miami has a change process that details how they will
handle changes driven by natural disaster (hurricanes). And that is given to each customer
at the beginning of the project. That is effective change management, by virtue of knowing
what may drive change.
PLANNED CHANGE MANAGEMENT

....................................................
Approaches
• Configuration management
• Prototyping
Conventions
• Documentation
• Communication channels
Building the plans means that we have approaches we can manage. If we do not plan for
change, it will happen without us. (See Appendix A, Tool 5)
There are two extremes in change management. Configuration management takes a
deliverables-oriented approach to change, focusing on modifications to change items or
components. It is forms-driven, extremely time-consuming and demanding on the customer,
the team and the project manager. Change management involves the extremely detailed
breakdown of activities and a contractually oriented adherence to that breakdown.
The antithesis to change management is prototyping. It encourages change, rather than
stifling it. It invites change and works well in fluid, highly conceptual efforts.
The key with a prototype is to know when we are done. We are done with a prototype when
it is ready to do what we want it to do, or when we run out of either time or money.
In both cases? Major issues include communications and documentation. Both have to be
thorough to make the process work.

.....
Change Control
CHANGE CONTROL
....................................................
The basic objectives of a change control system are to -
• Continually identify changes, actual or proposed, as they occur.
• Evaluate the consequences of the proposed changes in terms of cost and schedule
impacts.
• Permit managerial analysis, investigation of alternatives, and an acceptance or
rejection checkpoint.
• Communicate changes to all stakeholders.
• Insure that approved changes are implemented.
• Update the development process.
The Change Process
Identify Proposal to Document &

Change Customer Communicate
Clarify Scope Customer NO Update File

Accepts?
YES
Identify Update Project

Impacts Baseline
Document & NO Accept YES Implement

Communicate Changes? Changes
Change control is required in a project to eliminate scope creep and to ensure that the
customer and other stakeholders are aware of any changes to the original scope. We

3 Estimating Fundamentals
should clearly document the control system and control process in the statement of work
(SOW) and in the project management plan. The change control board (CCB) is a special-
purpose group of three to five functional experts who are responsible for considering
change requests submitted through the project manager. The project manager presents the
requests to the change control board (CCB) along with a reason for the request and the
impact to the project's budget and schedule. If the change control board (CCB) decides the
change request is beneficial to the project, they will make a recommendation to the
customer along with a proposal outlining the benefits and costs. The customer decides
whether to pursue the requested change or not. If he decides to go ahead, then a formal
modification to the contract is written and communicated back to the selling organization.
We make the change and the stakeholders are notified. Finally, once the customer approves
the change request we need to get the appropriate signatures. Do you have all the
signatures necessary to authorize this request?
ESTIMATING FUNDAMENTALS
....................................................
• Order of magnitude
• Budget
• Definitive
When providing an estimate, the project manager should know the level of accuracy and
detail he or she is working toward.
Order of magnitude is a broad estimate often provided early in the project when only the
basic objective has been defined. These are often ballpark, guess, conceptual, or feasibility
estimates. These broad estimates have an accuracy of +75/–25 percent. I have had
students argue “My management will not buy it.” They will say, “Give me a hard number.” If
the original number was a million dollars +75/–25, then say, “Fine, the estimate is 1.75
million.” Management will understand the message you are attempting to convey far more
readily.
The top-down estimate, sometimes called the analogous estimate, is significantly more
accurate. It is based on some historical data, and comparisons with other similar projects
are usually used to develop its costs. The one thing to be cautious about when using
analogy, though, is to make sure the two projects are actually similar. The cost of building a

.....
Project Estimating
road in Arizona during the summer is not the same as building the same size road in New
Hampshire in the winter. One other disadvantage of this method is that you can easily
overlook tasks that are required. One project might have some unique requirements that
another one, despite similarities, does not have. This type of estimate is accurate to within -
10% and +25%.
The most accurate method of all is the bottom-up or definitive estimate. It relies on
estimates made at the lowest WBS level and is done by the people responsible for the task.
Once the estimates are completed, the total cost of the project is the sum of the costs of all
the tasks. This type of estimate is accurate to within -5% and +10%.
PROJECT ESTIMATING
....................................................
• Try another approach
• Validate in the marketplace
• Keep records
• Admit—and do not punish—errors
• Review the contract
A friend of mine was bidding on a government contract and a encountered a challenge.

They had developed an estimate and realized at the end that they had come up with an
unbelievably low price. They were thrilled, of course, because they knew they would win the
work, but they also had doubts about their estimate. So they went through a major review of
the estimate.
It was for a military base in Europe and it was going to be a major installation. As they
looked at the estimate, they realized they had assumed that it was all going to be done
within the same facility. It was all stated that it was going to be done for one particular
organization, at one particular location, but they did not say within the RFP [request for
proposal] that it was all going to be in a single facility. They came up with an original
estimate in the hundreds of thousands of dollars. Instead, they should have come up with an
estimate in the millions of dollars.
A friend came in and did a ballpark estimate for them. When that ballpark estimate came in,
it was roughly $5.5 million. They checked around the market and tried to get a sense of what

3 The Work Breakdown Structure - Overview
other organizations were charging for similar work. The average price tag was about $6
million. A thorough review of the contract is what led them to realize that they had actually
not understood the work at all. It was a variety of small facilities within a single location.
Coordinating and integrating those various facilities within that single location was going to
increase the cost by hundreds of thousands of dollars. Had they simply accepted their
original estimate on face value, there would have been a serious loss.
THE WORK BREAKDOWN STRUCTURE - OVERVIEW

....................................................
• A deliverable-oriented grouping of project elements that organizes and defines the
total work scope of the project (PMBOK® Guide)
• A task- or product oriented hierarchy of the work to be performed
• A decomposition of the work to be accomplished
• A common organizing model
The Work Breakdown Structure (WBS) is a hierarchical description of the work that must be
done to complete the project. It is perhaps the most useful project management tool. When
done correctly, the WBS is the basis for planning, scheduling, budgeting, and controlling the
work of the project. An example of the WBS is shown below.
To begin our discussion of the WBS, you need to be familiar with the terms introduced in the
WBS figure. The first term is activity. An activity is simply a chunk of work. The second term
is task. Note that activities turn to tasks at some level in the hierarchy. A task is a smaller
chunk of work. While these definitions seem a bit informal, the difference between an
activity and a task will become clearer shortly.

.....
The Work Breakdown Structure - Overview
GOAL
ACTIVITY ACTIVITY ACTIVITY
Activity Activity Activity Activity Activity Activity
Task Task Task Task Task Task
Task Task Task Task Task Task
Task Task Task Task Task
Work Breakdown Structure Task
The terms activity and task have been used interchangeably. Some would use the
convention that activities are made up of tasks, while others would say that tasks are made
up of activities, and still others would use one term to represent both concepts. In this book,
we refer to higher level work as activities, which are made up of tasks.
We also use the term work package. A work package is a complete description of how the
tasks that make up an activity will actually be done. It includes a description of the what,
who, when, and how of the work.
Breaking down work into a hierarchy of activities, tasks, and work packages is called
decomposition. Decomposition is important to the overall project plan because it allows you
to estimate the duration of the project, determine the required resources, and schedule the
work. The complete decomposition will be developed by using the completeness criteria
discussed later in this chapter. By following those criteria, the activities at the lowest levels
of decomposition will possess known properties that allow us to meet planning and
scheduling needs.
This process of decomposition is analogous to the process we all used in grammar school
to prepare a detailed outline of a research paper we were going to write. Despite the
teacher's extolling the value of preparing the outline before we wrote the paper, we chose to

3 The Work Breakdown Structure - Overview
do it the other way around-by writing the paper first and extracting the outline from it. That
won't work in project planning. We have to define the work before we set out to do the work!
THERE ARE FOUR USES FOR THE WBS:
Thought process tool. First and maybe foremost, the WBS is a thought
process. As a thought process it is a design and planning tool. It helps the
project manager and the project team visualize exactly how the work of the
project can be defined and managed effectively. It would not be unusual to
consider alternative ways of decomposing the work until an alternative is found
with which the project manager is comfortable.
Architectural design tool. When all is said and done, the WBS is a picture of
the work of the project and how the items of work are related to one another. It
must make sense; in that context it is a design tool.
Planning tool. In the planning phase, the WBS gives the project team a
detailed representation of the project as a collection of activities that must be
completed in order for the project to be completed. It is at the lowest activity
level of WBS that we will estimate effort, elapsed time, and resource
requirements; build a schedule of when the work will be completed; and
estimate deliverable dates and project completion.
Project status reporting tool. The WBS is used as a structure for reporting
project status. The project activities are consolidated (that is, rolled up) from the
bottom as lower-level activities are completed. As work is completed, activities
will be completed. Completion of lower-level activities causes higher-level
activities to be partially complete. Some of these higher-level activities may
represent significant progress whose completion will be milestone events in the
course of the project. Thus, the WBS defines milestone events that can be
reported to senior management and to the customer.
Trying to find a happy compromise between a WBS architecture that lends itself well to the
planning thought process and the rolling up of information for summary reporting can be
difficult. It is best to have input from all the parties that may be using the WBS before settling
on a design. There is no one right way to do it; it's subjective. You will get better with
practice.

.....
Task - vs. Product-Oriented WBS
TASK - VS. PRODUCT-ORIENTED WBS

....................................................
1.0 Project
1.1 Key task Area
1.1.1 Summary
1.1.1.1 Cost account
1.1.1.1.1 Work package
1.0 Product
1.1 Key component
1.1.1 Subsystem
1.1.1.1 Cost account
1.1.1.1.1 Work package
Different Work Breakdown Structures will be different. Take a look at these two. The top one
is task-oriented. The second one is deliverables-oriented. PMI leans toward a deliverables-
oriented approach. In either case, you are looking at a decomposition of the work to be
performed. You are seeing different approaches to the same effort.
The key is to know your organization. Do they prefer to see how the tasks break out? Or do
they want accountability on how much they are paying for what they are doing to produce a
deliverable? Also, note the numeric breakdown. It forces a logical assessment of what
belongs where in terms of groupings of work.
Everything that starts with 1.1.1 is part of the 1.1 family. Everything that starts with 1.1.1.1 is
at the cost account level or lower, serving the summary at 1.1.1. Why does it matter? It lets
you identify what work naturally goes together. And it lets you identify groups of work
packages.

3 The Work Package
THE WORK PACKAGE

....................................................
• Lowest level of the WBS
• Level at which resources are assigned
• PMI's guidelines: 80 hours
• Supports the statement of work
• Verb-object format
ABC Pro j
ec t
Provide Project
Initiate Develop
Management
Project Services System
Validate Develop Project Hold Kickoff Develop Develop

Design System
Requirements Plan Meeting Software Hardware
Work Package Level
The work package is the cornerstone of the work breakdown structure (WBS). It is where
work gets done. The rest of the WBS is support for this critical level. In a perfect WBS, these
are all identified with the same number of sets of numbers. All work packages are at the
same numeric level in the WBS. In this example, they are three levels deep. In a great WBS,
they are consistent in size and cover every bit of work. PMI recommends a guideline size of
80 hours of effort, although they can be as small as a few hours in some organizations or as
large as a few months in others.
The verb-object format? For the work package, it helps to clarify. A work package labeled
“Locate contractors” is far more comprehensible than one simply labeled “Contractors”. It
helps us know what we are supposed to be doing.

.....
The Control Account
THE CONTROL ACCOUNT

....................................................
• Level above the work package
• Level for management reporting
ABC Pro j
ec t
Control Account Level
Provide Project
Initiate Develop
Management
Project Services
System
Validate Develop Project Hold Kickoff Develop Develop

Design System
Requirements Plan Meeting Software Hardware
One other critical element in breaking down the work is the control account. It is one level
higher than the work package. In other words, if all your work packages are at the 1.1.1
level—as they are here—then the control account level is 1.1. No matter what you call it,
you need a reporting level that will keep upper management from micro-managing your
project. The control account is the current practice.
The control account is not an accounting term. It is a term that highlights that the control
account is an aggregate level where costs are reported back to the organization. It is also
where performance is reported back to the organization.
While we are here—one note. How do you build these? How do you know what goes
where? Most project managers find good examples and re-work them. If you build them
from the ground up, you can do it by breaking the work down from the top OR by identifying
all the work and looking for the natural groupings by function, deliverables and work areas.
But the key is that all the real work is done at the work package level. And all the reporting is
done at the control account level.

3 Project Charter
PROJECT CHARTER
....................................................
A project charter is a document that formally recognizes the existence of a new project. The
charter gives a general description of the project’s objectives, which are the quantifiable
criteria that indicate completion of the project. An individual with authority must sign the
project charter in order to grant the project manager the authority to spend money and use
the organization’s resources to accomplish project objectives and activities.
Usually the project manager, functional managers, senior managers, and clients all sign the
project charter. However, it is important to have all individuals who will be actively supporting
the project sign the project charter. The reason for this is that it indicates buy in from the
involved parties.
A project charter is not used to manage changes that occur during a project. If large-scale
project changes make the charter out of date, a new charter should be issues rather than
updating the old charter.
The project charter can contain any information that the organization feels is pertinent, but
at the minimum it should contain the following:
• A brief summary of the project scope
• The business or strategic goal that the project was undertaken to address
• A description of the product
• The name of the project manager
• The functional areas supporting the project
• A signature block for all internal stakeholders
• Resources necessary for project completion
• The expected project deliverables
SCHEDULING WITH THE WBS OR TASK LIST: PRECEDENCE

DIAGRAM
....................................................
Ultimately, the work packages or the tasks from the task list become the project schedule.
For this example, the work package level of the WBS has been rearranged for this type of

.....
Basics of Critical Path Analysis
diagram. This is a small part of a plan about conducting a survey. It is a simple example with
a little bit of float, or free time, for that one black square. Can you identify the total project
duration? It is 18 days. Are there any activities that you, as the project manager, are not too
worried about? Probably “Discuss market.” Why? It has 2 “free days” because of the way
the network is laid out.
As you can see, this is nothing more than a sequential relationship. If there are more paths?
The key is simply to add the total duration of each path until you find the biggest total. In this
case, the two paths have duration of 16 and 18 days. The longest of the two becomes the
duration for the project. It is no more complicated than that. In more complicated networks, it
becomes a function of simply adding up more paths—until you find the highest total.
Create Final Copy

Start Discuss M arket Draft Survey Conduct Testing Finish
of Survey
1 0d 2 1d 4 8d 5 4d 6 3d 7 0d
Determine Survey
Objectives
3 3d
BASICS OF CRITICAL PATH ANALYSIS

....................................................
• Early start
• Early finish
• Late start
• Late finish

3 Basics of Critical Path Analysis
Early Start Early Finish

(ES) (EF)
Late Start Late Finish

(LS) (LF)
Early Start
The early start (ES) of an activity is the least amount of time that must pass from a project
start date before that activity can begin. Finding ES involves making a forward pass through
a network diagram along the longest path toward the activity for which you are estimating
ES. Making a forward pass means starting at the beginning of the diagram and calculating
the duration of each activity preceding the activity for which you are estimating ES. The ES
of an activity is equal to the sum of all duration times for its predecessor activities.
Suppose Activity A is the first activity of a project, so it does not have predecessor activities.
Since Activity A must begin on Day One of the project, it has an ES of zero. Suppose
Activity C is the third activity of a project, so its predecessors are Activities A and B. If
Activity A has a two-day duration and Activity B has a one-day duration, then the ES for
Activity C is three days. Therefore, three days must pass after the project start date before
Activity C can begin.
Early Finish
The early finish (EF) of an activity is the least amount of time that must pass from the project
start date before an activity can finish. As with ES, finding EF involves making a forward
pass through a network diagram. The EF of an activity is equal to the sum of its EST and its
own duration:
EF = ES + activity duration.
Suppose Activity D's ES is four days into the project and that Activity D has a six-day
duration. Therefore, the EF for Activity D is 10 days. The earliest that Activity D can possibly
finish is 10 days from the first day of the project, resulting in the EF.

.....
Critical PatH Analysis
Late finish
The late finish (LF) of an activity is the greatest amount of time that can pass between the
project start date and the activity finish date without affecting the end date of the entire
project. LF is calculated by making a backward pass through the network. In other words,
LF calculation starts at the end of a project and works backward to the beginning of a
project. LF calculation assumes that constraints are already factored into the network
diagram.
Suppose that you calculated a 50-day EF for an entire project, which means that the project
must be completed by the end of Day 50. The final two project activities are Activities Y and
Z. The latest that Activity Z can finish without disrupting timely project completion is Day 50.
Since Activity Z cannot begin until Activity Y ends, if Activity Z takes exactly 10 days to
complete, then the LFT for Activity Y is no later than the end of Day 40.
Late Start
Latest start time (LS) is the latest time that an activity can start without affecting the end date
of the entire project. The latest start time of an activity is equal to the difference between its
latest finish time and its duration:
LS = LF - activity duration
Suppose that Activity Y has an eight-day duration and has an LF of 40 days before the end
of the project. The LS for Activity Y is 32 days. If Activity Y does not begin by Day 32, then
the project will not finish on time.
CRITICAL PATH ANALYSIS

....................................................
Lets bring all the pieces of the schedule together with an example using the chart below.
Let us start with the first activity. In the upper left-hand corner of the buy supplies activity,
you can put, or imagine, a zero. That is the earliest it can start...the very beginning of the
project. Time zero. It is a four-day activity. Zero plus four is—Four. That is the Early Finish.

3 Critical PatH Analysis
START
By Supplies Scrape Old Wall Paper
Clean up Mess
Duration = 4 days Duration = 7 days
FInish
Cut & Size Wall Paper Hang Wall Paper Clean Up Room
Duration = 5 days Duration 6 days Duration = 4 days
If you have trouble following that logic, imagine that each time is 8AM. Buy supplies begins
at 8AM on Day Zero and Finishes at 8AM on Day Four. So when can the next two activities
begin? Day Four. Scrape off old paper begins on Day Four and ends on Day Eleven. Cut
and size the wallpaper has an Early Start of Day Four and an Early Finish on Day Nine.
Dispose of old wallpaper mess has an Early Start of Day 11 and an Early Finish of Day 15.
Hang the Paper has two predecessors. So the question is “When is the earliest it can start?”
Both predecessors have to be done first. So the Early Start of that activity is Day 11. With its
six-day duration, it ends on Day 17. The clean-up activity must wait until both of its
predecessors are complete, so it will begin on Day 17. It finishes—on Day 21.
We now have the Early Start and Early Finish for each activity.
To get the numbers across the bottom, we work the same process in reverse. If the last task
is to end at 8AM on day 21—when is the latest it can start? Right—Day 17. Note they now
have the same thing for an Early Start and a Late Start. That means that last task is critical.
If the latest it can start and still get the project done on time is Day 17...what is the latest
time its two predecessors can finish? Day 17! They have to finish by Day 17 in order for the
project to get done on time. That means that the latest we can finish getting rid of the
wallpaper mess is Day 17...and the latest we can start it is Day 13...But look at the
EARLIEST we can start it. The latest we can start is Day 13. The earliest is Day 11. That
means there is some time to play with there. 2 days of difference. That is two days of free
time or float. This task is not critical. Along the bottom...hang paper has a Late Finish of 17
and an Early Finish of 11. It has no float. It is critical. One more task we need to look at to
make this complete is scrape off old paper. What is the latest it can finish? Here, it is Day 11.

.....
Effective Scheduling
It is driven by the lower of the two numbers. Because if it is any later than that, the project
will be delayed.
Going forward? We carry the high numbers. Backward...we carry the low ones.
EFFECTIVE SCHEDULING
....................................................
ID Task Name Duration Start

Dec
S S
1 Scope 3.5 days Thu 1/1/04
2 Determine project scope 4 hrs Thu 1/1/04
3 Secure project sponsorship 1 day Thu 1/1/04
4 Define preliminary resources 1 day Fri 1/2/04
5 Secure core resources 1 day Mon 1/5/0
6 Scope complete 0 days Tue 1/6/04
7 Analysis/Software Requirement 14 days Tue 1/6/04
8 Conduct needs analysis 5 days Tue 1/6/04
9 Draft preliminary software spe 3 days Tue 1/13/0
10 Develop preliminary budget 2 days Fri 1/16/04
This is an assignment on schedule display. Here is a Gantt chart. This is one of the most
common approaches to displaying a schedule. Most of us are very used to seeing this piece
of documentation. We are used to seeing it on our projects, and we use it in our reports. But
there are other options.
There is activity-on-arrow diagramming. It communicates information in an entirely different
fashion. Some people find these diagrams terribly confusing. Others, however, find them to
be a lesson in clarity. Activity-on-node diagramming is something that we are a little more
familiar with—the precedence diagrams you just worked with. It is the way that most project
management software displays the information. There are also others that we do not see
very often—some of the conditional diagramming approaches, such as GERT, the Graphical
Evaluation Review Technique. It allows for circular relationships among activities.

3 Schedule Acceleration:
SCHEDULE ACCELERATION:
....................................................
Taking action to decrease the total project duration after analyzing a number of alternatives to determine
how to get the maximum duration compression for the least cost (PMBOK® Guide)
1 window washer can clean a building in 1 week
10 window washers cab clean a building in 1 day
Once a schedule has been created, it might be necessary to reduce activity duration to
ensure that the project can be completed on time. Duration compression is the process by
which a project's completion time is reduced without altering the project scope. While the
project scope should not change, duration compression often affects quality and cost, and
leads to additional risk. There are several methods of duration compression that project
managers can consider during scheduling.
These methods are:
• Crashing
• Fast tracking
• Assigning limited overtime
• Implementing shortcuts
Crashing
Crashing accelerates activity completion by using more resources to complete activities on
the critical path. Crashing alters the duration of activities on the original critical path and can
lead to the creation of a new critical path. Since crashing uses more resources, it often
results in a higher cost for activity completion. Crash plans illustrate crash cost versus
original cost, as well as changes in activity duration. Project managers can use a crash plan
to determine whether crashing is compatible with the project's budget and goals.
It is important to understand that critical path activities are the only activities eligible for
crashing, since crashing other activities will not affect the project's completion date. Before
crashing a project, always make sure that it is a feasible option for schedule compression.
Fast tracking
Fast tracking rearranges activities based on precedence relationships so that those

.....
Scheduling Issues
activities are performed at the same time rather than in sequence. Performing activities
simultaneously reduces project duration.
It is important to understand that fast tracking involves a high level of risk. Therefore, a
project's major stakeholders must be aware of the risks before agreeing to fast tracking.
Because of the risk involved, fast tracking is used only when the other schedule
compression techniques are found to be inadequate.
Assigning limited overtime
Assigning limited overtime to project team members for certain activities can shorten overall
project duration. It is important to carefully consider which project team members to include
when assigning overtime. Too many hours of overtime can lead to burnout.
Implementing shortcuts
Shortcuts might include using a specialized computer program to design a construction
model, acquiring resources based on availability rather than specification, or reducing the
amount of time allotted for product testing. It is important to note that there is risk involved
when using shortcuts. You must be careful when implementing shortcuts, so they do not
have an adverse effect on the final project deliverable.
SCHEDULING ISSUES
....................................................
When you go to use virtually any display, there can be some pitfall as to how you are
presenting the information. Here are just a few of the items that you can run into.
The examples above are just a few things to watch for. With particularly long schedules, you
want to be aware of what we call “network spaghetti.” In the long relationships, with all those
dependencies that are woven into your project, it is very easy to lose the relationships or
forget critical relationships. For project managers who do not like network diagrams, the
Gantt chart is a godsend, but you do need the network. And beware the Gantt time-scale
network diagrams or dependency Gantts you sometimes see in the software. They can be
somewhat deceiving in that the relationships are hard to track. Milestone people sometimes
lean toward “inchstones,” which is putting a milestone at every small incremental step along
the way. And finally, there may be dysfunction among the network relationships that you
have established. Not all relationships are finish-to-start, but they are not all fancy with lead
and lag either. Ensure realism as you build relationships into your network diagrams.

3 Input to Cost Estimates
INPUT TO COST ESTIMATES

....................................................
• WBS
• Resource requirements
• Resource rates
• Duration estimates
• Estimating publications
• Historical information
• Chart of accounts
Building a cost estimate is a task that comes in a variety of types, shapes and sizes. The
trick is to know what information you need and where to get it. The information in the left-
hand column is from the PMBOK® and refers to what input is necessary to a good cost
estimate. The WBS—what is the work? Resource requirements: Whose do we need and
how many of them do we need? Resource rates: Who is more expensive? Duration
estimates: How long is this thing going to take? How long has it taken historically? What are
the customer’s time constraints? History? Ours, and that of other organizations published in
other sources.
As soon as you see the term “chart of accounts,” it can be unsettling, because it sounds like
high finance. Do not fear. PMI® defines a chart of accounts as any numbering system used
to monitor project costs by category (such as, labor, supplies, materials). The project chart
of accounts is usually based on the corporate chart of accounts of the primary performing
organization. Who do I report costs to and what is the format? In many organizations, such
information is not available to the project manager.
As these are the key inputs to cost estimates, they ultimately become the inputs to the next
level of process as well...cost management. Since the performance of the cost estimate is
going to be based on our performance in these specific areas, they become extremely
important to our success not just as project managers, but also as cost managers.

.....
Joining Schedule and Cost Estimates
JOINING SCHEDULE AND COST ESTIMATES

....................................................
One of the key aspects of cost management is not just how much we are spending, but
when we are spending it. If the schedule is well developed and the information is in hand
from day one, we can plot this type of chart at the beginning of the project.
Normally, however, there is a second line reflecting actual spending. Suppose you saw that
line, beginning in January at the left and spiking to 1.5 million dollars by March 1. Most
project managers would say that means we are terribly over budget. In fact, that is
information we do not have. The cost curve does not tell everything. It could mean we are
over budget. Or it could just as easily mean that we are just very early. If the project was
done by mid-March, it would be indicative of impressive early performance.
The cost curve here ultimately provides perspective on how we spent against the plan. The
key is to be able to use the information to generate sound information about whether we are
performing well or poorly.
2000000
1750000
1500000
1250000
1000000
750000
500000
250000
0
May
March
November
January
July
April
June
August
February
September
October
December
Months

3 Evaluating Status and Change
EVALUATING STATUS AND CHANGE

....................................................
BASELINE EVALUATION
• Subjective evaluation
Team/customer reporting
Performance appraisal
• Objective evaluation
Earned value
Forecasting
That which we do, we should do consistently. This applies particularly in cost management.
We want to have consistent evaluation practices so that we can compare performance with
past performance or compare one project with another. The challenge there is the
fundamental difference between subjective and objective evaluation. Subjective evaluation
is often more commonplace, although objective evaluation is deemed preferable. That is
because subjective analysis is based on individuals. Objective is tough, as there are few
objective measures, particularly when costs are not accounted for well according to the
projects.
Part of the challenge is human nature. Many team members tend to report work as 85%
complete (even though it will still take as long again to complete the effort). Customers often
report what they think will drive the project to a more expeditious conclusion. For us, the key
is to identify, at the earliest point possible, what management practices we will put in place
to ascertain whether we are doing well or poorly.
With objective evaluations, if the metrics are there, the reporting is easy. But if they are not
there, it can be a substantial level of effort. In larger-scale projects, over 50 to 65% of costs
may be administrative, and a big chunk of those administrative costs are associated with
evaluations.

.....
Life Cycle Costs
LIFE CYCLE COSTS

....................................................
One other type of evaluation is that of life cycle costs. Life-cycle costing includes
considerations of project decisions that will affect the cost of using the project product
throughout its life. There are two kinds - system life cycle costs and project life cycle costs.
Project costs are those that start at the beginning of the project and continue until the project
is turned over to the customer.
System life cycle costs take into account the entire life cycle of the system. For something
like a water plant, this includes the years and years of maintenance that go on after the plant
goes “on line”.
Why does this distinction matter? If our organizations evaluate project life-cycle costs, we
have direct influence and need to make sure that influence is felt in the decision-making
process. But our concerns and issues will be focused (for this example) on the two years of
the project.
If our organization evaluates system life cycle costs, we have direct influence during the first
two years, but the continued effects will be felt into the decade ahead...and any concerns we
have, as project manager should be focused on the longer term.
COST MANAGEMENT
....................................................
• Where is the data coming from?
• How is the data reported?
• Does it provide additional insight?
• Can it be misinterpreted?
• Does it tell the story you need to tell?
When it comes to the information you have been looking for, these are the big issues you
need to be looking at. Where is that data coming from? In many cases we get it from
sources that are somewhat less than reliable. Is it coming from a database? Is it being
tweaked by professionals in accounting or finance? Or is it simply being provided by team

3 Cost Management
members who really are not sure where the cost data is coming from? Or in some cases,
the team members provide the best possible cost data.
One big issue is, does the cost information that we have been gathering provide additional
insight? Does it really give us more information than we had before? Or can it more readily
be misinterpreted? That can create some serious problems throughout the organization.
How often are we getting it? Are we getting it monthly? Does it come with or without any
commentary? Is it data or, as somebody once explained to me, is it information (making the
distinction that data is simply a pile of numbers, whereas information is information we can
use)?
Does it tell the story that you really need to tell? Does it present the information the way it
needs to be presented? S-curves may be appropriate—variances, monthly, cumulative—
you need to be considering this information whenever you are analyzing or presenting cost
data.

P ROJECT I MPLEMENTATION
...................................
4
.....
STAFFING CONSIDERATIONS
....................................................
• Experience
• Interest
• Personal traits
• Availability
• Productivity
If you do not consider all parameters associated with project team, you will not know how
well the staff will function.
The project manager has to consider all of the performance attributes of the project team.
Some team members are brilliant, and there is little doubt about their performance. Others
leave us with less optimism, and force us into decisions based on limited parameters. In
some organizations, the emphasis is on who is available. In others—it is who will be most
productive. In still others, it is a function of who has done it before. Team formation often
reflects corporate strategy…and we may not even be aware of it.
On all of these issues, more is not inherently better. When it comes to experience, we may
want less experienced people if the project calls for a fresh perspective. As for personal
interest, we do not always want every team member who is excited about a project.
Someone needs to bring perspective along. Sometimes, it is just a matter of who is
available and who will fit in with the team.
All too often, project managers complain that they get no say in the matter. Even if you do
not, you need to have a sense of what your staff shortcomings may be if staff is assigned
from outside or above.

PROJECT IMPLEMENTATION
4 Establishing Responsibility
ESTABLISHING RESPONSIBILITY
....................................................
You need an overview of who is doing what or you will not know who to manage and who is
supporting you. This matrix provides that overview. It is a resource matrix. It is easy to
construct. List project activities down the side. List team members across the top. Identify
key functions for each person for each task.
Jayson
Robert
Janice
Janet
Milestone/Task
Buy Paint P R A
Prep Room A P R
Paint Trim A R P
Paint Walls P A R
P = Perform
A = Approve
R = Review
Look at this matrix:

• Robert is taking on a significant level of effort, and we hope he is an expert in the
field.
• Jayson is clearly in a supervisory role and should not be expected to do any of the
heavy lifting.
• Janice must have a keen eye for processes and a solid ability to do process
assessments.
• Janet should have an eye for integration.
You can probably do a similar type of analysis on your projects. And it provides a wealth of
information.

.....
Recruiting the Team
It is vital that someone have primary responsibility. If two folks have primary responsibility,
tasks will have either too many people in charge, or no one would take charge.
Responsibility matrixes can lead to chicken-egg discussions: they are sometimes built at a
high level for sake of bringing the team on board, but in their technical rendering, they are
built on detail level against the WBS. The key? Make sure the whole team concurs on who
is responsible for what.
RECRUITING THE TEAM

....................................................
• Negotiation
• Pre-assignment
• Procurement
It is one thing to identify the right team members. It is another to actually recruit them. The
question here is how do you get who you need? You know (based on the organization, the
project, the resources) who you want. How do you get them? Even the best plan will fail if
you can not win the resources.
We can acquire them through negotiation...which has its advantages. There is the give and
take, the opportunity to present perspectives, and the chance for collaborative win-win
solutions. Of course, if you are a lousy negotiator, you lose.
Some organizations thrive on preassigning resources. There is not much thinking required.
And the project manager can test him/herself with a team of management’s design.
Although not a healthy measure, the project manager may be able to blame someone else
for project failure. Of course, you may get a team you can not work with and can not stand.
If you buy the resources, you definitely have purse-string authority. You know who you are
getting. But, the team may have mercenary tendencies. They may lack loyalty.
Finally, you can beg, borrow, and steal. This is the default setting in some organizations. It is
realistic. You know what you are getting. But then again, you may not get what you need.
One of the keys is to know what resource acquisition strategies work in your organization.
What applies...and what works well.

4 Resource Allocation
RESOURCE ALLOCATION
....................................................
Does your resource allocation reflect the best interests of your —
• Organization?
• Resources?
• Project?
Before you read any further think the realities of your world in regards to resource allocation.
You cannot possibly make one person happy without upsetting some of the others.
Competing interests is the hallmark of quality resource allocation. It is one battling against
the other, trying to come to resolution on whose best interests must be served. It is up to you
to balance them.
This goes back to some of the issues we have already examined. We go back and we need
to look at our stakeholders. Look at all the various parties who are participating in the
project. What are their needs? Whose needs are going to take priority over other persons’
needs? Look at the various schedules that are involved and how we can tweak and modify
those schedules. And look at the costs and the cost tables. How are we going to deal with
cost issues when it comes to resource allocations? Is money more important, or are the
people? Is project schedule more important, or are people? Are the organization’s interests
more important, or are the team members’ interests? It becomes a critical issue in resource
allocation, and it is one that you need to work on and resolve. All those needs need to be
considered.
RESOURCE LEVELING
....................................................
The demand for resources can vary drastically throughout a project. Varying degrees of
demand can result in limited productivity and wasted resources. Resource leveling is the
process by which project managers adjust scheduled activities so that all resources are
distributed evenly.
It is important to note that resource leveling can affect activity duration, which ultimately
affects duration for the entire project. During resource leveling, resources might be taken

.....
Risk Issues
away from an activity in order to spread them more evenly across the project. With fewer
resources used for that activity, the activity might take longer to complete. The increase in
activity duration might then increase the total cost of project completion.
PROCESS OF LEVELING RESOURCES

1 Identify the resources required for the entire project. It is important to
remember that resources include people, as well as equipment and

materials.
2 Identify the activities for which resources are in peak demand. During this
step, you should determine which activities demand an unreasonable or
wasteful quantity of resources.
3 Determine the amount of float for each activity identified in Step 2, and
delay those activities based on their float times. The delays can help you
to distribute resources more evenly by spreading them consistently
across activities. The delays can also reduce the amount of wasted
resources by allowing you to make sure that each activity is given only as
many resources as it absolutely needs for completion.
4 If Step 3 is not possible for some activities, then reassess the activity
distribution among project team members. For example, look for
opportunities to assign one person to an activity originally assigned to two
people. If you make changes at this point, you need to reevaluate your
initial schedule.
RISK ISSUES
....................................................
• What risks exist?
• Who knows our risks?
• What may drive risk?
• What risks may drive our project?

4 Managing Risk
If you do not know the risks, you do not know the project. No matter how attractive a project
looks in revenue, the risks may become the show-stoppers.
Early in the project, we deal with risk at an extremely high level. What risks exist almost
universally in your projects? Customer commitment, timetable/schedule risks, previous
experiences, resource coordination (internal and external), time allowed for evaluation of
requirements, technology risks, product maturities risk, geographic distribution risk. All of
these may consistently be resident.
If we know there are always going to be certain types of risks, we should be documenting
the solutions to those risks early on.
MANAGING RISK
....................................................
Just finding the risks is not enough. The project manager has to do something about them.
This is a risk management course boiled down to a single page. It is also the approach
recommended in the 2000 edition of PMI®’s Guide to the Project Management Body of
Knowledge.
Risk planning is the development of infrastructure and support for risk management. It is
knowing how you will approach the risk management process.
Risk identification: What are the risks? For setting up a project website, for example, what
are the risks? Non-functional links. Difficult connections. Weak communications
infrastructure. Poor navigation. We need to identify the risks.
Qualitative risk analysis is setting risks into relative categories of high, medium and low to
allow for quick assessments of relative severity.
Quantitative analysis: We can quantify risks based on their potential value and the
probability of their occurrence.
For risk response planning, the PMBOK® Guide stresses that the four real responses are
avoidance (do not do it), mitigation (control it), deflection (give it away), and retention (face
it). These strategies give you options on how you can actually manage your risks.
And finally, the last step? Risk monitoring and control. Doing what needs to be done to
follow through and implement the risk plans.

.....
Risk in Scheduling - PERT
RISK IN SCHEDULING - PERT

....................................................
Optimistic + (4 X Most Likely) + Pessimistic
6
40 + (4 X 50) + 90
6
Just one example of the many tools at your disposal to deal with risk is the Program
Evaluation Review Technique. Or PERT. PERT is used to establish schedule duration when
our information is limited or when our resources can not come up with a fixed value for the
duration.
Suppose you had a 50-minute commute to work. But on a good day, you might get there in
40 minutes. On a bad day? It could take as long as 90. How could you account for the span
of duration possibilities without more information. PERT is designed to fill that void.
Specifically, it sets a value where a range exists. In this instance, the PERT value for our
commute is 40 plus 200 plus 90…or 330…divided by six…55. 55 minutes is our commuting
allowance, according to PERT.
Note that we are now saying our 50-minute commute is really a 55-minute commute. We are
doing so by virtue of the range of possibilities…saying, on average, it will really take us a full
55 minutes to make the drive in.
PERT is a vital tool. Before you move on, try calculating your commute to work or any drive
you make regularly. You may notice that PERT tends to extend duration. Why? Because
problems can ALWAYS get worse. But there is generally a limit as to how well we can
perform on schedule or cost.
RISK TOOLS
....................................................
Risk Management Planning
• Planning meetings

4 Risk Tools
Risk Identification
• Documentation reviews
• Information-gathering techniques
• Checklists
• Assumptions analysis
• Diagramming techniques
Qualitative Analysis
• Risk probability and impact
• Assumptions testing
• Data precision ranking
Quantitative Analysis
• Interviewing
• Sensitivity analysis
• Decision trees
• Simulation
Risk Response Planning
• Response strategies
Risk Monitoring and Control
• Response audits
• Reviews
• Performance Measurement
As with most aspects of project management, risk is rife with tools…there are planning tools
like meetings and risk identification tools like brainstorms. For qualification, we have tools
like internally set metrics for high, medium and low. Quantification tools like Monte Carlo
simulations afford the ability to look at the range of possibilities.
The key is to use the right tool in the right situation. With Monte Carlo, for example, the tool
uses iterative simulations to examine ranges of options and possibilities. If we have access
to the data and knowledge of how to use the simulations, Monte Carlo is wonderful.
Otherwise, its output becomes a work of fiction.

.....
Evaluation and Control
The point? Thinking about risk tools? It is the same as with most project management tools.
Get the right tool for the right situation.
EVALUATION AND CONTROL

....................................................
Evaluation
• Periodic
• Planned
• Formal
Control
• Incremental
• Situational
• Informal
As project managers, we are always concerned about the issues relating to evaluation and
control. Management frequently expresses concerns about evaluations. They want reports.
Formal reports. They want information. We, by contrast, as project managers, frequently
lean toward control mechanisms. We want to manage at the personal level. We want to
facilitate team members and their experiences.
That is the core difference between evaluation and control. Evaluations are planned events.
They are detailed. They are expensive to conduct. They take time and energy. Control steps
are small and incremental. They are the day-to-day of personnel management. We need to
allot time for both in the project day…but if you are ever wondering which takes more
time…it is definitely evaluation. Let’s look at a key evaluation tool.
EARNED VALUE
....................................................
What’s the dollar value of the work scheduled as of today? (planned value—PV)
What’s the actual amount spent? (actual cost—AC)

4 Earned Value
What did the organization plan to spend for the work performed as of today?
(earned value—EV)
Comparing planned cash flow with actual cash flow has it uses, but it does not tell you
whether the project will be over or under budget. To get the true picture of cost
performance, the planned and actual costs for all completed tasks need to be compared.
This is accomplished with a technique called earned value management. Earned value
management uses cost data to give more accurate cost and schedule reports. It does this
by combining cost and schedule status to provide a complete picture of the project. For
example, projects can be ahead of schedule (good), but over budget (bad). Alternatively,
they can be ahead of schedule (good) and under budget (good).
All EVM control account plans must continuously measure project performance by relating
three independent values: the planned value, the earned value, and the actual costs
incurred.
....................................................
Question Answer Acronym
How much should be done? Planned Value PV

How much work is done? This Earned Value EV
is the actual earned value of
the project, because it is the
value of the work that has
been completed.
How much work did the “is Actual Cost AC
done” work cost?
What was the total job Budget at Completion BAC
supposed to cost
What do we now expect the Estimate at completion EAC
total job to cost? This is a
reestimate of the total project
budget. it’s a way of saying
that if current cost
performance trends continue,
the final cost can be
predicted.
Planned value (PV) = portion of approved cost estimate planned to be spent on the activity
in a given period.

.....
Earned Value Fundamentals
Actual cost (AC) = total of costs incurred in accomplishing work on the activity during a given
period.
Earned value (EV) = value of work actually completed.
Interpretation of EV: "Task A, which I was supposed to complete today, is scheduled to cost
$1,000. I have completed only 85 percent of this task. Thus, I have completed $850 worth of
work, which is my earned value (EV)."
EARNED VALUE FUNDAMENTALS

....................................................
80
70
60
50
40
30
20
10
0
1st Qtr 2nd Qtr 3rd Qtr 4th Qtr Final
With those three key pieces of information, we can use earned value to evaluate change—
to see if anything has changed and to manage future change.
By the middle of the second quarter, it may have looked like we were seriously
underspending here. The actuals were well below what was scheduled to have been spent.
But the actuals were tracking very closely to the work that was done. Which is what we
would hope for…or expect. As those ultimately will determine how well we do.
Most of us are not rewarded for spending money on time. We are rewarded for spending
money on the work it was supposed to accomplish.

4 Earned Value Fundamentals
The three pieces here again are…the planned…the budgeted cost of work scheduled…the
actuals…what we spent…the actual cost of the work performed…and the earned
value…the budgeted cost for the work performed…what we planned to spend…for what we
did.
In this diagram, the fact that all three lines converge is considered a very healthy sign. It
means we are on time and we are spending according to plan, and according to the work.
The following calculations are used during earned value analysis:
• Schedule Variance (SV)
• Cost Variance (CV)
• Cost Performance Index (CPI)
• Schedule Performance Index (SPI)
COST VARIANCE (CV)

Recalculating the estimated cost at completion using earned value implies that current
trends will continue.
Nevertheless, be careful not to assume that just because you are over budget now, you will
be granted more money for your budget. Instead, the cost variance (CV) should be used as
a warning flag to help you identify problems early, when there is still time to get back on
track.
Cost variance (CV) = EV - AC
CV = BCWP - ACWP
Interpretation of CV: "I have done $850 worth of work (EV), but it actually cost me $900 to
do this (AC). It has cost me $50 more to do what I have done than I originally thought (CV)."
SCHEDULE VARIANCE (SV)

Is the project on schedule? This is a question that all stakeholders want answered.
However, it can be difficult to measure the degree to which a project is ahead or behind
schedule. What if the majority of tasks are on schedule, but a few are ahead of schedule
and others are behind? What is the accurate description of this project’s schedule status? In
this kind of situation, earned calculations can help measure schedule variances (SV) just as
they help measure cost variances (CV).

.....
Earned Value Fundamentals
Using the cost figures as the basis for schedule measurement is useful because it takes into
account the number and size of tasks that are behind schedule. That means if 10 concurrent
tasks, each worth $25,000, are all one week behind schedule, the scheduled variances will
be larger than if only one of those tasks is one week behind schedule.
Schedule variance (SV) = EV - PV
Interpretation of SV: "As of today, I was supposed to have done $1,000 worth of work on
Task A (PV). I have actually done $850 worth of work (EV). Thus, I am behind in my
schedule by $150 worth of work (SV)."
The formulas for cost variance (CV) and schedule variance (SV) will yield either a positive or
negative numeric value. If the value is positive, then the project is under budget and ahead
of schedule; if negative, then the project is over budget and behind schedule.
It is common to have a negative cost variance (i.e., to be over budget) but to have a positive
schedule variance. This means that although you have overspent at that point, you are
ahead of schedule. So the project is not necessarily in trouble. It may mean that you were
able to begin some tasks sooner than planned.
COST PERFORMANCE INDEX (CPI)

CPI is the relationship between actual costs expended and the value of the physical worked
performed.
CPI is widely used as a forecasting tool because it is very accurate. Once a project is
roughly 20%
complete, the total CPI for a project generally does not change by more than 10%.
Therefore, CPI gives the project team and stakeholders a quick and reliable estimate of final
project costs.
CPI = EV / AC or
CPI = BCWP / ACWP
Interpretation of CPI: "I have done $850 worth of work (EV). It has cost me $900 to do so
(AC). Each dollar I actually spent generated 94.4 cents worth of work (cost performance
factor)."

4 Project Progress
SCHEDULE PERFORMANCE INDEX (SPI)

SPI is the relationship between the value of the initial planned schedule and the value of the
physical work to be performed.
SPI = EV / PV or
SPI = BCWP / BCWS
Interpretation of SPI: "I have done $1,500 worth of work (EV). The value of work scheduled
is $1,000.
Each dollar of scheduled work generated $1.50 worth of work (schedule performance
factor).
To interpret CPI and SPI: if they are equal to 1, then the project is on budget and schedule;
if less than 1, then the project is over budget and behind schedule; if greater than 1, then the
project is under budget and ahead of schedule.
CPI and SPI provide the same information as CV and SV – whether the project is on budget
and schedule – but in a decimal format. For instance a CPI of .85 means that for every dollar
spent, you are 85 cents.
This is a much more meaningful measure and is very good for use in status reports.
PROJECT PROGRESS
....................................................
• Do your approaches to monitoring and control match the size of the project?
• Do they match the personnel?
• Do they deal with the organizational issues?
• Can you actually manage them?
I have to say, I have seen some pretty remarkable control processes. They range from the
sublime to the ridiculous. Some organizations create incredibly complex and ornate systems
to monitor, track, and evaluate projects. Others have no tracking mechanisms required
whatsoever. The trick is to ensure that yours matches the organizational, personnel, and
personal tolerances that exist in your project.

.....
Types of Organizations
That is no easy feat. You need to evaluate and assess what you can handle and what your
project mandates. If the organization demands far more evaluation than the project merits,
you may want to challenge it. If the organization does not require proper tracking, you still
should consider a tracking and control approach that matches your project needs. It is a
matter of balance.
TYPES OF ORGANIZATIONS
....................................................
The types of controls that are put in place are frequently driven by organizational demands.
The organizations depicted above are from the Guide to the Project Management Body of
Knowledge (PMBOK® Guide), and they represent the extremes in terms of where project
management functions
The one extreme is the classic functional organization... “Any organizational structure in
which staff are grouped hierarchically by specialty” (according to the PMBOK® Guide). It is
conventional line authority. Stovepipe management. Often territorial in nature, functional
managers may have “their own way” of doing business. Here, the project manager is
challenged, battling against the territories.
Chief
Executive
Functional Matrix
Functional Manager Functional Manager Functional Manager
Staff Staff Staff
Staff Staff Staff
Staff Staff Staff

4 Types of Organizations
Chief
Executive
Projectized
Project Manager Project Manager Project Manager
Staff Staff Staff
Staff Staff Staff
Staff Staff Staff
The opposite extreme is the projectized organization…The PMBOK® Guide refers to this as
“Any organizational structure in which the project manager has full authority to assign
priorities and to direct the work of individuals assigned to the project” Only a few
organizations adopt projectized cultures because of expense and loss of efficiency splitting
apart the conventional functional organizations.
Why show you the extremes? So you have a sense of where your world falls in-between.

.....
Types of Organizations
Chief
Executive
Strong Matrix
Manager of
Functional Manager Functional M anager Project Manager
Project
Staff Staff Manager
Project
Staff Staff Manager
Project
Staff Staff Manager
Chief
Executive
Weak Matrix
Staff Staff Staff
Staff Staff Staff
Staff Staff Staff
These are the more classic project environments. These are matrix environments.

4 Team Structure and Communication
The matrix is the most common project management organization. This is where most
modern project management organizations function. In fact, most are actually weak matrix
organizations. Very few organizations have been able to wrest financial tracking from the
functions and hand it over to the project managers.
The difference between weak and strong is who is responsible for financial tracking and is
perceived as generating revenue for the organization. In a weak matrix, the functional
organizations get credit for profit and loss. In the strong matrix, that responsibility rests with
the project managers.
The Project Management Institute® also recognizes the “balanced matrix” where the
authority is delicately poised between these two structures.
But for most of us. It is a weak matrix world, which means a lot of long-term cooperation with
the functional management of our organizations.
TEAM STRUCTURE AND COMMUNICATION

....................................................
Coordination is not easy, but there are components we can use as project managers to
facilitate our jobs. We need to know the team structure and make sure that the team knows
what we are doing and why it is going to work. We need the team to know that their needs
will be served and their needs will be met. As a project grows, that becomes more
challenging, but it is still part of our job. We need to share a common vision across the
organization. Success is everyone’s job, whether working in a functional environment or in
the matrix. That is perhaps the biggest challenge a lot of organizations face. (See Appendix
A, Tool 6)
MANAGING BORROWED RESOURCES

....................................................
• Are they valued?
• Do the various components of management know the value?
• Is the matrix clearly understood and articulated?

.....
Team Structure Alternatives
In many cases, we do not realize what it is going to take to get people moving in the project
environment. In the matrix environment, some people just are not motivated. We need to be
aware of the keys to managing borrowed resources. Are we looking at the employees as
valued employees? Do the employees really know what their role is and know what they are
contributing to the project? Does management know that the employees are contributing as
well? In many cases, employees and resources find themselves in a situation where they
really do not see the value of what they are doing. You need to be communicating that value
to your team members.
Are the various bosses that are involved in the matrix environment communicating with
each other? Do they all know what they are contributing and what the other parties are
contributing? Do the employees have their priorities—from you and from their functional
managers as well? All this information needs to be integrated to properly manage borrowed
resources.
TEAM STRUCTURE ALTERNATIVES

....................................................
It is not just the organization that influences the team. YOU structure teams as well. And the
team structure you choose can help determine success or failure. If you always use one

4 Team Structure Alternatives
type, you might consider another to get the job done more effectively. Each has its
advantages.
Type of Structure Strengths Weaknesses
Isomorphic Role definition Integration
Scheduling
Specialty Task efficiency Coordination

Quality
Egoless Integration Accountability

Quality
Surgical Integration Dependency on the expert
Task efficiency
Structuring the team establishes the framework in which the team will ultimately operate.
Each team structure has different implications. In Isomorphic, the team takes on the same
shape as the project, with individuals or subteams responsible for specific activities. It is
good for individuals who can do their jobs but are lousy at synergy.
On specialty teams, the individuals and subteams share responsibility for activities, based
on their capabilities. Higher synergy is generated. It is good for a team that works well
together with balanced skills.
Dave Frame’s book “Managing Projects in Organizations” goes into more depth on each of
these teams. The key is that you match the team to the need. The egoless team is
assembled for the greater glory of the effort’s objective; no specific leader; working with no
regard for the individual.
Surgical teams need one highly skilled person (“surgeon”) leading the effort to do specific
tasks with support staff. Surgeons often get most of the credit, the project manager serves
as the facilitator. Is it good if you need staff development and you have a single brilliant team
member.
There are some de facto teams that form on their own and have no formal roles assigned.
Individuals take on specific roles and responsibilities based on their activities and perform
well together as a team. Individual development is often not emphasized.

.....
Team Member Roles
In all cases, the key is to pick the team structure that complements the skill sets of the
people involved.
TEAM MEMBER ROLES

....................................................
You do not exactly “structure” individual team members, but it is essential to know who is
doing what and performing what roles (and that multiple roles may be embodied in single
individuals).
These are three potential team member roles within a project. You probably see yourself in
at least one of these.
Subject matter experts (SMEs) are often also the technicians but always have the greatest
insight and ability to understand how the work should be done.
The technicians are those who actually implement the work.
The coordinators? Those who work to ensure processes are followed effectively.
As the project manager, you need to juggle team members in these roles and more. And as
for which role is most important? They all are. A failing on the part of any one may lead to
significant project failure. Each has different input into the project process. It is important for
the project manager to identify team members’ roles and determine if it is an appropriate fit.
Invariably, you will build teams with strengths in some areas…shortcomings in others...but
we need to know what the team members are capable of in order to know how well we will
support the project.
COMMUNICATION TOOLS
....................................................
• Meetings
• E-mail
• One-on-one
• Phone calls

4 The Project Manager's Authority
• Fascimiles
• Memorandums
• Letters
• Typed
• Handwritten
• Video conferences
• Telephone conferences
This is a rather substantial list of communications tools. As with tools in any toolkit, some
are appropriate at different times than others. And your choice of which to use may largely
depend on how many team members you have.
If you have only yourself and one other team member, you have only one channel for
communication. One-on-one will probably suffice. Four team members? There are SIX
communications channels to be maintained. 10 team members? 45 communications
channels. Time to start looking at conferences and e-mail.
And the reason that is important is that it takes that bit of knowledge to know which of these
tools is going to be appropriate for your project. As Marshall McLuhan was quick to point
out, the medium is the message.
THE PROJECT MANAGER'S AUTHORITY

....................................................
• Formal
Real
Referent
• Purse-string
• Expert
• Charismatic

.....
The Project Manager's Authority
• Bureaucratic
• Coercive
• Reward
The most common complaint of project managers is that they have enormous responsibility
with no authority. There are myriad types of authority out there...and project managers need
not rely on formal authority.
Chief
Executive
Functional Matrix
Staff Staff Staff
Staff Staff Staff
Staff Staff Staff
Some of these authority types are from the basic leadership books, while others are from
the Guide to the Project Management Body of Knowledge. What all three resources
emphasize is that there are a lot of types of authority we can draw on.
Yes, there is real, formal authority…like the CEO has.
And there is referent, as well...which is authority handed down by reference from someone
with real formal authority. Authority by virtue of a relationship with someone in the
organization with power.
We have authority over vendors when we control the purse strings or money.
There is expert authority... Technical authority derived from understanding a particular
subject matter, like an expert in Microsoft Project®. But when the paradigm on expert
authority changes, the level of authority changes significantly.

4 Deploying Authority
Charismatic authority is another key. It is derived from the ability to obtain influence via
personality (for example, to motivate and inspire others to take action).
Ever known someone who knew your organization better than you do? They have
Bureaucratic authority. Knowing the system.
Some managers derive coercive authority through threats...while others derive reward
authority by providing opportunities for others.
With all these different types of authority at the project manager’s disposal, the options...and
opportunities...are legion.
DEPLOYING AUTHORITY
....................................................
• Leading
• Communicating
• Negotiating
• Problem solving
• Influencing
It is not just a function of having authority...it is a function of using it. PMI ascribes to these
key leadership traits, that some folks have re-ordered into the acronym of
“PLINC”...Problem-solving, Leading, Influencing, Negotiating and Communicating.
To succeed in USING authority, the idea is to maximize the use of those skills you do best.
If you identified that you have purse-string authority in the last lecture, then this is where you
decide how to use it. You can use it to lead through incentives. You can use it to
communicate the relative importance of a message by attaching monetary value to it.
Having potential authority is not enough. That authority must be deployed.
These are core competencies of project management, and there will be some that you use
to deploy authority better than others. One idea or ideal is to ensure that you know what
your strengths are and find allies to help work through your weaknesses.

.....
Building Authority and Influence
The point here is to know that our team members will not naturally recognize authority. They
will recognize it when it is deployed well, and these are the different means by which we
highlight and illustrate our authority.
BUILDING AUTHORITY AND INFLUENCE

....................................................
• Build authority that you can sustain
• Build authority that works in your organization
• Remember that influence is art, not science
In any management role, it is important to select styles and approaches that are appropriate
to you. I am sure a lot of you can empathize with an experience I had working in an
unfamiliar environment. I was told that the team members I was working with were
“different” from other people I had worked with in the past. These team members were going
to be a special group and required a different style of management than that to which I had
become accustomed. I worked very hard to learn their environment, to learn their
conditions, and I changed my management approach altogether. I failed miserably.
You can only build authority with skills that you have. Do not try to rely on different tactics,
styles, and approaches with every group. Work within the context of your personal strengths
and your personal weaknesses. While you play to your strengths, you need to recognize the
organizational ties you maintain. The organization needs you to work within the context of
their approaches to management and their leadership protocols. You need to work within
the environment. And remember: it is an art, not a science. There are no specific formulas
that are going to make this easy for you. Work with what you know.
WHO AND WHAT DEFINE SUCCESS?

....................................................
If you do not establish what success is, you cannot achieve it.
We build the perfect team, we have authority…we are working from a great plan….Still there
are challenges. And a project is not successful until there is some concurrence on success.

4 Personal Closeout
Team members will not have a sense of accomplishment if they do not know what they are
supposed to accomplish.
Different parts of the organization have different expectations. What does the organization
want? Perhaps financial gain, customer satisfaction, management satisfaction, public
relations.
What does the customer want? Increased capabilities, clearer organization, end-user
delight, regulatory conformance. Customers also look to their ability to use the product or
service for their success.
What does your team want? New skills acquired, new capabilities, image enhancement, and
a host of personal successes as well.
In some instances, there is the perception that one person’s success is another person’s
failure. If that is the case, then we have an obligation to identify whose success is whose,
and how we will resolve that issue.
The classic story is one of the project manager who had completed a successful effort, with
customer and organizational satisfaction and buy-in, but continued to hammer on the
success with the customer so long and with such vigor that the customer eventually tired of
the project manager’s presence. Out of the hand of victory, the project manager was able to
snatch a defeat!
The sooner we define the parameters of success for all concerned, the sooner we can
achieve it.
PERSONAL CLOSEOUT
....................................................
• Conduct public relations
• Look to the future
• Document success
• Track team members
• Facilitate team member transitions

.....
Personal Closeout
SELF-
ACTUALIZATION
Pursue Inner Talent,
Creativity, Fulfillment
SELF-ESTEEM
Achievement, Mastery.
Recognition, Respect
BELONGING - LOVE
Friends, Family, Spouse, Lover
SAFETY
Security, Stability, Freedom from Fear
PHYSIOLOGICAL
Food, Water, Shelter, Warmth
Maslow's Hierarchy of Needs
Success is often a personal experience. What do team members want out of a project?
What rewards do they seek?
Maslow, the creator of the famed “hierarchy of needs” posited that different people are at
different stages on the hierarchy.
Some simply need to feel safe, while others already feel safe and have their social needs
addressed and are looking more at self-esteem. This concept, which is tested on the PMP®
exam, goes to the idea that people have different needs based on what needs have already
been addressed. In the ideal, we are setting up an environment where team members can
self-actualize...where they can achieve well.
Herzberg argued that if you want people to feel successful you have to motivate them. And
he felt motivation was closely tied to opportunity. Give people the opportunities (like those in
Maslow’s hierarchy) and they will be motivated. Toward the end of the project, this is doubly

4 Implementing Effective Reward Systems
challenging. The key, according to Herzberg, was not to shower them with money or
trinkets, but to give them chances to be more than they are.
Why discuss this now? At the end of the project, we declare successes. Or are declared as
failures. It is often up to us to make the distinction.
Successes need to be documented for both our interests and our organizations’. Without
documentation, insight is lost.
And public relations—PR—is important as well. We can do it for both the project and the
team. They need recognition and credit, too. Public relations does not necessarily mean
sending out press releases. It may simply be talking positively about your project in the
organization. Those who are obsessed with communicating negatives about their project
will find that others pick up on the negative tone. As the project managers, we set the tone.
IMPLEMENTING EFFECTIVE REWARD SYSTEMS

....................................................
When it comes to reward and punishment, remember Herzberg’s theory of motivation and
the importance of Maslow’s hierarchy of needs, as discussed previously. Without
considering those aspects, there is the potential to do significant damage to a business
relationship. Remember that rewards need to come in the form of opportunities to move up
in Maslow’s hierarchy. If the rewards you considered accomplish that goal, you have
accomplished a great deal. As for punitive measures, make sure that if you decide to deploy
them, the employee is aware of what they are and why they are being used. Nothing is more
useless than intentional demotivation that is not accompanied by a clear explanation of why
it is being done.

P ROJECT C LOSE - OUT
...................................
5
.....
ADMINISTRATIVE CLOSEOUT
....................................................
Input
• Performance measurement documentation
• Documentation of project products
Tools
• Performance reporting tools and techniques
• Project reports
• Project presentations
Output
• Project archives
• Project closure
• Lessons learned
The project is not over until the paperwork is complete. And in most projects, by the time we
hit administrative closure; team members are running for the door. We cannot afford to let
that happen. Customers have expectations right through administrative closure, and
improperly done, we run the risk of customer dissatisfaction.
Closure is supposed to be structured. In many projects, it is when people simply abandon
the project. To keep that from happening, we need to ensure that others know the value.
That they understand how the data will be used and why it is important. They also need to
know the data has value. On the outputs, the tragedy is that they are often stored on a shelf
and forgotten. Never dragged out again until it is time to throw them away. The more we can
do to build lessons learned into our systems, through the project management software,
through the processes and templates the more we do to ensure that we build our
organizational memory.

PROJECT CLOSE-OUT
5 Contract Closeout
CONTRACT CLOSEOUT
....................................................
• Documentation
• Contract
• Supporting schedules
• Approved changes
• Technical documentation
• Financial documentation
• Procurement audits
• Contract file
Administrative documentation is the paperwork. Contract documentation is what ensures we

get paid. There is sometimes a temptation to simply push for customer signatures without a
thorough, last-look, review of the contract. That has its perils. If the contract has not been
closed out, the project cannot legally be closed out. Legal issues may linger.
The list of contract documentation here is substantial. (See Appendix A, Tool 5 for sample of
a document that may be used as the FInal Document Report) It is weighty. And it is the
project manager’s responsibility. Some organizations have procurement staff to support in
this effort, but for the most part, this belongs to the project manager.
The concept of a procurement audit (internal, external, or by the government) is one that is
foreign to most project managers, until it occurs. The focus is on paperwork; the project is
secondary. The focus is on whether all paperwork is complete and was submitted properly.
Ensuring this happens well is no mean feat. And when it is done?
We keep the paperwork. The contract file, despite its potential size, must be stored for
reasonable time. The key to success here? Maintain an easily accessed, comprehensive list
of document locations.
A technology customer wanted the installation instructions for a new system. The
instructions could not be found. The customer was on the verge of canceling the contract
when the PM realized that the installation instructions had been moved from Chapter 1 in
the manual to the Appendix. Better document filing could have avoided some uncomfortable
moments in the client relationship.

.....
PROJECT CLOSE-OUT
Scope Verification
SCOPE VERIFICATION
....................................................
• Did the project meet the stated scope?
• Is there sufficient documentation to prove it?
At the beginning of the book, we talked about setting objectives…clarifying the work to be
done. At the end, it is just as important. Even if everyone seems happy, it is important to
verify that all the work is done—just in case.
In both project and customer organizations, there are changes. Management changes,
project management changes, approach and vision changes. All of these may change the
potential influence of a given project for the better or worse.
Scope verification is the only documentation that is going to count in terms of proving
customer satisfaction. Without this kind of thorough reassurance that the deliverable met the
scope, the project cannot be considered complete.
In some cases, a customer may express satisfaction with the deliverables, only to change
his/her perspective at a later date. Or a different customer may replace the PM’s contact on
the project and have a different set of values. That customer may go back to ensure that the
deliverables were provided as promised. Without a clear verification that the scope of the
project was met, there cannot be proper closure.
ORGANIZATIONAL
....................................................
At the end, as at the beginning, the question needs to be asked—does this project make
sense in our organization. Does it change our capabilities and/or competencies.
Even the best projects are bad if they are not in line with what the organization should be
doing.
Some organizations refer to the organizational ‘fit’ as “portfolio management.” Some
organizations work on nothing BUT portfolio management. The key is to know what the
portfolio really is. And to ask the question as to whether or not the portfolio is influenced in
any way by the latest accomplishments (or failures).

PROJECT CLOSE-OUT
5 Project Management in the Business Environment
Working within an organization’s capabilities does not mean that organizations should
refrain from expanding their strategic perspective. It does mean, however, that they need to
pursue directions that are within the framework of their existing capabilities.
• Can we serve this customer base?
• Will we get anything from this?
• Can we do it?
The answers to these questions sometimes change after a successful or unsuccessful

project. At the end of the project, we need to do a final review of the effort’s organizational
context.
PROJECT MANAGEMENT IN THE BUSINESS ENVIRONMENT

....................................................
• Apply project management to projects
• Apply project management consistently
• Apply project management progressively
• Apply best practice
This goes back to the very first lesson you learned in this book. What is a project? We need
to make sure that when we apply project management, we are applying it appropriately—we
are applying it to real projects. You are going to achieve your best success that way when
you apply it to projects rather than applying project management to every effort that comes
through the door. The greater the consistency of application, the greater the opportunities
for success, because you become repeatable—you are able to do the same things over and
over again and able to achieve success consistently. And if you are following practices that
everybody can recognize as best practice, there is a better chance you will be able to
replicate success.
The last two bullets really do work together: applying project management progressively and
applying best practice. That means watching what other people are doing and learning from
them. Keep your eye on the trade journals for some of the latest activities that are going on
in project management. It is a very progressive practice. New practices are being applied
every single day. It is a good idea to keep your eyes wide open!

.....
PROJECT CLOSE-OUT
Lessons Learned
LESSONS LEARNED
....................................................
When creating lessons learned make sure that they are -
• Timely
• Relevant
• In context
• Detailed
Lessons learned. Lessons learned are the organizational memory. (See Appendix A, Tool
9).
In this book, you have gradually, through the readings, built up a database of more than a
dozen “lessons learned.” The key now is to find a way to actually implement them. The key
is to explore and find ways to put them to work.
That is the essence of a good lesson learned. It captures more information. It provides
specific guidance. It is reviewed and followed up on. It is applicable and applied. And like the
data you’ve generated here, it is not all bad news. Much of it is good news. Tricks you can
apply...new ways of doing business. That is where the victories are achieved.

PROJECT CLOSE-OUT
5 Lessons Learned

A PPENDIX
...................................
A
.....
Appendix A - Project Management Tools
Tool 1 - Project Plan Outline ................................................................ 75
Tool 2 - Stakeholder Analysis .............................................................. 77
Tool 3 - Project Requirements Document ............................................ 79
Tool 4 - Basic Requirements Checklist ................................................ 81
Tool 5 - Change Request Form............................................................ 85
Tool 6 - Communication Plan ............................................................... 87
Tool 7 - Closeout Procedures .............................................................. 89
Tool 8 - Final Project Report ................................................................ 93
Tool 9 - Lessons Learned .................................................................... 95
A Project Managers Guide to Managing Successful Projects A-75

APPENDIX
A
A-76 A Project Managers Guide to Managing Successful Projects

TOOL 1
Project Plan Outline
Project Name Project Ref. No. Prepared By (print) Preparer’s Initials
Customer Contact Contact’s Phone Date Prepared
Management Summary
Executive summary
Project charter
PM designation letter
Proposed solution
Milestones
Acceptance criteria
Contract conditions
Budget/finance agreements
Customer role
Project objective
Project scope
Deliverables
Overall description
Components
Services
Third-party deliverables
Project Requirements
Statement of work
WBS
Resources
Internal organization
Customer organization
Third-party organization
Project team
Roles and responsibilities
Risk Plan
Assessment
Mitigation strategies
Schedule
Customer schedule
Project plan schedule
Milestones
Reporting
Internal
External
Regulations and Standards
Evaluations
Status reporting
Customer reporting
Supporting Plans
Implementation
Documentation
Hardware
Software
Service
Finance
Integration
Customer training
Internal training
Quality assurance
Subcontracting
Risk management
Testing
Acceptance
Safety
Transition
Life cycle management
Configuration management
Support Documentation
TOOL 2
Stakeholder Analysis
Stakeholder Name + 0 - Reason for Position Strengths & Strategy

Weaknesses
TOOL 3
Project Requirements Document
BACKGROUND/SUMMARY OF PROJECT
COMMENTS
PROJECT OBJECTIVES
COMMENTS
PROJECT PHASES/DELIVERABLES
COMMENTS
KEY MILESTONES
COMMENTS
ASSUMPTIONS
COMMENTS
RISKS
COMMENTS
KEY RESOURCE REQUIREMENTS

COMMENTS
CONSTRAINTS
COMMENTS
INTERRELATED PROJECTS
COMMENTS
ACCEPTANCE CRITERIA
COMMENTS
SIGNATURES
COMMENTS
REVIEWS
COMMENTS
COMMUNICATION PLAN
COMMENTS
CHANGE MANAGEMENT PLAN

COMMENTS
FINANCIAL ANALYSIS
COMMENTS
TOOL 4
Basic Requirements Checklist
q Authority
• Who’s in charge here (who’s the PM)?
• Who is in charge of the project manager?
q Market
• What’s the anticipated price?
• What consumer market is targeted?
• What are the customer benefits?
• Who is the competition?
• What competitive advantage does it present?
• How does it differ from other similar products?
• What research has been done on the product and its customer base?
• Are there existing market surveys?
• What is the intended market?
• What are the advertising plans?
• What is the market entry strategy?
• Could it be used in other market segments?
• What is the appropriate sales channel? Distribution methodology?
• Are there discount plans?
• Have you conducted a trademark search?
• Is this the only product of its kind?
• Why hasn’t the product been introduced before?
• Why are you interested in the market you’ve selected?
• Why did you select this product?
• What will people love? Talk about?
• What do you want people to experience in using this?
• What is the perceived benefit of this product?
• What is the value added for the consumer?
• What’s motivating you in this market?
• What’s the next step in the market strategy?
• Are there market alliances or partnerships?
• Is there legal liability? To what degree?
• Do we share liability with any partners?
• Have you conducted a patent search?
• What’s the planning schedule?
Tool 4 Basic Requirements Checklist
• What’s the development schedule?
• What’s the volume for the initial rollout?
• What is the rollout schedule?
• What’s the anticipated production life?
• What production facilities are available?
• What is the organization’s conventional product or service life cycle?
• How much of our manufacturing capacity will this consume?
• Where will it be manufactured?
• What internal resources are available?
• Are there supporting vendors and subcontractors?
• Is engineering staff available for modifications?
q Budget
• What’s the budget?
• What’s the cost to build?
• What’s the anticipated price to the consumer?
• What’s the volume?
q Capability
• What does it do?
• How does it work?
• Does it use any breakthrough technologies?
• How is it used?
• How can it be misused?
• Are there any uses that might be dangerous to children? Adults? Pets?
• Is it safe? (For everyone? Heart patients?)
• How easy should it be to use?
• Is the product oriented primarily or exclusively for right- or left-handed people?
• Does it have varying levels of capability based on the usage environment?
• Are there specific products that can or cannot be used with it?
• How does it function?
• Has it been tested? Will it be? How?
• Is there a prototype?
• How will it be built?
• Are there specific environmental requirements?
• Can the product be recycled?
• Is it single-location-oriented, or is it portable?
• Are there supplemental products to support it?
• Are there peripherals?
• Can it be used in conjunction with other products developed by us?
• Can it be used in conjunction with other products developed by other firms?
• Are upgrades available?
• Will it be compatible with the upgrades?
• Will there be more than one model? What other models are there?
• Are repair parts available?
• Can it be repaired by the “average” user?
• What repair cycle will be used to implement repairs?
• What are the storage requirements?
q Appearance, Capacity, and Functionality
• What does it look like? (Draw it for me!)
• What color?
• What size? What dimensions?
• What weight?
• Does it have adjustable capabilities? (Speed? Physical action?)
• Will all the products be identical?
• What’s it made of?
• How is it constructed?
• What are the key components?
• How will those components operate and interact?
• Can we use those components in other products or services?
• Do we already produce any of those components?
• Can this product serve as an upgrade for existing products?
• How will they integrate?
• Will the components be readily available?
• What are their dimensions?
• What are their construction materials?
• What are its mandatory performance capabilities?
• Is it powered?
• By what source?
• Are there alternative sources?
• Does it have a limited life span? What is it?
q Regulation
• Does it meet regulatory requirements?
• Does it meet industry requirements?
• Does it meet UL requirements? (Should it?)
• What’s the life span on the power source?
• What customer criteria must the power source meet?
• Are there limitations on the decibels the unit can produce?
• Are there limitations on the vibration levels of the unit?
• Will the power capabilities be within manageable levels for the “average” user?
q Support
• Is there computer support?
• Is any programming required either before production or by the user?
q Training
• Will auxiliary training be required?
• How much training is required?
q Documentation
• Is supporting documentation required?
• What types of documentation?
• Are formats required for that documentation?
• Will the documentation be developed in any languages besides English?
q Storage and Retrieval
• What are the storage requirements?
• How will the product be packaged?
• Are there additional products you want sharing the limelight with this one?
• If so, how will they help you achieve your vision?
• How will delivery be accomplished?
q Maintenance
• How will this product/system/service be maintained?
• What warranties will it carry?
• What service networks are required?
• What off-the-shelf support is available? Will be available?
• Are there disposal issues?
• How will it be recycled?
TOOL 5
Change Request Form
PROJECT BACKGROUND INFORMATION

PROJECT MANAGER CHANGE REQUEST NO. DATE REQUESTED
ORIGINATOR DEPARTMENT/COMPANY
TELEPHONE FAX E- MAIL
PROPOSED CHANGE
BASELINE DESCRIPTION
CHANGE DESCRIPTION
RATIONALE
MODIFIED ACTIVITIES
WBS NO. ACTIVITY NAME/TITLE
OTHER REFERENCES
Tool 5 Change Request Form
APPROVALS
NAME (PRINT) SIGNATURE DATE
IMPACT REVIEW
MEETING DATE
TECHNICAL IMPACT
BUDGET IMPACT
SCHEDULE IMPACT
PERFORMANCE IMPACT
CONTRACT IMPACT
CHANGE CONTROL BOARD (CCB) ACTION

SIGNATURE, CCB CHAIRPERSON
Approve and forward for customer concurrence
Deny
CUSTOMER DECISION
COMMENTS (IF APPROPRIATE)
Approved
Tabled
Disapproved
CUSTOMER SIGNATURE
NAME (PRINT) SIGNATURE DATE

TOOL 6
Communication Plan
DOCUMENTS (FILE NAME OR CODE) SENT

PRIMARY INTERNAL STAKEHOLDERS TO PRIMARY INTERNAL LIST DATE

PRIMARY EXTERNAL STAKEHOLDERS TO PRIMARY EXTERNAL LIST DATE

SECONDARY STAKEHOLDERS TO SECONDARY LIST DATE
COMMUNICATION CODES STORAGE CODES

E-Mail E-(Date)-(Storage) Computer File C
V-Mail V-(Date)-(Storage) Central Office File F
Postal P-(Date)-(Storage) PM Office File M
Verbal O-(Date)-(Storage) Deleted/Destroyed D
EXAMPLE
E091498D E-mail sent September 14, File description cross-referenced in document control
1998, was deleted
V012399C Voice mail sent January 23, File description cross-referenced in document control
1999, was stored in a computer
reference
DOCUMENT CONTROL
Code Description Source Name
TOOL 7
Closeout Procedures
REVIEW DELIVERABLE REQUIREMENTS AND PROCEDURES

TOOLS AND
DESCRIPTION GOAL PARTICIPANTS TIMING DOCUMENTATION
Review— Customer Project manager All customer Contract
• Contract deliverable requirements understanding of Customer project meetings Customer sign-off
• Deliverable acceptance requirements procedures and manager procedures
acceptance Acceptance plan
• Process for gaining customer
acceptance Sign-off checklist
• Customer’s direct level of involvement in
acceptance process
• Sign-off procedure
Incorporate additional customer provisions
as appropriate.
ORGANIZE DELIVERY, INSTALLATION, AND TESTING REQUIREMENTS

TOOLS AND
Verify that the acceptance plan addresses Matrix of Project manager Must be Contract
contract requirements for— deliverables completed Acceptance plan
• Delivery before
• Installation customer
implementa-
• Testing
tion
Determine the order in which deliverables will
be provided.
TEST (AS APPROPRIATE)

TOOLS AND
Conduct test Customer Project manager As deliver- Acceptance plan
• Ensure that test evaluates deliverable signature Customer project ables are Contract
according to contract criteria accepting each manager completed
• Review results deliverable
• Correct deficiencies
Retest if necessary and document results Project manager Test report
• Describe tests performed Project team
• Present results
• Explain unusual results or occurrences
Obtain sign-off if applicable Project manager Customer sign-off
Customer project procedures
manager
POSTTEST
TOOLS AND
Provide test results Invoice to Project manager Upon Acceptance plan
• Forward acceptance plan review to customer completion of Customer
customer; include test results, request each test acceptance checklist
for review and approval, and copy of
customer acceptance checklist
• Specify date by which customer must
act to keep project on schedule
• Ship or install deliverables; customer
must sign customer acceptance
checklist to verify satisfactory receipt
Forward invoice request and customer Project manager Invoice initiation
acceptance checklist to customer request
Customer sign-off
procedures
Customer Acceptance Checklist
DELIVERABLE REF. PARA. PAGE COMMENTS DATE INITIALS

TOOL 8
Final Project Report
1.0 EXECUTIVE SUMMARY

1.1 Scope Statement. Current update
1.2 Customer Satisfaction Review. Review results of customer satisfaction assessments,
including deliverable and process reviews.
1.3 Project Review. Analyze project results at a high level.
1.4 Transition Review and Closeout. Provide detail on the transition process for future services
as well as an overview of closeout procedures followed.
2.0 SPECIFICATIONS
Include updated technical plans. Reference any long-form diagrams or support documentation in
Appendix A.
3.0 SCHEDULE
Assess major areas of delay and acceleration. Reference Gantt charts and network diagrams in
Appendix B, showing baseline performance versus actual performance.
4.0 FINANCIAL ISSUES

Incorporate current customer payment schedule. Report any outstanding payments (or outstanding
billing). Reference project invoice and billing reconciliation in Appendix C.
5.0 CLOSEOUT
Insert copies of administrative and contract closeout plans.
APPENDIXES
A: Specifications: Insert specification diagrams or support documentation.
B: Gantt Charts and Network Diagrams: Insert final schedule results from the project
management software tool in Gantt and/or network diagram formats.
C: Financial Issues: Insert final project invoice and billing reconciliation.
TOOL 9
Lessons Learned Documentation
SUMMARY
PROJECT BACKGROUND
LEARNING HIGHLIGHTS
RECOMMENDATIONS SUMMARY
TECHNICAL REVIEW
PROJECT EXPERIENCE
RECOMMENDED PROCESS IMPROVEMENTS
PROPOSED TOOL MODIFICATIONS OR IMPROVEMENTS

ADMINISTRATIVE REVIEW
PROJECT EXPERIENCE
CONTRACT MANAGEMENT REVIEW

PROJECT EXPERIENCE

RISK MANAGEMENT REVIEW
PROJECT EXPERIENCE
FINANCIAL MANAGEMENT REVIEW

PROJECT EXPERIENCE

CUSTOMER RELATIONSHIP MANAGEMENT
PROJECT EXPERIENCE
TEAM RELATIONSHIP MANAGEMENT

PROJECT EXPERIENCE

05 Successful Projects PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

05 Successful Projects PDF

Caricato da

Copyright:

Formati disponibili

A Project

A Project Managers Guide to Managing Successful Projects Preface

www.pmptools.com publishing division welcome corrections and comments on its

ISBN 0-9726656-7-6 (paperback)

Preface A Project Managers Guide to Managing Successful Projects

Chapter 2 - Understanding Project Management

Chapter 3 - Project Management Foundations

A Project Managers Guide to Managing Successful Projects Table of Contents

Chapter 5 - Project Close-Out

Appendix A - Project Management Tools

Table of Contents A Project Managers Guide to Managing Successful Projects

A Project Managers Guide to Managing Successful Projects Introduction 1-1

Introduction to Project Management

1-2 A Project Managers Guide to Managing Successful Projects

A Project Managers Guide to Managing Successful Projects Introduction 1-3

1-4 A Project Managers Guide to Managing Successful Projects

A Project Managers Guide to Managing Successful Projects 2-5

PROJECT MANAGEMENT IS A PROCESS

2-6 A Project Managers Guide to Managing Successful Projects

DETERMINING WHO A PROJECT AFFECTS

A Project Managers Guide to Managing Successful Projects 2-7

2-8 A Project Managers Guide to Managing Successful Projects

WHERE DO PROJECTS COME FROM?

A Project Managers Guide to Managing Successful Projects 2-9

ESTABLISH AND REFINE OBJECTIVES BASED ON NEEDS

2-10 A Project Managers Guide to Managing Successful Projects

REQUIREMENTS: FUNCTIONAL AND TECHNICAL

A Project Managers Guide to Managing Successful Projects 2-11

REQUIREMENTS DEFINITION CHALLENGES

2-12 A Project Managers Guide to Managing Successful Projects

A Project Managers Guide to Managing Successful Projects 2-13

2-14 A Project Managers Guide to Managing Successful Projects

A Project Managers Guide to Managing Successful Projects 3-15

PLANNED CHANGE MANAGEMENT

3-16 A Project Managers Guide to Managing Successful Projects

The Change Process

Identify Proposal to Document &

Clarify Scope Customer NO Update File

Identify Update Project

Document & NO Accept YES Implement

A Project Managers Guide to Managing Successful Projects 3-17

3-18 A Project Managers Guide to Managing Successful Projects

A friend of mine was bidding on a government contract and a encountered a challenge.

A Project Managers Guide to Managing Successful Projects 3-19

THE WORK BREAKDOWN STRUCTURE - OVERVIEW

3-20 A Project Managers Guide to Managing Successful Projects

ACTIVITY ACTIVITY ACTIVITY

Activity Activity Activity Activity Activity Activity

Task Task Task Task Task Task

Task Task Task Task Task Task

Task Task Task Task Task

Work Breakdown Structure Task

A Project Managers Guide to Managing Successful Projects 3-21

THERE ARE FOUR USES FOR THE WBS:

3-22 A Project Managers Guide to Managing Successful Projects

TASK - VS. PRODUCT-ORIENTED WBS

A Project Managers Guide to Managing Successful Projects 3-23

THE WORK PACKAGE

Validate Develop Project Hold Kickoff Develop Develop

Work Package Level

3-24 A Project Managers Guide to Managing Successful Projects

THE CONTROL ACCOUNT

Validate Develop Project Hold Kickoff Develop Develop