project wreck ebook (v62)

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.

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

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 skills4” 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.


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. The activities performed by this team will include: • Defining the project requirements for each

decision gate. • 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. I appreciate and support your efforts. Regards, Cornelius Vanderbilt

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 authority5

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.


• 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 manager7 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 shanghaied8. 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 19th 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.


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 nth 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.


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 8th, 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.

QTim

e Cost

Scope

QTim

e Cost

Scope

QTim

e Cost

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

2PLAN 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.


Figu

re 1

: Pha

se G

ate

Proc

ess

Con

cept

Dev

elop

Exe

cute

Proposals

Fini

shC

harte

r

= P

hase

Gat

e D

ecis

ion

Che

ckpo

int

Con

cept

Dev

elop

Exe

cute

Proposals

Fini

shC

harte

r

= P

hase

Gat

e D

ecis

ion

Che

ckpo

int

Con

cept

Dev

elop

Exe

cute

Proposals

Fini

shC

harte

r

= P

hase

Gat

e D

ecis

ion

Che

ckpo

int

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 profit10 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.


• 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 2nd 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

Figu

re 2

: How

Pro

ject

Rep

orts

Rel

ate

to E

ach

Oth

er

Valu

e•

Acc

urat

ely

portr

ay p

roje

ct

stat

us a

fter

base

line

com

mitm

ent i

s es

tabl

ishe

d

•U

nblin

king

re

view

of r

isks

an

d is

sues

Stat

us

•M

anag

e pr

ojec

t th

roug

h ea

ch

phas

e ga

tes

•E

stab

lish

Trip

le

cons

train

t ta

rget

s

•E

nsur

e th

at

reso

urce

s to

su

ppor

t ph

ase

activ

ity a

re in

pl

ace

•Lo

ok A

head

•A

void

po

tent

ial

poth

oles

•D

efin

e la

unch

ca

denc

e fo

r st

eady

sta

te

busi

ness

•Es

tabl

ish

base

line

sche

dule

ta

rget

s

•Es

tabl

ish

reas

onab

le

Pro

ject

K/O

da

tes

(bac

kwar

d pa

ss)

Freq

uenc

y

Roa

dmap

Key

Dat

esK

ick-

off

Che

ck P

oint

s

PM

T an

d Pr

oj. M

anag

er

PM

TP

MT

Rep

orte

d at

Key

Rep

ort

Ow

ner

PM

TO

fferin

gM

anag

erP

roje

ctM

anag

er

Inve

stm

ent

Rev

iew

Boa

rd

Inve

stm

ent

Rev

iew

Boa

rd

Onc

e pe

r m

onth

Onc

e pe

r m

onth

Twic

e pe

r m

onth

Twic

e pe

r m

onth

Step

1St

ep 2

Step

3St

ep 4

Prio

ritiz

edPo

rtfo

lio

Pro

ject

Man

ager

Offe

ring

Rev

iew

Wee

kly

Post

Pla

n

•A

lign

proj

ects

to

Bus

ines

s O

bjec

tives

•P

riorit

ize

proj

ects

•Id

entif

y co

re

capa

bilit

y &

re

sour

ces

cons

train

ts

PM

T

Por

tfolio

M

anag

emen

t Te

am

Onc

e pe

r m

onth

Valu

e•

Acc

urat

ely

portr

ay p

roje

ct

stat

us a

fter

base

line

com

mitm

ent i

s es

tabl

ishe

d

•U

nblin

king

re

view

of r

isks

an

d is

sues

Stat

us

•M

anag

e pr

ojec

t th

roug

h ea

ch

phas

e ga

tes

•E

stab

lish

Trip

le

cons

train

t ta

rget

s

•E

nsur

e th

at

reso

urce

s to

su

ppor

t ph

ase

activ

ity a

re in

pl

ace

•Lo

ok A

head

•A

void

po

tent

ial

poth

oles

•D

efin

e la

unch

ca

denc

e fo

r st

eady

sta

te

busi

ness

•Es

tabl

ish

base

line

sche

