Project Wreck

Project Wreck

Twelve Reasons Projects Fail





by John M. Langlois







2007
JoRoJim Publishers
North Carolina

PROJECT WRECK. Copyright © 2007 by John M. Langlois.


All rights reserved. No part of this book may be used or reproduced in
any manner whatsoever without written permission except in the case
of brief quotations embodied in critical articles and reviews.

IBM is a trademark of International Business Machines Corporation in
the United States.

Photo Credits
Þ All images in this publication were purchased from iStockphoto.com
unless otherwise noted. Þ Page 44: Magna Carta reproduced with
permission of the Perot Foundation Þ Page 51: Photoshop image of
John Langlois Þ Page 182: Photos of Leland Stanford, John “Casey”
Jones and an unidentified train conductor are in the public domain Þ
Page 187: Hand is from Michelangelo's The Creation of Adam, a fresco
on the ceiling of the Sistine Chapel


First Edition

Printed on acid-free paper

Manufactured in the United States of America



Library of Congress Cataloging-in-Publication Data

Langlois, John M., 1960 -
Project Train Wreck: Lessons from failed business projects / John
Langlois. – 1st ed.
p. cm.
Includes index.
ISBN-13: 978-0-9792978-0-9
ISBN-10: 0-9792978-0-x
Library of Congress Control Number: 2007922761

1. Business. 2. Leadership. 3. Management. I. Title

10 9 8 7 6 5 4 3 2 1 0


For Chris and Katie




Contents

ACKNOWLEDGEMENTS ............................................ iii

FOREWORD......................................................................v

1 THE DIRTY DOZEN................................................1
1.1 What Causes Project Disasters?...........................2
1.2 The Role of the Project Manager .........................5
1.3 The Role of the Sponsor ......................................9
1.4 The Great Train Robbery...................................15
1.5 The Rights of Your Crew...................................20

2 PLAN YOUR TRIP .................................................24
2.1 Pull the Brakes on a Runaway Project...............25
2.2 Leave the Kick-off Station on Time ..................31
2.3 Confirm the Trip With Your Customer .............34
2.4 Construct Off-Ramps.........................................41
2.5 Charter the Project .............................................44
2.6 Scrap the Process Checklist ...............................49

3 LAY THE TRACKS................................................54
3.1 Document Project Scope....................................55
3.2 Estimate Project Cost (Model Overview) ..........57
3.3 Collect and Prioritize Requirements ..................60
3.4 Confirm Core Delivery Capability.....................67
3.5 Construct the WBS ............................................71
3.6 Plot the Schedule................................................74
3.7 Play the Percentages ..........................................81
3.8 Prepare the Cost Estimate ..................................89
3.9 Reduce Project Friction......................................94

4 LEAD THE TEAM................................................100
4.1 Stretch Your Soft Skill Muscles ......................101
4.2 Train Your Crew..............................................106
ii
4.3 Limit the Number of Rules and Regulations ...109
4.4 Enforce Acceptable Behaviors.........................114
4.5 Redirect Narcissists..........................................120
4.6 Provide Behavioral Feedback ..........................123
4.7 Triage Missed Commitments...........................131
4.8 Pour On the Praise ...........................................135

5 MONITOR TRAFFIC...........................................138
5.1 Report Project Status........................................139
5.2 Debate Earned Values......................................143
5.3 Scan Your Risk Radar......................................150
5.4 Control Change ................................................156
5.5 Time Your Run ................................................162
5.6 Limit Lines of Communication........................166
5.7 Control Your Email..........................................170
5.8 Fireside Chat ....................................................176

6 TUNE YOUR MANAGEMENT ENGINE..........179
6.1 Install Meaningful Dashboards........................180
6.2 Protect Your Interests ......................................185
6.3 Prevent Decision Paralysis...............................190
6.4 Visit the PMO Junction....................................197

7 LAST STOP............................................................201
7.1 Investigate Every Accident ..............................202
7.2 Collect Tools....................................................206
7.3 The Rules of Project Leadership......................208
7.4 Cruising Down the Tracks ...............................212

Ready-to-Use Templates................................................214
Figures and Tables.........................................................215
Index................................................................................216

iii

ACKNOWLEDGEMENTS

Thanks to:

• My wife Christine. She encouraged me to write this
book “in the evenings” while keeping my day job. She
is an excellent risk planner.
• My daughter Katie. The final arbiter for all design
decisions related to this book and the projectEZ.com
website.
• My mom. The project manager I aspire to be. She
raised six kids and managed to make each of us feel
special.


iv
v
FOREWORD

You are about to see the world through the eyes of a
contrarian. This book challenges the reader to abandon
commonly held beliefs about managing people and
processes to deliver a project.

The author draws inspiration from both pop culture and
ancient history. Generous anecdotal evidence, user
templates, and visual illustrations greatly support the
author’s mission to let you in on the secrets for shaking and
moving projects through the organization.

This highly readable book is recommended for employees
in every layer of the business organization:
• from the executives in boardrooms who charter ill fated
projects,
• to the project leaders who defend their project from
robbers,
• to the functional employees trying to survive the run
without proper provisions.

Let Mr. Langlois guide you on new paths through portfolio
planning and project execution. It’s a fun trip full of keen
insights and laugh out loud satire. You are going to enjoy
this journey.

Mamoon Hammad

Dr. Mamoon M. Hammad, PhD.
Department of Decision Sciences, School of Business
The George Washington University
vi



1 THE DIRTY DOZEN







THE DIRTY DOZEN
1


Key Topics Covered In This Section:
• What causes projects to derail?
• Why you should never leave the station
without a conductor.
• How a sponsor can help you move large
obstacles on the tracks.
• Why you should protect the rights of your
crew.


2 THE DIRTY DOZEN
1.1 What Causes Project Disasters?

An odd comedy called The Addams Family
debuted on network television in 1964. In
one of my favorite scenes, Gomez, the
stogie-smoking head of this macabre
household, flipped a switch on his elaborate toy train set to
deliberately initiate a head-on collision between two trains.
There is something curiously hypnotic about watching a toy
train wreck in motion.

However, it is a different story when you are the conductor
on a real project train and someone keeps flipping the
switch on your tracks to initiate head-on collisions. Surely
there must be somebody undermining your efforts! How
else do you explain why so many business projects finish
late and over budget?

Being a wealthy tycoon, Gomez simply repaired his
expensive train set each week so that he could recreate
another spectacular crash on demand. He quite literally had
money to burn.
1
Businesses, however, run on fixed budgets
and profit performance expectations set by Wall Street, so
they can’t afford to watch project wrecks unfold each week
like reruns of the Addams Family.

I’ve been the project manager on quite a few doomed
projects, so I can attest that it is chilling to be the first
person to see an obstacle on the tracks, a broken rail, or
another project approaching on a collision course. In some
cases I jumped to another assignment before the collision.
Sometimes I rode out the disaster after refusing to listen to

1
Trivia: Gomez Addams was a lawyer.
What Causes Project Disasters? 3
that little voice in my head yelling “Save yourself! Save
yourself!” This book documents the lessons I learned so
that you can identify troubles early and take action to keep
your projects on track.

Major Causes of Wrecks:
Based on my experiences, here are the most common
reasons projects derail:
1. Projects leave the boarding station without a
conductor to coordinate activities.
2. Project sponsors are unwilling or unable to move
large obstacles on the tracks.
3. Executives place irrationally large bets on
exceedingly risky projects.
4. Employees throughout the organization lack the
courage to cancel a doomed project (stop a runaway
train).
5. Stakeholders can’t agree on the final destination.
6. Projects are not properly provisioned with the
necessary resources to reach their final destination.
7. Schedules are overly complex and difficult to follow.
8. Cost estimates are grossly understated.
9. Offerings are burdened with unnecessary scope.
10. Dysfunctional teams fight with each other and
sabotage project deliverables.
11. Status reports are uninformative.
12. Risk crossing lights are missing from dangerous
intersections.

This book addresses each of these problems as it details
specific instructions for getting the job done quickly. Each
chapter includes practical tips to help you avoid the
common traps that derail projects.
4 THE DIRTY DOZEN
If you apply the principles in this book, you will see fewer
project wrecks. It doesn’t matter what process you employ
to deliver your project – Agile Development, Extreme
Programming, Waterfall, Spiral, Seat-of-Your Pants, Rapid
Application Development – they all have merit. Keep doing
whatever works for you. The principles in this book are
universal guides that help shepherd projects through any
process.

I hear the whistle that’s telling us that our project is about
to leave the station, so climb aboard and I’ll introduce you
to the conductor!
The Role of the Project Manager 5
1.2 The Role of the Project Manager

Projects are the delivery vehicle for every product and
service in the market today. The Project Management Body
of Knowledge (PMBOK
®
)
2
defines the term project as “a
temporary endeavor undertaken to create a unique product,
service or result.” Let’s parse this definition into two parts:
• Projects have a finite beginning and an end.
• Projects have a defined set of deliverables.
The railroad metaphor also satisfies this definition. Train
trips have a beginning and an end. We call these two points
the boarding station and the final destination. Furthermore,
there are scheduled stops at interim stations along the route.
We use these stops to gather provisions and track our
progress against published time schedules.

The project manager is a lot like the conductor on a train
who supervises rail service to ensure that the train runs
efficiently and on schedule. Like a train conductor, the
project manager is the focal point for
project communication. He or she
coordinates activities, communicates
status, and marshals the resources to
respond to emergencies.

The successful project manager devotes
meaningful time to developing the
team. The end-goal of team
development is to motivate the crew to meet their
objectives even when they aren’t being watched. After all,
the conductor can’t be physically in every car at once. The

2
Published by the Project Management Institute (PMI
®
)
6 THE DIRTY DOZEN
highest levels of performance are achieved when the crew
is motivated to perform their tasks without supervision.

We’ve all been guilty of slacking when a supervisor isn’t
looking. Consider the following example. My dad owned a
boat marina. My job each morning was to scrape the
barnacles off the hull of a boat. This was a very important
task, since a barnacled boat plods through the water; the
extra drag dramatically reduces fuel efficiency. Despite the
importance of the task, scraping hulls with a putty knife is
just plain monotonous so I’d stop working whenever my
dad left the scene.

Barnacle Babble:
endless excuses for
poor performance.
When he returned to complain about my lack of progress, I
did what most unmotivated, underachieving employees do:
I made impassioned
excuses. “Barnacles are
really tough, dad. They
can manufacture a glue
so strong that it has a
sheer strength of 7,000 pounds per square inch. Removing
just one of the little buggers is like trying to hold open three
and a half gator jaws!”
3
I spewed these useless facts to
rationalize my poor performance. My familial manager,
anxious to do real work, usually left me alone when I
started these intellectual rants. As you might expect, my
projects typically ran late and over budget!

The effective project manager silences this prattle at once.
Don’t tolerate a lazy employee who wastes time with
irrelevant excuses for poor performance. Your project has a
schedule to meet. If it is off schedule, stop talking and start
working to get it back on track. Please see the section of

3
A gator exerts 2,000 psi when closing its muscular jaws.
The Role of the Project Manager 7
this book called Leading the Crew for useful tips on how to
address underperforming employees.

Practical Application
• Assign a project manager (conductor) to every
important project. This person must possess the skills to
chart a realistic schedule, to accurately report status, to
respond to emergencies, and to lead a diverse crew.
• Spend time developing a high-performance team.
Immature project managers focus only on tasks and
deliverables. They are in such a hurry to get things done
that they leave the station before the crew is even on
board the train!
• Don’t waste time listening to Barnacle Babble excuses
for poor performance from your crew. Instead, restate
expectations with clear completion milestones and
challenge the team to meet them.
• Practicing “soft skills
4
” to develop your team doesn’t
mean you have to be soft with your expectations.
• Tell your employees that you put a premium on
execution over reporting. When there is a problem,
encourage them to get to the root cause of the issue and
resolve it quickly with the absolute minimum number
of excuses, presentation slides, reports and meetings.
• Regularly communicate the “next stop” milestone, so
that the crew knows exactly where they are currently
and where they are going next.

4
Soft skills: cluster of personal qualities (sociability, honesty, integrity)
and interpersonal skills such as the ability to exercise leadership.
8 THE DIRTY DOZEN
Summary
The successful project manager charts realistic routes with
achievable time schedules and keeps the project moving on
schedule through each checkpoint station.

If you are an executive reading this book, never allow the
train to leave the station without a conductor! If you are the
project manager, don’t neglect your crew. Work to develop
a team that performs at the highest level of professionalism
– even when nobody is watching.

The Role of the Sponsor 9
1.3 The Role of the Sponsor

In mountain terrain, landslides may deposit heavy rocks on
the tracks. When you reach this kind of impasse, it’s time
to call your project sponsor. By formal definition, a project
sponsor is the executive or manager with the fiscal
authority, political clout and personal commitment to get
things done. In other words, he or she is your Boulder
Mover.


Obviously, you cannot move this massive boulder without
substantial help. This isn’t a poor reflection on your
technical skills; it’s simply an observation of physical laws.
Traffic will remain clogged if you don’t move this boulder,
so call your sponsor promptly and request help. Don’t be
uncomfortable about exercising this reverse flow of
authority. Intelligent sponsors appreciate their critical role
and willingly offer aid when required. In fact, sponsors take
more pride in the project when they directly influence the
results!

Ideally, your sponsor should be a single person rather than
a committee: you won’t have time to stroke multiple egos
during a crisis. Remember, the queue behind the boulder
grows with each passing second.

10 THE DIRTY DOZEN
Sponsors can be especially helpful when you’re managing a
joint project with an external company. A key part of the
sponsor’s role in this case will be relationship
management. Your sponsor shakes hands, signs contracts,
plays golf and resolves conflicts. The sponsor gives the
other company confidence that your company values the
relationship.

Choosing your Sponsor
Identifying a project sponsor is quite easy. Ask yourself,
“Who really wants this project?” A good project sponsor:
• Has a vested interest in seeing that the project traffic is
moving smoothly.
• Possesses the power and resources to move large
boulders.
• Willingly exercises that power in an emergency.

Jot down a list of potential candidates, then ask, “Would
you consider being the project sponsor?” If the person is
genuinely interested in the success of the endeavor, why
would he or she turn you down? If you can’t name a
person, then why are you executing the project? Kicking
off a project without formal support is just plain foolish.

Draft a Sponsor Letter
Draft the following letter and ask your sponsor to send it to
the team prior to your kickoff meeting so that everybody
has clear expectations for team member participation.
The Role of the Sponsor 11
Template 1: Sponsor Letter

TO: Team Members
FROM: Sponsor

You have been selected to participate on the new
[project name] team led by John Langlois. The team
will meet once per week.O The activities performed by
this team will include:
• Defining the project requirements for each
decision gate. O
• Committing a closed plan to deliver project scope
on [x date].
• Sponsoring change requests to modify product
plans based on significant changes to the
committed baseline.
• Communicating project status for your
deliverables with the project manager to confirm
that we have alignment of the piece parts.
• Highlighting project risks early and often..

You have been selected to participate on this team
because you have the knowledge and experience to
make important contributions to this initiative. If for any
reason you feel that you will not be a productive
representative on this team, just let John know.O

I appreciate and support your efforts.

Regards,

Cornelius Vanderbilt O

12 THE DIRTY DOZEN
Here are the important elements of this letter:
1. Communicates meeting frequency
2. Defines activities
3. Sets expectations
4. Establishes referential authority
5


Moments after this letter is sent, it will become readily
apparent that some members of the team never agreed to
support your project. How often do you hear, “I don’t have
the time for this, go away?” That’s the beauty of using this
letter, since it flushes out resistance early in the process so
that you can deal with it.

If a team member’s workload is constrained, then become
an advocate for that team member and ask his/her manager
to reprioritize that person’s work. Functional managers and
sponsors who tell the employee to “just do it” are your
worst enemy. You should never be the source of a major
work/life balance issue in your team and you shouldn’t
have to beg and cajole resources to help. Use your sponsor
to help resolve these resource issues.

Practical Application
• If you can’t find a single executive to stand up and say,
“I want this project!” then hold the train at the boarding
station.
• Select a sponsor with real power. Does she hold the
purse strings, or does she have recognized authority?
Since market-driven projects are typically incubated
within the marketing function, start your search for a
sponsor there.

5
Referential authority from a respected sponsor grants the project
manager the legitimacy, justification, and right to exercise power.
The Role of the Sponsor 13
• Brief your sponsor early in the proposal phase. Make
certain that both you and your sponsor have a common
understanding of both your relationship to each other
and the project parameters.
• Draft a sponsor letter to the team at the start of each
project. Re-charter the initiative if the project loses
steam.
• Validate major decisions with your sponsor before you
present them to a wider audience.
• Recognize that executives don’t care about
implementation details – they only want to know the
customer value of the project and its financial
contributions to the business. They hire you to manage
the details. Use exception-based reporting techniques to
communicate with your sponsor.
6

• Ask your sponsor to identify a new sponsor when she
moves on to another job. She should introduce you to
her replacement.

Pitfalls to Avoid
• If your sponsor is a figurehead with little authority or
low interest in the project, then find a new sponsor. You
want a sponsor who possesses heavy equipment to clear
the tracks.
• Be prepared to patiently educate your executives on the
role of a sponsor. If you are chicken, just copy this
chapter and slide it under their door.
• Do not allow your sponsor to start the delivery clock
until the crew boards the train.

6
See the Report Project Status chapter for a simple reporting template.
14 THE DIRTY DOZEN
• Lack of resistance by the sponsor does not mean that
she supports your position on important matters. Ask
her directly, “Do you agree?”

Summary
Carefully select a sponsor that has a vested interest in your
project and one that possesses the power (money and
resources) to get the job done. You and your team will have
peace of mind, knowing that somebody really cares about
the project.

Develop a strong interpersonal relationship with your
sponsor. A good sponsor is there to assist you. She can
move large boulders that you’ll never budge on your own.
One word of caution is warranted here: don’t abuse this
relationship!
The Great Train Robbery 15
1.4 The Great Train Robbery

Projects are hijacked at an alarming rate in today’s business
world. A typical heist goes this way: A delivery function is
falling behind on a key task for one project, so the
functional manager
7
of the department reassigns resources
from your project to work on the project that’s running late.
This would not be a problem if the decision to prioritize
those resources was transparent and approved by all
stakeholders. Unfortunately, it is not uncommon for thieves
to cut the telegraph wire and redirect resources without
communicating the shift. The project manager may not
even be aware that his crew has been shanghaied
8
.

The organizational structure of your organization
determines whether the project manager is unarmed and
defenseless to stop these bandits. In a matrix organization,
where resources are assigned from functions to support a
project, employees are put in the “two boss” bind. The
functional manager may say “go left” to Deadwood while
the project manager says, “go right” to Petticoat Junction.
Can you blame the employee for obeying the functional
manager that completes his/her performance appraisal?

The Strong Matrix Protects Your Project
Most organizations publicly support what’s known as a
strong matrix environment where power is centered on the
project manager. The project manager is the prime
contractor in this organizational structure; the one throat to

7
Functional manager: Person who completes human resource activities
for team members in the delivery organization including the
performance review.
8
Shanghaied: Forcibly conscripted to work on another project.
16 THE DIRTY DOZEN
choke. In my company, this role is euphemistically called
the “single point of contact.”

Unfortunately, many people unconsciously weaken the
matrix environment. This isn’t deliberate; they probably
don’t know what the term means. Here is a proper working
definition for the strong matrix:
• The portfolio planning team determines the strategic
direction of investments.
• The project manager controls project dollars and what
is done and when it is done.
• The functional manager determines who will do the
work and what technology will be used.

Significant decision authority rests with the project
manager in this clear view of the organization. Conflict and
tension plague organizations, on the other hand, where the
project manager and the functional managers vie for power
and control in the matrix organization. By default, the
functional manager wins these battles unless executives
consciously choose to dial the matrix strength toward the
project manager.

Defend Your Project
In the 19
th
century, conductors and other personnel took
enormous pride in their duty. They were even willing to
risk their lives to protect a train shipment.

What are your core values? Do you defend them with
passion? The Conductor’s Creed can help you meditate on
these fundamental questions. This document describes the
strong matrix without ever using the term. Modify it to fit
your personality and then share it with your team.

The Great Train Robbery 17
Template 2: The Conductor’s Creed

1. This team is a decision-making body. Our executives
trust us. So let's chug ahead and not look backward at
decisions already made unless some new piece of
critical data surfaces.
2. I feel comfortable using directionally correct data to
make decisions. If the n
th
iteration of a case won't add
any new insight or change a decision, then don't run it.
3. The team makes every project commitment.
Development doesn't commit the launch date. Nor
does marketing. The whole team commits to every
deliverable.
4. I value open and honest communication. You will
always be respected for telling the unfiltered truth.
You should provide headlight warnings if we could
potentially miss an important milestone or deliverable.
If I hear about a missed milestone after the fact, then
there will be negative consequences.
5. I encourage you to openly discuss problems. If you
need help, ask for it.
6. You are the single focal point for your entire function.
This helps limit the lines of communication and
eliminates “pass-offs” through the organizations.
7. Set up a communication channel with your
management team to keep them posted on team
decisions and execution status.
8. You are empowered to schedule side meetings and
talk directly to anyone else on the team. I’m not your
administrative assistant.
9. I expect every person on the team to provide tangible
value to the project. If this is impossible either
because of motivation or ability issues, then please see
me and let's try to work it out or ask your manager for
a transfer to another assignment.
18 THE DIRTY DOZEN
Your team will appreciate that you have core principles by
which you live. Naturally, some people will take exception
to your views. But right or wrong, this is the way your
brain is wired. That is the great thing about communicating
your philosophy; it is a personal statement that explains
why you behave the way you do. Who can argue with that?

Disarming the Bandits
Communicating your philosophy empowers you to confront
weak matrix behaviors. Here is a useful technique you can
use to defend your philosophy:
1. Make an observation. “I notice that you started work
on another project without notifying me.”
2. State the impact. “This puts our project at risk of
missing its schedule.”
3. Restate your expectations. “In the future, I expect you
to inform me if you are being redirected by someone
else to work on other assignments.”

By regularly enforcing your creed, you will build a
reputation as a tough but fair leader who does not tolerate
bad behavior.

Practical Application
• Establish the project manager as the prime contractor
and primary communication channel for the project.
• Write down your personal project management
philosophy. Convince yourself that you have
considerable power.
• Send it out to the team. Ask them if it sounds
reasonable.
• Call violations every time you see one.


The Great Train Robbery 19
Pitfalls to Avoid
• Don’t assume that the team understands basic project
management principles such as “strong matrix.”
Explain new terms.
• If you don’t communicate your expectations, then
people will guess. (And they will chronically guess
wrong!)
• Don’t let bad behaviors slide. When somebody attacks
your core values, defend them with passion – or you
will lose respect for yourself.

Summary
The project manager must defend the train from Butch
Cassidy, Jesse James and functional managers. Establish a
strong matrix with clear boundaries for roles and
responsibilities to reduce the amount of unproductive
political maneuvering in your organization.

In the strong matrix arrangement, the project manager
exercises considerable control over the project. Use the
Conductor’s Creed template to describe the strong matrix in
simple real world terms. Your team will respect you for
communicating your core values and for defending them
with passion.
20 THE DIRTY DOZEN
1.5 The Rights of Your Crew

Are you as quick to advocate for the rights of your team as
you are to remind them of their responsibilities? A
historical event illustrates the folly of abusing employee
rights. Hark back to the golden spike that connected the
transcontinental railroad at Promontory on May 10, 1869.
Most people don’t know that the ceremony to
commemorate this monumental project was originally
scheduled for May 8, two days earlier. What caused the
delay?

The Union Pacific train had been held up in Piedmont,
Wyoming on May 8
th
, by a rowdy crowd of 500 workers
demanding back wages. When the conductor attempted to
inch out of the station, the strikers uncoupled the car
carrying top Union Pacific dignitaries, switched it to a
sidetrack, and chained the wheels to the rails. The angry
gang then commandeered the telegraph office until an
official wired to Boston for the money to pay their wages.
After they were paid, they released the car to continue on to
Promontory for the ceremony.

That employee strike reminds us that when you habitually
violate the rights of your team (in this grievous case,
employees were not paid for their work), bad things will
happen to your project. The abused team will give you less
than their best effort and, in severe cases of malcontent,
they may sabotage the project.
The Rights of Your Crew 21

Triple Constraint
Project Managers use the Triple Constraint to protect the
team. This term describes three key project objectives –
scope (the deliverables), time (the schedule), and cost (the
monetary budget) – visually depicted as an interrelated
equal sided triangle.
Q
T
i
m
e
C
o
s
t
Scope
Q
T
i
m
e
C
o
s
t
Scope
Q
T
i
m
e
C
o
s
t
Scope

If one side of the triangle changes, then the other sides must
adjust to keep the shape in balance. Say, for example, that
marketing requests additional project scope (a new feature),
then it is only fair to give the team an opportunity to assess
the impact to the other sides of the triangle – schedule may
slip and costs may rise.

Some people consider the Triple Constraint an obsolete
term. They cite Quality as another key interrelated project
parameter. We can still keep our basic triangle, though, by
putting Quality inside the triangle or by considering it part
of Scope.

Recognize the Rights of Your Crew
Recognize the rights of your crew publicly. Here’s a
template that communicates their rights and
responsibilities. This manifesto gives your team permission
to sound off when their rights are violated. You want to
hear their complaints, since controlled venting reduces
anxiety in the workplace.

22 THE DIRTY DOZEN
Template 3: Team Member Rights & Responsibilities

Your Rights
· You have a right to work in a strong matrix
environment.
· You have a right to be properly provisioned by
your sponsor.
· You have a right to understand the project
parameters for scope, time, cost and quality.
· You have a right to exercise formal change
controls if any element of the triple constraint is
affected after the baseline is committed.
· You have a right to demand a decision (Go, No
Go, or Redirect) on your proposals.
· You have a right to be heard.

Your Responsibilities
· Understand and empathize with customers.
· Commit revenue/profit and schedule for the
proposed offering as a team.
· Drive improvements to project costs.
· Manage stakeholders.
· Communicate openly:
o Break down every artificial wall erected between
functions.
o Provide crisp status reports.
o Provide risk headlights and mitigation plans.
· Share lessons learned.
· Be the single focal point to your extended team.
· Train your replacement.

The Rights of Your Crew 23
Practical Application
• Draft a short list of rights and responsibilities for your
team.
• Review the list with both your team member and
his/her functional management. This list teaches the
subtle concepts of a strong matrix in an inoffensive
way.
• Tell your team to call violations whenever their rights
are violated.

Summary
A leader recognizes that all humans have rights. The
fundamental rights that you and your team agree upon
should reflect the mutual respect you have for each other.



2 PLAN YOUR TRIP






2
PLAN YOUR TRIP


Key Topics Covered In This Section:
• How to put the brakes on bad projects.
• How to confirm the final destination with
customers.
• The importance of a charter that formally
authorizes the journey.
• Why you should trim down your process
checklist.

Pull the Brakes on a Runaway Project 25
2.1 Pull the Brakes on a Runaway Project

Most businesses behave a lot like a railroad system. Sure,
we want to believe that our business model is flexible and
that our employees are as quick-footed as Gandy Dancers;
9

the truth, however, is that people, processes and tools are
slow to change. Like a railway system, once project tracks
are in place they are extremely difficult to move.

A high-performing
team can’t save a
crummy idea.
If you want to run a successful business, you would do well
to select the right project and plan it well before it leaves
the station because once a train reaches cruising speed it is
extremely difficult to stop. In other words, if a project
proposal is weak, then you should stand on the tracks to
keep it from leaving the
boarding station.

In this chapter we will
discuss how we can use the
portfolio planning process to suppress bad project
proposals. But first a word of caution: efforts to cancel
projects, even apparent losers, will be met with strong
resistance. Why? Because someone obviously thought that
the proposal was a good idea. That “someone” is likely a
high level executive. Do you dare tell the executive that his
idea is dull? More to the point, does he really value open
and honest communication?


9
Gandy Dancer was a term for track workers back in the 1800s who
used tools made by the Gandy Tool Company of Chicago, Illinois. The
shovel head was strong enough to pry up a tie and standing on the
handle for leverage made for a wild-looking “dance.”
26 PLAN YOUR TRIP
Reject Bad Projects Early
In an efficient portfolio-planning model, only a few ideas
are chartered for execution and some of those are cancelled
later at one of several phase gate decision checkpoints (see
Figure 1).

This figure parses project delivery into sequential stations
or phases: Concept, Develop, Execute and Finish. This
follows the convenient mnemonic C, D, E, and F. Some
organizations complicate this simple phase gate model by
changing the standard gate names and adding a few more
gates. This keeps their process bureaucrats employed.

Notice that the shape of this phase gate model is a funnel
with a wide opening on the left and a narrow pipe at the
other end. In this example, only three out of 21 “brilliant”
project ideas reached their final delivery destination!
Where did the other 18 chartered projects go? They met
their demise at a decision checkpoint station. At these
checkpoints, stakeholders vote to either proceed to the next
station or to cancel the project.

Pull the Brakes on a Runaway Project 27




F
i
g
u
r
e

1
:

P
h
a
s
e

G
a
t
e

P
r
o
c
e
s
s








