Why Project Managers Fail

I’ve managed a lot of projects. I tried to count them – I can’t.  As I’ve progressed in my career, I’ve embraced a succession of methodologies that cumulatively represent a rather predictable evolution away from zero sum game management towards non-zero sum game management.

What does this mean?

As the science of project management  evolves, we are clearly learning that managing based on guess work is a recipe for consistent failure. Traditionally, we managed projects based on the trusted opinion of a project manager who estimated the length, scope, cost, and resources required for a project. These project managers have a natural tendency to underestimate, and their guesses are vetted through a process designed to save money, rather than arrive at an accurate estimate.

While well-intentioned, agile methodologies  have not appreciably changed this process. In the end, agile projects still obtain their backlogs in bulk and gather up-front estimates prone to error. For all of agile’s intentions, agile projects seldom break out of this pattern, even if they are well managed at the team level.

The top five reasons I see projects fail are (1) No slack in the system (2) Managing for the knowns (3) Not limiting work-in-progress (4) Political promises and (5) Sloppy communication.  Let’s examine these:

1. No Slack

Every system requires slack in order to work correctly.  Old reel-to-reel tape recorders needed an extra bit of tape fed into the mechanics to ensure that the tape wouldn’t rip. Roadways operate best at 65 to 70% capacity – they bog down over 80 and are at a dead stop at 100.  In mills, grain is fed into the stones at about 70% capacity – anything over that gums up the works and makes the mill grind to a halt.

Why, then, is slack so foreign to project management?  Because we negotiate it away every time.  Why do we do this?  Because we estimate at the individual task and not at the project level.

It’s like saying “Yes, my Porsche can go 185 miles an hour” and estimating a 90 mile drive at 30 minutes.  Then we’re surprised when there are other cars on the freeway.

“Contingency” funds rarely work to abate this problem because contingency is not real. It is arbitrary and has no basis in reality.  It is a lie. Without understanding our throughput, we cannot adequately estimate a project. 

Successful project managers understand how long tasks usually take, what role variability plays, and what types of tasks slow their processes down.

2. Managing for Knowns

We manage for knowns.  When we estimate, we use our history to '”know” when the project will be completed. We manage for people doing what we know they will and when they know we will.

That’s not a good idea.

Human systems are complicated. Yes, we can finish that task in 3 days provided no one gets sick, there isn’t a power outage, there isn’t a blizzard.  Well, there are colds and blackouts and blizzards.

Successful project managers worry less about making sure their Gantt chart is religiously adhered to or if their two-week iteration goes unhindered and more about how to elegantly deal with the unexpected.

3. Not Limiting WIP

Again, people and teams have a capacity. If you exceed a certain percentage of that capacity, people become stressed, distracted, and increasingly ineffective.  If a Freeway at 100% capacity is at a stand-still, its throughput is 0%.  If your people are at 100% capacity, their throughput is likewise seriously impaired.

Limiting work-in-progress (WIP) is vital for maintaining throughput. Intentionally limiting WIP frees people to maximize their effectiveness by ensuring they work at an adequate percentage of their capacity. In turn, WIP is used to limit the number of features the organization can feed a team at a time. This helps the organization appreciate the true opportunitiy costs of new features. WIP limits communicate that employees are a limited resource and helps upper management understand the true cost of labor.

Successful project managers understand the capacity of the individuals working under them and can regulate the flow of work to optimize their throughput.

4. Political Promises

Politics are stressful and are often no-win situations. Project managers are often placed in political situations that force them to promise to produce more with less resources. (“Can’t you just add this one additional feature?”) Project managers cannot win these political situations because they don’t understand their true throughput. Project managers need to concretely show true productivity statistics to weather these confrontations.

Being able to say with firm evidence, “It takes us 21 days to release one new feature”  diffuses political pressures and opens the door to real discussions.

Armed with a firm understanding of their operations, successful project managers can avoid overpromising due to ignorance. 

5. Sloppy Communication

Teams run on information. In my experience, most delays and waste can be traced back to communications. Do people know why they are doing what they are doing? Does the team know what their co-workers are doing? Are recent developments rapidly disseminated so workers feel at-ease? Are the actions of the team being communicated up the management chain? Is the value of people’s actions understood by all? Are improvements to the development system being quickly discussed and acted upon? Is waste being spotted and dealt with?

