How to handle deadline-driven plans
The theory behind project management starts from the iron triangle. We divide the work into estimated work items and allocate a team. Then, we map these puzzle pieces onto a timeline, and we have our plan.
If there's a lot of work and limited resources, the project's completion date will run out. We can often improve this deadline by assigning more people and parallelizing some work. Starting from scope and resources, we distill a timeline. Classic!
While this kind of deadline contains certain risks, it's an excellent way to get a general idea of when the project will end.
But there's another kind of planning that's way too popular. Sometimes, we don't start from scope and resources. Sometimes, we start from the deadline and work our way back to a plan. This is called retro planning and can be a scary, siren-like beast that lures hopeful sailors to certain doom.
The retro plan (or backward plan) starts from a fixed deadline and then tries to devise a way to get all that work done on time. When this happens at the beginning of a project, we can navigate its rough edges. We can cut scope until the plan seems feasible. If the deadline is important, retro planning at the start of the project is a good idea.
But too often, retro planning is an act of desperation. We've promised our stakeholders the app would be ready by September 1st. We've told them exactly which features to expect. And then, when we notice we are way behind schedule, we tweak the plan in the hope of getting back on track.
What makes this particularly dangerous is that the manager who gets to fix this plan has all the incentives to lie to themselves. Nobody wants to give bad news, and nobody likes to receive it either. When I was a young manager and came up with a new plan that somehow got the team back on track, I was lauded by the stakeholders. When I tried telling them the plan was lost, my project was given to a more experienced manager who would do a better job. The underlying message was clear: Just make it work, buddy.
It's easy to dismiss retro planning and treat it like the "dumb" option.
"Just move the arbitrary deadline, idiot".
If you've been reading this newsletter for a while, you know I'm allergic to that kind of thinking. While, yes, mid-project retro plans are dangerous, there are sometimes moments when they make sense. There are often contractual or political reasons why the delivery date matters. Techies who tend to dismiss this kind of politics severely underestimate how much influence these have on the organization. So, let's assume that for whatever reason, the deadline is fixed, and you're asked to create a retro plan. What are your options? What can you do to retrofit the plan to save the deadline?
Don’t believe in magic
The iron triangle is ruthless. If time has passed, the cost will go up, or the scope will decrease. When you're behind schedule, there is no way to get a project back on track without increasing the resources or cutting scope. The sirens will sing a song about "future efficiency" and "increased velocity". Don't listen to them.
Gannt chart tweaking can often result in a plan that somehow manages to keep the deadline without cutting scope or increasing the budget. That's a clear tell that it's a flat-out lie. We love to delude ourselves.
Only magic defies the iron triangle.
Stretch the other legs
If we respect the iron triangle and agree that we can't alter the "time" leg, we can still play around with "scope" and "resources".
While Brooks's Law is real, there are sometimes ways to get back on track by increasing the resources. Sometimes, we can buy a piece of software we intended to build. Sometimes, we can hire an experienced freelancer to remove some of our team's learning curve.
But more often than not, we need to cut scope, and that's easier said than done. Cutting scope mid-project is hard. Not only did we make promises to our stakeholders, but we usually already cut all the nice-to-have features at the start of the project. It's very common to have only a lean set of must-have features.
In this case, cutting scope means asking what we can deliver after the deadline. This is where we often have some creative leeway. Maybe we can launch with a "coming soon" on the dashboard page? Maybe our users can make do without certain reports for the first few weeks?
Some of the best mid-project retro plans I've worked with moved as many features as possible to Phase 2. Looking at big projects, you'll notice they often follow this pattern. They go live with known defects and missing features but manage to celebrate the deadline. It doesn't have to be black and white.
Notice how this respects the iron triangle: the scope stays fixed, but time and resources get stretched.
Involve another manager
If you've been managing a project for a few months and need to retrofit the plan, chances are you've got some blind spots. Your developers had some trouble getting the infrastructure up and running, but now that that’s done, you just know they will start picking up speed. Such a beautiful song…
Odysseus asked his sailors to put beeswax in their ears so they wouldn’t hear the sirens’ song. When retrofitting a plan, we could also use a partner who’s immune to those incentives that might lead us astray.
It's a great idea to involve a second manager who has nothing to do with the project. They'll act as a sounding board and keep you accountable if you get too optimistic about future team velocity. Managers succumb to the sirens because they have all the wrong incentives. An outsider who isn't responsible for the outcome provides a welcome set of eyes when making a retro plan.
Alarms should go off whenever we see the need for a retroplan in the middle of a project. It's not impossible, but we should be aware that we're entering dangerous waters.
When we are behind schedule, the best way is often to postpone the deadline. But I understand that that’s not always an option. When we do need to overhaul the plan in the middle of the project, it’s vital that both the team and stakeholders understand that this is never for free. There is always a cost involved.
A manager who produces a plan that somehow saves the deadline without impacting the budget and scope is delusional. They give in to their incentives and steer the ship toward a treacherous coast.