Are you planning your product to death?
Here’s a thought experiment — let’s say you’re the CTO of 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.
Finally, the plan is ready. The project manager proudly presents a GANTT chart with hundreds of tasks, meticulously wired dependencies, and dozens of resources individually assigned to each task.
You take a look at the plan, and the upcoming weeks look something like this:
Looks okay, right? There are tasks, work estimates, start- and end dates, cost estimates, a 5-star priority scale, and the familiar GANTT task bars wired up with team members and dependencies. You can’t really improve this any further.
You check the rest of the project and notice that the level of detail remains consistent. 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 the following predictions about the project:
- Your product will be delayed
- The project will be more expensive than the cost estimate
- The customer will be disappointed with the final product
How do I know this? Because you’ve been hit by Death By Planning — a common leadership anti-pattern.
A clear giveaway is the elaborate and 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 your 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 your 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. The team can never be blamed if they all stick to a plan that someone else created.
Of course, for this to work they’re going to need detailed plans for everything. And there is absolutely no room for experimentation of any kind because that will re-expose the team to potential blame. So if anything unexpected happens, the team will halt the project and ask the PM to revise 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 your organization create a super-elaborate project plan in the first place? To keep costs under control. Time is money, and a detailed project plan micro-manages time. The plan predicts exactly how much the project will cost and ensures that nobody is wasting time.
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 creating wealth for their customers, the organization has a policy of extracting wealth by minimizing cost and work effort.
This is completely wrong. 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 you to help your organization 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 empowering 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 produce this report.
But if you really have to use a GANTT chart in your organization, please make it look like this:
This plan still has 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 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 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 up selling.
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?
Are you interested in Leadership anti-patterns? I have recently produced an online course that will teach you some essential tools to master healthy leadership and communication in your organization. Read more…