Don't add gasoline to the fire!

I’m hoping you already know this, but just in case you didn’t know, here’s a friendly reminder:

When faced with a fire, don’t pour gasoline on it.

No need to explain why adding gas isn’t a great idea because it is obvious that pouring gasoline on a fire will only make it bigger and harder to put out. It’s common sense. 🧠

But when the fire is metaphorical, it is less clear what will make it worse. If a project is struggling (i.e., on fire), what should you avoid doing? 🤷‍♀️

I’ve been chatting with numerous business analysts, project professionals, and product management peeps about projects-on-fire and here’s a round up of the worst things you can do should you find yourself on a project that is in crisis.

Based on our own real world experiences, here’s what not to do: 👇

🦸 Management heroics
🙈 Don’t look!
🍉 Bad communication
🏚️ Avoiding the fix
🪙 Shortchanging the change

So sit back and enjoy reading about how others have made their situation much, much worse than it needs to be. I’m hoping that the next time you find yourself in a similar situation, you will avoid making the these common mistakes.

The most common thing people get wrong under crisis is adopting a management-as-hero approach.

Management heroics is when management folk go all secret squirrel, then go make a plan in a room by themselves. They don’t involve the people on the ground (management knows best right?) and later emerge with a master plan to save us all from disaster!

The problem with this approach isn’t lack of good intent, but rather the level of knowledge in the planning-room. Managers (bless them) are typically the people who know the least about what’s really going on with the project, so it is unsurprising that this approach usually yields another complete disaster.

Please forgive me because I’m about to go on a detour for a moment, but trust me: it’s important.

One of the most interesting things about a project that’s off track is the amount of knowledge created during the time the project has been running. A guaranteed return on any sunk cost is learning.

So when a project is off track? Well that means that rather than guessing at and preparing for things that could possibly trip you up, you already know what’s going to hit you! How brilliant!!

You now know exactly how challenging the stakeholders are, and just how expensive the market research will be, hell, you even know how much real support you will get from your executive team!

You are no longer guessing, you have facts, and you actually know how hard this thing will be to do!

In fact, you have more information about the actual state of play then was ever known when the original plan was created. When you think about it, planning before you know any of this is kinda insane, no?

But let’s get back to those managers.

Off they go to make a plan without the benefit of all the knowledge that has been collected over the last X number of months. So they use the same pattern they used when setting up the project in the first place.

The result? They make a plan as flawed as the one they’re replacing. And fail to leverage the investment they’ve made in the project to date. It’s bad planning, and bad economics.

Worse, the team is disempowered, feels unheard and kept in the dark, so any resulting change is starting off on the worst possible footing.

The fix is obvious. Simply include the project team in the re-planning!

Caveat: context matters. Sometimes you do need management heroics. Just far less often than you think.

This one is really easy to do. It goes like this:

1. You find out something big is wrong. Or a number of small somethings. Maybe a piece of your solution design is under-scoped and the design needs to be re-thought in a big way. Maybe the procurement timeline is going to be much longer than you planned. Maybe part of it is going to cost more than you budgeted for. Well, crap. 😞
2. You fix that thing!
3. Everything is now fine, right?

Yay! Go you!

But also, do you see the problem with that?

You missed something. You had a blind spot. You thought something was solid and it turned out not to be.

The question you should be asking is: what other assumptions are you treating as solid that actually are just assumptions? My mum used to say, “if you see one mouse, you have ten”. That’s true! And the same thing is true about risks.

If you can see one, you have ten (at least). 🐀🐀🐀🐀🐀🐀🐀🐀🐀🐀

So in the event you find something wrong, by all means go ahead and fix it. But rather than assuming that everything is now fine, actually check that it is!

Not taking the time to make sure your foundations are solid is the easiest thing to do wrong. This is actually a massive contributor to a project being in crisis. Because the reality is, a crisis is usually a collection of things gone wrong.

And on big projects people tend to be spread thin. Which creates the conditions for things to smoulder in the gaps. Any one of these things could flare up to become the next disaster.

You want to find out what is smouldering at the earliest possible opportunity.

Don’t play whack-a-mole with fire.

The fix?

Check things. Having a really good look at the risks and making sure everything is covered (and communicated) is always a solid move.

I’m not advocating for a 3-month pause in action while the team checks line by line all artefacts they’ve created to date every time a small discrepancy is discovered, but rather an ongoing prodding of what you believe to be true.🕵️‍♀️

Asking “does this still make sense?” of all key artefacts will never be a waste of time.

Ignoring suggestions that you might not be in as good a position as you hope you are is throwing gas on the fire.

Better yet, how about avoiding this one entirely? It is possible to do, but it requires a culture of psychological safety. In an ideal world, no artefact should be immutable. No belief should be above challenge.

And the more you can encourage the team to be able to raise concerns and dig into issues, then the more you’ll know and the less likely you’ll find yourself on the road to calamity.

Building this kind of culture on a project is well worth the investment.

Not putting enough effort into (honest) stakeholder management and communication is another way project teams make things much, much worse.