C
o
n
c
e
p
t
D
e
v
e
l
o
p
E
x
e
c
u
t
e
P r o p o s a l s
F
i
n
i
s
h
C
h
a
r
t
e
r
=


P
h
a
s
e

G
a
t
e

D
e
c
i
s
i
o
n

C
h
e
c
k
p
o
i
n
t
C
o
n
c
e
p
t
D
e
v
e
l
o
p
E
x
e
c
u
t
e
P r o p o s a l s
F
i
n
i
s
h
C
h
a
r
t
e
r
=


P
h
a
s
e

G
a
t
e

D
e
c
i
s
i
o
n

C
h
e
c
k
p
o
i
n
t
C
o
n
c
e
p
t
D
e
v
e
l
o
p
E
x
e
c
u
t
e
P r o p o s a l s
F
i
n
i
s
h
C
h
a
r
t
e
r
=


P
h
a
s
e

G
a
t
e

D
e
c
i
s
i
o
n

C
h
e
c
k
p
o
i
n
t
28 PLAN YOUR TRIP
“No matter how far
you go in the wrong
direction, turn back.”
– Turkish Proverb
A project may start out with a solid proposal, but many
things can happen to change the business forecast after
charter. A competitor may make an announcement that
makes your project irrelevant or delivery costs may be
escalating out of control.
Doesn’t it make sense to
cancel a project that has
derailed when no amount
of reasonable effort and
money can put it back on
track? Canceling projects is the sign of a mature
organization.

High-performance teams give the executive decision
maker(s) all the information needed to make a wise choice
at each checkpoint. Since you are spending cumulatively
more dollars as projects chug through this funnel, you have
considerable incentive to cancel misguided proposals as
early as possible before you sink gobs of money into a
doomed venture. Nonetheless, there is never a bad time to
cancel a hopeless project. It is even conceivable that you
might cancel a project at the finish (launch) gate if the
lifecycle support costs for the product exceeds the current
forecasted gross profit
10
for the project.

Warning: Standing on the Tracks is Dangerous
Well, that’s the theory. My experience does not fit this
model. In a Gomez Addams kind of world, all proposals
that leave the charter boarding station chug blissfully along
to their final destination (even if they are years late to the
market). Stopping a project that’s underway is nearly
impossible because:
• Executives initiate pet projects. Recommending that a
pet project be cancelled can be career-limiting.

10
Gross profit equals revenue less cost.
Pull the Brakes on a Runaway Project 29
• The planning folks carve reams of market data into
mouth-watering opportunity projections. It is difficult
for executives to pass on any opportunity even if it is an
illusion.
• Once you start sinking money into a project, there is a
reluctance to write off unrecoverable expenses. That’s
admitting that someone made a poor decision.
• People develop an emotional attachment to the project.
What will you do if the project is cancelled? Sitting on
the bench waiting for the next project assignment is
risky when companies are cutting expense.

For all these reasons, project trains enter the funnel with a
head of steam that pushes them all the way through to the
end. Once a project is staffed and starts cruising down the
tracks, it is extremely difficult to stop. Best-of-class
companies, however, find ways to blunt this momentum
and to cancel weak projects at every phase of the delivery
process.

Put the Brakes on Bad Projects
Unsuspecting crews often board the train … even when it is
pointed in the wrong direction! The Project Manager,
however, should be level headed and protect both the team
and executives by lobbying strongly to keep foolish
projects at the station.

Nine out of ten project proposals should be rejected. You
might be thinking, If I turn down most of the proposals that
cross my desk, how will we ever make money? That’s a fair
question, but I have a good answer: You will make barrels
of money on the one good proposal you accept and you
won’t lose any money trying to recover derailed trains
along the way.

30 PLAN YOUR TRIP
Practical Application
Use a front-end portfolio planning process to point your
team in the right direction. Lobby passionately to cancel ill-
conceived projects early in their lives. Save your
executives, your team and yourself.
• Secure agreement on the final destination.
• Divide the journey into phases with station stops at the
end of each phase where you can make a decision to
continue, cancel or redirect the project.
• Define your cancellation or off-ramp criteria early in
the planning phase.
• Resist the tendency to develop an emotional attachment
to a project. Be objective when you present the facts to
your management at each checkpoint.
• Make sure that your project train is properly
provisioned. It’s crazy to leave the station without a
crew or without coal to stoke the engine.

Summary
If a project cannot be completed on the target schedule,
with a minimum set of deliverables, or for the target cost,
then say so. Be heard. If you don’t make your stand early,
you will lose your best chance to skip a harrowing ride. But
even if a bad project escapes through several phase gates,
lobby strongly to cancel it if there is no chance that it can
be redeemed.
Leave the Kick-off Station on Time 31
2.2 Leave the Kick-off Station on Time

Whenever the portfolio management team (PMT) adds a
new project to the roadmap for future delivery, they should
immediately peg a reasonable kickoff date for the project.

Kickoff dates aren’t arbitrary; they should be based on best
estimates of timelines for delivery of similar projects.
Otherwise, the conductor may find himself behind schedule
before the project is even chartered. Figure 11 helps you
get your bearings as it traces project reporting from
inception to delivery. Notice that Step 2 establishes the
kickoff dates based on roadmap input.

You can employ a simple “backward pass” to determine the
target kickoff date for the project using broad-brush order
of magnitude estimates. For example, you might develop a
complexity factors planning table based on the experiences
in your organization that looks like this:
Table 1: New Project Complexity Table

Complexity
Technology
Usage
Size of
Effort

Budget
Baseline
Timeline
High Leading
edge
1,000
tasks
$1M 16
months
Medium 2
nd

generation
500 tasks $500k 10
months
Low Common
parts
100 tasks 100K 3 months

Using the parameters in the complexity table above, we
know that we need to kickoff a highly complex project
sitting on the launch roadmap 16 months before the target
launch.
32 PLAN YOUR TRIP



F
i
g
u
r
e

2
:

H
o
w

P
r
o
j
e
c
t

R
e
p
o
r
t
s

R
e
l
a
t
e

t
o

E
a
c
h

O
t
h
e
r


V
a
l
u
e

A
c
c
u
r
a
t
e
l
y

p
o
r
t
r
a
y

p
r
o
j
e
c
t

s
t
a
t
u
s

a
f
t
e
r

b
a
s
e
l
i
n
e

c
o
m
m
i
t
m
e
n
t

i
s

e
s
t
a
b
l
i
s
h
e
d

U
n
b
l
i
n
k
i
n
g

r
e
v
i
e
w

o
f

r
i
s
k
s

a
n
d

i
s
s
u
e
s
S
t
a
t
u
s

M
a
n
a
g
e

p
r
o
j
e
c
t

t
h
r
o
u
g
h

e
a
c
h

p
h
a
s
e

g
a
t
e
s

E
s
t
a
b
l
i
s
h

T
r
i
p
l
e

c
o
n
s
t
r
a
i
n
t

t
a
r
g
e
t
s

E
n
s
u
r
e

t
h
a
t

r
e
s
o
u
r
c
e
s

t
o

s
u
p
p
o
r
t

p
h
a
s
e

a
c
t
i
v
i
t
y

a
r
e

i
n

p
l
a
c
e

L
o
o
k

A
h
e
a
d

A
v
o
i
d

p
o
t
e
n
t
i
a
l

p
o
t
h
o
l
e
s

D
e
f
i
n
e

l
a
u
n
c
h

c
a
d
e
n
c
e

f
o
r

s
t
e
a
d
y

s
t
a
t
e

b
u
s
i
n
e
s
s

E
s
t
a
b
l
i
s
h

b
a
s
e
l
i
n
e

s
c
h
e
d
u
l
e

t
a
r
g
e
t
s

E
s
t
a
b
l
i
s
h

r
e
a
s
o
n
a
b
l
e

P
r
o
j
e
c
t

K
/
O

d
a
t
e
s

(
b
a
c
k
w
a
r
d

p
a
s
s
)
F
r
e
q
u
e
n
c
y
R
o
a
d
m
a
p
K
e
y

D
a
t
e
s
K
i
c
k
-
o
f
f
C
h
e
c
k

P
o
i
n
t
s
P
M
T

a
n
d

P
r
o
j
.

M
a
n
a
g
e
r
P
M
T
P
M
T
R
e
p
o
r
t
e
d

a
t
K
e
y

R
e
p
o
r
t
O
w
n
e
r
P
M
T
O
f
f
e
r
i
n
g
M
a
n
a
g
e
r
P
r
o
j
e
c
t
M
a
n
a
g
e
r
I
n
v
e
s
t
m
e
n
t
R
e
v
i
e
w
B
o
a
r
d
I
n
v
e
s
t
m
e
n
t
R
e
v
i
e
w
B
o
a
r
d
O
n
c
e

p
e
r

m
o
n
t
h
O
n
c
e

p
e
r

m
o
n
t
h
T
w
i
c
e

p
e
r

m
o
n
t
h
T
w
i
c
e

p
e
r

m
o
n
t
h
S
t
e
p

1
S
t
e
p

2
S
t
e
p

3
S
t
e
p

4
P
r
i
o
r
i
t
i
z
e
d
P
o
r
t
f
o
l
i
o
P
r
o
j
e
c
t
M
a
n
a
g
e
r
O
f
f
e
r
i
n
g

R
e
v
i
e
w
W
e
e
k
l
y
P
o
s
t

P
l
a
n

A
l
i
g
n

p
r
o
j
e
c
t
s

t
o

B
u
s
i
n
e
s
s

O
b
j
e
c
t
i
v
e
s

P
r
i
o
r
i
t
i
z
e

p
r
o
j
e
c
t
s

I
d
e
n
t
i
f
y

c
o
r
e

c
a
p
a
b
i
l
i
t
y

&

r
e
s
o
u
r
c
e
s

c
o
n
s
t
r
a
i
n
t
s
P
M
T
P
o
r
t
f
o
l
i
o

M
a
n
a
g
e
m
e
n
t

T
e
a
m
O
n
c
e

p
e
r

m
o
n
t
h
V
a
l
u
e

A
c
c
u
r
a
t
e
l
y

p
o
r
t
r
a
y

p
r
o
j
e
c
t

s
t
a
t
u
s

a
f
t
e
r

b
a
s
e
l
i
n
e

c
o
m
m
i
t
m
e
n
t

i
s

e
s
t
a
b
l
i
s
h
e
d

U
n
b
l
i
n
k
i
n
g

r
e
v
i
e
w

o
f

r
i
s
k
s

a
n
d

i
s
s
u
e
s
S
t
a
t
u
s

M
a
n
a
g
e

p
r
o
j
e
c
t

t
h
r
o
u
g
h

e
a
c
h

p
h
a
s
e

g
a
t
e
s

E
s
t
a
b
l
i
s
h

T
r
i
p
l
e

c
o
n
s
t
r
a
i
n
t

t
a
r
g
e
t
s

E
n
s
u
r
e

t
h
a
t

r
e
s
o
u
r
c
e
s

t
o

s
u
p
p
o
r
t

p
h
a
s
e

a
c
t
i
v
i
t
y

a
r
e

i
n

p
l
a
c
e

L
o
o
k

A
h
e
a
d

A
v
o
i
d

p
o
t
e
n
t
i
a
l

p
o
t
h
o
l
e
s

D
e
f
i
n
e

l
a
u
n
c
h

c
a
d
e
n
c
e

f
o
r

s
t
e
a
d
y

s
t
a
t
e

b
u
s
i
n
e
s
s

E
s
t
a
b
l
i
s
h

b
a
s
e
l
i
n
e

s
c
h
e
d
u
l
e

t
a
r
g
e
t
s

E
s
t
a
b
l
i
s
h

r
e
a
s
o
n
a
b
l
e

P
r
o
j
e
c
t

K
/
O

d
a
t
e
s

(
b
a
c
k
w
a
r
d

p
a
s
s
)
F
r
e
q
u
e
n
c
y
R
o
a
d
m
a
p
K
e
y

D
a
t
e
s
K
i
c
k
-
o
f
f
C
h
e
c
k

P
o
i
n
t
s
P
M
T

a
n
d

P
r
o
j
.

M
a
n
a
g
e
r
P
M
T
P
M
T
R
e
p
o
r
t
e
d

a
t
K
e
y

R
e
p
o
r
t
O
w
n
e
r
P
M
T
O
f
f
e
r
i
n
g
M
a
n
a
g
e
r
P
r
o
j
e
c
t
M
a
n
a
g
e
r
I
n
v
e
s
t
m
e
n
t
R
e
v
i
e
w
B
o
a
r
d
I
n
v
e
s
t
m
e
n
t
R
e
v
i
e
w
B
o
a
r
d
O
n
c
e

p
e
r

m
o
n
t
h
O
n
c
e

p
e
r

m
o
n
t
h
T
w
i
c
e

p
e
r

m
o
n
t
h
T
w
i
c
e

p
e
r

m
o
n
t
h
S
t
e
p

1
S
t
e
p

2
S
t
e
p

3
S
t
e
p

4
P
r
i
o
r
i
t
i
z
e
d
P
o
r
t
f
o
l
i
o
P
r
o
j
e
c
t
M
a
n
a
g
e
r
O
f
f
e
r
i
n
g

R
e
v
i
e
w
W
e
e
k
l
y
P
o
s
t

P
l
a
n

A
l
i
g
n

p
r
o
j
e
c
t
s

t
o

B
u
s
i
n
e
s
s

O
b
j
e
c
t
i
v
e
s

P
r
i
o
r
i
t
i
z
e

p
r
o
j
e
c
t
s

I
d
e
n
t
i
f
y

c
o
r
e

c
a
p
a
b
i
l
i
t
y

&

r
e
s
o
u
r
c
e
s

c
o
n
s
t
r
a
i
n
t
s
P
M
T
P
o
r
t
f
o
l
i
o

M
a
n
a
g
e
m
e
n
t

T
e
a
m
O
n
c
e

p
e
r

m
o
n
t
h

Leave the Kick-off Station on Time 33
Here’s another technique to quickly perform a backward
pass to calculate the kickoff date. Suppose a new product is
added to the roadmap with a target launch of June 2010.
From analogy (experience), you know the general cycle
times for the various stages of development for this type of
product. At a high level, you can create reverse flow WBS:
Figure 3: "Backward Pass" Planning
Duration
(days) Start Finish
Kickoff 0 3/16/2009 3/16/2009
Concept 28 3/16/2009 4/23/2009
Develop 80 4/23/2009 8/13/2009
Execute 200 8/13/2009 5/20/2010
Finish 30 5/20/2010 6/30/2010


Just hardcode the targeted finish date and then input
duration assumptions for each phase of your project
schedule. In a scheduling tool such as Microsoft Project
®
,
define the task relationships as “SF” which means “Start to
Finish.” Usually we finish one task and than start the next,
but in this exercise we are going to reverse the flow so that
the tool can automatically calculate the kickoff date.

Summary
Don’t expend a great deal of effort on this initial planning
exercise. If the PMT is functioning properly, most projects
won’t see the light of day. Why invest significant resources
planning projects destined for the trash bin?

34 PLAN YOUR TRIP
2.3 Confirm the Trip With Your
Customer

If your project doesn’t satisfy a real customer need or
resolve a pain point, then it will be difficult to sell. But how
do we know if a brilliant idea has market potential? Ask the
customer – preferably before you make a significant
investment. It is in your best interests to put on your
listening ears when you talk to people who
are going to use your product or service. This
doesn’t mean that you will always do what
they want. It simply means that you are
interested in their opinions.

It is, admittedly, extremely difficult to satisfy some
customers. They may not really know what they want, but
they still have important things to say. They may, for
instance, be able to communicate what they don’t want –
and that is very useful information.

Ultimately, the customer determines the success of your
project by voting in the marketplace with his dollars. Thus,
your team can achieve all its internal project metrics for
scope, time, cost and quality, but the project can still be a
market loser if it doesn’t satisfy real customer needs.

If you are always listening to the customer, how will you
ever be able to finalize scope and finish the project? Good
question. For practical purposes, you will need to stop
negotiating and kick-off the project at some point. Define
that checkpoint date and the station stops along the tracks
where you can tweak requirements slightly along the way.

Confirm the Trip With Your Customer 35
Remember to protect your baseline position with a strong
change control process. Any midstream changes to project
scope should be managed through the change control
process so that their impact can be fully assessed.

F P Z CAN YOU SEE T H I S
A good way to solicit customer input is to invite several
customers to an advisory council where you record
customer’s initial impressions before you make a critical
decision on the project scope. Pragmatic customers
appreciate that products evolve, and they will take great
pride in influencing the evolutionary path of your product.
A Customer Advisory Council need not be an expensive
event. If you can’t afford to host the conference at the plush
Pinehurst golf resort in North Carolina, then you could plan
a more modest event or you could just call a few of your
most valuable customers and ask them for their opinion.

At the council meeting, imagine that you’re sitting your
customers down in an optician’s chair while fitting them
for a pair of prescription glasses. Flip figurative lenses with
different refraction properties while asking, “Which option
is more clear: A or B? … C or D? … E or F?” In a similar
way, frame your project options. “We’re considering two
different tracks we might go down: A or B. Which would
you choose?” In this way, you will be confirming whether
or not the customer wants to make the trip with you.

Don’t Let Development Drive
Some technology companies let the development
organization define the product roadmap. This is risky.
Tech heads tend to assume that everyone wants the latest
crank of the technology handle. They reason, “Who
wouldn’t want a faster processor, more memory and a
larger hard drive?”
36 PLAN YOUR TRIP

Speeds-and-feeds are not always the top purchasing criteria
for a product. For example, only a small percentage of
computer users stress the capacity of the processor chip.
How many gigahertz do you really need to manage your
email and create spreadsheets? Only niche high-end
applications and games require cutting-edge processors and
graphics. So another bump in processor speed won’t
motivate most people to make a mad dash to upgrade their
computer. For these reasons, I’ve seen design and usability
gaining greater weight in the purchase criteria for both
computers and software. Before you commit to your project
plan, you could ask targeted users, “Which would you
prefer, a faster processor or an EZ button that performs
some specific task?”

Customer Persona
One way to better understand your customer is to create a
customer persona. This is a composite profile for an
average customer. You don’t need reams of market
intelligence to do this exercise. Just ask your team to
describe the average customer in personal terms.

Customer persona:
· Name Janet Greene. CIO, Banking Inc.
· Segment Traditional Info Technology
· Manages 42 people in data center
· Education MS Comp Science
· Children 2
· Car Mercedes sedan

Janet’s Top Headaches:
1. Shrinking IT budget
2. Explosive data growth.
3. Compliance to government security regulations.

Confirm the Trip With Your Customer 37
Now you can ask, “What would Janet want” every time you
debate a line item requirement, design decision or change
request. This persona helps you phrase project goals in
meaningful terms: “Let’s help Janet sleep soundly at night
and enjoy the weekends with her family without having to
worry about disruptive software maintenance patches and
crashes.” You want your team to identify with a person not
an abstract entity.

Emotion Beats Logic Every Time
Using this customer persona, we can broadly describe the
next killer product or application in any industry as a
“thing” that:
• saves Janet time
• saves Janet money
• makes Janet happy (triggers a positive emotional
response)

A standard requirement for just about any product should
be to elicit a positive emotional response since this would
build customer advocacy into product design. My daughter
Katie developed an immediate emotional attachment to her
iPod
®
when she touched the polished case and played with
the addictive selection click wheel. Ask her what chip is
running the software and she’d tell you, “Who cares?”

When it comes to purchase decisions, emotion beats logic
almost every time. Think of the last big purchase you made.
What was the criteria tipping point that motivated you to
open your wallet? Whatever it was, it probably fell in the
category of either design or ease-of-use.

38 PLAN YOUR TRIP
The “Oops” Test
Try to delight your customer by building the product to
withstand the “oops test.” This test has two key
components. First, the customer should be able to set up
and use the product without hurting himself and second, the
product should survive unintended abuse.

One of my project teams designed a notebook computer to
withstand the PC Magazine
11
bake, freeze and drop torture
test. We baked our notebook computer in an oven for two
hours to approximate the conditions of a car trunk on a
sweltering summer day. Then we chilled the system in a
freezer to simulate the average wait at a cabstand at O'Hare
Airport in February. Finally, we dropped the notebook from
a desktop. Would the system still power up after this
abuse?

A cup of coffee
shouldn’t destroy a
$2,000 system.
Taking our stress test further, we poured a cup of soda on
the keyboard. With two thousand dollars of electronics
underneath the $30
plastic keys, you would
think that a can of soda
wouldn’t destroy the
whole system.

Some people on my team argued that these tests were
extreme since people shouldn’t mistreat their computers.
That’s like saying it’s the customer’s fault if the computer
is attacked by a computer virus, since the customer should
have implemented a strong firewall, antivirus, proxy filters,
a virtual private network and intrusion detection. Yeah,
right … and we should all put on sunscreen before we leave
the house. Sometimes people don’t do what they should.
Why not protect them from themselves?

11
PC Magazine is published by Ziff Davis Publishing Holdings.
Confirm the Trip With Your Customer 39

How can you go wrong if you harden your designs?
Brainstorm how your customer might use the product
outside of the normal design parameters. You can collect
valuable insights by reviewing the defect reports for
predecessor products. Treat every service call from a
customer as an opportunity to improve the product; resist
the tendency to classify some calls as “no defect found.”
Every call represents a meaningful defect. Maybe the setup
instructions weren’t clear? Better yet, can you design your
product so that the customer doesn’t need any hard-copy
documentation at all? Follow the lead of the computer
game industry. Kids can open up and play video games
without ever looking at the manual!

Practical Application
• Wear your listening ears when you talk with customers.
Give your most valuable customers a direct link to your
development organization.
• Schedule a “day in the life” visit with your customer,
ideally prior to the formal development start of a
project. Watch them use products. Let them draft a wish
list of features. Attempt to make those wishes come
true.
• Run pilots early and often especially when you are
launching a new product category. Select pragmatic
customers for these pilots; ones that accept the
immaturity of the technology and are willing to work
with you to influence the direction of your project.
Assign human factors professionals to the pilots who
will observe and report back on the customer
experience.
• Use what you sell.
40 PLAN YOUR TRIP
• Understand the criteria behind editor’s choice awards.
Whether you agree with their assessment methods or
not, busy people are influenced by a third-party seal of
approval. Build their assessment criteria right into your
project objectives.
• Pick up requirements that your competitors gleaned
from their customers by browsing their websites
regularly.
• Design your product or service to illicit an emotional
reaction. Apply the real estate concept of curb appeal
which attempts to elicit an emotional response before
the client even opens the door to the home.
• Delight your customer by designing the product to
withstand real-world abuse.
Summary
Make certain that the customer wants to take a long journey
with you. Always frame decisions within the context of a
customer persona. “What would Janet want? How does this
impact Janet?”

Think about how real people will use and react to your
product. Your goal is to delight your customer with a
usable product or service that solves a business problem.
Since imperfect people will use your product, harden it to
withstand real world misuse. Your efforts will help build
long-term customer loyalty.

Construct Off-Ramps 41
2.4 Construct Off-Ramps

Agreeing on the off-ramp criteria for your project will
reduce the emotional turmoil associated with canceling a
project. Here are some sample kick-out criteria:
• Critical resource skills aren’t on board in two months.
• Your competitor announces more than 15% price
reduction on his product in the next quarter.
• Product cost cannot be reduced enough to achieve the
minimum 45% financial target for gross margins.
• The delivery date slips past October 1, 2010 (the
assumed window of market opportunity).
Agreeing on these criteria upfront reduces an executive’s
anxiety when he/she needs to cancel a troubled project.
These are discrete, measurable criteria. You might also
switch to an off-ramp if your project doesn’t possess
minimal acceptable levels of quality or if you are unable to
add key features to differentiate the product from the
competition.

Smart companies regularly reassess the project’s viability
and cancel projects when the offering fails to meet
expectations. The following Offering Definition template
for a hypothetical car project helps you keep track of key
requirements all through the project life cycle.
42 PLAN YOUR TRIP

Template 4: Offering Definition
What’s In What’s Out
• Fuel Efficiency: 60
mpg using diesel
hybrid engine
• Fuel Efficiency: New
low cost composite
materials for frame
• Ease of Use: Apple
Click Wheel
integrated in steering
wheel
• Ease of Use: Folding
window tray on window
to hold fast food orders
• Safety: Diver,
passenger and side
curtain air bags
• Safety: Mandatory
breathalyzer test before
engine starts (deemed
unconstitutional)

Some teams drop a requirement from the list if the delivery
team cannot execute it. That’s a mistake! Instead, maintain
an untainted record of customer requirements by listing
those requirements in the What’s Out portion of this sample
template. This provides you a measure of protection from
executive amnesia. Nobody can say later, “I didn’t know
you dropped that!”

Practical Application
• Poll your sponsor and executive team to describe
expectations for the project scope.
Construct Off-Ramps 43
• Never drop a requirement from your offering definition
chart unless the customer validates the decision. If the
delivery team can’t execute the requirement, then strike
it through or move it to the What’s Out list. Keep a
written record of the requirement even if you are not
going to satisfy it.
• Highlight critical anchor requirements. If those anchors
can’t be delivered then switch the train to a spur siding.
Reach a consensus with key stakeholders about these
off-ramp criteria before the project train leaves the
boarding station.
• Never rush a project to market ahead of its time.
Customers eventually forget if you are a few months
late to market. They will never forget if the product is
shipped with poor quality.
Summary
Adroit teams define the kick-out criteria to switch a
troubled project to an off ramp. Define that criteria at the
start of the project.

Never lose track of requirements that are dropped. Instead,
list them in the What’s Out column of the Offering
Definition table. Review this column of the chart at each
phase gate decision checkpoint station.
44 PLAN YOUR TRIP
2.5 Charter the Project

The project charter is the key document that authorizes the
project to leave the station. The charter defines project
parameters – scope, time, cost and quality – in broad
strokes. Smart project leaders also recognize that you can
use the charter to define the civil liberties of the team.

Let’s take a lesson from a historic event in 1215 C.E. In
that year, King John published the Magna Carta (Great
Charter). One can only imagine what prompted the people
to draft this law:
No constable or other bailiff of ours shall
take corn or other provisions from anyone
without immediately tendering money
therefore, unless he can have postponement
thereof by permission of the seller.

It seems obvious from this passage that the
king’s men were violating the civil liberties of the common
folk! After enough commoners got angry, they banned
together in protest and forced the king to recognize their
rights. When King John met with the rebel barons at
Runnymede on June 15, 1215, to negotiate the details of
this charter, the rebels strategically appeared at full military
strength. Don’t think that King John relinquished his
privileges willingly!

A modern-day example of violating employee rights is
when business executives direct a team to deliver a project
without providing the team with the funding, tools and
support they need to be successful. In effect, they are taking
the corn without tendering money or provisions.

Charter the Project 45
This charter illustrates subtle tricks you can use to protect
the civil liberties of your project teams.

Template 5: Project Charter

Value Proposition
If your marketing representative can’t describe the
project’s value in a 60 second elevator ride [in this
space], then do not accept the assignment.

[Business Area] strategic priorities
• Improve market share in emerging countries like
India and China
• Establish five marquis beachhead references in
five target market segments
• Develop Business Partner channel distribution

[Project x] priorities
• Deliver X on Y date for Z money
• Deliver compelling plate of features/functions on
schedule
• Win customer mindshare by achieving world
class quality and ease-of-use
• Run pilots to solicit customer feedback

Unique Project Guidelines
• Apply Agile Development principles
• Utilize web-based project collaboration tools to
report status
• Resist pressing the “Reply to All” button in
email
46 PLAN YOUR TRIP
Here are important elements of the charter:
1. Value proposition: At the top of this charter, sketch
the value proposition of your product or service to the
customer. Give your marketing manager this
challenge: “During an elevator ride of 60 seconds or
less, tell me why a customer should consider
purchasing this product.” If the response is neither
crisp nor compelling, then reject the proposal.
2. Strategic imperatives: Considers how the project
supports business strategies. Shun sandbox projects
with no direct linkage to strategy, as these orphan
projects typically lack executive support.
3. Project priorities: Ask your executive team to tell
you which parameter of the project scope, time or
cost is most important. Knowing your priorities
upfront can greatly reduce the time you debate change
requests later. You may be forced, for instance, to
delay some secondary scope items in order to
maintain the schedule.
4. Project guidelines: Use this section of the charter to
outline your own personal guidelines for the project.

Although not shown on this sample template, the charter
should also identify the key members of the crew. If you
kickoff a project without the people needed to do the work,
then you’ve mortgaged the schedule. Record every To Be
Hired resource on your risk plan. Jot down the required
resolution date and say, “Either the resource is on board
and productive by this date or the task/deliverable will
slip.” This puts pressure on your executive team to resolve
any open resource issues.

One key feature of this charter is that it fits comfortably on
a single slide. For comparison, the Pacific Railroad Act of
1862 commissioned the construction of a railroad and
telegraph line from the Missouri river to the Pacific Ocean,
Charter the Project 47
one of the most complex projects in history, in just 20
paragraphs of prose; the entire document fit comfortably on
just 12 pages. If the verbose US government could draft a
succinct charter for that massive project, then you can
certainly charter your project with even fewer words. Try to
fit it on a single page.