Now that we have a multitude of tools to communicate with, poor communication simply can no longer be tolerated. The increasing commoditization of goods and services leaves profit margins too slim to tolerate that waste.

Successful project managers build social systems designed to rapidly disseminate information, keep team members informed, provide a pipeline to other areas of the enterprise, and improve operations.

Closing

Agile methodologies are great, I’ve been using them since 1997 when William Rowden and I first built our TreePro product. They went a long way to solving some of these tensions. Prior to that, as an urban planner, I managed multi-million dollar planning and engineering projects.  As we move forward into the 21st century we need to understand that all knowledge work (which includes both software development and urban planning) requires a more adept type of project manager: a project manager that manages for the unknown because they understand the knowns very well – and those knowns include what were previously unknown: variability, waste, and politics.

Disclaimer: This is a blog post. It is short. Food for thought. Just think about it.

Comments

[Vikrama Dhiman]

How can one manage for the unknowns? What does Agile lack that stops you from managing the unknown?

[twitter.com/pmstudent]

You can't manage the unknowns...only react to them...even in agile be sure to not load up the sprint backlog so the tasks are 100% of your team's optimistic full capacity.

Josh Nankivel
http://pmstudent.com

[Jim Benson]

Josh,

But you can manage unknowns, by ensuring you have the capacity to react to them and the processes in place to spot them as soon as possible.

If your team does not understand the value they are providing (what they are doing, why they are doing it, how it fits into the company) then it is much less likely that people will spot an "unknown" until it becomes a full-fledged problem.

It is very possible to manage unknowns.

[Jim Benson]

Vikrama,

While totally answering your question would require another post, or maybe a book, I'll try to make this work here. :-)

Agile methodologies are team-based productivity systems that tend to isolate development teams from the rest of the organization. This is certainly not the intent - but I've seen it time and again.

Scrum and XP are entirely unique processes to the dev team and have very weak communication rules outward. The original rhetoric of agile was very anti-management and the methods reflect that.

This means that Agile unwittingly creates its own silos. Constructs like client proxies and product owners - while infinitely better than what came before them - become bottlenecks where individuals are designated with tasks that are often better left distributed to the entire team.

Agile methods also do little to define the value that individual coders are providing to the overall organization. Again, this isn't the intention of Agile, but I see it repeatedly. Programming therefore ends up being an isolated task, where your backlog is provided in-bulk from outside sources who are clueless to the actual amount of work a team can complete at a given time.

Metrics like velocity measured through burndown charts do not have the statistical rigor necessary to communicate actual throughput to higher ups. Again, was it better than what came before? Certainly. Is it useful? Certainly. But it isn't a leading indicator for good future predictions - it is a good lagging indicator of past issues and performance.

In order to manage unknowns, a team needs to be actively plugged into the organization, have adequate communication internally / externally, have capacity (slack) to deal with surprises, and intimately understand their throughput.

Like I said, I've used agile for 12 years now. It has served me well. But over the last several years, I have become an agile repair man - going in and helping teams make those next steps.

[Karen Anderson]

This cheered me up. I just responded to an RFP that asked me to describe my process for doing something. I sent them a flowchart of the process in which several of the steps were ways to deal with things that go wrong. I'll be curious to see how the agency deals feels about that.

[henry]

ClearWorks New Version - 2.4 Released

Many our customers asking us about enhancements, and we are doing our best to provide requested features and functionality.
Today's release is a big update of current Sevenuc best seller product (also known as agile lifecycle tool for hardware & software project)
and at the same time composition with other software configuration management tools,
and more automation test tools and build servers.

Update contains more elements for Lean R&D real-time collaboration platform
and reflects latest innovations in Lean Kanban created by Sevenuc and other platform vendors.

What's New in 2.4

* Workflow define for deferent project with Lean stage management.
* Event and status driven mechanism by Triggers.
* Email classfication for effective customer request life-cycle management.
* Complete release support for Lean agile project.
* Lean R&D behavior improvements for all type of statistic charts.

read more