dule

ta

rget

s

•Es

tabl

ish

reas

onab

le

Pro

ject

K/O

da

tes

(bac

kwar

d pa

ss)

Freq

uenc

y

Roa

dmap

Key

Dat

esK

ick-

off

Che

ck P

oint

s

PM

T an

d Pr

oj. M

anag

er

PM

TP

MT

Rep

orte

d at

Key

Rep

ort

Ow

ner

PM

TO

fferin

gM

anag

erP

roje

ctM

anag

er

Inve

stm

ent

Rev

iew

Boa

rd

Inve

stm

ent

Rev

iew

Boa

rd

Onc

e pe

r m

onth

Onc

e pe

r m

onth

Twic

e pe

r m

onth

Twic

e pe

r m

onth

Step

1St

ep 2

Step

3St

ep 4

Prio

ritiz

edPo

rtfo

lio

Pro

ject

Man

ager

Offe

ring

Rev

iew

Wee

kly

Post

Pla

n

•A

lign

proj

ects

to

Bus

ines

s O

bjec

tives

•P

riorit

ize

proj

ects

•Id

entif

y co

re

capa

bilit

y &

re

sour

ces

cons

train

ts

PM

T

Por

tfolio

M

anag

emen

t Te

am

Onc

e pe

r m

onth

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 FinishKickoff 0 3/16/2009 3/16/2009Concept 28 3/16/2009 4/23/2009Develop 80 4/23/2009 8/13/2009Execute 200 8/13/2009 5/20/2010Finish 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.


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 Magazine11 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.


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


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.



• 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

3LAY 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


• 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

Collect requirements

Prioritize requirements

Confirm core capabilities and size requirements

Construct WBS & schedule

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

Collect requirements 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

Fig

ure

5: C

ost E

stim

atin

g M

odel

– D

etai

led

Vie

w

Prio

ritiz

eR

equi

rem

ents

Siz

e R

equi

rem

ents

Cus

tom

er

Req

uire

men

ts

Prio

ritiz

edLi

st

Rev

iew

Req

uire

men

tsD

eter

min

eQ

ualit

y Le

vel

Prep

are

Cos

t Est

imat

e

Sam

ple

Tool

s:•

Anal

ogy

•In

dust

ry R

ules

•C

oCoM

o II

•Q

SM S

LIM

•C

usto

m

Sam

ple

Tool

s:•

Ran

k &

Wei

ght

•D

ecis

ion

Supp

ort

Syst

ems

Cor

e C

apab

ility

Asse

ssm

ent

Rev

iew

P&L

Yes

Cla

rity

Cla

rity

Cle

ar a

s a

Bel

l

Cle

ar a

s a

Bel

l

•#

of re

quire

men

ts

•#

of s

cree

ns

•Fu

nctio

n po

ints

•Li

nes

of C

ode

Pre

pare

Sch

edul

e

•D

urat

ion

or E

ffort

Bas

ed W

BS

Com

mitt

ed p

lan

acce

pt

Asse

ssm

ent

Rev

iew

P&L

Yes

acce

pt

Prio

ritiz

eR

equi

rem

ents

Siz

e R

equi

rem

ents

Cus

tom

er

Req

uire

men

ts

Prio

ritiz

edLi

st

Rev

iew

Req

uire

men

tsD

eter

min

eQ

ualit

y Le

vel

Prep

are

Cos

t Est

imat

e

Sam

ple

Tool

s:•

Anal

ogy

•In

dust

ry R

ules

•C

oCoM

o II

•Q

SM S

LIM

•C

usto

m

Sam

ple

Tool

s:•

Ran

k &

Wei

ght

•D

ecis

ion

Supp

ort

Syst

ems

Cor

e C

apab

ility

Cla

rity

Cla

rity

Cle

ar a

s a

Bel

l

Cle

ar a

s a

Bel

l

•#

of re

quire

men

ts

•#

of s

cree

ns

•Fu

nctio

n po

ints

•Li

nes

of C

ode

Pre

pare

Sch

edul

e

•D