Practical Application
• If the value proposition is not well defined, reject the
proposal. Take your stand for both the customer and
your team. Give executives your honest assessment if
the project is a loser.
12

• Do not assume that everyone knows and agrees with the
strategic imperatives. Can you recite the top three
strategic imperatives for your business right now?
• Make sure that scope, time and cost (funding) is
explicitly documented on the charter.
• Keep the number of top priorities in each section low,
between three and five. Too many priorities will
confuse the team.
• Ask your team to suggest other project priorities and
guidelines (sometimes the people closest to the project
really do know best).
• Execute the project to the best of your ability, even if
you don’t agree with the executive direction to proceed.
Do not whine. Your team will not respect you.


12
Definition of Loser: Project with low probability of meeting the
customer/sponsor expectations … or anyone who bets at a casino in
Vegas.
48 PLAN YOUR TRIP
Summary
Use the charter document to protect the team and to cancel
misguided projects before they kick off. You may well find
that the creation of a useful charter will stimulate
conversations and debates that are more vital than the
document itself!

Once projects leave the boarding station and reach cruising
speed, they are difficult to stop. So make sure your project
charter points the team in the right general direction.

Scrap the Process Checklist 49
2.6 Scrap the Process Checklist

We’ve spent some time planning our trip. But we haven’t
yet mentioned the process we will use to deliver our
project. Give careful attention to process scope when you
plan your journey since process compliance consumes
valuable resources. If your organization is hampered by
layers of bureaucracy, you will find yourself taking detours
that consume precious time and money. You want to avoid
any unnecessary side trips.

A careful review of your process checklists may uncover
some unnecessary tasks and deliverables that add no value
to your business. Scrap those checklist items and let your
process auditors know that you intend to cruise right
through them without stopping.

Checklists never
shrink without a
fight.
This recommendation may seem to run counter to project
management methodology, which attempts to outline a
definable, repeatable process to deliver projects. Don’t
checklists help us achieve that goal? Sure they do, but they
also tend to take on a life of their own. It is the nature of
checklists to grow out of control unless someone
periodically trims them down. It is in your best interest to
resist adding any new item to
the process checklist,
because once a new task or
process is added, it is
extremely difficult for it to be
removed at a later date.

Test yourself: Does every item on your current checklist
still serve a useful purpose? Consider this example:
Suppose a product launches with poor quality. The natural
50 PLAN YOUR TRIP
response (from management) is to add a checklist item
called “Review Defects with Smart Executives.” The
implicit assumption is that executives can catch problems
that the project team cannot. Once this new step is
approved by executive congress, you are condemned to
review defects with 14 layers of middle management in
perpetuity! Over time this silly review step becomes
institutionalized.

In the case just cited, the underlying issue is with the test
process; it is a leaky sieve where defects are escaping
unnoticed through the test harness. Rather than add another
set of reviews, why not work to fix the core problem
instead? Rewrite the test suite to catch the bugs. Then you
no longer need the checklist item. If your executives feel
uneasy without their extra review security blanket, then try
to negotiate new terms for the checklist deliverable.
Perhaps they will let you broadcast the final test exit report
showing defects classified by severity in lieu of formal
reviews.

Don’t shine the Back of Your Shoes
Why aren’t we as quick to remove a checklist item as we
are to add a new one? The lazy project manager completes
the checklist item thinking that it is simpler to do the task
than to accept a ding on an audit or to trudge through the
gauntlet required to seek an exception. Heraclites wrote,
“To do the same thing over and over again is not only
boredom: it is to be controlled by, rather than to control,
what you do.”

Now before you charge down the hill to eliminate checklist
items, I should warn you about a group of employees that
will put formidable defensive bulwarks in your path. They
are called internal auditors. Many auditors are crusty old
project managers who created the checklist items in the
Scrap the Process Checklist 51
first place. They may threaten that if you don’t complete
every item on the checklist, you’ll be slapped with an
unsatisfactory result on your audit. Whoa … are you
scared?

Auditors in my organization remind
me of Barney Fief, the deputy sheriff
in fictional Mayberry, North
Carolina. He screams, “Citizen’s
Arrest! Citizen’s Arrest!” when he
sees the smallest violation of the law.
Barney was a laughingstock because
of his overzealous arrests. Similarly,
my auditors tend to focus on minor infractions, ones that
are easy to observe. While they diligently root for an
incomplete checklist item or a missed process step, they
forget to ask more meaningful questions – like “Is your
project going to make money?” or “Show me how you
reflect customer feedback in your product design.” In short,
auditors often fail to ask teams to demonstrate genuine
measures of project success.

In one episode of Mayberry RFD, Barney prepares Gomer
to be deputy while Sheriff Taylor goes on vacation. Barney
runs a tight ship. He reminds Gomer that it is critical to
shine the backs of his shoes. “Why?” Gomer asks.
“Because it’s the last thing people see!” This answer
demonstrated Barney’s intense focus on the mundane and
irrelevant. Don’t ever let an auditor convince you to shine
the back of your shoes.

52 PLAN YOUR TRIP
Nip It In The Bud
Can you articulate the value for each item on your process
checklist? Was an item added because somebody once fell
into a mud puddle? Has that mud puddle evaporated? If so,
remove the item from the checklist.
• Carefully review your checklist. As Barney Fief would
say: “You’ve got to nip it … nip it in the bud!” Scrap
the items that no longer add value to the business.
• In some cases, you will be forced to complete a
task/deliverable that adds no value to the business. If
you are directed down that path, then find a way to do it
faster. Cross it off the list quickly and move on.
• Join forces with other project managers and flex your
collective muscles. Meet and discuss the checklist and
then recommend updates as a group.
• Seek process exceptions to ignore low value
tasks/deliverables with your audit team. If enough
people resist performing valueless tasks, you can
change the process.

If you are directed to complete a task or deliverable that
you consider to be of low value to the business, you may
decide to retain the risk by ignoring the task. If caught, you
could say, “I’m sorry, I forgot it. It won’t happen again.”
Legal disclaimer: Never ignore government compliance or
valid business control safeguards.

Scrap the Process Checklist 53
Practical Application
• Don’t mindlessly complete every deliverable on the
checklist. Streamline your processes today.
• Seek exceptions when the task or deliverable adds no
tangible value. Never convince yourself that it isn’t
worth the effort to seek an exception or you will
condemn future teams to working in the same salt mine.
• Build a project management toolkit of templates to
automate the production of checklist deliverables that
are still required. Carry your toolkit with you to every
new job.
• Don’t grumble about useless checklist items with your
team; they can’t fix the problem. Address useless
checklist items with the process owner and auditors.

Summary
Critically purge your checklist before you dutifully
complete each deliverable. Dismantling bureaucracy will
lower delivery costs. Eliminate unnecessary
tasks/deliverables. Ignore low risk items. Travel light.

3 LAY THE TRACKS







3
LAY THE TRACKS


Key Topics Covered In This Section:
• How to estimate project cost accurately.
• What are the advantages/disadvantages of
using duration based vs. resourced
constrained scheduling?
• How project scale factors impact
productivity.

Document Project Scope 55
3.1 Document Project Scope

How much will it cost to deliver your project? Before we
can answer that important question, we must first decide
what needs to be done. How far is your train going to
travel? How many freight cars of scope will it carry? How
often will process auditors board to inspect your train?
What checklist documents do they expect you to furnish
before they let you proceed?

Project scope includes everything, both product and process
requirements, that require resources to deliver. There is a
host of oft-neglected project deliverables that must be
completed prior to the project pulling into its final
destination. If your product crosses country borders, for
example, the cost of import/export controls could be
significant.

Most cost estimate errors are sins of omission where we
forget to include the most obvious requirements in our
definition of scope. To illustrate: How many people ask the
car dealer to show them the windshield wipers on the car?
Wipers are an obvious “meets min” product requirement
since every car needs them. If you are on the project team
chartered to deliver a new automobile and you forget to
include wipers in your plan, then your cost estimate will be
understated. Of course, your car would never leave the
assembly line without wipers, this oversight will be caught
and remedied somewhere during execution, but the cost
estimation error will have harmed your profit estimates. In
short, we want to create a comprehensive plan so we aren’t
forced to take corrective emergency action during project
delivery.

56 LAY THE TRACKS
Practical Application
• Project cost estimation errors are usually sins of
omission. Use a memory jogger checklist to make sure
you include all relevant items in your committed project
scope document.
• Consider both product and process items when you
detail project scope. For example, the overhead
associated with project management and audit
compliance is often forgotten in the estimate, yet these
things represent a significant amount of effort and
expense.
• Don’t forget “meets minimum” customer requirements
and mandatory deliverables prescribed by government
regulations. Efforts to meet export and product safety
compliance, for example, can be considerable.

Summary
Make sure that your assessment of project scope is
comprehensive. This will help you calculate the real project
cost before the project leaves the station.

Estimate Project Cost (Model Overview) 57
3.2 Estimate Project Cost (Model
Overview)

Estimating the cost to deliver the project is, perhaps, the
trickiest part of project planning. We get it wrong far more
often than we get it right. How else can you explain why so
many projects run over budget?

In this chapter, I’m going to introduce a model that can
dramatically improve the accuracy of your cost estimate. At
a high level, the model splits the project manager’s brain
right down the center:
Figure 4: Cost Estimation Process – Overview
Left Brain Activity Right Brain Activity
O Collect requirements
O Prioritize requirements
O Confirm core
capabilities and size
requirements
O Construct WBS &
schedule
O Prepare cost estimate

The left hemisphere of our conductor’s brain collects and
prioritizes line item requirements. The right side of his
brain then intuits the core capability of the organization to
deliver each requirement. Notice that the first three steps
are completed before we even begin constructing a fancy
network schedule or a detailed cost estimate.

This model attempts to leverage the unique abilities of our
brain. The activities performed in each side of the brain
58 LAY THE TRACKS
map well to the preferences between left and right brain
thinking:

Left Brain Preferences Right Brain Preferences
Thrives on order Registers novelty
Objective Subjective
Analytical Intuitive
Sequential Holistic

The objective left side of the brain organizes a tidy list of
raw requirements. The subjective right brain tells us
whether we can or can’t do each item based on past
experience, resource capacity and skills. Confirming core
capability is more art than science and the right brain is
better suited for this type of activity.

Never Drop a Requirement
The two hemispheres of the human brain are neatly
separated down the middle by a solid line called the corpus
callous,
13
a Latin phrase that means “hard and thick bundle
of nerves.” This solid vertical line keeps the process steps
cloistered. It reminds us to not pollute the requirements-
gathering process by listening to a delivery organization tell
us what can or can’t be done.

If you only ponder the requirements that the delivery
organization can commit, then the checkpoint decision to
proceed or cancel the project will be distorted. A balanced
checkpoint decision reveals the gap between pure customer
requirements and your organization’s ability to satisfy
them. The relevant decision is framed this way: “Can we
deliver enough requirements to close the deal with the
customer? And when we make that decision, do we have all
of the facts on the table including the requirements that we

13
For left brain-dominant readers, the real term is corpus callosum.
Estimate Project Cost (Model Overview) 59
cannot deliver?” If so, then the retained risk is transparent
and you’ve done your job.

Practical Application
• Structure the cost estimation model with a clear
separation between requirements-gathering and delivery
capability.
o Use the left brain to prioritize requirements. Record
the raw uncensored list of pure customer
requirements.
o Use the right brain to assess delivery capability and
to estimate the project schedule and cost.
• Keep the left and right brains separate until the
prioritized list of requirements is complete.
That is the high level view of the process. Now let’s
explore each of these process steps in greater detail.
60 LAY THE TRACKS
3.3 Collect and Prioritize Requirements

Customers are fickle. They change their minds, they hem
and haw over price, and they step away from the
negotiation table without cause. Satisfying customers
doesn’t necessarily mean that you have to give them
everything they want. It means giving them just enough
incentive to pull out their wallet to make the purchase.

In the first two steps of our model, we are going to explore
how we collect and prioritize customer requirements.

Left Brain Activity
O Collect requirements
O Prioritize requirements

You can’t accurately forecast project costs until you first
define the scope of work on your plate. In some
organizations, requirements are defined by the marketing
department as a surrogate for the customer. Since
marketing personalities aim to please, they may be inclined
to overstate project requirements.

We are going to resist that tendency by assigning quality
levels to each requirement (see the details of Step 1 in the
figure below).
Collect and Prioritize Requirements 61






F
i
g
u
r
e

5
:

C
o
s
t

E
s
t
i
m
a
t
i
n
g

M
o
d
e
l



D
e
t
a
i
l
e
d

V
i
e
w


O O O
P
r
i
o
r
i
t
i
z
e
R
e
q
u
i
r
e
m
e
n
t
s
S
i
z
e

R
e
q
u
i
r
e
m
e
n
t
s
C
u
s
t
o
m
e
r

R
e
q
u
i
r
e
m
e
n
t
s
P
r
i
o
r
i
t
i
z
e
d
L
i
s
t
R
e
v
i
e
w
R
e
q
u
i
r
e
m
e
n
t
s
D
e
t
e
r
m
i
n
e
Q
u
a
l
i
t
y

L
e
v
e
l
P
r
e
p
a
r
e

C
o
s
t

E
s
t
i
m
a
t
e
S
a
m
p
l
e

T
o
o
l
s
:

A
n
a
l
o
g
y

I
n
d
u
s
t
r
y

R
u
l
e
s

C
o
C
o
M
o

I
I

Q
S
M

S
L
I
M

C
u
s
t
o
m

S
a
m
p
l
e

T
o
o
l
s
:

R
a
n
k

&

W
e
i
g
h
t

D
e
c
i
s
i
o
n

S
u
p
p
o
r
t

S
y
s
t
e
m
s
C
o
r
e

C
a
p
a
b
i
l
i
t
y
A
s
s
e
s
s
m
e
n
t
R
e
v
i
e
w
P
&
L
Y
e
s
C
l
a
r
i
t
y
C
l
a
r
i
t
y
C
l
e
a
r

a
s

a

B
e
l
l
C
l
e
a
r

a
s

a

B
e
l
l

#

o
f

r
e
q
u
i
r
e
m
e
n
t
s

#

o
f

s
c
r
e
e
n
s

F
u
n
c
t
i
o
n

p
o
i
n
t
s


L
i
n
e
s

o
f

C
o
d
e
O
O
P
r
e
p
a
r
e

S
c
h
e
d
u
l
e

D
u
r
a
t
i
o
n

o
r

E
f
f
o
r
t

B
a
s
e
d

W
B
S
C
o
m
m
i
t
t
e
d

p
l
a
n
a
c
c
e
p
t
A
s
s
e
s
s
m
e
n
t
R
e
v
i
e
w
P
&
L
Y
e
s
a
c
c
e
p
t
O O O
P
r
i
o
r
i
t
i
z
e
R
e
q
u
i
r
e
m
e
n
t
s
S
i
z
e

R
e
q
u
i
r
e
m
e
n
t
s
C
u
s
t
o
m
e
r

R
e
q
u
i
r
e
m
e
n
t
s
P
r
i
o
r
i
t
i
z
e
d
L
i
s
t
R
e
v
i
e
w
R
e
q
u
i
r
e
m
e
n
t
s
D
e
t
e
r
m
i
n
e
Q
u
a
l
i
t
y

L
e
v
e
l
P
r
e
p
a
r
e

C
o
s
t

E
s
t
i
m
a
t
e
S
a
m
p
l
e

T
o
o
l
s
:

A
n
a
l
o
g
y

I
n
d
u
s
t
r
y

R
u
l
e
s

C
o
C
o
M
o

I
I

Q
S
M

S
L
I
M

C
u
s
t
o
m

S
a
m
p
l
e

T
o
o
l
s
:

R
a
n
k

&

W
e
i
g
h
t

D
e
c
i
s
i
o
n

S
u
p
p
o
r
t

S
y
s
t
e
m
s
C
o
r
e

C
a
p
a
b
i
l
i
t
y
C
l
a
r
i
t
y
C
l
a
r
i
t
y
C
l
e
a
r

a
s

a

B
e
l
l
C
l
e
a
r

a
s

a

B
e
l
l

#

o
f

r
e
q
u
i
r
e
m
e
n
t
s

#

o
f

s
c
r
e
e
n
s

F
u
n
c
t
i
o
n

p
o
i
n
t
s


L
i
n
e
s

o
f

C
o
d
e
O
O
P
r
e
p
a
r
e

S
c
h
e
d
u
l
e

D
u
r
a
t
i
o
n

o
r

E
f
f
o
r
t

B
a
s
e
d

W
B
S
C
o
m
m
i
t
t
e
d

p
l
a
n
62 LAY THE TRACKS
Step 1: Determine Quality Levels
Customers think in terms of “grades of quality,” such as
good/better/best. If we are building a house, for example,
the customer might say that he wants copper gutters. The
seasoned contractor
14
would confirm this unusual request
by parroting back, “You want copper gutters? They are
gorgeous. However, they cost $20 a foot for basic
installations. Do you want me to run them all the way
around the house or just in the front of the house, which is
visible from the street?” If you were that customer, you
would appreciate this conversation because the contractor
is giving you critical information to make potential quality
trade-off decisions.

Likewise, the cagey contractor tells his customer, “I know
that you asked for a slate roof, but I’ve seen a new
architectural asphalt shingle that looks a lot like slate, but
costs 50% less. Would you like me to show you a sample?”
Our contractor then asks, “Do you want it with a 20-year or
40-year warranty? Do you want an algae resistance
coating?” This seasoned contractor skillfully carves
requirements into quality grades. He gets answers to these
fundamental questions before he directs his subcontractors
to create detailed cost estimates.

There are several places in this model where we test for
“clarity.” Are requirements as clear as bell? True,
requirements can’t be defined perfectly at the front end of
this planning process, but that shouldn’t stop you from
asking these clarification questions.


14
The prime contractor on a home build is also a project manager since
he/she coordinates the activities of subcontractors from various
disciplines.
Collect and Prioritize Requirements 63
Step 2: Prioritize Requirements
In step 2 of our flow chart, we prioritize the requirements.
Immature organizations dump a load of unfiltered
requirements on delivery organizations by claiming that all
requirements are high priority. This is patently false.

Peter Marks, Managing Director of Design Insight, rails
against that notion that all requirements are high priority,
“Our experience is that 10% of the work in most companies
does not contribute enough value to justify the cost.” He
goes on to say, “The only effort that counts is one the
customer sees.”

Institute a new rule that requirements must be translated to
a useable level of clarity and prioritized before you hitch
new cars of scope to your project train. You might use a
process called Analytical Hierarchy Process (AHP)
15
to
facilitate this exercise. It is based on the premise that
consumers simplify the purchase decision by:
• Comparing only two purchase criteria at a time.
• Focusing on just a few of the many purchase attributes.
• Using simplification techniques like stereotypes to
justify the purchase decision.
• Letting their emotions sway the purchase decision.
Studies show that most consumers consider only eight to
ten total attributes when making a purchase. We can prove
these principles by playing this insightful game. Ask a
friend to cite his purchase criteria for a new car. I
guarantee that he will consider fewer than ten criteria.
Furthermore, he’ll be preoccupied with only one or two key
features. This exercise shows that the average person will
shell out big bucks for an expensive product based on a

15
AHP was developed in the 1970’s by Dr. Thomas Saaty.
64 LAY THE TRACKS
very short list of features. Challenge your friend to list
more requirements. You will be surprised by how quickly
he starts grasping at insignificant things – like cup holders.
It may sound odd, but a cheap one-dollar plastic cup holder
really does influence the purchase of a $30,000 car,
because it touches an emotional chord.

Model the Purchase Decision
Construct a logical hierarchy for your purchase decision
model. Limit your high-level purchase criteria to roughly
eight to ten buckets. Put up to eight children inside each of
these high-level parent buckets, For example, one high-
level purchase criterion for a car might be Ease of Use and
the children for that bucket could include power locks, GPS
navigation, cup holders, Bluetooth
®
cell phone
functionality, and integrated iPod
®
.

Once you define the purchase criteria buckets for your
product or service, ask your marketing department or
person to rank and weight the attributes. In the ideal
situation, she will sit with a sampling of your customers,
but if you are pressed for time or short on money, you can
sanction marketing to complete the exercise as a surrogate
for the customer.

You can use powerful software to do the heavy lifting in
this exercise. An application suited for this purpose can
quickly guide you through the various pairwise
comparisons and performs the math. You start by
comparing the parent buckets against each other, and then
you compare the children within each bucket. At the end of
the exercise, you get a report that looks like this:
Collect and Prioritize Requirements 65
Figure 6: Rank & Weight of Car Purchase Criteria
Weight
44%
20%
17%
8%
6%
4%
0% 10% 20% 30% 40% 50%
Gas mileage
Price
Ease of Use
Service costs
Design
Social acceptance


Notice that this process doesn’t just rank the buckets: it
weights them. This is the key to making trade-off decisions.
In the example above, if you were asked to add a new
higher cost material to the car that would dramatically
reduce vehicle weight and improve gas mileage, would you
do it? With only this table as your guide, you would answer
“yes,” since gas mileage trumps price by a large margin.

Automated software tools make it easy to extend this
process to a comparison of hundreds of features and
functions. Just remember that every feature you add to the
mix battles for a fixed piece of the total purchase decision.
Be careful that you don’t overwhelm your customer with
too many functions.
66 LAY THE TRACKS
Play the Zero-sum Game
I love to watch marketing reps prioritize requirements. It’s
all fun and games until they get to the end. Then their eyes
jump out of their head when they see a report that lists
some features on the bottom of the priority list. They
instinctively go back and rerun the tool to move the
features at the bottom of list to a higher rank because they
sense that things on the bottom might get dropped out of
the project. Naturally, as they move one item higher in the
queue other items fall lower. It takes the average marketing
person three or four runs to figure out that this is a zero-
sum game; something always ends up at the bottom of the
list. Put a two-way mirror in the room and you could sell
tickets to the event!

Summary
Don’t fight with marketing over the priority of
requirements. Frame a decision model and then let them
fight with themselves. Only permit marketing to pass a
collection of unprioritized requirements to the estimating
team if you possess unlimited resources.

The first half of our cost estimation model directs the
marketing department to clarify and prioritize
requirements. This involves defining acceptable quality
levels for each requirement. Each requirement is also
assigned a unique rank and weight. Now we are ready to
pass the bucket over to the right side of the brain to
estimate project schedule and delivery costs.


Confirm Core Delivery Capability 67
3.4 Confirm Core Delivery Capability

Once requirements are properly prioritized, open the corpus
callous pipe and pass them over to the right side of the
brain. It’s time for the delivery organization to answer the
not-to-simple question “Can we do it?” This is Step 3 in
our high level process.

Right Brain Activity

O Confirm core capabilities and size
requirements
O Construct WBS & schedule
O Prepare cost estimate

This is a natural right-brain activity because intuition
(expert judgment) plays a role in formulating the answer.
The best functional managers have a keen sense of their
organizational capabilities:
• They know whether their delivery capability is already
fully consumed.
• They know whether they have the necessary skills to
complete the project.
• They know whether they have, or can acquire, the
necessary capital and tools to complete the project.

Good functional managers feel in their gut whether or not
their organization can accommodate the new workload or
whether the team has the skills and motivation to deliver
the goods. Based on intuition alone, you may reject some
bids before anybody produces reams of resource pipeline
data analysis.
68 LAY THE TRACKS

If the delivery organization decides that the project is
within the scope of its core competency and that the
necessary resources are available to complete the task, then
– and only then – should you sanction a detailed sizing of
cost.

Step 3: Consider Your Core Capabilities
The construction industry has fairly well defined
procedures for estimating how much it costs to build a
house. Experienced contractors use analogous costing
techniques when they quote estimates such as $175 per
square foot to build a new home. In affect, they are saying
I’ve built similar homes in the past and I know within an
order of magnitude how much it costs. If the request is
fairly standard and you have experience with a similar type
of project, there is no need to perform a detailed cost
estimate. You can stop right here.

This estimating game gets more nebulous, however, when
we ask our contractor to build a custom home. When he
builds 100 of the same house plan, his estimates are
precise. When he builds a one-of-a-kind home, the estimate
variance widens. Suppose the homeowner demands the
following unique features:
• Copper Gutters
• Slate roof
• Biometric locks on outside doors

How would you estimate this project if you don’t have any
experience with these custom elements? Intuition doesn’t
help when you’ve never worked with a given material
before. Your team has no experience with the product or
technology. So you need to either subcontract the expertise
Confirm Core Delivery Capability 69
or retrain your own team. A valid third option is to walk
away from the bid if the first two alternatives don’t fit well
within your business strategy.

The core capability of your organization should grow over
time as you allocate time for learning and process
improvements. Some resource pipeline loading models
recommend that you only consume 85% of your resource
time on specified tasks and set aside the remaining 15% of
pipeline capability for functional improvement.

Shortsighted functions overload the pipeline at 120%.
16

Stressing the pipeline this way is a common mistake made
by short-sighted companies trying to squeeze maximum
value from salaried professionals. The mature organization,
on the other hand, trims down requirements to a level that
clears the calendar for learning activities such as attending
a class on a new technology.

Flexibility by Design
Ultimately, your team determines whether it can actually
deliver requirements. Team members move down the
prioritized list and identify their delivery threshold, making
decisions based on resource constraints for people,
expense, and capital. It is prudent to build in architectural
flexibility as you conduct this exercise. In our custom home
example, the contractor might tell the customer that he can
stub plumbing in the attic in case the customer wants to
install a bathroom later.

Another method of improving design flexibility is to divide
the bid into two parts: Core Functions and à la carte
secondary features. Promise to deliver the core function by
a specified date, but say that the secondary features require

16
Resource loading at 120% implies persistent 20% overtime.
70 LAY THE TRACKS
further technical assessment. This approach allows you to
refine your estimate in phases as knowledge is gained.

Size Requirements
The delivery organization will convert functional
requirements to technical requirements. What’s the
difference? Functional requirements are business needs
stated in general customer terms. Technical requirements
are the quality of service (QoS) level that the product must
fulfill. An example may make the distinction more clear:

Functional
Requirement
FR01 - The computer must be easy to
service.
Technical
Requirement
TR01- A woman with long fingernails
should be able to remove the hard drive
in under five minutes without tools.

Next we size each technical requirement. What are the
resource dependencies, and how long will it take to
complete each one? How much will it cost? The sizing may
be based on the number and complexity of features or on
artifacts such as the number of screens, lines of code or
function points.

Summary
In step number three of our cost estimation model, we
confirm our core capability and size the requirements. Now
we can build a detailed schedule. That is the last
preparatory step before we forecast the final cost.

Construct the WBS 71
3.5 Construct the WBS

To the uninformed, the “WBS” sounds like a TV channel.
The Work Breakdown Structure (WBS) is actually a
powerful method to help you structure the tasks and
activities (work) to deliver the project. It is a key to
constructing an accurate cost estimate, since it prompts you
to lay out everything that needs to be done to travel from
the boarding station to the final destination of your project.
We are now at Step 4 in our model.

Right Brain Activity

O Confirm core capabilities and size
requirements
O Construct WBS & schedule
O Prepare cost estimate

An easy way to create the WBS is to use Post-it notes to
describe the following attributes for each deliverable:
• Who is responsible?
• When will it complete?
• Are there any dependencies (predecessor tasks)?

In lieu of Post-it notes, you can fabricate the schedule
directly in a tool like Microsoft Project
®
while you display
the work in progress on a projector. I prefer this approach
since it saves you from having to transcribe the Post-it
notes back to your computer.

I suppose that there is never a good time to tell you this, so
let me just get this out of the way: the baseline WBS rarely
72 LAY THE TRACKS
holds true to form. The day you publish the WBS is the day
it becomes obsolete. Face it. Unexpected stuff happens.
Consequently, while you draft your WBS, put a standard
footer on every page “subject to change while you are
reading this.” This will remind your team to build
flexibility into the schedule. It will also remind you to not
become emotionally attached to your schedule.

Work Packages
Actual efforts are tracked against planned work packages
(deliverables at the lowest level of the WBS), so give
careful attention to these work packages and ensure that
each one has the following attributes:
• a short duration
• a scheduled start and finish date
• an assigned budget

Accepted methodology suggests that you carve up your
schedule into 24-hour or 48-hour work packages. This
would tell you when the schedule is moving off the track in
a timely manner. If your work packages were a month long,
then you might not know that you’ve hit an obstacle for
weeks. That’s the theory, at least! I recommend that you
carefully balance the cost of collecting information against
the benefits the data might afford. You could, for instance,
choose to carve your schedule into large work package
chunks if the project is low-risk or the impact of missing a
date is not too serious.

Are you finished yet?
After you commit your plan and the train leaves the station,
you start to monitor and control the project. We will
discuss this topic further in the chapter Project Reporting,
but for now, I will tell you that I personally track actual
Construct the WBS 73
times for each task as either a 0% or 100% complete. I just
ask, “Have you started or are you finished?” Yes or no
responses are recorded as either 0% or 100% complete.
You can track your projects at much finer levels of
granularity, but always make sure that the value of data
exceeds the cost for collecting the data.

Practical Application
• Engage your whole team when you build the WBS so
that everyone can see where they fit in to the big
picture.
• Keep the WBS at the highest tracking level that still
maintains project control.
• Be forewarned: the greater the number of tasks in your
schedule, the more likely team members will report
spurious actual times. They’ll enter anything just to get
you off their backs.

