Here’s a thought experiment – let’s say you’re in a leadership position in your organization, and you are responsible for a big project. The project manager has been working hard on the project plan, and everybody is waiting patiently for the plan to be ready so they can get started.
If you hear me say something weird, please feel free to interrupt.
Finally, the plan is ready. The project manager proudly presents a GANTT chart with hundreds of tasks, meticulously wired dependencies, and dozens of developers individually assigned to each task.
You take a look at the plan, and the upcoming weeks look something like this:
Looks pretty good, don’t you think? There are tasks, a work estimate, start- and end dates, a cost estimate, a 5-star priority scale, and the familiar GANTT task bars wired up with resources and dependencies. You can’t really improve this any further.
You check the rest of the project and notice that the level of detail stays the same. Six months down the line, the planning still mentions tasks, dates, and resources in high detail. The planning accurately predicts the date of alpha-, beta-, and final release milestones.
It all looks great, so you sign off on the planning and the dev team, happy that the planning is finally ready, gets to work implementing the project.
I’m going to make a couple of predictions about the project:
- You will not deliver the project on the predicted milestone date
- The project will be a lot more expensive than the cost estimate
- The customer will be disappointed with the final product
How do I know this? Because you’ve just been hit by Death By Planning – a common leadership anti-pattern.
A clear giveaway is the elaborate and overly-detailed project plan. And remember what the rest of the organization was doing? The dev team was waiting for the plan to be complete _before_ starting work, so the planner effectively sets the pace for the entire project.
That doesn’t scale at all.
So what causes Death By Planning in an organization?
The three root causes of Death By Planning
There are three root causes that lead to Death By Planning. The first is weak role boundaries.
The project manager (PM) is responsible for the project planning and owns all deadlines and milestones. He or she provides project oversight and drives the work through the process to completion. The PM also provides weekly status reports to the executive management.
In practice, this is a fairly hands-off role. Most dev teams are self-steering and are well capable of managing their own workload. The PM only needs to monitor progress and in crisis, drive functional changes to get the project back on track.
The thing to watch out for is if the PM is taking on responsibilities of the lead developer role: breaking up requirements into detailed tasks, mapping task dependencies, and assigning tasks to individual developers. These are all dev team responsibilities that should not be done by the PM at all.
If you allow the PM to take on these extra roles, you will get project plans that are too detailed and need to be revised after every sprint. You will also disempower the lead developer and force the team to work at the pace set by the PM.
The second root cause is fear.
Waiting for a finished project plan before starting work is typical behavior in a culture of fear. You can never be blamed if you stick to a plan that someone else created.
Of course, for this to work you’re going to need detailed plans for everything. And there is absolutely no room for experimentation of any kind because that will re-expose you to potential blame. So if anything unexpected happens, the project will need to be halted while the PM revises the project plan.
Does your organization have bullying executives who blame, demean, and belittle others? This is a fertile ground for the Death By Planning anti-pattern. Before you know it, everybody will be hiding behind a plan that someone else created.
The final root cause is an unhealthy definition of success.
Why would organizations create super-elaborate project plans? To keep costs under control. Time is money, and a detailed project plan micro-manages time. The project plan predicts exactly how much the project will cost and ensures that nobody is wasting time while working on the project.
Unfortunately, this never works in practice. Tech projects are inherently unpredictable, and the overhead of having to redo the plan every few weeks far outweighs the benefits.
But let’s take a step back and look at the wider issue. A focus on cost suggests that the organization is using an unhealthy definition of success: instead of focusing on wealth creation for their customers, the company instead appears to have a policy of wealth extraction.
Instead of focusing on minimizing costs and maximizing revenue, the organization should aim to make their customers successful and work out a fair compensation model that encourages experimentation and creativity.
How to fix the anti-pattern
It’s not hard to fix this anti-pattern, but it requires some bravery from your organization to step out of its comfort zone.
The first thing you need to do is tackle the culture of fear. Executives who rant, criticize, and blame will create a toxic and fearful work environment, and you should have a zero-tolerance policy for this kind of behavior.
A culture free of blame is a very interesting work environment. In the absence of blame, everybody is free to try out experiments, move outside of their comfort zone, and be secure in the knowledge that mistakes will be treated as learning opportunities. This will stop people from hiding behind a planning.
The second thing you need to focus on is the project plan.
The problem with GANTT charts is that they use the same level of detail for both near-future and far-future work. This is perfectly fine when planning for next week, but it’s completely ridiculous to attempt to do this for work six months down the line.
Another disadvantage of GANTT charts is that it takes a lot of work to create one, and you have to constantly make adjustments to the plan to account for unexpected events. Keeping the plan up to date is a full-time job.
I much prefer to work with a Scrum burndown chart with a confidence level for the final release. It takes zero effort to keep that plan up to date, I still get my milestone date, and I have a confidence level too. A tool like FogBugz can automatically create this report.
But if you really have to use a GANTT chart in your organization, please make it look like this:
We still have milestones and deadlines, but now the entire development phase has been reduced to a single task called “development” without any resource allocations or dependencies. The lead developer is now responsible for creating tasks, wiring up dependencies, and allocating developers to tasks. The lead developer and PM now work as a team to hit the deadline.
This is hugely empowering for the dev team, and it takes a massive amount of work off the shoulders of the PM. You will find that everybody is happier, and the PM can now easily manage many more projects simultaneously.
And finally, take a long hard look at your organization’s definition of success. Are you focused on wealth-extraction or wealth-creation? The former is a risky strategy that will almost certainly drive your customers away, and kill off any chance of cross- or upselling.
A focus on wealth creation will lead to happy and returning customers and inspire experimentation and creativity in your organizations. It’s a win-win.
Have you seen Death By Planning in your organization? What did you do?
Also published on Medium.