urat

ion

or E

ffort

Bas

ed W

BS

Com

mitt

ed p

lan

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 contractor14 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.


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:


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


Construct WBS & schedule 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


Construct WBS & schedule 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


• 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


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 Carlo18 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.


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


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/200820% 11/24/200830% 12/15/200840% 12/19/200850% 12/23/200860% 1/2/200870% 1/3/200880% 1/6/200890% 1/12/2008

100% No such thing

Completion std deviation: 1.4d95% confidence Interval: .3d


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 23rd 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 PERT20 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 patsy22 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 19th 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

Confirm core capabilities and size requirements Construct WBS & schedule 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?


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.


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.


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 Cleopatra25 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?


• 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.


• 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


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


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.


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


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.


• 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 Behaviors29

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.


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.


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.



• 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 Managers31 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

5MONITOR 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 15Target 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 investigationSchedule

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 15Target 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 investigationSchedule

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


• 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?


"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.


Tem

plat

e 12

: Ear

ned

Val

ue P

rogr

ess R

epor

t

#A

ctiv

ityFY

Bud

get

Wor

k Sc

hed

Wor

k C

ompl

ete

Wor

k Sc

hed

Wor

k C

ompl

ete

Sche

dule

Va

rianc

eA

ctua

l C

ost

Cos

t Va

rianc

e10

Act

ivity

11,

500

$

60

%40

%90

0

60

0

(300

)

1,10

0$

(5

00)

$

20

Act

ivity

22,

000

$

45

%20

%90

0

40

0

(500

)

1,50

0$

(1

,100

)$

30

Act

ivity

33,

000

$

20

%40

%60

0

1,

200

600

1,

100

$

100

$

40

Act

ivity

41,

500

$

60

%75

%90

0

1,

125

225

1,

100

$

25$

50

Act

ivity

51,

500

$

60

%75

%90

0

1,

125

225

1,

100

$

25$

Tota

l4,

200

4,

450

250

22

,400

$ (1

,075

)$

YTD

Per

cent

YTD

Dol

lars

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 ScheduleEfficiency

Earned Value(EV)

Planned Value(PV)

Cum

ulat

ive

Val

ue

Time

Budget at Completion

(BAC)

ProjectedProjectDelay

ProjectedCost

Overrun

Estimate atCompletion

(EAC)Today

YTD ScheduleEfficiency

Earned Value(EV)

Planned Value(PV)

Cum

ulat

ive

Val

ue

Time

Budget at Completion

(BAC)

ProjectedProjectDelay

ProjectedCost

Overrun

Estimate atCompletion

(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


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

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.

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.


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.


• 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.


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

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.

Develop-ment

Delay test end date by two weeks

Team Self approved07/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 ChannelsWeekly Meeting

w/Manager

WeeklyPM 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


w/Manager


Instant Messages

Telephone Calls

Random Audits




w/Manager


Instant Messages

Telephone Calls

Random Audits



Limit Lines of Communication 169


• 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!


• 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 From: Joe Polite Subj: Answer to Modem Question __________________________________ John, You asked the question, will our modem be homologated for India. The answer is Yes. __________________________________ Joe Polite Modem Test Engineer RTP, NC Phone: 919 xxx-xxxx

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


ping-pong back and forth over several emails, just pick up the phone to resolve it.


• 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

6TUNE 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)?


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.


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.


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.


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.


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.


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.


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.


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.”


His argument ran along the lines of Moore’s Law37 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).


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


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.


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.


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.


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.


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

CustomerCustomer persona,

DashboardDecision,

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,EmpowermentEstimating 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,HeadlightsHigh-performance team,

InboxIssue,

Risk,

Kickoff,KLOC (thousands of lines of

code),

Leadership,Leadership style,Lean into the wind,Lessons learned,Listening ears,

Magna Carta (Great Charter), 44Management 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, 16Praise,Precedence, 90Prioritize requirements,Process,Program Evaluation and Review

Technique (PERT),ProgressProject,

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),

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

project wreck ebook (v62)

Documents