Summary
The WBS helps you create a logical schedule. It tells you
what needs to be done and who will do it. Engage your
entire team to create the WBS. This lets them see where
they fit into things (predecessor and successor
relationships) and encourages cross-functional teaming.
74 LAY THE TRACKS
3.6 Plot the Schedule

It’s time to arrange the collection of work packages into a
network schedule to forecast the arrival date at the final
destination. There are two choices for forecasting the
delivery date: duration-based or resource constrained.

Duration-Based Estimating
If you are managing a simple project, the duration-based
schedule may satisfy your needs. It is very simple to
construct. Just list the tasks and how long (duration) it will
take a resource to complete it. You can keep this schedule
at a very high level. For example, when my wife asks me to
“get a gallon of milk,” she assumes that I can figure out the
steps to get there. Her succinct WBS would look like this:

Task Duration Start Finish Resource
Get
Milk
15 mins Wed
1/11/06
Wed
1/11/06
John
Langlois
You could add fine layers of unnecessary precision to this
WBS by preparing MapQuest
®
directions for the same
project:
Plot the Schedule 75

Total Estimated Time to Get Milk: 5 minutes
Directions Distance

1: Start out going SOUTH on TALL OAKS
<0.1 miles

2: Turn LEFT onto FORTUNES RIDGE DR.
0.5 miles

3: Turn LEFT onto WOODCROFT PKWY.
<0.1 miles

4: Turn RIGHT onto FAYETTEVILLE RD.
0.9 miles

6: End at Circle K Stores Inc.

1.6 miles total
START
END

This level of documentation is not justified for this simple
exercise. Why torque your team with this level of mind-
numbing WBS details? Challenge them to find the most
efficient path to secure the deliverable.

If you can’t trust a team member to “get milk” without
detailed directions, then work with his/her functional
manager to develop his skill. If the team member still
requires hand holding after a sufficient amount of training,
then lobby for a replacement with a brain.

Resource Constrained Schedules
With resource constrained schedules, you define the effort
required to complete the task (typically in hours) and then
let a scheduling tool calculate the end date based upon
resource availability.
76 LAY THE TRACKS
Here are a few instances where effort based scheduling
may be in order:
• A government contract mandates earned value
reporting.
• Resource constrained schedules work well in stable
environments where processes are well defined and
there are few post-commitment updates to the baseline
schedule.
• Systems exist to claim labor against project tasks. If the
labor-claiming system is accurate, then you can data-
mine very useful information from this level of
reporting.

The Leveling Illusion
Resource constrained scheduling provides a platform to
resolve resource allocations. Just don’t become overly
enamored of these techniques, since they may lead you into
a dark tunnel! Microsoft Project
®
, for instance, gives you a
number of ways to get lost when you level resources:
• You can adjust the resources assigned to the task by:
o Changing the resource’s availability
o Assigning more resources to the task
o Replacing an over-allocated resource with an under-
allocated one
o Removing the over-allocated resource from another
assignment
o Contouring the amount of work assigned to the
resource

Plot the Schedule 77
• You can reduce a task’s duration, delay the task, or split
the task.
o If a resource is over-allocated, the tool can search
for the tasks that are causing the over-allocation and
prompt you to delay those tasks.
o Tip: If you set a priority of 1000, Microsoft
Project
®
will invoke a hard constraint of “Do Not
Level.” This keeps the program from delaying or
splitting the task when leveling.
• You can change overtime assumptions. Unfortunately,
this alternative can be easily abused. It is easy to play
with overtime in a tool, but if you mandate persistent
overtime with real people, productivity will fall. Long
term, this is never the optimal solution.

Tip: Save your file before you press a resource leveling
key, or you will never find your way back to the last
station.

My problem with all of these resource leveling features is
that they present far too many possibilities. You could
spend endless hours playing the leveling game. I
recommend instead that you perform the leveling exercise
in broad strokes and accept that you will never get it
exactly right.

People Aren’t tools
Another problem with these leveling features is that they
present an illusion that resources are interchangeable. The
truth is employees demonstrate different levels of skill and
real work often requires an incalculable blend of art and
science. For these reasons, Sally may be able to complete
the same task in half the time as Tom. Let’s just say that
she is more intelligent or clever than Tom. We could try to
78 LAY THE TRACKS
adjust Tom’s skill level assumption to compensate (say by
changing Tom’s availability to 50%), but this nurtures the
fantasy that we can convert everything into a mathematical
formula.

Can any human accurately judge the skill and talents of
another person on any given day? Skill levels are too
dynamic to tag with a fixed ratio. On any given day, a
headache or a medical condition could influence the
performance of your top employee.

It is extremely important to recognize that a tool can’t
expose the underlying conditions that affect human
productivity. Don’t become overly enamored with a
sophisticated tool. Remember to talk to people directly
when you need a true sense of their productivity at a critical
moment in the project. Ask, “How are things progressing
on this deliverable?” The inflection in a person’s voice will
often tell you if he is confident in meeting the commitment
or if something is worrying him.

Automate Data Collection
Whether you choose duration-based or resource constrained
scheduling, try to automate data collection for task
reporting and labor claiming. Make it painless for your
team to report progress, or your system will fail.

My company once created a tool that allowed me to upload
my schedule to a server. An automated agent then notified
each person when they had a task on deck. It was like
commissioning a “Mini-Me” to collect everyone’s status.
The fatal flaw in this system was that it offered a
preference option for how often the agent would run. I
concluded that daily updates would be better than weekly
reminders. My one-thousand-task WBS pumped out mail
reminders faster than the post office at Christmas. Soon
Plot the Schedule 79
people started ignoring them. Eventually I turned off the
agent after the team threatened to throw me off the train.
The lesson: Pilot the collection tool with a trusted team
member and listen to the feedback before implementing it
with a wider audience. My team never forgot their bad
experience with this tool and they were thus conditioned to
resist my later efforts to roll out a new task status collection
tool.

Practical Application
• Choose your scheduling approach: duration-based or
effort-based.
o Duration-based schedules are adequate to sketch
simple deliverables.
o Effort-based schedules enable sophisticated
resource analysis.
• Anticipate changes to the schedule and build in
flexibility. Don’t let a sophisticated WBS chart seduce
you into thinking that your project will execute
according to plan. It won’t.
• Don’t develop an unhealthy emotional attachment to
your WBS. If you need to update it down the line and
print out another wall size copy of the schedule, then do
so.
• Automate data collection. Pilot the collection
process/tool before you roll it out to the full team.
• Recognize that a schedule forecast is still a random
variable. No matter how good your schedule looks on
paper, “The best-laid plans of mice and men often go
awry.”
17


17
Adapted from a line in “To A Mouse” by Robert Burns.
80 LAY THE TRACKS
Summary
Be nice to your team. Choose duration-based scheduling
when it is appropriate (if your project is simple and
contains only a few routine tasks). Choose resource
constrained scheduling when you need finer level of
tracking and control. In either case, build a schedule that
you can track against, and automate the data collection
process.

Play the Percentages 81
3.7 Play the Percentages

Let’s take a break and sit for a spell to discuss how the
principles of gambling can help us create better schedule
estimates.

Are You a Wise Guy?
“I lost $35,000 in
less than a week at
the Mirage in Las
Vegas.”
– Dennis Rodman
It is a little-known fact that casino operators are called
“wise guys” not because they carry heat, but because of
their mathematical prowess –
they are shrewd statisticians.
From the casino point of
view, gambling isn’t about
luck. It is about averages;
and the house always plays
on the safe side of statistics.

Veteran project managers also appreciate and leverage the
power of statistics. For example, the wise-guy project
manager will quantify schedule risks by presenting a range
of schedule estimates to management. Unfortunately, many
project managers behave like naïve gamblers at a card table
when they present their schedule to senior management.
The inexperienced project manager often makes the classic
mistake of communicating a single point estimate for the
final delivery date. He commits to delivering the project on,
say, January 1, 2010, without any discussion of the
probability of hitting that date. A more prudent approach is
to present a range of estimates with each date pegged by a
probability of occurrence:

82 LAY THE TRACKS
Date Probability
01/01/2010 50%
01/15/2010 75%
01/31/2010 95%

By providing a range of estimates in this way, we openly
acknowledge the risk associated with a committed date.
Since these statistical simulations can turn into an
unproductive marathon of endless cases and theory, let’s
consider three ways we can dramatically reduce the costs of
collecting the data necessary to run useful cases.
1. Publish the rules of the game to ensure that
fundamental assumptions are consistent across
everyone who provides schedule input.
2. Estimate the worst-case forecast for only the high-risk
tasks.
3. Use Monte Carlo
18
software to calculate the
probabilities of occurrence for a range of final
delivery dates.

Publish the rules of the table
Begin by clearly communicating your scheduling
assumptions with everyone who provides estimates. Do this
before people start creating their schedules. Tell your team
to enter the expected or most likely duration for each task in
their baseline schedule. Explain to them that this means that
there is a fifty-percent chance that the actual date will fall
on either side of the estimate. Likewise, establish common
assumptions for things like the number of hours worked per
week/month. If you don’t define guidelines for these basic
assumptions, then every person will give an estimate based
on his or her own risk tolerance and work schedule.


18
Monte Carlo simulations treat the schedule exercise as a game of
chance by analyzing the impact on dates from randomly generated
values for uncertain variables.
Play the Percentages 83
The end date calculated for your project will have a 50%
probability of completion. That is the design goal of this
exercise, yet very few executives would approve the
schedule if they really knew that it had a 50% chance of
being late. This is why you should produce a range of date
estimates and allow your executives to pick one based on
their risk tolerance. For example, you might pick three
points on the completion probability table with 50%, 75%,
and 95% likelihood of occurrence.

Just Give Me the Bad News
After you agree on a common set of assumptions, tell your
team to ask themselves this basic question for every task
they define: What can go wrong? Does the task have
significant potential to slip? If so, will it impact the end
date of the schedule? For these high-risk tasks, ask the
estimator to note the worst-case estimate along with the
most likely estimate.

Let’s use Microsoft Project
®
, a fairly ubiquitous scheduling
application, to demonstrate how we can automate the
collection of this critical data. Right click on the task and
enter “W=x days” in the Notes tab of the pop-up screen. In
the task note shown below, our estimator has assumed that
the worse case duration is 100 days. Remind all estimators
to use the same “W=x days” nomenclature so that you can
easily sort on the Notes field later.
84 LAY THE TRACKS
Figure 7: Entering Worst Case estimate in MS Project
This notation tells you that
the worse case duration is
100 days.
This notation tells you that
the worse case duration is
100 days.


You may have noticed that I didn’t ask the schedulers to
specify the best-case estimates for any tasks. Nor did I ask
for worst-case estimates for every task. There are three
reasons that I deliberately bias my schedules:

1. I’ve never seen the best-case estimates materialize
during my tenure as a project manager. In my world,
negative risks tend to outweigh positive risks 10 to one.
2. This shortcut simplifies the schedule data collection
chore. If you make this an onerous exercise by forcing
your team to log best, worst, and most likely duration
for every task in your WBS, then they may jump off
your project train!
3. This deliberate negative bias helps offset other biases
already built into the schedule exercise:
a. The inadvertent omission of routine tasks from
the schedule.
b. The underestimation of the time it takes to
complete routine tasks.

Why do negative risks tend to outweigh positive risks on
your project? As we discussed in an earlier chapter, most
estimating errors are sins of omission. That is, we usually
Play the Percentages 85
fail to define every task and deliverable. It’s easy to lose
sight of mundane tasks. Thus it is more likely that your
schedule is missing some tasks than it has extraneous tasks.

Schedule risk is further compounded by estimators who
chronically low-ball or underestimate the effort required to
accomplish common tasks. When you hear someone say,
“That’s an easy task,” be skeptical of that forecast. Try this
simple exercise: Ask yourself how long it will take you to
go to the store and buy milk. Jot down your answer on a
sheet of paper. Now go out and actually clock the task.
Why did it take 50-70% longer than your estimate? You
may have forgotten to account for any of the following
variables: the number of red lights you encountered, traffic
on the road, and the skill and speed of the checkout clerk. It
is very likely that you grossly underestimated the actual
time it takes to complete this simple task. Likewise, we
tend to underestimate the time it takes to complete tasks at
work that we consider easy.

For these reasons, concentrating on the worst-case estimate
for critical tasks will offset the inherent bias from
incomplete task definition and estimating overconfidence.
You are only asking for worst-case estimates on select
high-risk tasks that trigger a substantial amount of concern.
If you direct the estimator to limit analysis to these risky
tasks, you will be more likely to balance the cost of
collecting input with the benefits derived from the effort.

Disclaimer: We all know that it is inappropriate to
deliberately bias statistical analysis this way and if this
offends you, please collect best-case, most-likely, and
worst-case estimates for every task in your schedule. Apply
the level of rigor that you think is necessary for your
project.

86 LAY THE TRACKS
Generate the Percentages
From your main Microsoft Project
®
screen you can now
create a Worst-Case filter to view only the high-risk tasks.
Just follow the instructions in the application to create a
filter with the following logic:
• Field name: Notes
• Test: equals
• Value: w*

There are many advantages to this filter. For one thing, you
can quickly load a Monte Carlo simulator software
application to generate a distribution of delivery dates with
probabilities of success. For example, I was able to
generate the distribution below in minutes, using an off-
the-shelf Monte Carlo application.
Figure 8: Monte Carlo Simulation
Cum
Probability
Date
10% 11/21/2008
20% 11/24/2008
30% 12/15/2008
40% 12/19/2008
50% 12/23/2008
60% 1/2/2008
70% 1/3/2008
80% 1/6/2008
90% 1/12/2008
100% No such thing
Completion std deviation: 1.4d
95% confidence Interval: .3d


Play the Percentages 87
In this example, the date with a 50% probability of
occurrence is December 23. Our experience tells us that a
small slip from that date will push the schedule into a year-
end holiday. In this case, a more realistic delivery date is
sometime in January. Do you think a wise-guy casino
operator would place a bet on the December 23
rd
date – or
even the January 3rd date – which have a 70% probability
of occurrence? Your executive would also think twice
before he puts money down against these risky dates. A
more judicious commitment might be a January 12th
delivery. The beauty of this report is that it invites
executives to choose their risk tolerance.

Practical Application
• Publish the rules of the table. Explain that the baseline
date has a fifty-percent chance of occurrence.
• Ask each scheduler to provide worst-case estimates for
high-risk tasks.
• Recognize that schedules are typically biased by the
omission of mundane tasks and by underestimating the
actual time it takes to complete easy tasks.
• Filter the worst-case estimates and review them
carefully.
• Run a Monte Carlo simulation to generate a range of
schedule estimates.
• Never present the 100% probability date because
statistically challenged executives will think that a
guarantee comes with the commitment.
19


19
All estimates are a random variable. Even a date with 100%
probability of occurrence can slip!
88 LAY THE TRACKS
• If you do not have Monte Carlo software, then use the
PERT
20
table built into Microsoft Project
®
to analyze
and judge three-point estimates: best-case, expected and
worst-case scenarios. These three points are still better
than one.

Summary
Casinos dictate odds that are always in their favor. Their
hold percentage guarantees a decent return as long as
gamblers keep placing bets. You may not get many chances
at the project gambling table. Executives may transfer you
from the conductor role on the project train to the less
prestigious role of fireman if you miss just one schedule
commitment.
21
So you are probably worried that you are
not going to get many shots at this game before you get
yanked from the Conductor role.

You have a right to be concerned. We are taught that a risk
can be either good or bad, but trust me, the good risks will
never bless your projects. You may lose your schedule bet,
even though you played a smart game. But if you
consistently apply proven logic to your scheduling
activities, then over the course of your career you can
expect to perform better than the patsy
22
who wages a bold
unrealistic bet every time he sits at the scheduling table.


20
The Program Evaluation and Review Technique commonly
abbreviated PERT was developed for the US Navy Polaris program to
allow randomness in task durations. It is typically used to analyze
complex, one-of-a-kind projects.
21
In the 19
th
century, fireman started and maintained the fire in the
firebox of a steam locomotive. This would heat tubes in the boiler
changing water to steam. The job was physically demanding and, to put
it bluntly, extremely dirty.
22
Patsy: a person who is easily manipulated or victimized
Prepare the Cost Estimate 89
3.8 Prepare the Cost Estimate

The last step in the estimation process is to forecast the
project cost. Now we are going to take all of the project
scope carried in our freight cars and calculate the cost to
complete our journey. This is Step 5 in our cost estimation
model. If you fail to do this properly, then no amount of
heroic effort will save your project from financial ruin.

Right-Brain Activity

O Confirm core capabilities and size
requirements
O Construct WBS & schedule
O Prepare cost estimate

The seasoned project manager solicits multiple quotes for
each unique line item to determine the cost boundaries for
the requirement. You should do the same when dealing
with unfamiliar requirements. Test the accuracy of the
estimate by preparing top-down, bottom-up, and sidewise
(third-party review) estimates. Multi-source estimates
reduce forecast risk.

Of course, the time you spend on this exercise should
correlate to the relative importance of the estimate. For
small, low-risk projects, a ballpark estimate like “it will
cost $175 per square foot to build the home” works just
fine. For bigger projects, you may choose to pull out the
big gun – a sophisticated estimating tool like COCOMO.
23


23
COCOMO is a model designed by Barry Broehm to estimate the
amount of resources (man-months) it takes to develop a software
product. The underlying principles of this model apply to hardware and
service projects as well.
90 LAY THE TRACKS
COCOMO
COCOMO stands for COnstructive COst MOdel. I selected
COCOMO to discuss modern estimation methods because
the name is soothing – it sounds like something you would
drink on a blistery winter’s night while listening to “Take
the A Train” by Duke Ellington. Though used primarily to
estimate software projects, COCOMO concepts have
universal applicability; the model can be easily tuned to
estimate lines of documentation in a help system or the
hardware features on a widget.

In this open model, scale drivers dramatically influence a
project's duration and cost. At a high level, the five scale
factors are:
• Precedence – Have you managed a project like this
before?
• Development flexibility – Does the design need to
interface with external interface specs? Is there a
premium on early project completion?
• Architecture/risk resolution – What is the level of
uncertainty in key architecture drivers?
• Team cohesion – Are project stakeholders aligned and
pointed in the same direction?
• Process maturity – Do you have process controls to flag
out of bound variances?
Prepare the Cost Estimate 91
The COCOMO II effort equation can be expressed as
follows:

Effort = 2.94 * EAF * (KLOC)
e


Where:
EAF = Effort Adjustment Factor derived from the cost
drivers
KLOC = Thousands of lines of code
e = Exponent derived from the five scale drivers

This model calculates required effort (measured in person-
months) based primarily on your estimate of the software
project's size as measured in thousands of lines of code
(KLOC). Based on default cost and scale driver
assumptions, the effort required to produce a 10,000 KLOC
project would be:

Effort = 2.94 * (1.0) * (10)
1.0997
= 37 Person-Months

This result implicitly tells you how long the project will
take, depending upon how many resources you assign to it.
One person would take roughly three years to complete this
assignment. Three people would take one year to complete
this assignment, right? Not so fast. Notice how the scale
driver increases the required person-months exponentially
due to diseconomies of scale from communication
overhead and large-system integration.

The author of this model admits, “While this formula
provides us a useful rule of thumb, the realities of staffing
the project will not be an easy equation to resolve. We can’t
allow the precision of an equation to fool us into thinking
that the project actuals will follow the model.”
24


24
See COCOMO Model Definition Manual.
92 LAY THE TRACKS
Experience with COCOMO indicates that users estimate
cost within 30 percent of actuals, 74 percent of the time. So
we might ask the question: is the model flawed, or did users
plug in the wrong assumptions? Or is the team performing
the work dysfunctional? Are the employees who are
actually writing the code the A Team – or F Troop?

Bottom line, COCOMO is a useful model in that it invites
us to explore the variables influencing productivity (scale
and cost drivers). This will spur you to ask relevant
questions when you size the amount of resources you will
need to execute your project. Just remember that these
models won’t map the realities of your world to a level of
precision that your management expects, so frame your
estimates with confidence boundaries: “Our estimate is $1
million with 70% confidence or $1.3 million with 90%
confidence.”

Tracking Actual Expense
Try to build your cost estimate using categories that lend
themselves to easy comparison with actual expense later.
You want to be able to calculate, explain, and mitigate
variances to the baseline easily.

True confession: I never really know how much it costs to
implement my projects. My delivery functions have a
secret sandbox that is managed inside the weak matrix. And
my financial systems do not support project-based
reporting. Nevertheless, the estimation processes defined in
these chapters have value in helping to calculate realistic
schedules and project cost. In other words, this is a
meaningful exercise even if you can’t compare the plan
baseline against actual results later.

Prepare the Cost Estimate 93
Summary
There are some bids that you should flatly reject. If the
project doesn’t fit your business strategy, or if you lack the
core capability to deliver the goods, say, “pass” on the
proposal. Of course there are many bids that you should
accept if they add value to your business. For those bids, it
is extremely important that you estimate the delivery costs
accurately.

Explore the variables that influence productivity and
carefully consider the impact of scale factors when you
prepare your estimate. Present a range of cost estimates
with confidence indicators just as we did with our schedule
estimates so that management can choose their level of risk
tolerance.

94 LAY THE TRACKS
3.9 Reduce Project Friction

Reduce friction by
unhitching empty
boxcars.
Friction is the bane of projects since it slows down
delivery. In the last chapter, we learned that scale drivers
cause friction which, in turn, increases the effort required to
complete a task. When you are carrying extra load, the
locomotive engine has to work harder to maintain cruising
speed. It is in your interest to reduce friction by lowering
both project and process
complexity. Unhitch every
empty boxcar that doesn’t
add tangible value to the
project. Lighten the load.

Whenever someone tries to link another car to your train by
adding scope to your project, carefully assess the impact on
speed. In many cases, you will find that speed – time to
market – is your primary competitive weapon so you may
choose to either reject the change request or add it to your
plan in a future release.

Friction has derailed countless projects in the past and will
continue to do so unless you take active measures to resist
project complexity. A case study of an epic failed project in
ancient history will help us appreciate the destructive
influence of friction. Let’s review Mark Antony’s project to
conquer the world.
Reduce Project Friction 95

Roman Warships
The year is 31 B.C.E. The first milestone in Antony’s
project plan is to defeat his rival Octavian in a naval battle.

Mark Antony, an accomplished general (on land), led a
fleet of 220 warships to the Gulf of Actium to destroy the
Roman fleet led by Octavian (Caesar Augustus). Antony’s
ships were mostly large Quinqueremes, which in Latin
means “sitting ducks.” The Greek historian Polybius
laughingly recounts that these massive ships had a
complement of 300 oarsmen, 150 marines ready to storm
the other ship, and 50 administrators. Picture that you are
the commander of one of these behemoths. The bow of
your ship is fitted with a three-ton battering ram. All you
need to do is rouse your team of oarsman to stroke swiftly
so that you can outmaneuver and ram the enemy ship.

In the epic Hollywood movie Ben Hur, the oarsmen were
chained to their benches. If the enemy rammed and sank
their vessel, the poor slaves would drown. We can
conclude, therefore, that these valued employees were
highly motivated to perform at heroic levels. Still, to make
absolutely certain that each employee carried his weight; a
sweaty guy with questionable soft skills walked the deck
and whipped the laggards. The threat of drowning or of
beating virtually guaranteed top employee performance.

Mark Antony led his crew of eager employees out to the
Gulf of Actium. He didn’t know his port from his
starboard, but he was one of those charismatic leaders who
96 LAY THE TRACKS
thought that he could “will his troops” to victory. But could
Antony overcome these contributors to project friction?
• Antony had no precedence with this type of warfare.
• Antony’s ship were massive which offered a measure of
protection, but also limited their tactical flexibility
during the battle.
• Team cohesion was poor. His men were depleted by an
outbreak of malaria so he didn’t have the baseline level
of resources required to execute his tactics.
• Octavian had cut Antony’s supply line so Mark’s troops
were hungry and crabby (the ancient equivalent of low
morale).
We just described are a few of the standard COCOMO
scale factors.

The Battle Begins
Octavian’s fleet formed a semi-circle to prevent Antony’s
escape. This was particularly ironic since Antony wasn’t
trying to escape; he wanted to ram Octavian’s fleet.

Once the battle started, we can safely assume that the crews
on each ship were extremely motivated to give it their all.
When the big sweaty guy quickened the cadence of the
drum, the oarsmen increased their pace. Nonetheless, Mark
Antony was soundly defeated in this battle, despite his
crews’ best efforts. Almost all of Antony’s 220 ships sank
that day.

What went wrong for Antony? The answer is that the
lighter Liburnian vessels were able to protect themselves by
outmaneuvering Antony’s large Quinqueremes. Therein
lays this important truth: the best motivated employees
can’t overcome a poor strategy that points a heavy ship in
the wrong direction.
Reduce Project Friction 97
Although Antony managed to escape on a dinghy along
with his flag, his land army lost its trust in his leadership
skills after this decisive naval defeat. They deserted in large
numbers, leaving his world conquest project grossly under-
provisioned. Mark Antony committed suicide and his lover
Cleopatra
25
also committed suicide after she was unable to
negotiate favorable surrender terms with Octavian. This
singular event in human history is credited with the
transformation of Rome from a Republic to an Empire.

Lessons Learned
The primary lesson from this engagement still rings true
today: friction works against large projects to impede speed
and maneuverability. We can glean these addition lessons
from this disaster:
1. No amount of employee effort can overcome a bad
battle strategy. Both sides in this battle had highly
motivated employees chained to their workbenches.
Octavian won this battle with smaller, lighter, ships.
2. You must obey physical laws. There is a physical
maximum boat speed based on project size and
complexity. Whipping employees won’t make it go
faster than top speed.
3. Heroic effort is not sustainable. You can only row at
full speed for a short distance. Then your oarsmen
lean over the side to empty their guts. If you
demand heroic effort over long periods of time,
crew productivity will plummet.

Modern cost estimation models support these conclusions
by adjusting the drivers that trigger diseconomies of scale.


25
Trivia: On the TV Show The Addams Family, Morticia’s man eating
plant was named Cleopatra.
98 LAY THE TRACKS
Yo COCOMO and a Bottle of Rum
The five COCOMO scale drivers described in the previous
chapter explain why Mark Antony’s naval campaign was
doomed from the start:
• Precedence – he had never fought this kind of naval
engagement before.
• Development flexibility – Big ships don’t turn quickly.
• Team cohesion – His oarsmen were depleted by malaria
and low morale.
• Architecture/risk resolution – Antony had no risk
management plan other than to escape in a dinghy if
things went badly.
• Process maturity – Octavian had the better-trained crew

Practical Application
The magic formula to increase project productivity is the
same today as it was over two thousand years ago: The
ribbed frame of the project ship should be the smallest
possible skeleton necessary to float the boat. In other
words, throw meaningless requirements overboard.
Applying this principle to our train metaphor we should
unhitch every boxcar that doesn’t add tangible value to the
project.

To accelerate project speed, ask these questions:
• Can I leave the dock in a smaller, more maneuverable
boat by: reducing the number of platforms, models, or
features in the portfolio or by carving the project into
smaller chunks and only committing the near term
deliverables?
• How can I raise the skill level of my team?
Reduce Project Friction 99
• How can I consciously streamline communications so
that the team can spend more time on the project
deliverables and less time on reporting?
• How do I keep all oars in the water?

Notice that I didn’t ask if you could throw more resources
(headcount) into the battle. If we could go back in time and
double the number of oarsmen on Antony’s ships, would
that have changed the course of that battle? No. Imagine
the chaos of 600 men attempting to row in unison? The
work quarters would be too tight for anyone to move. The
next time your executive asks, “If I double my manpower,
can I cut the schedule in half?” bring in a scale model of a
Quinquereme with three hundred dots representing
oarsmen. Give the executive 300 more dots and ask where
you should put them.

Summary
Real project productivity is heavily influenced by the size
of your project ship (project complexity factors), not by the
size or the motivation of your team. If you want to
dramatically improve productivity, trim your project ship
down to the smallest, lightest frame and make sure that it is
pointed in the right strategic direction.

4 LEAD THE TEAM







LEAD THE TEAM
4

Key Topics Covered In This Section:
• Why you should bulk up soft-skill
muscle.
• Rules are meant to be broken.
• How to confront and redirect bad
behaviors.
• Why you should reward positive
behaviors during the journey.


Stretch Your Soft Skill Muscles 101
4.1 Stretch Your Soft Skill Muscles

Naïve project managers assume that they are commissioned
to build projects. The mature leader recognizes that he is
commissioned to build the team that builds the project. This
key insight reveals the importance of soft skills. It puts
team building at the top of your priority list.

The PMBOK
®26
definition of “team” gives only a glimpse
of the problems you will face when you build your team:

Team: Groups of people with a shared goal.

This definition is misleading because it assumes that people
have agreed to pool their expertise to achieve a common
goal. When your team forms, people on it haven’t agreed to
anything. They didn’t volunteer; they were assigned.
Furthermore, each person exhibits a personality based on
his/her unique experiences, education, philosophies and
work ethic. When diverse people work closely together it is
inevitable that they will “get under each other’s skin” from
time to time. Soft skills can help you facilitate your team
through the inevitable storming phase of team
development.