The business stakeholders are the client of the project. They need to be kept informed and engaged. The worst thing you can do is keep them in the dark. Especially when things are going wrong.

Adopting a “watermelon comms” approach is the worst idea of them all.

If you haven’t yet encountered the term “watermelon” in this context, that’s when a project’s status is all red on the low-level reports, but green and happy on all of the executive reporting. It’s red on the inside but green on the outside. Get it? Like a watermelon 🍉!

The team on the ground absolutely knows what’s wrong, what’s really happening, and what the end result will be—and it’s not great. But they haven’t communicated that reality to the business owners.

Somehow as information is reported upwards, each report gets a little rosier and by the time it is in the hands of the exec, well it’s on track for success!!

The result? The key stakeholders are in the dark. They’re not going to be happy.

But that’s not even the worst of it.

Because the business folk don’t understand the real situation, they aren’t able to make good decisions!

A critical part of good decision making is accurate information. If you think you’ve still got a bunch of savings to fall back on, you might take that nice holiday in Thailand! But if you’ve got no savings, you might hold off on committing to a trip.

How much or how little buffer is in the bank accounts is a key input to decision making.

In a watermelon project, the business doesn’t know how little buffer they have, so they’re likely to make the situation a billion times worse (rough estimate). They continue requesting more scope to be added or wanting things faster.

Or they want to investigate things that the project won’t get to for a while, thus taking attention away from the priority things that are necessary to get to MVP.

The fix? Transparency. The more informed your stakeholders are about what’s happening, the better they can avoid regretable decisions. Warts and all.

Projects cannot right themselves without support from the business folk. So any time you are playing politics with information, you’re adding gasoline to the fire.

Another great way to make things worse is deliberately (or accidentally) not tackling the right fire. Ya know, taking a “low hanging fruit” approach:

“Oh, look! The house is on fire! But I really need to mow the lawn today, so I’d better get that done first!”

It’s easier (the lawn looks great!), but pointless (a shame about the house, though …).

Sometimes the avoidance of dealing with the big hard thing is so extreme, it really is the equivalent to discussing future plans for landscaping while the house is on fire.

Lot’s of things can lead to this special kind of gasoline. It could simply be terror of the big fire creating reluctance to talk and/or deal with it.

It can also be caused by an impulse to self-preservation: an attempt to avoid being tarred with the failure brush—the project version of “he who smelt it dealt it”. And sometimes it is lack of experience, i.e., a genuine lack of knowledge of how to tackle a house fire.

For the avoidance of doubt, leaving a fire to burn is adding gas.

The fix is a bit context-dependent. But all fixes require two things: confirming the thing(s) that matter—“the most important thing is that we save as much of the house as possible”—and naming the big bad—“the house is on fire and if we don’t move quickly we could lose it all.”

You can’t deal with something that you won’t acknowledge. And you’re likely to scatter your focus if you don’t keep attention on the things that matter.

Saying it out loud is really important and problem statements are a useful tool to focus attention.

Let’s assume for the sake of argument you’ve done everything else right! You’ve identified the problem! You’ve taken a step back and really understand where you’re at with the project. You’ve been transparent with all the stakeholders and have a comprehensive plan to move forward—a plan that wasn’t built in isolation.

Congrats! 🎉

Here’s where you can still go wrong after all the rightness of your process so far. And how you can double down on the bad if you’ve fallen victim to any of the other pitfalls above. 👇

You shortchange the change.

You book in a couple of hours of meetings, along with a team charter review and think that you’ll be able to change direction with that minimal level of effort.

You, my friend, could not be more wrong.

Hate to tell you this if you didn’t already know it but change is hard work. The very hardest.

The team needs time and space to pivot, to understand the changed situation, and to get on board. This is critical to any success.

According to a brief internet search, it takes a minimum of eighteen days to form a new habit, and an average of sixty-six days for a new behaviour to become automatic. That’s rather a lot longer than a business day.

Now a team with an awesome culture and great performance can pivot quickly, but if they’ve been under pressure it’s not fair to expect them to leap on board! All the peeps on the ground have been working in a particular way, on things that they are probably invested in. Reshaping that focus onto something different will take time.

Any change will absolutely hit your delivery momentum. And the impact will be even more significant if the change includes people or process changes.

The fix? Take the change seriously. Work with the peeps on the ground to understand what they need and work hard to deliver that.

Also communication, communication, communication! Almost everyone I spoke with saw how critical communications were to navigating through a rough patch.

You’re at the end of the article (congrats for making it this far), so this is when I have to admit that these things aren’t bad for projects on fire exclusively.

They’re just doubly important to avoid when things are highly flammable. The impact of a spill without a spark isn’t as dramatic, but still worth avoiding.

In short and in reverse, I’m saying you would be far more likely to succeed in any endeavour if you:

👫 Invest in taking your people on the journey
💪 Identify, name, and lean into the hard stuff
💬 Always report honestly
🔍 Stay alert for issues
🤝 Involve experts in decisions

Which all sounds deceptively easy doesn’t it?