Review the hard and soft skills in the figure below and ask
yourself which skills are more important to the job of a
project manager who “conducts” a team.

26
The Project Management Body of Knowledge (PMBOK) is
published by the Project Management Institute.
102 LEAD THE TEAM
Figure 9: Definition of Hard vs. Soft Skills

Soft skills or maintenance behaviors are directed
toward building a high performance team
• Setting norms for acceptable behavior
• Maintaining peace within the team
• Building Morale
• Persuading
• Counseling
Hard skills or task behaviors are directed toward
accomplishing the project goals
• Providing structure
• Problem solving
• Decision making
• Analyzing
• Summarizing

Adapted from Katzenbach, J.R. and Smith, D.K, The
Wisdom of Teams, Harvard Business School Press,
1993.

The successful project manager possesses the social graces
and the interpersonal skills to lead a diverse crew.
Unfortunately, soft skill muscles tend to suffer from severe
atrophy because:
• Management classes place emphasis on hard skills
(scope, time and cost management), which are easier to
teach.
• Performance evaluations put more emphasis on results
than on teaming.
• We incorrectly assume that soft skills can’t be
developed. We think we’re either born with them or
not.
Stretch Your Soft Skill Muscles 103
• Practicing soft skills makes us feel uncomfortable.

The project leader warms up and stretches his soft skill
muscles before the train even leaves the station,
recognizing that soft skills are the key to accelerating the
crew through their natural evolution of forming, storming
norming and performing.
27
Every team goes through these
phases; the project leader consciously acts to reduce the
time in the first three stages so that the team can extend
their stay in the final performing phase where the project
train is cruising smoothly at high speed.

How much time do you actually spend exercising your soft
skills? Are you behaving more like the task oriented
locomotive engineer or the team leading conductor on the
project train? Un ineffective leader spends 99% of his time
on hard skills while grossly neglecting his soft skills.

My brother Joe played on the tennis circuit. His right-arm
bicep (nicknamed Popeye) was noticeably larger than his
left (Olive Oyl). Hard skills are like our dominant arm with
grossly overdeveloped muscles. Since we don’t stand in the
mirror each day and look at our leadership muscle
definition, we may be unaware of the imbalance. Are your
soft skill muscles wasting away? Have you built an over-
reliance on hard skills? When a boulder blocks the path, do
you start attacking it with your hard skill pickax, even
though a soft skill nudge might produce better results …
with less effort?

27
Bruce Tuckman first proposed the Forming – Storming – Norming -
Performing model of team development in 1965.
104 LEAD THE TEAM
Meet Your Crew
Start exercising your soft skills before the train even leaves
the station. Begin your first team meeting with a self-
effacing admission like “I need you more than you need
me.” Your team already knows it, but they still love to hear
you say it.

Next, describe the skills that you bring to the project. This
shouldn’t be a recitation of your job history. Try to explain
how you can help the team accomplish their goals.
Otherwise you will be perceived as just another layer of
overhead. Before the meeting, inform the team that you
will be asking each person to explain the value he or she
brings to the project (in just a few sentences). After
everyone answers that question, the crew should recognize
their interdependency on others. No one person can deliver
the project by himself.

No Man is an Island
My grandpa Joe owned a service station in Chicago,
Illinois. Back in the 1950s, full-service stations offered
four-point service. After a car rolled up to the pump or
“island,” one or several employees cleaned the windshield,
checked the oil and tire pressure and, believe it or not,
filled the gas tank while you sat in the car!

One day, Grandpa was short on
help so he trotted out from
behind his desk to fill a
customer’s tank. He searched
furtively for the gas cap, but
couldn’t find it. In his defense,
gas caps in that era were
occasionally hidden behind the
license plate. Eventually, one of
the lowest-paid employees at his shop came out to help
Stretch Your Soft Skill Muscles 105
him. Was he embarrassed? Not at all! He recognized his
reliance on other people. I asked him, “How could you own
a service station when you can’t even find the gas cap on a
car?” His reply, “I know how to hire people who do.” He
freely acknowledged that his skill was in hiring and
retaining intelligent workers.

Project managers who are groomed from the technical
ranks don’t always appreciate this lesson. Their natural
inclination may be to do the work instead of supervising the
work. Unfortunately, while they are doing someone else’s
job, plodding along in the trenches, they are neglecting
their primary responsibility, which is to develop the high-
performance team to deliver the project.

Summary
Being stuck in the storming phase of team development is a
sign of soft skill neglect. Do you spend adequate time
exercising your soft-skill muscles? Warm up your soft-skill
muscles by convincing your team that the project needs
unique contributions from each member of the team.
Describe the skills that you bring to the team table. Value
the skills that others lend to the project.
106 LEAD THE TEAM
4.2 Train Your Crew

Before your first trip down the project tracks, you are
usually nervous and apprehensive. It seems like everyone
knows their way around except you. Wouldn’t you love to
have a map to help you find your bearings?

Think about the critical things you would want to know if
you were joining a project team. Succinctly document those
items and publish the list broadly to team members and
their functional managers. Here is a sample new crew
member training package:
Train Your Crew 107
Template 6: New Team Member Training Checklist


Subj: Team Training

This note documents the training requirements for new
team members. I expect the functional team member
who is leaving to fully explain these things to you. This
will help ensure that you can contribute to our team
quickly.

· Review team roles:
– Print out team member list and review each
member's role. Give examples of the types of
questions that should be directed to each team
member.
– Encourage new team member to work directly
with the rest of the team and not broker requests
through the project manager.
· Review meeting guidelines:
– Remind the new team member that our weekly
review is not a "data gathering" meeting. It is a
decision-making meeting.
– Items on the agenda should be discussed, debated
and resolved (if possible) prior to the meeting.
– Actions should be closed quickly.
· Show how to access the integrated project file.
– Write the project manager a note to add the new
team member to the access list.
– Once the new team member has online access,
show him/her how to view folders and how to
search the database.
· Review project charter
· Review baseline plan
· Review change requests under consideration
· Review budget
· Review latest status report
108 LEAD THE TEAM
This training package teaches new team members what
they need to know to get up to speed quickly and make
valuable contributions to the project. Notice that the
responsibility for training falls on the function. Teams
don’t always stay together for the full journey; some crew
members are reassigned midstream. The person leaving
must train his/her replacement. After all, who can provide
the best advice about how to fulfill the role – you or the
person who actually performed that function?

Practical Application
• Prepare a team-member training package. Ask your
team to provide feedback. What other things do they
wish were included in the package?
• Don’t let a team member jump from the train until he or
she trains a replacement. Give honest feedback to the
functional manager if the training is inadequate.
• Ask the new team member to report on training
progress at the end of each week and report deficiencies
in training to the functional manager.

Summary
Do everything in your power to make your team members
feel at ease. A training package can drastically reduce team
member anxiety. Assume that new team members are too
shy to ask for help. Be open to providing extra assistance
until the new person feels comfortable on your train.

Limit the Number of Rules and Regulations 109
4.3 Limit the Number of Rules and
Regulations

You need to trust your crew to do their jobs. In the ideal
environment, you will establish a few guidelines and then
let the crew find the fastest way to get their job done.

Guidelines are an outline of policy or conduct. Rules, on
the other hand, are more prescriptive directions for dealing
with specific circumstances. In general, your crew will
welcome guidelines, but resist rules. As Henry David
Thoreau wrote, “Any fool can make a rule, and any fool
will mind it.”

Other than project managers, few people like rules and
regulations. Some team members, especially the technically
brilliant ones, may resist the imposition of rules by sniping
from the sidelines. We can learn how to redirect the sniper
by considering the 1967 movie Cool Hand Luke. Paul
Newman played the anti-hero Luke Jackson in this film. He
was sent to a southern prison for civil disobedience after
cutting the heads off parking meters. That strange behavior
reflected his contempt for rules and regulations. Parking
meters represented authority, so he decapitated them.

Luke Don’t Like Rules
Imagine Luke’s surprise when he arrived at prison and was
greeted by a crusty guard named Car who rattles off this set
of definitive rules:
“Them clothes got laundry numbers on 'em. You
remember your number and always wear the ones that has
your number. Any man forgets his number spends the
night in the box. These here spoons, you keep with ya.
Any man loses his spoon spends a night in the box.
110 LEAD THE TEAM
There's no fightin' in the building. You got a grudge
against another man, you fight him Saturday afternoon.
Any man fightin' in the building spends a night in the
box. First bell is at five minutes of eight... Last bell is at
eight. Any man not in his bunk at eight spends a night in
the box. There's no smokin' in the prone position in bed.
If you smoke, you must have both legs over the side of
your bunk. Any man caught smokin' in the prone position
in bed spends the night in the box. You'll get two sheets.
Every Saturday, you put the clean sheet on the top and
the top sheet on the bottom. The bottom sheet you turn
into the laundry boy. Any man turns in the wrong sheet
spends a night in the box. No one will sit in the bunks
with dirty pants on. Any man with dirty pants on sittin' on
the bunks spends a night in the box. Any man don't bring
back his empty pop bottle spends a night in the box. Any
man loud-talkin' spends a night in the box.”
28


This list of rules is darn’ right oppressive! Luke doesn’t pay
them much mind. He tells his fellow inmates, “I ain't heard
that much worth listenin' to. There's a lot of guys layin'
down a lot of rules and regulations.”

Your team doesn’t like rules either so expect their level of
resistance to increase in direct proportion to the number of
rules you set. Given that you need some rules to run an
orderly railroad, you will be well served if you solicit team
member feedback on any code of conduct, meeting
guidelines or checklists before you publish them.

28
From Cool Hand Luke, 1967
Limit the Number of Rules and Regulations 111
Even if you take the liberty of writing the first draft of a
rules document, ask the team to review it:
• Are these guidelines reasonable?
• Do you recommend any changes?
Remember, rules should apply equally to everyone. Ask
your team to give you feedback if you violate one.

You Can’t Beat Luke into Submission
“That's my Luke. He
grins like a baby but
bites like a gator.”
Dragline
Luke was a very
disruptive influence in his
prison gang. Is there
someone like Luke on
your team – the guy who
won’t ever back down?
He’s so persistent that people avoid a battle with him at all
cost. If left unchecked, Luke will disrupt the healthy
rhythms of your team. So how do you encourage other
people to talk and share their opposing views when they are
scared of upsetting Luke? And how would you redirect the
person exhibiting Luke-like self-oriented behaviors?

In Luke’s case, no amount of punishing nights in the box
changed his behavior because the strong-arm approach
didn’t reach his seat of motivation. The Luke on our teams
usually has strong technical skills. People are going to
listen to him. So you need to secure his buy-in on important
decisions. Perhaps you can meet with Luke prior to a key
decision to allow him to vent his views privately.

112 LEAD THE TEAM
This hypothetical soft-skill nudge might be effective on a
guy like Luke:
“Luke, people respect you. I’m here to ask for your
help. During our meetings, you are very decisive. And
you are usually right. But I want to encourage other
members of the team to contribute so they buy in on the
decision. Could you hold your opinion on matters until
we canvass everyone else?”

Turn the disruptor into a facilitator. You are asking Luke to
promote a work environment where the views of everyone
on the team are respected.

Practical Application
• Make project rules reasonable and secure buy in before
you enforce the law.
• Don’t let Luke dominate your team.
• Don’t battle Luke head on or punish him. Instead,
encourage changes in Luke’s behavior by appealing to
his seat of motivation. Guide Luke with principles, not
rules.
• Recognize that “Luke” typically has strong technical
skills. Others respect him. So secure his buy-in on
important decisions.
• Meet with Luke prior to a major decision and give him
sufficient time to vet his opinion prior to an open
discussion with the rest of the team.

Limit the Number of Rules and Regulations 113
Summary
Too many rules can burden your team and spark carping
from the sidelines. Try to limit the number of hard-and-fast
rules and regulations on your project.

Secure buy-in on a few essential rules before you start
enforcing them. Use the tips in this chapter to turn
disrupters into allies.
114 LEAD THE TEAM
4.4 Enforce Acceptable Behaviors

The conductor maintains order all during the project’s
journey. If you don’t address bad behaviors, then they
become deeply rooted. In this chapter we will analyze
dysfunctional behaviors during meetings and techniques to
respond to them.

Meetings are a great place for you to exercise your soft
skills because people generally come to meetings with an
edge. Teams are annoyed by meetings because they disrupt
their natural work flow. In my company, it is not
uncommon to have a solid block of meetings scheduled
from 9 am to 5 pm. Some meetings will run right over
lunch (very discourteous) and there won’t be any time
scheduled for bio breaks (each meeting starts and ends on
the hour). By the third or fourth meeting each day, I
become disenchanted and start to exhibit bad behaviors like
impatience. I can’t help myself and I assume that others are
equally irritated by meetings. Disruptive behaviors are
inevitable.

Don’t create an environment that promotes disruptive
behavior. For example, don’t schedule a meeting unless it
is absolutely essential. And for the very few select meetings
you do schedule, strictly adhere to a published list of
meeting guidelines.

Enforce Acceptable Behaviors 115
Template 7: Meeting Guidelines

Meeting Guidelines
· Only schedule meetings that are absolutely
required.
· Publish an agenda prior to the meeting and issue
timely meeting minutes.
· Attendance is mandatory for core members or
their deputies.
· Start/finish the meeting on time. Be sensitive to
time differences across the country and across the
world.
· Focus the meeting on decisions and not data-
gathering.
- Stay focused on the topic at hand.
- Table long debates and try to resolve them
outside of the meeting.
- Call violations when the discussions drift.
· Do not use computers to process mail or instant
messages during the meeting (unless required for
collaboration).
· Let other people talk more than you do.
· No cursing (you can raise your voice and scream if
you are angry, but keep the words clean).
· End the meeting five minutes early so that
everyone has time to take a bio break before their
next meeting.

Would you take exception to anything on this list? These
are common sense acts of courtesy. We’ve seen this list a
hundred times and, quite frankly, we don’t pay much
attention to it. After all, we aren’t children, right? But if
everyone already knows these things, then why are these
basic guidelines routinely violated? Why does a person
with a strong personality hijack your meeting and talk
incessantly without pausing for others to share their
116 LEAD THE TEAM
opinions? Why does your team continually step in rabbit
holes and data-gather on a single topic that consumes all of
the allotted time? What is going wrong here? Why doesn’t
a published list of guidelines stop the bad behaviors? The
answer is that guidelines are worthless unless someone
enforces them. Lists don’t stop bad behaviors. Leaders do.

If you are sitting in a worthless meeting with no agenda, an
unproductive flow, and no movement toward a decision,
then why don’t you say, “What are we doing here? What is
the purpose of this meeting? Who is facilitating this
session? What are the steps for reaching a decision? Why
don’t we cancel this meeting and regroup later after we
answer those questions?”

In practice, people look to a leader to be the gatekeeper or
meeting cop. The average person doesn’t feel comfortable
counseling other human beings about bad behaviors. That’s
not a skill taught in business school! So they look to you to
maintain order on the project train. If you tolerate bad
behaviors, you will lose the respect of your team. Be honest
with yourself: are there disturbing patterns in your
meetings? Are you scheduling too many meetings? Are
certain recurring meetings unproductive? Do topics
wander? Do you passively tolerate bad behaviors? If you
answer “yes” to any of these questions, then cancel the
meeting or make the meeting more productive. Those are
the only two valid responses.

Zero Tolerance means Zero Tolerance
The successful project manager enforces guidelines. Let’s
demonstrate how we can effectively counsel a team
member who violates a guideline. One of my meeting
guidelines states: “No cursing. You can yell at the top of
your lungs at each other, but keep the words clean.” The
Enforce Acceptable Behaviors 117
guideline apparently wasn’t clear because I had this actual
exchange with a team member:

PM You cursed several times during my meeting.
Mr. Rude No I didn’t … [pause] … oh you mean when I
said, xx??x!! I didn’t think that was a curse
word.
PM Well, I do. And I find it offensive. Please
don’t use it again.

This same employee laced my next meeting with the same
jaunty word. Since I had previously counseled this team
member about this particular infraction to our meeting
guidelines, I felt comfortable restating my expectations
more forcefully:

PM You cursed several times during the meeting
today.
Mr. Rude Oh … sorry ... it’s a habit.
PM Well, it isn’t going to be a habit in my
meetings. Please tell your manager that I
need a replacement for you on the team.
Mr. Rude Wait! We can work this out.
PM No, we can’t. There are some things that we
can work out over time. This isn’t one of
them. I’m giving you the courtesy to get
ahead of the curve and talk to your manager
before I do.
Mr. Rude No, that’s not necessary. I promise that I
won’t do it again.
PM I’m going to make an exception this once.
But the next time it happens, you will no
longer be welcome at our team meeting. I
will tell your manager to sit in for you until
he can find a replacement. Cursing is not
tolerated. Do you understand?
118 LEAD THE TEAM

Of course, your level of intensity should match the severity
of the infraction. Cursing happens to be a zero tolerance
item for me. For other less-serious meeting guideline
violations, I may chat with the team member repeatedly
before I start playing hardball. The key point here is that
someone – you – must enforce the guidelines to foster an
environment of mutual respect and common courtesy.

Silencing the Digresser
One of the biggest drains of meeting productivity is the
long-winded digresser. This person commandeers the
meeting to pontificate about a topic that isn’t even on the
agenda. How would you address that situation? Here’s a
method that works. You could say, “The discussion appears
to be drifting ... Let’s move on.”

If you’re dealing with a particularly obstinate digresser
who refuses to move on after such a suggestion, then raise
the stakes with this technique:
1. Interrupt the talker.
2. Make an observation, “The discussion appears to be
wandering.”
3. Then say, “I am going to poll the team. If you would
like to continue this conversation, please say ‘Stay.’
Otherwise, I’ll assume that you want to move on.”

Silence, the default response, sanctions the team to “move
on” to another topic. You will be surprised by how
effective this technique is at silencing a digresser.

Practical Application
• Limit the opportunities for bad behaviors to incubate.
For example, don’t schedule useless meetings; if you
do, you’re just asking for trouble.
Enforce Acceptable Behaviors 119
• Throw away all of your guidelines unless you plan to
enforce them.
• Permit your team to review and comment on any
guidelines you publish.
• Practice what you would say to each violation of the
guidelines. Keep your counsel short and direct:
o Make an observation.
o Remind the offender that it is a violation to a team
approved guideline.
o Restate your expectations.
• Address bad behaviors before they become
institutionalized.
• Tell your team to feel free to counsel you if you fail to
meet their expectations for proper conduct and
behavior.

Summary
Your team expects you to lead. They need you to guide
them to their destination. This means more than mapping
the schedule of tasks. They also want you to make sure that
everybody is playing nice together during the journey.

When repeated face-to-face counsel for a guideline
infraction fails to produce results, ask the functional
manager to sit in for the person until a replacement can be
found. The manager will fix the problem quickly. If left
unchecked, bad behaviors will corrupt the entire team.
Establishing guidelines is the first step in addressing bad
behaviors. When you consistently counsel employees who
violate the guidelines, the number of violations will fall
dramatically and the team dynamics will remain healthy.
120 LEAD THE TEAM
4.5 Redirect Narcissists

Change projects. Change trains. But you are always going
to see the same unsavory characters on every crew. In the
last chapter we established that project leaders are not
afraid to counsel team members. Let’s extend that concept
to deal with these troublesome team members:
Table 2: Self-Oriented Behaviors
29


Character

Behavior

Example
Possible
Redirect
The
Blocker
Rejects all
ideas and
refuses to play
nice.
“Here are three
reasons why
that idea won’t
work.”
“Tell me one
reason why it
might work.”
The
Digresser
Can’t stay
focused on a
topic.
“That reminds
me of a vacation
I took to an
island in the
Bahamas.”
“We need to get
back on topic or
we won’t be
able to cover our
agenda today.”
The
Recognition
Seeker
Asserts
personal
agenda.
“I really want to
talk about a
different topic
right now.”
“All those in
favor of
changing the
topic, please
raise your
hand.”
The
Withdrawer
Manages
email during
meetings.
“Yeah. Sure.
Whatever.”
“What do you
really think
Bill?”
The
Sniper
Resists
authority.
“I don’t take
directions from
you.”
“I need your
support. This
project will fail
unless we pull
together.”

29
Adapted from "Functional Roles of Group Members," Benne and
Sheats, Journal of Social Issues 4 (Spring 1948): 41-49.
Redirect Narcissists 121

Character

Behavior

Example
Possible
Redirect
The
Dominator
Boasts,
criticizes,
condemns and
complains.
“That’s stupid.
Here’s what we
need to do.”
“No personal
attacks and
please watch
your tone.”

It’s quite easy to pigeonhole most members of a team into
one of these character roles. But did you realize that you
also wear these masks? Everyone exhibits a touch of
narcissism. There may even be times in a telephone call
that you display several of these self-oriented behaviors

No team can stay at a sustained level of high performance
unless somebody keeps the teaming engine tuned. But who
really wants to tackle these bad behaviors head on? Real
leaders stand up and do just that – they confront and
redirect bad behaviors

Practical Application
• Review the list of self-oriented behaviors during a team
tune-up portion of your meeting agenda.
• Tell the team that you are going to try and address these
behaviors, but you feel uncomfortable doing so. Ask for
their patience as you learn how to facilitate the team
interactions better.
• Redirect offensive behaviors immediately. Don’t wait
for an opportune time. It will never come.
• Visualize each self-oriented behavior and play out your
anticipated response before your meetings.
• Practice the redirection techniques until they become
second nature.
122 LEAD THE TEAM
Summary
Self-oriented behaviors are sometimes referred to as
“crazy-making.” These behaviors are destructive to the
team. They subvert work and fun.

Do not let a bad behavior slide – or your team performance
will slide with it.
Provide Behavioral Feedback 123
4.6 Provide Behavioral Feedback

Building a high performance team takes time, effort and a
backbone. In a weak matrix, you may feel that you lack the
authority to confront team members. Why should team
members listen to you when you don’t even get to provide
input to their performance appraisal? Nonetheless, project
leaders counsel team members.

The key to building a high performance team is to provide
continuous feedback, adjustments, tuning all during the
project journey. Here’s a technique you can use to provide
continuous feedback in any environment. Strong or weak
matrix, it doesn’t matter.

1. Ask functional managers to include a brief snippet of
your project performance goals in the employees’
performance plan at the beginning of the appraisal
period (See Template 8).
2. Provide unsolicited feedback and counsel to the
employee when you observe a violation to the norm
for conduct and behavior.

124 LEAD THE TEAM
Template 8: Team Member Performance Goals


To: Functional Manager and Team Member
From: Project Manager
Subj: Performance Goals

Please ensure that these key principles of project
management are properly reflected in your employee's
performance goals for the year:

Business Goals:
· Meet all delivery and business objectives consistent
with project charters and project contracts.
· Ensure that appropriate project tasks and deliverables
are completed in a timely fashion in accordance with
our project work plan and checklist.

Teaming Goals:
· Maintain open and honest communication regarding
project status.
· Surface risks early and execute effective mitigation
plans.
· Fully support the project team arrangement and
conscientiously close actions assigned by the project
manager.
· Act as single focal point to your extended function.
Represent your function in all aspects of project
planning, execution and empowered decision-making.
Provide Behavioral Feedback 125
This note diffuses potential political power struggles. If the
functional manager agrees with your performance goals or
works with you to modify them – great, you have an
advocate in your corner. Even if the functional manager
challenges, “You don’t set goals for my employee!” you’ve
already accomplished your mission, which was to clearly
communicate your expectations. People can choose to
agree or not agree. Your objective isn’t to win a power
play; it is to simply tell people what you expect.

The next template describes specific positive and negative
teaming behaviors. You can use this list to provide
meaningful feedback to your team members. Prepare your
own list of good and bad behaviors. Share the list with your
team. Then call violations any time a team member fails to
meet your expectations. Address bad behaviors
immediately by counseling the team member in private. If
repeated counseling does not change the behavior then ask
the employee if your expectations are unreasonable or if
there is some other obstacle in the way.
126 LEAD THE TEAM
Template 9: Performance Expectations – Good/Bad
Good Not So Good
· Your attendance is regular
and you actively
participate in team
meetings.
· You strive to reach
consensus with other team
members.
· You are the single point of
contact for the function.
· You close actions
promptly.
· You provide crisp, clear
status reports.
· You manage your
stakeholders so that there
are few surprises during
decision checkpoint
meetings.
· You drive sponsored
change requests through
the established process.
· You schedule sub-team
meetings to resolve issues.
· You raise risks early and
often and you crafts
effective mitigation plans.
· You uses directional data
to make decisions.
· You provide tangible value
to the project.
· Your attendance is spotty
and you are often late to
team meetings.
· You tend to take a
functional point of view on
decisions.
· You redirects other core
team members to other
people in his function. This
over extends the lines of
communication.
· Your management team is
surprised by project
decisions.
· You do not assume
ownership of change
requests initiated by his
function.
· You depend heavily on the
me to call sub-team
meetings, to collect impact
assessments and to secure
other team member votes.
· You do not highlight risks
early.
· You get bogged down by
data paralysis.
· You demand multiple case
studies when the first sizing
is sufficient to make the
decision.
· You resist direction from
the project team.


Provide Behavioral Feedback 127
The Seat of Motivation
The effective leader teaches proper behaviors by appealing
to the seat of employee motivation. I know, this sounds like
soft-skill mush, but discern how a clever manager taught
me to be prompt to meetings. After I was late to one
meeting, he said, “John, I noticed that you were late to our
meeting. It’s no big deal. Here’s what we covered before
you arrived …” When I was late to another meeting, he
gave me the same spiel. After the third infraction he said,
“John, being late to a meeting is excusable. Being
chronically late is a sign you lack organizational skills. Is
that how you want other people to view you?” Click. That
was the right button to make me think seriously about
getting to the meeting on time. Prior to that counsel, I
didn’t even wear a watch. After that meeting, I bought a
cheap Timex.

My manager never dictated that I attend meetings on time.
Instead, he expressed the need to be prompt in terms of
how it affects my reputation. In short, he appealed to my
seat of motivation. Notice that he took the time to counsel
me privately on three separate occasions. How often do we
let bad behaviors slide because we don’t have the courage
or the time to address them? When you observe a bad
behavior, call it out and restate your expectations.

In addition to private counseling, you can also provide
feedback to your team member’s manager. This can be
unsolicited. What prevents you from sending this type of
note today?
128 LEAD THE TEAM
Template 10: Performance Feedback Letter

To: Functional Manager
From: Project Manager

Subj: Feedback on Mr. Colbert

As you know, Stephen is a core team member on
[project x]. He attends regularly and he actively
participates in the call. He strives to reach consensus
with other team members.

As a core team member, Stephen is the single point of
contact to the extended team. However, he sometimes
redirects me to other people in his function. This
extends the lines of communication, which results in
delays in closing actions.

I appreciate your help to build the strong matrix. And I
hope that this feedback is useful to you as you consider
Stephen’s performance assessment.

You know that the brightest employees with superior
technical skills do not always make the best team members.
They can drag the whole team down if they are permitted to
display unchecked bad behaviors. Get a backbone and
address bad behaviors in private counseling sessions with
the offender and with on-going feedback to the functional
manager. If your efforts don’t work, lobby for a
replacement.



Provide Behavioral Feedback 129
Practical Application
• Draft a list of good and bad behaviors that are
consistent with your core philosophy.
• Review the list of good and bad behaviors with your
team so that they understand your expectations.
• Set aside a given time frame per week, say Wednesday
afternoon, to address violations to your expectations.
o Pick your worst team member and give him and/or
his manager feedback.
o Pick your best team member and give her thanks. If
you are sending her a note, copy her manager.

Pitfalls to Avoid
• Recognize that people in power will do anything to
keep power. Ignore political power struggles. Instead,
concentrate on specific employee behaviors. Your
consistency will eventually turn the power dial your
way.
• Take time to discuss your expectations with each new
member of your team.
• Actively work to reassign an employee that cannot
work well within a team. It is the functional manager’s
responsibility to provide you with a skilled resource.
“Skills” include both a technical and teaming
component.
130 LEAD THE TEAM
Appraisal Feedback
Employee appraisals are typically processed once per year
and they tend to be a very stressful experience for
employees. I recommend that you put a moratorium on
“minor bad behavior” counseling during the appraisal
window since it might be viewed by the employee as an
attempt by you to negatively influence the appraisal.

Let the poor employee suffer through the appraisal process
without any perceived interference from you. You have the
rest of the year to provide regular counseling and I
encourage you to exercise that right. Think of it as your
counseling mission to help your team members develop the
skills they need to get a top rating on their appraisal.

Summary
How much time do you spend counseling your team
members on behaviors? If you answer “none,” then you
deserve your dysfunctional team. Remember, counsel is
instructive and beneficial to the employee. Never treat the
exercise as a punishment. Strive to make it a genuinely
valuable experience for the employee.

Setting expectations for a behavior gives you a platform to
provide employee feedback all during project execution.
People who argue against the principles of good behavior
will lose in the court of public opinion. Consequently,
behavioral feedback can be used in any organizational
construct.
Triage Missed Commitments 131
4.7 Triage Missed Commitments

The conductor on a project train coordinates activities,
communicates status, and marshals the resources to respond
to emergencies. Say that you are the conductor and you’ve
set clear expectations for performance, but someone still
misses a commitment. What do you do next? Erupt in
anger? No, your next step should be to try to understand the
underlying cause of the problem.

Generally, the underlying cause of missed commitments
falls into two buckets.
• The person is not motivated and/or
• The person lacks skills.

Lack of Motivation
An employee may be more motivated to work on a
different task than the one you assigned. Case in point, his
functional manager redirects his efforts. In this case, it
would be more productive for you to talk to the functional
manager, not the employee, to break the logjam and get
proper focus on your assignment. Lack of motivation in this
example doesn’t imply that the person is lazy; he is more
motivated to listen to his manager.

Lack of motivation may also be traced to personal issues. It
is a moral imperative that we handle these situations with
empathy. A shipping executive at FTD Florists related,
“My sister passed away and her funeral was scheduled for
Monday. When I told my boss, he said she died so that I
would have to miss work on the busiest day of the year. He
then asked if we could change her burial to Friday. He said,
132 LEAD THE TEAM
‘That would be better for me.’"
30
Would you be motivated
to give your very best effort for this heartless manager?

Play out this scene. You sit down with Tom to discuss why
a key milestone was missed without any warning. How
would you handle each of these responses?
1. Tom says, “I had a dependency on Bill’s software
code and he hasn’t delivered it yet.”
2. Tom says, “I knew there was a potential problem, but
I thought I could resolve it before it blew up into a big
issue.”
3. Tom says, “My daughter has been very sick and “my
head just hasn’t been in work.”

To counsel Tom about missing a milestone when his
daughter is sick would be heartless. The other two
responses, on the other hand, lend themselves to
constructive counsel since Tom should have provided
headlight warnings at a minimum.

When the employee doesn’t have a good reason for
slacking off, you may be able to motivate him by showing
the consequences for the missed deadline or deliverable.
How will the successor task be impacted? Talk about how
the missed commitment will impact the person that will
receive the baton pass: “Sally now has to work over the
weekend to make up the lost time.” Sometimes, just
knowing the impacts of a missed commitment motivates
the employee to perform better the next time.


30
This “urban legend” story was posted anonymously on the Internet. I
use it here for illustrative purposely only.
Triage Missed Commitments 133
Lack of Capability
Insufficient capability is another possible diagnosis for a
missed commitment. There will be times when an
employee lacks the knowledge or skill to complete the task.

In many project delivery organizations, employees are
pressed to work so hard that they don’t have any time to
improve their skills by taking classes on the latest tools and
techniques of their profession. The core capability of the
organization in these sweatshops dwindles over time. This
is not the employee’s fault. You should lobby for your
organization to set aside buffer time time – 10%-15% is a
good estimate – to allow employees to improve their skills
and capability. for employees to refresh skills.

Here’s another example of a capability gap. Suppose a
member of your core team leaves to have a baby or to start
a new career path. The replacement employee invariably
lacks the skills to perform at the highest levels within your
team framework. It isn’t the replacement’s fault; he or she
just hasn’t had sufficient time yet to pick up the
interpersonal nuances of working within an established
team. Use the training package discussed in a previous
chapter to address this particular situation.

In the exceedingly rare case where an employee lacks basic
skills and won’t ever gain them, you are within your rights
to ask the functional manager to sit in on your team
meetings to monitor tasks and deliverables for the
underperforming employee until a replacement can be
found. It is the functional manager’s primary job, after all,
to provide the necessary skills and resources to execute
project tasks.

134 LEAD THE TEAM
Summary
The average employee strives to meet every commitment.
When things aren’t getting done on time or with the proper
quality, diagnose the cause:
• Was the expectation reasonable?
• Does the team member lack motivation or ability?
Your response to problems will be different depending
upon your diagnosis. In cases where family or personal
issues result in a temporary slip in productivity, exercise
extreme patience. You will be rewarded later by a loyal,
trusting and motivated employee. If the problem is caused
by a functional manager giving conflicting directions to the
employee, negotiate directly with the manager to prioritize
workload. In the extreme case where the employee lacks
functional skills, then ask the functional manager to
provide an adequate replacement.
Pour On the Praise 135
4.8 Pour On the Praise

Managers
31
tend to raise their voices when things are going
poorly. We need to balance the interactions between the
project leader and the crew by making sure that we
consistently praise good behaviors.

Money is one way to reward good behavior. In my
organization, we dispense monetary rewards at the end of
the project run based on a completed deliverable or on
actual sales result. A better approach is to praise positive
behaviors all along the project path. This would yield far
greater returns. Think about it. If management. only doles
out perfunctory awards at the final destination, then those
rewards likely have no impact on behaviors during the
journey. In fact, a reward-for-results mechanism can
promote unhealthy behaviors.
• In such an environment, employees will jostle to work
on the high profile projects. What happens to the pilot
project that could produce fantastic returns to the
business three years from now? No one will want to
work on it since it isn’t generating immediate
results/awards.
• It discourages teams that are working on a misguided
project, one that is pointed in the wrong direction by
portfolio planning. You work just as hard as the other
team that has better sales results. Perhaps you even
implement revolutionary process improvements, but
you are ignored at the award ceremony because your
project hasn’t yet produced sales results.

31
The etymology of the word “manage” is from Latin manus, hand.
The word was originally used by the French to mean to “train a horse in
its paces.” Managers who yell are confusing people with horses.
136 LEAD THE TEAM

Instead of rewarding results, start
consciously rewarding positive behaviors all
along the path of the project journey. This is
a sophisticated technique to improve team
performance. Unfortunately, it is also a more difficult soft
skill to master. I recommend that you set aside fixed time
each week to reward positive behaviors using this
technique.
• Draft a simple thank-you note to the employee and copy
his/her manager.
• Say, “I observed this behavior and it had this positive
affect on [the project, me or the team]. I appreciate
[name]’s contributions to this team.

You can spruce up this note with an appropriate graphic
image or by using a fancy font. But the skeleton of this note
is very basic (just two sentences). It needs to be simple
because the key to this technique is to do it often; if it is a
chore you will neglect it. The key to physical exercise is to
do it regularly on a fixed schedule. Likewise, you should
exercise your soft skill muscles on a regular schedule. Put
this recurring notice on your calendar for 2:00 pm every
Friday: “Praise Positive Behaviors.”

Skip the Oscar Ceremony
There are many other opportunities to reinforce positive
behaviors during the project journey. For example, you can
publicly praise positive behaviors at a decision checkpoint.

Avoid the stale platitude, “I would like to thank everyone
on the team for their contributions to this project.” What
good is that dribble? There is a reason that the Oscar
ceremonies put a time limit on the acceptance speech.
Reciting a long list of people who helped you get the prize
Pour On the Praise 137
is boring. Try a more targeted approach! Highlight a
particular behavior that helped strengthen your team. “I
want to thank Joe Smith for reaching beyond his normal
desk responsibility to help us resolve this particular
customer issue.” That praise is specific and meaningful.

You Can’t Buy Performance
Monetary awards are useful at times, but tend to be
overrated. I can’t remember the specifics behind any
monetary award I received in the past, but I can recall the
names and faces of people long ago who treated me right.
When employees feel appreciated at a human level they
bring their “A-Game” to the table.

Summary
I do not advocate a purely monetary reward system.
Employees don’t need additional monetary inducement to
operate at peak performance – they need encouragement
and a healthy work environment.

If you do decide to use monetary awards, be sure to reward
the members of the team who exhibit the best team
behaviors. Shower your team members often with specific
and meaningful praise. They will feel better. So will you.

5 MONITOR TRAFFIC







5
MONITOR TRAFFIC


Key Topics Covered In This Section:
• What is the most effective way to track
project progress?
• How can you scan for obstacles on the
track ahead and mitigate the potential
impact of project risks?
• How should you deal with the inevitable
changes to your project baseline?
• Limit the lines of communication.
Report Project Status 139
5.1 Report Project Status

Once the project is committed and leaves the station, you
need a system to monitor status. Is the project running on
time? If it’s behind schedule, whom should you notify? Is
there anything you can do to make up the time?

Think seriously about how you can efficiently
communicate project status with the least amount of
drudgery. If you aren’t careful, you’ll be dragged into the
reporting dungeon shackled to Microsoft PowerPoint
®
for
most of the day. Try to resist any unique reporting
requirements. In some cases, stakeholders don’t really
know the trouble that they are putting you through. If you
tell them how much time you spend reporting they may
agree to accept an existing standard report.

Project Level Reporting
People stop reading reports when they are overwhelmed
with details. So ask yourself: “What information do they
really need to know?” How can you communicate that
information in an easy-to-digest format?

The following status report can be published to a wide
audience directly after your standing meeting with the
team. It serves double duty as both your meeting minutes
and your executive report. Notice how it uses simple
dashboard headlights – red/yellow/green – to describe
status. Encourage exception based reporting. Only report
on tasks/deliverables that have a yellow or red status. Why
is it off-track? And how do we resolve the issue or mitigate
the potential risk?
140 MONITOR TRAFFIC

Template 11: Status Report
January 15
Target Launch
Quick Hits Newsletter
Project Sailfish
• Project financials indicate 10% overrun by
project completion
• Additional resources required to bring schedule
back on track
Cost
• Defect Test curve running 10% higher than
baseline. Root cause under investigation
Schedule
Scope Changes
- Change request #S0101 approved to remove
sword from beak
- Change request #S0102 rejected to add two
tone color on fin
Scope
R
Y
G
Decisions
• The Team directs Development to apply additional resources to the
test team to help bring defect ‘S’ curve back on plan
• The Team directs Finance to complete an assessment of
competitive pricing. Are our projected prices still valid?
January 15
Target Launch
Quick Hits Newsletter
• Project financials indicate 10% overrun by
project completion
• Additional resources required to bring schedule
back on track
Cost
• Defect Test curve running 10% higher than
baseline. Root cause under investigation
Schedule
Scope Changes
- Change request #S0101 approved to remove
sword from beak
- Change request #S0102 rejected to add two
tone color on fin
Scope
Project Sailfish
Y
R
G
Decisions
• The Team directs Development to apply additional resources to the
test team to help bring defect ‘S’ curve back on plan
• The Team directs Finance to complete an assessment of
competitive pricing. Are our projected prices still valid?


Report Project Status 141
Practical Application
• Draft a simple project status report.
• Ask your management to help consolidate the reporting
structure and to eliminate unnecessary bureaucratic
reporting. Do this before management asks for custom
reports.
• When reporting upward, only tell executives things they
will care about. What specific things do you want them
to be aware of or take action upon? Don’t overwhelm
them with minutia.
• Make your report easy to read. Don’t require people to
click and open an attachment. They should “see” the
report as soon as they open the email, without having to
take extra steps.
• Report on where you are going, not just were you have
been.

Pitfalls to Avoid
• If a team member’s status is exactly the same as it was
last time, encourage them to say, “pass” during your
team meeting. Why spend any time restating the same
old story each week?
• Overcome team-member resistance to reporting bad
news. Set the standard for level-headed reactions to bad
news.
• Convince everyone in your organization that risks are a
natural part of any business and that they should deal
with them out in the open in an unemotional way.
142 MONITOR TRAFFIC
• Some executives erupt in uncontrolled rage when they
hear bad news (the truth). In these situations, your first
reaction may be to deflect your anger on someone else.
Don’t do it. Go outside and yell at the top of your lungs,
but never scream at anyone on your team. Two wrongs
don’t make a right.
A final warning: Don’t trust the dashboard light to ensure
proper focus on a risk or an issue. Locomotive engineers
sometimes call dashboard indicators “idiot lights” because
people often ignore them. In daylight they can be easily
overlooked. Hence, they also install a loud buzzer to warn
when the engine is overheating or the fuel is low. The loud
alarm is so annoying that it can’t be ignored. The corollary
in our project world is that you may need to speak boldly to
get proper focus on critical issues and risks. Reports, by
themselves, don’t resolve problems.

Summary
Lobby strongly to publish a single consolidated report.
Resist requests for custom reports.

Focus reporting on issues that need resolution (exception
reporting). Get to the point quickly when you report status.
Readership declines as the number of words rise. If there is
nothing to say, don’t say it.
Debate Earned Values 143
5.2 Debate Earned Values

Accounting systems today are a bit archaic in that they tend
to produce one-size-fits-all progress reports on fixed cycles
like month end, quarter end and year end. Even our old
time train conductor had a better system to measure project
progress – he carried a pocket watch which he would check
at regular intervals during the run to see if the train was on
time or behind schedule. This was a very useful and
efficient project reporting system. If the train was running
behind schedule, the conductor would yell to the engineer
to stoke the fire and pick up speed.

Common sense tells us to check on project activities all
during the delivery run. You shouldn’t have to wait until
month end for your accounting reports to tell you if
something is amiss. Unfortunately, the accounting systems
in most companies do not support the reporting goals of
project management which follow an economic model
based on reality. This table illustrates the differences.
144 MONITOR TRAFFIC
Table 3: Accounting Vs Economic Project Reporting
Accounting Model Economic Model
Projects open/close based
on ledger schedule.
Projects open/close at any
time.
Functional manager
builds 12-month budget
during planning cycles
(once or twice a year).
Delivery teams build
multiple year, time-phased
budgets during
concept/develop phase.
Budget equals summation
of expenses by accounting
major/minor for
accounting period.
Budget equals summation of
expense items by work
breakdown structure (WBS)
activity.
Performance tracking
focuses on budget to
actual expense variance.
Performance tracking
focuses on earned value
progress against the baseline
budget.

The difference between accounting and project centered
reporting leads us to three fundamental questions that
finance must answer before we can deploy an effective
earned value system:
• How do we create useful project budgets?
• How do we efficiently track actual expenditures against
the project budget baseline?
• How do we reflect actual progress against the outlaid
expenditures?

Debate Earned Values 145
"All I've ever wanted
was an honest week's
pay for an honest day's
work."
– Steve Martin
The accounting community, for instance, asks questions
like “How much of your contractor budget did you spend
this month?” In the project world, we ask a much more
sophisticated question: “How much progress did we make
this month and how
much did it cost?” By
taking progress into
account, an earned
value system inherently
promotes a more
realistic projection of
final costs.

What is an Earned Value?
An earned value is a predetermined amount of value
(budget) that is claimed, or earned, when the corresponding
work is accomplished. It is a measure of progress. For
example, when you start a task the earned value is 0%
complete. When you finish you are at 100% complete.

The merits of the earned value approach to performance
reporting are rarely debated. Instead, arguments swirl
around the infrastructure to deploy such a system. Niccolo
Machiavelli warned about resistance to an earned value
reporting system centuries ago:
“… there is nothing more difficult to plan, more
doubtful of success, more dangerous to manage, than
the creation of a new system. For the initiator has the
enmity of all who would profit by the preservation of
the old institutions and merely lukewarm defenders in
those who would gain by the new ones.”
32



32
Il Principe (The Prince) by Niccolo Machiavelli, published 1532.
146 MONITOR TRAFFIC
A Practical Earned Value System
There are two major inhibitors to rolling out an earned
value system. First, the accounting system is by nature rigid
and inflexible. Second, the cost of collecting earned value
progress data may exceed the value of the report. That is
why I sometimes cheat and use a simple hybrid earned
value worksheet to track project progress (See template 12:
Earned Value Report.

In this report, you can outline your major activities down
the rows of this worksheet. At appropriate intervals ask the
line functions, “How are you doing?” Report work
scheduled and work complete with percentages. This lets
you assess if you are on track or behind.

In the first activity in this table, we should be 60%
complete, but we are running behind at 40% earned value.
This raises the obvious question, what are we going to do to
get the activity back on track? Or, if we have no way to
make up time then how far to do we need to push out the
end date for the activity?

Don’t mandate earned
value reporting unless
you have an efficient
system to collect the data.
The earned value purists would reject this report because it
fails to aggregate the individual finite work packages;
instead it tracks progress at a higher level of activity
consolidation. But look at what’s right about this report –
it’s very simple to create, it gives you some feeling for
what activities are falling behind schedule, and it helps you
assess the impact to the completion date. True, it doesn’t
follow all of the
official earned value
handbook rules, but it
gets the job done with
minimum data
collection disruptions
to the team.
Debate Earned Values 147


T
e
m
p
l
a
t
e

1
2
:

E
a
r
n
e
d

V
a
l
u
e

P
r
o
g
r
e
s
s

R
e
p
o
r
t


#
A
c
t
i
v
i
t
y
F
Y

B
u
d
g
e
t
W
o
r
k

S
c
h
e
d
W
o
r
k

C
o
m
p
l
e
t
e
W
o
r
k

S
c
h
e
d
W
o
r
k

C
o
m
p
l
e
t
e
S
c
h
e
d
u
l
e

V
a
r
i
a
n
c
e
A
c
t
u
a
l

C
o
s
t
C
o
s
t

V
a
r
i
a
n
c
e
1
0
A
c
t
i
v
i
t
y

1
1
,
5
0
0
$






6
0
%
4
0
%
9
0
0




6
0
0









(
3
0
0
)








1
,
1
0
0
$



(
5
0
0
)
$





2
0
A
c
t
i
v
i
t
y

2
2
,
0
0
0
$






4
5
%
2
0
%
9
0
0




4
0
0









(
5
0
0
)








1
,
5
0
0
$



(
1
,
1
0
0
)
$


3
0
A
c
t
i
v
i
t
y

3
3
,
0
0
0
$






2
0
%
4
0
%
6
0
0




1
,
2
0
0






6
0
0









1
,
1
0
0
$



1
0
0
$






4
0
A
c
t
i
v
i
t
y

4
1
,
5
0
0
$






6
0
%
7
5
%
9
0
0




1
,
1
2
5






2
2
5









1
,
1
0
0
$



2
5
$








5
0
A
c
t
i
v
i
t
y

5
1
,
5
0
0
$






6
0
%
7
5
%
9
0
0




1
,
1
2
5






2
2
5









1
,
1
0
0
$



2
5
$








T
o
t
a
l
4
,
2
0
0

4
,
4
5
0






2
5
0









2
2
,
4
0
0
$

(
1
,
0
7
5
)
$


Y
T
D

P
e
r
c
e
n
t
Y
T
D

D
o
l
l
a
r
s

148 MONITOR TRAFFIC


Conceptual Forecasting
Here is another simple tool you can use to describe project
progress. This is a “concept” chart that requires very little
data to construct.
Template 13: Conceptual Earned Value Drawing
Today
YTD Schedule
Efficiency
Earned Value
(EV)
Planned Value
(PV)
C
u
m
u
l
a
t
i
v
e

V
a
l
u
e
Time
Budget at
Completion
(BAC)
Projected
Project
Delay
Projected
Cost
Overrun
Estimate at
Completion
(EAC)
Today
YTD Schedule
Efficiency
Earned Value
(EV)
Planned Value
(PV)
C
u
m
u
l
a
t
i
v
e

V
a
l
u
e
Time
Budget at
Completion
(BAC)
Projected
Project
Delay
Projected
Cost
Overrun
Estimate at
Completion
(EAC)


In this template, all of the lines are sketched without real
data except for the vertical line that marks today’s date. I
ask my delivery team to tell me their ballpark current
efficiency level. They may say that “we’re running at about
75 percent efficiency. That observation let’s us eyeball the
year-to-date (YTD) schedule variance. I can also ask them
if this efficiency rate will continue or if we will improve
productivity and catch back up to plan. These discussions
help us draw a bead on the estimate to complete (ETC)
forecast.

At a high level, we can describe the schedule delay, the
variance at completion and other important project forecast
variables by simply drawing lines on a blackboard (without
Debate Earned Values 149
real supporting data behind the lines). This isn’t intended to
be a thorough report; it is instead a method of conceptual
forecasting that helps you introduce these reporting
concepts to your team.

Personally, I’d love to sit behind the gauges of a finely
tuned earned value data dashboard. But that system doesn’t
exist in my organization and I am reluctant to manually
collect large reams information manually each month. Once
a painless infrastructure for collecting the data arrives, I’ll
be the first to join the earned value purist aristocrat club
(EVPAC). Until then I’ll use the surrogate reports
described in this chapter since they balance the cost of
collecting the input with the value of the report.

Summary
Use data, if it exists, to create a robust earned value project
progress report. If the data doesn’t exist, don’t ignore these
concepts. Draw a few lines on a white board or a sheet of
paper to facilitate the discussion with your team. You may
find out that your team can intuitively forecast the project
progress trends better than teams that rely on reams of
actual data.


150 MONITOR TRAFFIC
5.3 Scan Your Risk Radar

Dangerous railroad intersections are protected by
a crossing gate. In addition to the gate, flashing
lights and loud bells warn traffic when a train is
approaching. Don’t you wish every risk were
announced by bright flashing lights and a gate? This could
help avert many disasters.

Before we build a risk warning system, we need to make
sure that we have a common understanding of a risk. Do
you know the difference between a risk and an issue?
Here’s a simple definition: a risk is an event (either positive
or negative) that may or may not occur. That is, its
probability of occurrence is less than 100%. An issue, on
the other hand, is a risk that has materialized with 100%
certainty of occurrence. Educate your team so that they use
these two terms correctly.

Which Risks Deserve the Spotlight?
The effective project manager communicates relevant risks
and manages them with a proactive plan. Which risks
deserve special attention? To answer that question, let’s
suppose you have already brainstormed a list of potential
risks and sorted them by potential severity as in this
traditional risk plan:
Scan Your Risk Radar 151

Template 14: Risk Plan

Risk Event
Proba-
bility

Impact

Response
O
SW Interface
between widget and
gadget may not
complete in time
for production start.
High $$ Reduce: Hire
programmer with
high skills in this
area to perform
work.
O
Competitor
launches their
product six months
before us.
Low $$$$

Retain: Our
schedule is already
compressed to the
highest level of
acceptable risk.

Notice that we are taking specific action against the first
risk by hiring skills to complete the software interface. But
in the second risk we essentially “do nothing” or retain the
risk even though the potential dollar impact is greater. This
illustrates an important principle of risk management: there
are times when an appropriate response is no response.

Consider this example; marketing is concerned that a
competitor may beat us to the punch by launching their
product before us. They may describe this risk without
presenting any facts to support the threat. The knee jerk
response is to compress the schedule further to counter this
perceived threat. If your schedule already has a high degree
of parallelism, however, then you are better off
courageously defending your schedule then committing to
an unreasonable plan. Hence, the table above “retains” the
second risk which means we will live with the
consequences should the risk materialize.

152 MONITOR TRAFFIC
Monitoring Risks
You can survey risks at the same time you collect project
status. First you ask the team to report on the status of their
project deliverables. Then you survey for live issues that
have materialized and finally, you can ask them to report
on any risks they see on the horizon.

Here is a useful technique to monitor risks on an ongoing
basis while keeping emotions at bay. Picture an air traffic
controller’s radar screen. Radars indicate the presence and
movement of objects out of the range of vision. Each blip
on the screen represents a risk. Tell management, “A risk
just entered the outer circle of the screen. It may not cause
any damage, but I’ve got my eye on it.” As the project
progresses, warn them if the blip is moving closer to the
center of the radar circle (probability of occurrence is
rising). If a risk moves to the center of the radar screen,
then a collision is imminent (the risk is about to transform
into an issue). Executives appreciate this kind of proactive
risk reporting. On the other hand, if you have a reputation
for discussing problems after they become an issue, then
you are in the wrong profession.

Encourage the same type of proactive reporting in your
team. When an issue surfaces without any headlight
warning in a functional area, ask the team member to
explain: “Why were we blindsided by this risk?” There
may be a good reason. You simply can’t anticipate every
risk event. On the other hand, if one member of your team
is caught off guard repeatedly, you may have a skills issue
to address with that employee.

Scan Your Risk Radar 153
Individuals may be reluctant to surface a serious risk.
Perhaps they feel that they can mitigate the risk or resolve
the issue before it gets completely out of control. How
often do we hear: “I didn’t want to bother you with a
potential problem?” or “I thought that I could resolve it
before it got out of hand?” Perhaps they knew that they
were in trouble, but decided to be flogged tomorrow (when
they get caught) instead of today. In any case, make it
known that these are not valid excuses for turning off the
risk radar.

The Outrage Factor
Dr. Peter M. Sandman, an expert in communicating crisis,
advocates another dimension to risk management that is
often overlooked by the risk planner – Outrage. There are
some risks where the outrage impact is greater than the
material dollar impact. Case in point is the Ford Pinto. To
fight competition, Ford rushed the Pinto to market with a
defective gas tank design. The design flaw surfaced before
production. Ford prepared a risk impact analysis that
compared the cost of major burn injuries with the $11 cost
per car to fix the flaw. At that time, the auto industry was
fond of saying, "Safety doesn't sell," so they retained the
risk. With hindsight, we can appreciate that the actual
damage to Ford’s brand image (outrage) far outweighed the
monetary damage from insurance claims. In this case, the
risk assessment based solely on quantitative numbers was
flawed.

This concept of including outrage impact in your risk
assessment can be easily extended beyond the area of
safety. For example, aren’t you outraged when product
documentation is difficult to follow? The risk event in this
case is that the customer can’t get the product up and
running and must call the service hotline for help. The
business impact is $40 per call to an outsourced service
154 MONITOR TRAFFIC
center in India. To this figure we should add an outrage
penalty from lost revenue after the consumer tells friends
about the bad setup experience. Thus, the proper decision
analysis compares the total impact (service center cost +
outrage) with how much you save by skimping on a 10-cent
quick setup guide.

Include the impact of “outrage” for the following types of
risk events:
• A safety related event. One event is unacceptable.
• A feature / function that is difficult to use.
• An event that could negatively impact the product or
company brand image.
• An event that might upset your sponsor or important
people in your management chain.

Practical Application
• Use the risk radar metaphor to illustrate the concepts of
an early warning system with your team. Tell your
team, “You will never get in trouble for surfacing risks
early, but if you blindside me or management, there
will be dire consequences.”
• Make retained risks “transparent” by including them in
your risk table. They are just as important as the risks
that you consciously transfer or reduce.
• Include outrage factors in the impact assessment.
• Don’t treat every risk as equal. Agitate people who
become apathetic toward major risks. Wake them up.

Scan Your Risk Radar 155
Summary
Your goal is to create an early-warning risk monitoring
system. This helps diffuse emotions when/if the risk
graduates into an issue. People won’t be shocked if you’ve
been discussing the potential problem for some time. And
you will have a well reasoned damage control plan ready to
execute should the risk materialize as an issue.

156 MONITOR TRAFFIC
5.4 Control Change

The high performance project team is ready to change
course and speed in response to unplanned events during
the journey. They manage their response with a formal
change control process. A well-run railroad requires an
approved change request (CR) to modify these project
commitments:
• Scope – Function, performance and quality
commitments
• Time – GA date or other critical schedule milestones
• Cost – Expense and other business case variables

An efficient change control process will empower your
team to make immediate decisions on certain project
parameters without passing them through a gauntlet of
bureaucratic overhead. Your first course of business, then,
is to establish the rules for which decisions can be self
approved by a team without sponsor oversight. The
delegation table might look like this:

“Self Approved” Change Requests
Scope Addition/Removal of secondary features
and functions
Time +/- 2 week change to a key milestones
Cost +/- 10% changes to budget
Performance No delegated authority
Quality No delegated authority

Control Change 157
You aren’t trying to undermine your sponsor’s authority
with this delegation table; you are trying to accelerate
response time to minor changes and to build flexibility into
the process. You can, if you’re the nervous type, document
the decision to “self approve” a given change request in a
note to management so that they don’t come back later and
say, “You didn’t have the authority to make that decision.”

Use this template to assess the impacts from a change
request.
Template 15: Change Request Summary


· Change request # (from project manager)
· Initiator
· Description
· Proposed change
· Impacts to baseline:
• Scope
• Schedule
• Expenses: DE, SG&A, Capital, Other
• Product cost
• Revenue
• Performance
· Impact to other projects or programs
· Impact to processes
· Business case
· Competitive analysis
· Dependencies and risks
· Lessons Learned

Note: You are responsible for incorporating comments
and securing team consensus prior to our team meeting.
Team members should make an effort to avoid negative
positions or escalations.
158 MONITOR TRAFFIC
Butter Up the Guy Making the Change
Here’s a scene that challenges the level of methodological
rigor we apply to change control. Say you enter your new
home during the early construction phase, just after
framing, and you notice that the center ceiling electrical
outlet in the living room is not bracketed with additional
supports. You want to install a fan later, so you ask a
carpenter onsite if he will frame it out. Since the walls are
unfinished this task should take about 30 seconds using
scrap lumber lying around.

You “Can you do me a favor and nail that 2x4 in
that ceiling outlet to support a fan later?”
Carpenter “Was this additional framing in the
contract?”
You “No, but it will only take 30 seconds.”
Carpenter “Don’t tell me how easy my job is.”
(Note: he is staring at your delicate hands.)
You “But it could have been done already.”
Carpenter “Sorry, I can’t do it without approval. It’s
the rules.”

Were anyone’s interests well served by this exchange?
Over the next few hours, you track down the prime
contractor who agrees to perform this minor job for an
extra $75. A more effective approach might have been to
just offer the carpenter $20 on the spot to frame the outlet.
You could file the task under the “Don’t ask, don’t tell,”
streamlined change-control procedure.

Some people might argue that this sets an unhealthy
precedent; it opens the door to other people adding
additional scope to the delivery basket. It is true that
unplanned tasks, even easy ones, can cumulatively increase
project risk. This should be cause for concern. However, to
those who would complain about paying a subcontractor
Control Change 159
$20 to do a simple task like nailing a board on the spot, I
say give the carpenter a few dollars and forget about it.

Also remember that you should never make the guy
holding the hammer mad. Telling people who perform the
work that “their job is easy” guarantees substandard
performance levels.

Reduce the Number of Change Requests
You want to minimize the number of post-commitment
project changes as an ever-changing plan is the recipe for
schedule delays and cost overruns. You can reduce the
number of change requests by analyzing requirements
carefully and by maintaining an open dialog about project
objectives before you book your plan. In other words, make
sure that your team is completely interlocked before you
sign the commitment contract.

After the plan is committed, stick the responsibility for
managing any change request through the process on the
person who initiates it. Say, for example, that the delivery
organization is going to delay a key schedule milestone,
then why shouldn’t she document the proposal and impacts
using the form provided? Let her fill out the template; you
are not her personal administrative assistant. She can
schedule meetings, collect information and consolidate
responses to the change request. Likewise, if marketing
wants to add scope to the offering, then they should carry
the administrative burden for processing the change
request. Your role is to facilitate the process and assist the
team to reach a consensus decision.

The team will naturally resist this “extra” work. It is so
much easier to toss the request to you to manage. But there
is sound basis for requiring the initiator to carry the
administrative workload:
160 MONITOR TRAFFIC
1. The initiator is motivated to put earnest effort in the
front end planning process since this will reduce the
number of change requests later down the line. The
theory here is that it is easy to book a correct plan
than to modify one later.
2. The initiator will think twice before triggering a
spurious request since processing one is a “pain in
the neck.”

For these two reasons, the absolute number of change
requests will fall if you put the burden on the initiator to
carry one through the process. Another way you can reduce
the number of change requests on future projects is to
analyze each one at the end of project execution. Make this
exercise a part of your lessons learned at project finish and
present it to management.

Table 4: Change Request Assessment

#

Initiator

Description

Status
Process
Assessment
O
Marketing Add widget
scope to plan
Sponsor
approved
05/01/08
This feature
should have been
anticipated in the
baseline plan
since competition
already had it.
O
Develop-
ment
Delay test
end date by
two weeks
Team
Self
approved
07/01/08
Defect resolution
rate fell behind
schedule because
resources were
diverted to
another project.

This table asks, “Was there any way we could have avoided
the change request by planning better in the front end?”
The first CR in this table was avoidable and the initiator
Control Change 161
now feels a little public pressure to plan better the next
time.

Look for pattern abusers of the change request process.
How would you feel if nine out of 10 change requests came
from your function? This puts peer pressure on functions to
avoid unnecessary churn in the future.

Practical Application
Projects never travel in a straight line; they switch tracks in
response to market changes or poor planning. Consider
implementing these guidelines to streamline the change
request process.
• Permit teams to self approve change requests that fall
within defined boundaries. Be reasonably flexible when
applying procedures and rules.
• Use a standard template to assess the change request so
that you don’t forget to assess important areas that
might be impacted.
• Require that the initiator of the request shepherd the
proposal through the process.
• Present a summary of all change requests to
management as part of the close out lessons learned.

Summary
Enforce rigorous change control. This protects all members
of your team by giving them an opportunity to document
impacts to their function. Once the change request is
approved, it becomes your new project baseline for project
reporting purposes.
162 MONITOR TRAFFIC
5.5 Time Your Run

What is the first thing you do when you reach your final
destination by train, plane or automobile? It is likely that
you look at your watch and check the time. Are you early
or late?

In the same manner, your team should complete a scorecard
after you deliver the project. Your team can pencil in the
baseline column of this scorecard when they commit their
plan. Then everyone will know how you intend to measure
project success. The scorecard might also include a section
for innovation and learning. Did your team improve any
processes or learn anything at all during project execution?
If so, document it here. Demonstrate your value to the
business.

Here is a sample scorecard you can use to compare actual
project performance against the baseline parameters. This
scorecard is prepared at the end of project execution phase.
It should be the first thing you review at the start of your
next project.
Time Your Run 163
Template 16: Post Launch Project Scorecard
Project Scope Baseline Current
Mileage Per Gallon 60 52
GPS Parent Alert - ×
integrated iPod - -
New Building Blocks Parts 17 14
# of change requests NA 19
Schedule (weeks)
Concept 24 26
Develop 52 52
Execute 156 200
Finish 8 10
Project Cost
Dev Expense $10M -
Mfg Capital $100M -

Project Quality
Manufacturability 80 $72
Serviceability 75 73
1st yr defects 13 -

Business Success
Revenue $M $2,300 $2,800
Gross Profit $M $900 $1,000
Platform Cost / unit $15,000 $1,650
Weeks of Inventory < 3.0 -
ROI 11% -

164 MONITOR TRAFFIC
Should You Handicap the Run?
Teams frequently debate what they should compare their
timed runs against: is it the original baseline committed
plan or the last approved change request? The answer to
that question is simple. Your weekly project tracking
reports should compare against the last formally approved
change request. Why continue to show a variance every
week against the original baseline when executives have
already approved the change? You’ll just be poking needles
in your eyes. Executives already understand and approved
the change.

Are you lowering your standards for success by measuring
against the approved change requests? Not necessarily. A
change could conceivably raise the success hurdle. For
example, an approved change request could compress the
schedule or add scope requirements. In these cases, you are
raising the hurdle for success.

That said, it is useful at the end of the project to compare
the actuals against both the final approved change requests
and the original baseline. That comparison may yield useful
insights that you can apply to your next project. If ten
projects in a row require a post commitment change in
schedule in one direction, this should prompt a closer
evaluation of the baseline schedule for the next project.
Teach your team that it is easier to book a realistic schedule
right out of the gate rather than run the change request
gauntlet later.
Time Your Run 165

Summary
The project scorecard times your project run against key
project parameters like scope, time, cost, and quality. This
prompts you to explain variances to the baseline
commitments. This analysis can be very insightful,
especially if you are honest with both yourself and your
team.
166 MONITOR TRAFFIC
5.6 Limit Lines of Communication

Communication is a good thing, right? Not necessarily!
Some communication is detrimental to your project. For
example, decisions secretly negotiated by executives in
smoke-filled backrooms complicate your job immensely.
Another classic example of unproductive communication is
the seemingly innocuous note sent to an extended
distribution list that triggers a “reply all” email storm.

Reduce Communication Channels
You can reduce unproductive noise in the system if you
channel communications through the core members of your
team. That is why project management methodology
recommends that we keep our team size small (eight to 12
members). This formula demonstrates why it is in your best
interest to limit the lines of communication:

Channels = (Team Size x (Team Size – 1)) / 2

Thus,
If your team size is five, the open communication
channels equal 10.
If your team size is 12, the open communication
channels equal 66.

It should be obvious that channels grow exponentially with
team size. However, it is important to note that the formula
really describes the potential open communication
channels. You only reach the maximum number if
everyone is talking to everyone else at the same time. So
regardless of team size, remind people in your channel map
to resist broadcasting complex topics and issues to a wide
audience.
Limit Lines of Communication 167

Map Your Channels
A visual view of communication channels can help you
identify all of your open channels. To create this personal
map of communication channels, just review your calendar
for a sample month and record each standing meeting: Who
are you talking to and what is the frequency? Also note to
whom you speak regularly via instant messaging, email and
the telephone. This map illustrates what economists call
diseconomies of scale.

Notice that your core team represents a very small number
of total communication connections. This will remind you
to streamline the other channels. Other channels include:
There are special assignments, standing meetings and
regular phone calls to Mom. There are communications
with executives, managers, auditors and various other
sundry bureaucrats. Consequently, just keeping your core
team small won’t fix communication overload. You must
strive to redraw (shrink) the whole map by eliminating any
unproductive channel.
168 MONITOR TRAFFIC
Figure 10: Map of Communication Channels
Core Team
Development
Service
Finance
Manufacturing
Product Assurance
User Center Design
Marketing
Procurement
Other Channels
Weekly Meeting
w/Manager
Weekly
PM Lunch & Learn
Instant Messages
Telephone Calls
Random Audits
Decision Checkpoints
Other Meetings
(avg. 12 per week)
Core Team
Development
Service
Finance
Manufacturing
Product Assurance
User Center Design
Marketing
Procurement
Core Team
Development
Service
Finance
Manufacturing
Product Assurance
User Center Design
Marketing
Procurement
Other Channels
Weekly Meeting
w/Manager
Weekly
PM Lunch & Learn
Instant Messages
Telephone Calls
Random Audits
Decision Checkpoints
Other Meetings
(avg. 12 per week)
Other Channels
Weekly Meeting
w/Manager
Weekly
PM Lunch & Learn
Instant Messages
Telephone Calls
Random Audits
Decision Checkpoints
Other Meetings
(avg. 12 per week)


Limit Lines of Communication 169
Practical Application
• Keep your core team size small.
• Visually draw a mind map of your communication
channels to identify and shut down unnecessary
bottlenecks in communication channels.
• Look for ways to consolidate reporting. Try to use a
single report format to satisfy multiple stakeholders.
• Persuade your team to use the telephone and face-to-
face meetings to discuss complex issues rather than
play multiple rounds of ping pong in email.
• Encourage your team to work directly with each other
(and not use you to broker all requests).

Summary
Communication overhead adds friction to the delivery train.
Use a mind map of your communication channels to pin
point and eliminate unnecessary channels and bottlenecks.

170 MONITOR TRAFFIC
5.7 Control Your Email

Communication was difficult on an old time train because
of background noise and because the crew was dispersed
across several cars. Today, it is much easier to stay
connected via email, instant messaging, cell phone or
Blackberry
®
, but I’m not sure that overall communication
has improved.

Before the graphical user interface, business
communication was terse and direct. In the 80s, I received
five notes a day, and all were under 10 KB.
33
Now, I’m
blasted by over 100 notes per day and my system
administrator constantly pesters me to reduce my mail file
size. Do you collect piles of dusty old notes in your
electronic mail box?

It is shocking how many messages make it through spam
filters yet still have nothing meaningful to say. Let’s
consider some ways we can clean our email satchel by:
• Resisting the “Peek & Keep” game
• Preventing email blizzards
• Teaching email etiquette

Don’t Play the “Peek & Keep” Game
Never scan your inbox just for fun. It is a trap to peek
inside a note, scan it quickly, and then exit out without
taking some action because you deemed low priority. This
process of “Peek & Keep” is a grossly ineffective use of
time because you condemn yourself to reread the same note

33
Computer storage is measured in bytes. How appropriate since it
takes such a huge bite out of our … time!
Control Your Email 171
again. Over the course of a month, you may peek at the
same note four or five times just to remember what’s
inside.

Practical Application
• Set aside uninterrupted time to manage your inbox.
• Never open a note unless you have the time and
inclination to do something with it.
• Follow the No Peek & Keep Rule. Disposition every
note in one pass:
o Delete the note if it has no long-term value.
o Answer the note. Then file or delete it.
o Forward the note. Then file or delete it.
o Copy and paste the key content of the note into your
meeting agenda so that you can discuss it with the
team. Then file or delete it.

Your goal is to move every note out of your inbox in a
single pass. Here’s another tip. Keep a draft meeting
minutes document within easy reach of your inbox. Say
you receive an answer to an important question. Document
it immediately in the draft minutes document. Delete the
inbox note once you have the contents captured. You will
find that you can write a significant portion of your minutes
before you even hold the meeting.
172 MONITOR TRAFFIC
Prevent Email Avalanches
When snow accumulates on mountain ridges, hikers are
taught to be quiet so that they don’t trigger an avalanche.
This same warning should accompany these email buttons:



Pressing these keys starts a communication avalanche.
Have you ever been trapped in a Reply All email blizzard?
Are you irritated when you open a note stamped urgent
only to find out that it contains pedestrian information? Do
you wonder why you are on copy for so many notes that do
not require your attention?

Teach your team to pause before they press one of those
keys:
• Tell your team that you are going to track the number
of times they hit one of the offending keys
unnecessarily. The team member who writes the most
notes may quibble: “who are you to decide what is
important?” Respond that it is your inbox, who else
should analyze it?
• At each meeting, mention if the number of spurious
notes hitting your reader has gone up or down each
week. Don’t do a formal count or statistical analysis;
just give your overall impression.
• Lead by example. Ask your team if you are
inadvertently triggering email blizzards. Admitting that
you have a problem is the first sign of recovery!
Control Your Email 173
• Tell your team that you’ve created a mail filter that files
cc: notes in a special low priority folder. You will only
read those notes if you have spare time.

Teach Email Etiquette
Resist writing notes to executives unless absolutely
required. If you do write to an executive, be very brief and
clearly state what you expect that executive to do.
Executives get hundreds of emails a day; they do not have
time to read rambling notes.

From: Mr. Rude
To: John Langlois
Subject:
__________________
YES
Some notes are so poorly
constructed that the effort to
read them outweighs their
value. Here’s an actual note
that didn’t provide enough
context clues for me to even
figure out the question! To make matters worse, I couldn’t
pick up the phone and ask the sender what it was about
because Mr. Rude didn’t leave a closing address and
telephone number.

The next email on the same topic is much more courteous:
174 MONITOR TRAFFIC
Figure 11: Email Etiquette

To: John Langlois O
From: Joe Polite
Subj: Answer to Modem Question O
__________________________________
John,
You asked the question, will our modem be
homologated for India. The answer is Yes. O
__________________________________
Joe Polite
Modem Test Engineer
RTP, NC
Phone: 919 xxx-xxxx O

Let’s review the important features of this second note:
1. It addresses the recipient by name. When you leave the
opening address blank, you are really saying, “Hey,
you!” That’s impolite. People respond more quickly
when addressed personally.
2. This note includes an informative subject line. It tells
the recipient what the note is about – so someone
scanning their email knows what is urgent and what can
wait.
a. If any mail hits your inbox without a subject line,
add one before you forward it on to someone else. If
the subject line is unclear, rewrite it.
b. Encourage your team to use a relevant subject line
descriptor. Appropriate ones include: Action, FYI,
and Decision Required.
3. This note fits nicely on a single screen. Don’t make
people page down to find the question or the answer.
Put the question and answer together.
4. The closing line in this note includes a telephone
number. If you sense that a complex topic is going to
Control Your Email 175
ping-pong back and forth over several emails, just pick
up the phone to resolve it.

Practical Application
• Limit the number of notes that hit your inbox by
reaching an agreement with your team not to abuse
certain keys like Urgent, Reply All and Copy.
• Make it your practice to disposition every note in a
single pass. This technique will take some practice to
master, but the rewards justify the learning curve.
• Train your team to write polite and meaningful notes.
This will reduce the time it takes to read and interpret
the contents of each note.

Summary
Why do we continue to give employees an email account,
essentially a legalized form of harassment, without any
training? Email is major drain on business productivity. It
seduces us into thinking that we are more productive just
because we can contact more people during the day.

Manage your inbox. Warn your team about the pitfalls of
email, and teach them good email manners. These things
will reduce the level of unproductive noise in your email
“in” basket.

176 MONITOR TRAFFIC
5.8 Fireside Chat

We love to dazzle executives with stylish reports. There is
nothing wrong with high-quality presentations. But how
much time do you devote to creating and tweaking the
content? And how many review cycles does it go through
before it reaches the final decision maker?

Use fireside chats to
pull your team out of
the presentation salt
mine.
We can short-circuit the mind numbing slide production
carousel by advocating a new presentation format called the
“fireside chat.” With this
technique, you speak
from a single slide that
outlines the key topics.
You would be surprised
how many topics can be
adequately vetted this way. Using an outline will, of course,
put tremendous pressure on you to know your material
inside and out and to speak intelligently about the facts. On
the other hand, you will spend less time creating pretty
packages in the presentation salt mine.

Before you dismiss this technique, consider that it has been
used successfully to discuss very complex issues. Winston
Churchill used this format to discuss wartime progress with
his people. Listen to one of his radio addresses and you will
see that words alone can be a very effective means to
communicate status. To this day, the President of the
United States also uses this format for his Address to the
Nation. Can you image if he used Microsoft PowerPoint
®

slides to make his argument? That would detract from his
message. Since Winston Churchill and the president use
this format to discuss some pretty weighty topics, why do
Fireside Chat 177
we assume that our paltry business issues require a 30-page
slide deck to explain to management?

Don’t think for a moment that this fireside chat format only
suits politicians. Lou Gertsner, IBM’s former chairman,
railed against the preoccupation with slides at IBM. He
directed executives to talk directly to the topic without
using slides as a crutch. Unfortunately, when he retired, the
dinosaurs that had previously fed on pretty slides were
cloned from DNA in tree sap and they now roam our
business island once again.

Practical Application:
• Ask your management if you can discuss a topic/issue
in a fireside chat format.
• Acknowledge that you may feel uncomfortable with
this format since you don’t have a stable of
speechwriters to help you prepare your presentation.
Ask them to be patient with you as you learn how to
communicate effectively in this forum.
• If your executive requires a chart deck, ask him or her if
you can use an existing deck without any
customization. Warn them that you may wander around
the slide pages a bit, but this is preferable to spending
excessive administrative time customizing slides for
each reviewer.

Pitfalls to Avoid
• This format works best when you are very
knowledgeable about your material. Bring in a subject
matter expert for backup. Call on the expert if you
require help.
178 MONITOR TRAFFIC
• Carry out deep research on the topic. There is no excuse
for lack of preparation since you now have more time to
analyze the facts.
• If directed to create large presentation packages, use
very few fonts, formatting options, and pictures. Too
many design elements will consume valuable
preparation time and distract the audience.

Summary
Does it strike you as odd that we spend more time creating
slides to describe issues than we spend solving real
problems? Everyone likes a pretty picture and I’m no
exception. But ask yourself, “What is the cost of creating
and reviewing these pictures?”

Persuade your executives to close the chart production
mine and to dismantle the multiple person review gauntlet.
Your immediate manager may counter that an executive’s
time is very valuable and that it is risky to face a superior
without perfect charts. However, a rational executive will
be willing to work with you to experiment with this format
since it frees you and your team to spend more time solving
problems and that is good for business.


6 TUNE YOUR MANAGEMENT
ENGINE








6
TUNE YOUR MANAGEMENT
ENGINE

Key Topics Covered In This Section:
• How do you assemble an end-to-end
Management System?
• Why is it important to mind your own
business?
• How can you prevent decision paralysis?
• Should you create a Project Management
Office (PMO)?

180 TUNE YOUR MANAGEMENT ENGINE
6.1 Install Meaningful Dashboards

Who oversees the operations of your project and what
information is critical to each stakeholder in your project
environment? If you fail to answer these basic questions
then your management system will run amuck and start
spewing out large streams of indecipherable data.

You know that your management system is out of control
when your email inbox is busting at the seams and people
are acting on information outside of their domain of
responsibility. An effective management system, on the
other hand, will generate timely and targeted reports for
specific stakeholders. The project manager, for example,
needs detailed information about his schedule and crew.
The portfolio manager takes a higher-level view of the
landscape while watching all the projects trains.

Before we sketch a few dashboards to oversee our railroad
operations, we would be wise to confirm our overriding
management philosophy. You can do this by prompting
your executives to consciously tune the following levers in
this system:

1. Matrix strength. You may want to work in a strong
matrix, but your executive(s) can choose to leave
power and authority in the functions.
34

2. Formality. How formal are your processes and
procedures? Are some checklist items mandatory
and others optional?

34
Warning: the first tuning lever in this list, matrix strength, often
causes the greatest stress in the system since people in power don’t
like to relinquish it.
Install Meaningful Dashboards 181
3. Centralization. How much decision-making
authority does the team possess? For example,
executives may delegate decision authority to the
team to “self-approve” certain change requests that
impact the baseline commitment within an agreed to
variance.

Dashboards
At the heart of an efficient management system is the
principle that stakeholders should focus on their domain of
influence. Each dashboard should present useful
information to a specific person. This will drastically
reduce the noise in your communication channels.

If people disagree about which dashboard they own, you
have a problem so design the instrumentation panel with
your key stakeholders before you implement a management
system. The table below helps discuss the roles of various
stakeholders in this system.
182 TUNE YOUR MANAGEMENT ENGINE

Figure 12: Customized Dashboards
Persona Role Dashboard


LeLand Stanford,
Railroad Tycoon
Portfolio
Mgr.
Investment Direction Compass
Market Planning Charts
Competitive Positioning
Prioritized Portfolio
Program Headlights



C. A. Alford,
Conductor
Project
Mgr.
Earned Value Speedometer
Expense by Activity
Key Milestones
Project Headlights
Status on High Level
Deliverables


Casey Jones,
Engineer
Functional
Mgr.
Resource Availability Gas
Gauge
Skills Inventory
Technology Roadmaps
Function Headlights
Status on Functional
Deliverables


Pinkerton Agents
Corporate
and
Finance

Business Conduct Guidelines
Policies and Procedures
P&L by Accounting Period
Expense Reports


Install Meaningful Dashboards 183
After you sketch the instrumentation for your management
system, you must determine the frequency of data
collection. Carefully balance the cost of collecting the data
with value the data provides. Also consider the pace of
change in your organization. If things are relatively stable,
then you may only need to report once per month as
opposed to weekly.

In dysfunctional organizations, there is a tendency for
individuals to peek at everyone else’s dashboard. You
generally want folks to look straight ahead and mind their
own business. When people start fiddling with the
instruments on someone else’s dashboard, they
dramatically increase the level of unproductive noise in the
system. For example, the portfolio manager shouldn’t go
directly to the functional manager for project status. The
conductor is the focal point for all project communication.
When the conductor loses control of the project
communication channels, chaos reigns.

Practical Application
• Sketch your management system instrumentation
before you generate reports. Listen to key stakeholder
input.
• Clearly define areas of responsibility so that multiple
people aren’t triggering actions on the same
information.
• Balance the cost of collecting data with the value the
data provides. Err on the side of less data collected less
frequently.
• Encourage each stakeholder to watch his or her gauges
and resist the tendency to muddle in someone else’s
business.
• Streamline reporting overhead at every opportunity.
184 TUNE YOUR MANAGEMENT ENGINE
Summary
Your organization should consciously choose their
management system before everyone goes off creating
custom reports. Your executives can tune the dials for
matrix strength, formality and centralization. Leaving each
team to set these controls will result in a meltdown.

Negotiate an agreement with key stakeholders on what
information they need to see and at what frequency. Make
sure that each stakeholder understands their role in the
system and patiently guide them to stay focused on their
dashboard.
Protect Your Interests 185
6.2 Protect Your Interests

Consensus is a pleasant word. When everybody agrees with
decisions a warm shower of sunshine bathes the cubicle
scene. Unfortunately, people may disagree with project
directions, especially on a diverse team. Factors that make
it more difficult to facilitate consensus decisions include:
the number of people with voting rights, the higher their
pay scale and the more pronounced their delusions of self
importance.

To resolve these conflicts speedily, you might consider the
benevolent dictator leadership style. The term "benevolent
dictator" is a modern take on Plato's “philosopher king”
who wielded nearly total authority on the assumption that
his decisions always embodied the best interests of the
people. This leadership style offers the following
advantages:
• You can make decisions quickly.
• You can enforce guidelines for acceptable conduct and
behavior.
• You can fortify the strong matrix organization.

The benevolent dictator can stop decision spin cycles and
force the project to move forward by sheer chutzpa.
35
The
key is to define the boundaries of your kingdom and
exercise complete authority within those boundaries. And
always make rational decisions with the best interest of
your project in mind.


35
Webster’s definition of chutzpa: supreme self-confidence, nerve,
gall.
186 TUNE YOUR MANAGEMENT ENGINE
Lobby, cajole and press intensely for your interests. For
example, respond with overwhelming force if a functional
manager siphons resources from your project in favor of
another project:
• Call the functional manager and ask, “Why wasn’t this
decision made in a public forum?”
• Immediately raise the issue in your status reports.
• Do not worry about ruffling feathers. Your authority
has been challenged, your time has been consumed and
your project deliverables are at risk. Take action.

Internal forces will resist the benevolent dictator. Weak
matrix zealots, led by powerful functional managers, will
battle to maintain power. Challenges to your authority will
also come from team members who exhibit self-oriented
behaviors. Strangely enough, even the organizational
framework can undermine your authority. My organization,
for instance, sanctions a separate “core development team”
that operates with unusual autonomy. That “sub” team
wields near absolute authority over what gets done and
when it gets done.

“Mind your own
business.”
– Francis Bacon
Never tolerate another
person’s quest for land
and power if it
encroaches on your
domain of responsibility.
If you respond with passion, functional managers will
eventually learn to not mess with you. You may be
wondering, “Should my interests always take precedent
over other interests in the organization?” The unequivocal
answer is “Yes.” If you fight for your interest, you will
optimize the results for your entire organization.

Protect Your Interests 187
Let the Invisible Hand Guide You
The discussion so far sounds uncomfortably self-centered,
doesn’t it? Don’t be alarmed. The father of modern
economics, Adam Smith, outlined why we should embrace
the engine of self-interest:
36

...every individual necessarily labours to render the
annual revenue of the society as great as he can. … he
intends only his own security; and by directing that
industry in such a manner as its produce may be of the
greatest value, he intends only his own
gain, and he is in this, as in many other
cases, led by an invisible hand to promote
an end which was no part of his intention.
By pursuing his own interest he frequently
promotes that of the society more effectually than when
he really intends to promote it.

Stated differently, project managers who single-mindedly
pursue the interests of their project are led by the invisible
hand to unconsciously promote the best interests of the
organization.

Given that selfishness is the core engine behind this theory,
it might surprise you to learn that Adam Smith reconciles
this theory with his belief in a benevolent God. He noted
that God created humans with a nature that leads them to
pursue wealth. The struggle to become wealthier forces an
exchange and division of labor. According to Smith, God
wisely recognized that this struggle works out to the
optimum benefit of society. Smith asks, “Why quibble
about the nature of humans that God purposely designed?”


36
Adam Smith, An Inquiry into the Nature and Causes of the Wealth of
Nations, published in 1776.
188 TUNE YOUR MANAGEMENT ENGINE
Framework for the Invisible Hand
Adam Smith warned, however, that the invisible hand
mechanism depends upon an organizational framework to
work efficiently. For example, property rights must be
clear. Contracts must be enforceable. And people must
adhere to moral norms. The following table shows how
these same principles apply to a project framework:

Table 5: Organizational Framework
Framework for
The Invisible Hand
Framework for
Project Management
Property rights must be
clear and enforceable
Projects must be properly
provisioned
Public must adhere to
moral norms
Team must adhere to
guidelines for proper
conduct and behavior
Police must enforce laws Management must enforce
laws

It’s easy to think of scenarios where friction causes the
invisible hand to fail. Let’s assume, for instance, that a
functional manager decides to reassign resources without
notice [it happens]. This violates the first framework
assumption regarding project provisioning. Your charter
established your right to remain properly provisioned. That
contract is violated. In effect, the functional manager has
“stolen” from you. You have a right to call the police (your
sponsor or executive board) to demand restitution.

Protect Your Interests 189
It is in everyone’s best interest to let a governing body
make these types of resource leveling decisions
transparently. If people secretly violate charters, anarchy
prevails. You may still lose this battle for the resources, but
the process will have played out as designed. A formally
approved change request will document the impacts to
project scope, time and cost. This protects your team by
resetting performance expectations.

Summary
Single-minded pursuit of your team’s interests will
optimize overall business results. Ask your sponsor to help
establish the framework for the invisible hand market
mechanism to work.

No one likes to work in an organization plagued by
decision paralysis. People respect the project manager who
can make the tough calls. Consistently adhere to high moral
norms. Your team will appreciate clear boundaries and a
confident leader.





190 TUNE YOUR MANAGEMENT ENGINE
6.3 Prevent Decision Paralysis

Have you ever been caught at crossing gates while the
world’s longest train creeps by? Sitting in a car on a
sweltering day waiting for the caboose to pass and the gates
to rise is irritating. Do you like sitting in traffic? Neither
does your team.

Here are six handy techniques to keep traffic flowing on
your project:
1. Map two different routes to the destination
2. Rip out your rear view mirror
3. Lean into the wind
4. Make sure that everyone wants to go along for the
ride
5. Empower the team
6. Be the Judge at Traffic Court

Map Two Routes
A proposal with only
one option is an
ultimatum.
One reason that people resist making decisions is because
they aren’t given any options. Most destinations have at
least two routes so you should present at least two
alternatives to your executive team so that they can
exercise their right of
choice. This also let’s
your executives know
that you have at least
considered all of the
options.

Make the decision maker(s) comfortable with their choice.
For example, you might run a Monte Carlo simulation to
generate range estimates for your schedule (with
corresponding probabilities for each date). Never present a
Prevent Decision Paralysis 191
single point estimate for the schedule. Instead, say
something like “Date 1 has 90% confidence, Date 2 has
80% confidence and Date 3 has 70% confidence.” This is a
smart way to invite your executives to share risks.

Rip Out Your Rear View Mirror
Unless a significant piece of new information surfaces, why
revisit a decision made? There is nothing more frustrating
then a resurrected debate that was once settled.

Let’s say that a new piece of data surfaces: the market
opportunity is now $1.8M versus the original business case
of $2.0M. Don’t rerun the business case if the new
assumption won’t materially alter the decision. Since both
market opportunity numbers are estimates anyway, how do
you know that the $1.8M number is any more accurate than
the other number? Traffic slows when people feel
compelled to run cases ad infinitum. Remind your team that
all decisions embody some level of risk. Encourage them to
make decisions using directionally correct data.

Lean Into the Wind
Learn to lean into the wind. That is, anticipate learning
curves and technological advances. This will help you
accept decisions made on incomplete data. For example, I
managed the high performance team responsible for
creating an IBM ThinkPad
®
notebook computer. Tensions
escalated when our sponsor directed us to keep the
notebook height less than 1.5 inches. This was unrealistic;
laws of physics dictated that we couldn’t meet that
requirement. Nonetheless, my cunning executive
encouraged me to “lean into the wind.”

192 TUNE YOUR MANAGEMENT ENGINE
His argument ran along the lines of Moore’s Law
37
which
predicted that the number of transistors on a chip would
double every two years. My executive pointed out that our
system building blocks were shrinking on a predictable
curve so we could anticipate a technological breakthrough
during the development cycle. Sixteen months later we
delivered a brand-new category of thin and powerful
notebook computers using technologies that didn’t exist at
the start of the project. Lessons learned from that exercise:
1. It is okay to make a decision based on incomplete
data. Lean into the wind (retain the risk) if learning
curves support the decision.
2. In a fast paced market, try to meet invention on the
run. If you try to catch the moving innovation train
from a standstill, you will break your arm.
3. Leaning into the wind can be fun. Walt Disney
expressed the same thought this way: “It’s kind of
fun to do the impossible.”

Bypass Abilene
Professor Jerry Harvey of George Washington University
coined the term “Abilene Paradox” to describe how people
think they reach an agreement.
38
His parable describes four
supposedly sane adults sitting on a porch during a heat
wave in a small Texas town. They remain fairly listless
until someone gets the bright idea to drive an hour to
Abilene to eat at a cafeteria.

They all pile into a Buick that lacks air conditioning and
drive though a dust storm to eat a tasteless lunch. Then they
return home exhausted and cranky. After they return home,
they realize that nobody really wanted to go in the first
place. Someone made a innocuous comment about the trip

37
Named after Gordon Moore, the Intel co-founder.
38
Jerry B. Harvey, The Abilene Paradox and Other Meditations on
Management (San Francisco: Jossey-Bass, 1988).
Prevent Decision Paralysis 193
which prompted another person to vent, “It was not a good
idea or a nice trip!”

This leads us to ask, “Why did they all jump in the car?”
The answer is that each individual thought everyone else
wanted to go and so they all went along for the ride rather
than resist the will of the group.

The lesson here is that you may need to ask your team to
question their position on a decision out loud, “Do you
really want to get in the car?” Ask that question before you
book the decision so that everyone has an opportunity to
express their private misgivings.

Never Let the Accountant Drive
Resist the tendency to rationalize project decisions based
on a “to go” business case. How many wrecks have you
seen pushed through the decision process based on a
variable business case? “I know that this project is off
track, but if we just spend a few more dollars then we can
finish it and take our chances in the market.” Buckle up for
safety when you hear these words.

Some organizations view the write-off bucket as a sign of
stupid investments when, in fact, this ledger account may
reflect courageous decisions from a leader who stood on
the tracks and warned “turn back” after going just 10 miles
toward Abilene. Savvy businesses cancel bad proposals at
any point in the delivery pipe.

Empower the Team
Do you trust the specialists on your team to make important
decisions? Sure you do. We’re all cosmopolitan supporters
of empowerment. But when a decision turns our poorly, do
you immediately withdraw the delegation of authority? If
194 TUNE YOUR MANAGEMENT ENGINE
so, then you will unconsciously foster an environment of
risk aversion and that leads to decision paralysis.

The benchmark for proper decisions should be that they are
always the best decision made with the information on
hand. This mindset will ensure that decision authority isn’t
whipsawed back and forth between executives and teams if
decisions go awry. Efficient organizations delegate a
sizeable portion of authority with teams. If the team makes
a poor decision, they teach the team to make better ones.

Consider two gamblers in the lounge car of our train. One
player draws a queen-high straight flush.
39
This dream
hand boasts a 99.997% probability of success. How would
you bet with this hand? Certainly, you’d put on your best
poker face to suppress your glee. You’d escalate the bets
slowly so you don’t scare away your opponent and then
finally you’d go “all in.” Now picture that your competitor
plays into your trap (bets all of her chips) and makes the
call. When the cards are flipped, your opponent shows an
ace-high royal flush and collects the pot. You just lost your
rent for the month! The lesson: you can make all the right
decisions and still lose the game. Don’t be too hard on
yourself or others.


The optimum environment to promote empowerment is the
one where nobody expects perfection. As long as you
played the correct percentages with the information that
was visible at that time, then it was the right decision even
if it turns out poorly.


39
Adapted from a Wall Street Journal book review, Making Great
Decisions In Business and Life, by David R. Henderson and Charles
L. Hooper.

Prevent Decision Paralysis 195
Be the Judge at Traffic Court
If the team can’t reach a quick consensus, then make the
call for them. Be the judge in traffic court. Somebody has
to make the decision and it might as well be you, since you
have the project’s best interests in mind.

The silent resisters may come out of the woodwork when
you communicate the decision. That’s okay. Now you can
deal with them out in the open. In any case, do not allow
decision paralysis to stop your project progress.

Practical Application
• Keep your project moving. Your team hates sitting still
in traffic.
• When your team is spinning fruitlessly on a decision,
make the call (using your best judgment), and move on.
• Don’t second-guess decisions.
• Lean into the wind when you are competing in a fast-
paced market.
• Prod your team to state misgivings about a decision –
out loud.
• Reject bad ideas. Scrupulously observe the Turkish
proverb: “No matter how far you’ve traveled on the
wrong road, turn back.”
• Set realistic expectations for decision success. If you
really want to empower a team and see them exercise
ever increasing levels of authority, then tell them, “I
don’t expect you to make every decision correctly. I
only expect you to make the best decision based on the
information at hand.” This frees them to take calculated
risks.

196 TUNE YOUR MANAGEMENT ENGINE
Summary
When it comes to making decisions, time is your enemy. If
your team cannot reach a consensus decision, then make it
yourself, document it, and then deal quickly with the
resistors. Dealing with resistors is a better game than
dealing with decision paralysis.

Visit the PMO Junction 197
6.4 Visit the PMO Junction

As your business grows, you may choose to build a project
management office (PMO) to instill discipline in project
execution and to oversee operations. If you do decide to
open a PMO, then architect it as a relatively short railway
spur that leads from the main line of the railroad to a
destination where project managers can meet to discuss tips
and tricks of the trade and to share tools.

The goals of a PMO junction:
• Simplify methodology and continually streamline
checklists.
• Standardize phase gate checkpoint packages and status
reports.
• Publish best-of-breed WBS and deliverable templates.
• Manage cross-project dependencies and risks.
• Rescue trouble projects.
• Educate teams on the latest tools and techniques.
40

• Share lessons learned in a central depot.
If you are considering a PMO, carefully assess the value it
brings to your organization. Some PMOs are run by Ol'
Uncle Joe and he’s a-movin' kinda slow at the junction, and
this irritates conductors who need to cruise through quickly
on their project journey. The last thing any organization
needs is yet another layer of bureaucratic overhead. If you

40
The PMO should always commission a controlled pilot for any new
tool or method first to ensure that it works in a real world production
setting as advertised.
198 TUNE YOUR MANAGEMENT ENGINE
have Ol’ Uncle Joe running your PMO, then close the
junction or let Uncle Joe rock on the porch by himself.

Results Driven PMO
The successful PMO is always looking for a quicker route,
fewer steps and faster delivery of projects. Simplicity and
speed are the watchword for a useful PMO. As a goodwill
gesture, the PMO can review current processes and
eliminate unnecessary tasks and deliverables. This will
build needed ground level support for the PMO. A heavy-
handed PMO that dictates the use of complicated methods
and tools is doomed to fail because it is working counter to
the philosophy of high performance teams that are
continuously seeking shortcuts to get the job done faster.
Here’s another clue that a PMO is working against your
interests: it generates intricate process flow charts that
require a secret decoder ring to translate.

Project Reviews
The PMO is an extra set of eyes that can perform project
reviews and highlights risks that were unseen by the harried
project manager. A particularly useful role for a PMO is to
help teams in the early phase of project rollout. Teams can
review the PMO lessons learned library at the Shady Rest
Hotel before they start the next project. It’s okay to make
mistakes. It is not acceptable to repeat them.

The PMO reviews troubled projects when the train derails.
Since troubled projects are by definition under intense
pressure, the PMO must be careful to accelerate rather than
hinder project execution. Don’t let the PMO drive your
team into a review trap that slows the delivery engine.
Visit the PMO Junction 199
The adept PMO performs emergency room triage on
troubled projects. It prioritizes project conditions into one
of the following categories:
1. Life-threatening
2. Urgent, but not immediately life-threatening
3. Less urgent

In a real emergency room, you do not want life-threatening
conditions to sit unattended while resources are being
shifted to work on less-urgent conditions. The PMO can
help redirect resources to give immediate attention to the
key project deliverables that will most influence the
schedule critical path or project costs.

In a real emergency room, the nurse reviews the case,
collects important patient information (like blood pressure
and family history) and then prioritizes which case will see
the doctor first. Likewise, the PMO need not pester the
stressed-out project manager to create additional reports.
Instead, it can run the reports itself or use other
knowledgeable members of the team to collect information.
The project manager is already overwhelmed on a troubled
project and the PMO should offer comfort and aide.

Who’s to Blame?
The end goal of a troubled project review is to fix
problems, not to point fingers and place blame. Never
allow the review of a troubled project to turn into an
inquisition. Ensure that the work environment is conducive
to admitting mistakes and reporting bad news.

200 TUNE YOUR MANAGEMENT ENGINE
Metrics for Success
How do we know if the PMO is successful? First and
foremost, it will be deemed a success if the project
community embraces it. If teams run when they see a PMO
member walking the halls, then the system isn’t working
properly.

Another key measure of success will be if the PMO drives
more projects through the execution pipe with consistency
and at a faster pace. The organization should see tangible
performance improvements in cycle times, project cost and
planning accuracy. Finally, you can measure PMO
effectiveness by the only metric that really counts: business
success in the market.

All of these success metrics will take some time to
document, so your organization must be patient before
pulling the plug prematurely on the PMO experiment.

Summary
Many teams have a negative impression of PMOs based on
past experiences dealing with an autocratic manifestation of
this body. Bad PMOs make process more important than
results. They hinder project execution by adding yet
another layer of frustrating bureaucracy to the business.

The astute PMO, on the other hand, asks the project
manager directly, “How can I make your job easier?” and it
follows up on that question with meaningful support.


7 LAST STOP




7



LAST STOP

Key Topics Covered In This Section:
• Why you should investigate accidents.
• What’s in your toolkit?
• The rules of project leadership.

202 LAST STOP
7.1 Investigate Every Accident

Heavy trains travel on rails with minimum friction. That
makes them energy-efficient. Unfortunately, it also keeps
them from stopping quickly in an emergency. The collision
between a car on the tracks and the train is always
catastrophic for the car.

When I hear a report of a collision between a car and a
train, I instinctively blame the driver of the car. After all,
the train is traveling on fixed rails, so the car driver must
have consciously maneuvered over the rail to be struck.
Was the car driver trying to save some time by sneaking
around the crossing gates? Was the driver listening to
music so loudly that he or she couldn’t hear the blast of the
train’s horn? Did the car stall at the most inopportune time?

It’s fascinating to investigate the cause of wrecks and to
ponder ways that we can avoid the same type of accident
when we are driving. In the project world, we call these
investigations lessons learned. Our goal is to reduce the
number of accidents in the future. Collecting these lessons
is as straightforward as detailing:
+ Things that went well
++ Things that could be improved

Lessons Unlearned
Unfortunately, many lessons remain unlearned for these
reasons:
• Nobody has time to document the lessons. Our natural
tendency is to keep an eye on the work piling up in
front of us. We don’t have time to glance in the
rearview mirror.
Investigate Every Accident 203
• We hoard our lessons learned in order to maintain a
competitive edge over our peer competition.
Organizations that rank employees exasperate this
problem.
• We classify lessons learned as top secret. I worked in
one area that routinely kept lessons learned confidential
and private. The executives refused to publish them
broadly because some people were “reflected in a bad
light.”
• We wrongly equate troubled projects with poor skills:
“I’m going to look dull if the executives see the mud
puddle I stepped in.”
These excuses for not harvesting and sharing lessons
learned are absurd. Can you imagine the Federal Aviation
Administration (FAA) saying, “I’m too busy to investigate
the cause of a plane crash?” As a passenger, aren’t you
grateful that the FAA is obsessed with finding the cause of
a crash and fixing it for the future?

The FAA’s approach to lessons learned is very revealing.
The FAA builds an amazingly realistic mathematical model
of the airplane and flying conditions. Their model considers
various cause and effect relationships that caused the
accident. They publish the results at a news conference for
the entire world to scrutinize; they do not file away the
lessons in a top-secret cabinet. They appreciate that open
communication will improve safety standards. I strongly
recommend that you read one of their reports for useful
insights on how to structure your lessons learned exercise.

Share Lessons
Do your peers share their project lessons learned with you?
You can learn a great deal from the experience of others.
Ask your peers: “What tip, tool, or technique, do find
indispensable?” You’re not just looking for revolutionary
204 LAST STOP
insights, you’ll be happy with simple tips that save a
minute or two per day. The time-saving accrual will
become significant after you amass many such tips.

Practical Application
• Set aside enough time to properly conduct lessons
learned.
• Record lessons as you go. It will take you longer to
reconstruct the accident scene if you wait until the end
of the project. Your memory will fail you.
• Review and apply lessons from the previous project
early in the concept phase of your new project.
• It is easier to see flaws in other people’s projects than in
your own. Swallow your pride and invite peers to
critically review your project.

Pitfalls to Avoid
• Resist the tendency to focus only on the “troubles
you’ve seen.” If you only concentrate on troubles, the
exercise can become depressing. Record positive
lessons as well.
• Don’t put a troubled project behind you too quickly.
Dissect it. You learn more from a troubled project then
you do on a project that runs smoothly.
• Don’t hold your lessons learned close to the vest. Share
them with others. Encourage everyone around you to
share their best tips, tricks and techniques with you.
• Don’t treat lessons learned as a compulsory exercise.
This is one checklist item will benefit you far more than
it will benefit your auditors. Give it proper attention.

Investigate Every Accident 205
Summary
In order for lessons learned to be meaningful, they must be
documented, reviewed broadly, and applied. Take the time
to investigate accidents on your project and to document
them in a lessons learned file. Share that file with your
colleagues.

Wouldn’t it be great if you had a time machine that could
take you back to the beginning of your project? What if you
were permitted to carry five pages of notes with you in that
machine? My five pages would have some pretty
thoughtful lessons learned. Of course, we can’t go back in
time. But we can review our lessons learned at the
beginning of our next project. We can also share that
precious document with other people in our organization.
To our colleagues, the insights would be the equivalent of a
time machine if they prevent another team from repeating
the same mistakes.

206 LAST STOP
7.2 Collect Tools

Mature leaders are confident enough to open their toolkit
and let you peek inside. Make it a habit to ask your peers
this simple question, “What’s your most important tip,
technique or tool?” What does it say about a person who
refuses to answer that question? Are they tool-less? Don’t
they have a single trick of the trade to share? Or are they
deliberately keeping their secrets to themselves in an effort
to outshine their peers?

There are simple-minded dolts in every company who keep
their secrets of success to themselves. These are the
employees with a preoccupation with their own occupation.
These employees are bad for your business and, if you are
in a position to do so, usher them out of the company.
Everyone in your organization should be willing to share
their productivity tips.

Test the Water
Now that I’ve told you to collect tools, I’m going to warn
you to think twice before you roll one out to your team. Do
the benefits of using the tool exceed the cost of feeding it
data? Are you enamored with the tool just because it’s new
and sexy? I’ll admit that in my zeal to try out a new tool,
I’ve forced my team to follow me on some pretty hairy
adventures.

The young project manager might relish the opportunity to
earn a Fear Factor badge of courage by trying out a new
tool. The mature project manager, however, doesn’t
navigate his team through complex processes and
methodologies before testing the water himself. Think
about this: “Who was the first so-called expert at Sea
Collect Tools 207
World who jumped into the water with Hugo the Killer
Whale?” Do you think that person convinced several
people to jump into the water with him at the same time?
My hunch is that they ran controlled pilot with a lifeless
dummy before any live human put a toe in the water.
Likewise, we should run carefully controlled pilots
whenever we roll out a new tool or process.

Practical Application
• Only implement a new tool, concept or practice if there
is a high degree of certainty that it will add value to the
business and your team is willing and able to use it.
• Be open to team feedback to discontinue using a new
feature of a tool if it is driving them crazy.
• Practice the new features of a tool with a trusted team
member who has a high tolerance for pain.
• Keep a watchful eye on the team to make sure nobody
is drowning with the new tool.

Summary
Collect tools, but be very careful when you use them for the
first time. Test it with a trusted colleague before you direct
your entire team to use it.

You can learn quite a few fun facts and theories in project
management classes. On behalf of the people around you,
please do not put every theory into practice. And do not
roll out every cool new tool that promises to supercharge
project productivity.
208 LAST STOP
7.3 The Rules of Project Leadership

Consultants try to motivate people with pithy quotes like
this winger from WWII Fleet Admiral Chester Nimitz:
“When you are in command, command.” If things were
truly that simple, I could command you to be a successful
leader. Are you ready? Take a deep breath. Now repeat
these words out loud: “I’m confident. I’m successful. I’m
a leader.” Do you feel any different? No? Then why do we
naively assume that we can bestow the leadership mantle
on any eager employee?

Nimitz was Nuts
Nimitz happened to be a successful admiral. That doesn’t
mean that everyone following his “command to command”
will be a successful admiral or a successful business leader
for that matter. The best leaders that I’ve met were people
who made you feel like they really needed you more than
you needed them. They also freely shared tools from their
toolkit. They wanted everyone to win. And they addressed
both good and bad behaviors all during the project run.

I cannot guarantee that reading this book will make you an
effective leader. The tips and techniques presented in this
book worked for me in my project environment. You will
need to refine these techniques to fit the unique
circumstances in your environment. I encourage you to
experiment. Become an assiduous collector of useful ideas.
If you stumble across something that works well, please
share it with me at www.projectEZ.com. My way is not the
only way to run a railroad.
The Rules of Project Leadership 209
Are You a Project Leader?
Some project managers naively equate project management
with task management. Even the title “project manager”
suggests a bias toward hard skills. I think that we need to
spend more time leading and less time managing.

A project leader has that intangible soft skill talent to
motivate people to climb aboard for the ride. Project
leaders spend as much time promoting team dynamics as
they do on the mechanics of scope, time and cost
management.

Project leaders never become so enamored with the nifty
tools of the trade that they lose sight of what’s really
important. Leaders recognize that there are times when the
value of report does not justify the cost to produce it.
Leaders run controlled, small-scale pilots before they force
the entire crew to use a new tool.

Leaders protect their teams from unreasonable executives
and annoying process bureaucrats. Leaders execute plans
without complaining. Leaders never pass blame for a
problem on another person. Leaders praise team members
often. Leaders counsel team members freely (and accept
counsel gracefully).

Finally, leaders foster an environment where everyone feels
comfortable revealing bad news. True, it’s frustrating to
hear that there is a problem on the tracks ahead, but leaders
welcome that news so that they can take some emergency
measures to mitigate the potential disaster.

210 LAST STOP




Clip 'n' Save!!!

------------------------------------------------------------------------

The Rules of Project Leadership
by John Langlois
1. Select a boulder mover (sponsor) with real
power.
2. Trim down your process checklist.
3. Determine the quality level for every
requirement before the project leaves the
kickoff station.
4. Reduce project friction.
5. Don’t be afraid to counsel.
6. Don’t scream at anyone unless you are alone.
7. Protect your interests.
8. Investigate every accident.
9. Share your tools.
10. When confused, take a nap.
41

------------------------------------------------------------------------


41
If you are still at work, wear a cap after you take a nap to camouflage
“bed head.”
The Rules of Project Leadership 211
212 LAST STOP

7.4 Cruising Down the Tracks

It’s no fun riding a troubled project train. Stakeholders
scream. They may even fire you if they determine that you
should have foreseen the disaster.

Even if you keep your job, the effort to hoist a train back on
the tracks after it derails is monumental. You can expect to
work endless hours and sacrifice work/life balance. Hence,
the goal of this book was to show you how to keep your
project train on the tracks and running smoothly.

The underlying assumption of this book is that most project
accidents are avoidable. If you practice the techniques in
this book, then you and your team can be confident that
nothing will derail your efforts. You will reach your final
destination on time and on budget.

I hope that this book gives you new insights on how to run
your railroad more effectively because there is nothing (in
business) more rewarding than cruising down the tracks at
high speed.

Have a safe and pleasant journey.


John Langlois

Cruising Down the Tracks 213
214
Ready-to-Use Templates

Template 1: Sponsor Letter............................................... 11
Template 2: The Conductor’s Creed................................. 17
Template 3: Team Member Rights & Responsibilities..... 22
Template 4: Offering Definition....................................... 42
Template 5: Project Charter .............................................. 45
Template 6: New Team Member Training Checklist ..... 107
Template 7: Meeting Guidelines..................................... 115
Template 8: Team Member Performance Goals............. 124
Template 9: Performance Expectations – Good/Bad...... 126
Template 10: Performance Feedback Letter ................... 128
Template 11: Status Report............................................. 140
Template 12: Earned Value Progress Report.................. 147
Template 13: Conceptual Earned Value Drawing .......... 148
Template 14: Risk Plan................................................... 151
Template 15: Change Request Summary........................ 157
Template 16: Post Launch Project Scorecard................. 163

215
Figures and Tables

Figures

Figure 1: Phase Gate Process............................................ 27
Figure 2: How Project Reports Relate to Each Other ....... 32
Figure 3: "Backward Pass" Planning ................................ 33
Figure 4: Cost Estimation Process – Overview................ 57
Figure 5: Cost Estimating Model – Detailed View........... 61
Figure 6: Rank & Weight of Car Purchase Criteria.......... 65
Figure 7: Entering Worst Case estimate in MS Project .... 84
Figure 8: Monte Carlo Simulation.................................... 86
Figure 9: Definition of Hard vs. Soft Skills.................... 102
Figure 10: Map of Communication Channels................. 168
Figure 11: Email Etiquette.............................................. 174
Figure 12: Customized Dashboards................................ 182

Tables

Table 1: New Project Complexity Table .......................... 31
Table 2: Self-Oriented Behaviors ................................... 120
Table 3: Accounting Vs Economic Project Reporting.... 144
Table 4: Change Request Assessment ............................ 160
Table 5: Organizational Framework............................... 188


216
Index

A
193
143
63
130
50
, 137
B
31
7
51
162
123
185
53
C
181
35
156
26, 44, 46, 48
49, 50, 52, 53
90
18, 166
99
31
16
185
62
69
57
92
59
123
, 34, 35
36
D
, 180
190
26
190
114
.
74
183
E
145
91
170
172
, 193
F
203
176
148
180
15, 16
70
G
25
Abilene Paradox, 192
Accountant,
Accounting systems,
Addams Family, 2
Analytical Hierarchy Process,
Appraisal,
Auditor,
Awards
Backward pass,
Barnacle Babble,
Barney Fief,
Baseline,
Behavioral Feedback,
Benevolent dictator,
Blocker. See Self-Oriented
Behaviors
Bureaucracy,
Capability, 133
Centralization,
Change control,
Change request,
Charter,
Checkpoint. See Decision
chekpoint
Decision checkpoint,
Checklist,
COCOMO,
Communication channels,
Complexity factors,
Complexity table,
Conductor’s Creed,
Consensus,
Contractor,
Core capability,
Cost,
Cost estimate,
Cost estimation model,
Counsel,
Feedback. See Behavorial
feedback
Customer
Customer persona,
Dashboard
Decision,
Decision Paralysis,
Development flexibility, 90, 98
Digresser. See Self-Oriented
Behaviors
Disruptive behaviors,
Dominator See Self-Oriented
Behaviors
Duration-based schedule,
Dysfunctional organization,
Earned value,
Effort,
Email,
Email blizzard,
Empowerment
Estimating errors, 84
Federal Aviation Administration
(FAA),
Fireside chat,
Forecasting,
Formalization,
Functional manager,
Functional requirements,
Gandy Dancers,
217
Golden spike, 20
109, 115
H
102
, 139
105
I
, 170
150
K
31
91
L
208
185
191
202
34, 39
M

180
114
7, 132, 159
82, 86, 190
192
131
O
43
30, 41
188
153
P
171
91
28
26
31
, 25, 30
135
, 98
60, 63, 66
49
88
, 145, 148
5
46
197
15, 16
46
25, 28
188
64
Q
95
R
139
58
60

41
75
69
77
135
23
150
Gross profit (footnote), 28
Guidelines,
Hard Skills,
Headlights
High-performance team,
Inbox
Issue,
Risk,
Kickoff,
KLOC (thousands of lines of
code),
Leadership,
Leadership style,
Lean into the wind,
Lessons learned,
Listening ears,
Magna Carta (Great Charter), 44
Management system,
Matrix. See Strong Matrix
Meetings,
Milestone,
Monte Carlo,
Moore’s Law,
Motivation,
Offering definition,
Off-ramp criteria,
Organizational framework,
Outrage Factor,
Peek & Keep Rule,
Person-month,
Pet projects,
Phase gate,
Phases, 26
Portfolio management team,
Portfolio planning, 16
Praise,
Precedence, 90
Prioritize requirements,
Process,
Program Evaluation and Review
Technique (PERT),
Progress
Project,
Project Management Body of
Knowledge (PMBOK)
®
, 5
Project guidelines,
Project Management Office
(PMO),
Project manager,
Project priorities,
Proposal,
Provision,
Purchase decision model,
Quinqueremes,
Rank and weight, 64
Referential authority (footnote), 12
Reporting,
Requirement,
Requirements,
Requirements (See also Functional
and Technical requirements),
Resource constrained schedule,
Resource constraints,
Resource leveling,
Reward,
Rights and Responsibilities,
218
152
109
S
90
74
82
85
55
162
121
7, 95, 101, 102
1, 3, 9, 12, 14, 42, 154,
156, 189, 191
10
180
139
46
5, 16
T
85
90, 98
70
206
106, 108
20
199
2
V
46
W
71
74
Risk plan, 150
Risk radar,
Rules,
Scale drivers,
Schedule,
Work packages,
Schedule assumptions,
Schedule risk,
Scope,
Scorecard,
Self-oriented behaviors,
Sniper. See Self-Oriented
Behaviors
Soft Skills,
Sponsor,
Sponsor Letter,

Stakeholder,
Status,
Strategic imperatives,
Strong Matrix, 1
Task,
Team cohesion,
Team Development. (footnote)
Technical requirements,
Toolkit,
Training,
Transcontinental railroad,
Triple Constraint, 21
Troubled project,
Tycoon,
Value proposition,
Withdrawer. See Self-Oriented
Behaviors
Work Breakdown Structure
(WBS),
219
220

THANKS

The following people joined me on the journey to write this
practical book on project management. They provided
valuable feedback on early drafts of this manuscript.

John Aderton, Sr. Project Manager, Mayo clinic
Chris Algozzine, Development Manager, IBM
Edmund B. Campbell, III, Chairman of 1st Guard Corp.
Steven DelGrosso, PM Competency Leader, IBM
Heather Fox, Product Manager, IBM
Mitch Friend, Senior Vice President, Avocent Corporation
Vivian Homza, Senior Program Manager, AMD
Carolyn Jones, Executive Project Manager, IBM
Kristine Olka, Instructional Designer, IBM
Steve Roberson, SW Program Management, IBM



221

ABOUT THE AUTHOR

John Langlois led the team that planned and delivered one
of the most successful programs in the history of notebook
computers – the IBM ThinkPad
®
T-series. He’s received
numerous Editor Choice product awards as well as IBM’s
most prestigious corporate award for outstanding project
performance.

John has more than twenty years’ experience delivering
complex hardware, software and solution projects. He
specializes in nurturing projects targeted at new markets.
He has a unique ability to see patterns of dysfunctional
behavior in organizations and to identify the variables that
most influence team performance.

John’s credentials include a business degree from Rollins
College, a Masters of Science in Economics from Florida
State University, and a Master’s Certificate in Project
Management from George Washington University. John is
a certified Project Management Professional (PMP
®
) and a
Stanford Certified Project Manager (SCPM).

222

VISIT US ONLINE

Get on the right track. Visit us online at projectEZ.com for
more tips and downloadable templates to better manage
your projects.






projectEZ.com