It’s the nightmare of consultants and project managers everywhere – you made a mistake of some kind and caused a big, fat emergency with your project. Oh no!
Without an ounce of exaggeration, I tell you that moments like this can make or break business relationships, and sometimes entire careers! We all make mistakes from time to time, but how you handle the mistakes – particularly the out-and-out emergencies – will determine whether you are viewed as a cool-headed professional fixer or a ham-fisted screw-up artist after the smoke has cleared.
Here are 5 steps that have served me well in my long career of managing, implementing and building projects of various types…
1) Stop the bleeding.
The immediate fallout from a project fumble can take different forms – a system might be hard-down, end users might be locked out, emails might be going out to people they shouldn’t, payments might not be processing, entire departments may be grinding to a halt productivity-wise, etc.
Whatever the case, odds are that your stakeholders are shouldering a cost, and that cost can best be visualized in the form of a wide-open faucet with money, goodwill and credibility (possibly yours!) flowing robustly down a deep, dark drain, never to return.
Does that sound overly-dramatic? It’s not. In cases like this, your absolute priority is to stop the bleeding. If a system is down, get it back online! If a department has ground to a halt, get it moving again! If data is being exposed, secure it! If customers can’t reach support reps, get those phones or chats back up! Whatever the immediate, ongoing damage condition is, you must tie it off immediately.
2) Fix the underlying problem.
Once the emergent issue is no longer bleeding dollars, time and goodwill, it’s time to turn your attention to the root cause of the issue. This is where troubleshooting techniques like working backward from the symptom to the root problem or splitting the problem domain into likely causal areas, can come in handy.
You likely have these skills already, now it’s time to use them!
Sometimes the underlying problem has a very clear, slam-dunk fix. Sometimes you may need to put a speculative fix in place and do a bit of testing to ensure that you have the “Holy Trinity” of problem-resolution in place:
- Identified the problem correctly
- Identified the fix correctly
- Applied the fix correctly
In a computer system, this may be fairly straightforward. In a human-driven system, this may be less obvious, and you may even have stakeholders or end users working against your attempts to investigate. Trust your domain knowledge, be persistent, and keep asking hard questions until you find the fix.
3) Take responsibility.
You can use these steps to deal with any project-related emergency, but the premise of the article is that the emergency is the result of a mis-step made by you or someone you manage.
By this time, you’ve stopped the immediate damage and fixed the issue. When you communicate this to your stakeholders (see #5 below) it’s important to own your role in the problem. Lean into accepting responsibility for the initial mistake that caused the emergency. Don’t mince words, don’t try to minimize, and do not try to shift blame. Not only are these behavior blatantly unprofessional, they’re also clear as day to anyone with the ability to think critically.
Your stakeholders will rightfully have some difficult questions for you, and the harder you lean into owning your role in the emergency, the less opportunity there is for anyone to call you out. State the mistake as plainly as you can. State the underlying cause of the mistake in similarly blunt terms. Take the blame. Even an ounce of deflection will open you up to withering examination.
Own it. Answer the hard questions. Then move on.
4) Demonstrate change.
If the fix itself is sufficient to stave off future instances of this particular emergency, great! Your job is done.
If not, though, it’s time for some things to change:
- Is a process at the root of the problem? Change the process!
- Is a system at the root of the problem? Change the system!
- Is a person on your team at the root of the problem? Re-train the person!
Whatever you need to do in order to make it impossible for the problem to recur, do that. And if you can’t make it impossible, make it as unlikely as you possibly can.
Then, demonstrate this change to your stakeholders; make it clear to them that not only have you stopped the bleeding and repaired the underlying problem, but you’ve taken the extra step of heading off any future instances of the issue. Your stakeholders are human – they understand that errors happen, but they’re not likely to overlook the same costly error happening more than once.
5) Commit to communication.
It’s very tempting to put your head down and get busy fixing without coming up for air until you can demonstrate that the entire affair has been handled.
Don’t do this.
It’s natural to want to be viewed as the one who scored a touchdown by fixing everything, rather than admitting to being the one who fumbled the ball in the first place. But while you’re doing that, your stakeholders. end users, customers, and lateral dependencies are all left to wonder what’s happening – and to fill in the lack of details with the worst scenarios they can imagine!
Instead, commit to communicating with your stakeholders at every step – when you become aware of the issue, when you start troubleshooting, when you start implementing a fix, when the fix is in place, and when you’ve implemented changes that will prevent the issue from recurring.
It doesn’t take much – just a 3-sentence email to your stakeholders will do the trick at each step – but taking a moment to communicate at every step gives you a lot:
- It maintains your goodwill and credibility
- It demonstrates that you’re in control
- It reduces stakeholder anxiety
- It prevents you from being distracted by a flood of emails and phone inquiries, leaving you free to work the problem
If the error is big enough, you may find that you take a hit to your reputation and credibility. But if you also fail to communicate, the hit will be much, much worse. Not keeping your stakeholders fully-informed during an emergency is completely unprofessional and you’ll absolutely suffer for it.
Let’s be honest – I could probably split hairs and turn this into “100 Steps To Recovering From A Project Screw-Up”, but I suspect you’re capable enough to unpack these basic steps into smaller steps if you need to. The important thing is to keep these issues in mind as you try to recover from a self-induced project emergency.
It’s not easy to keep a clear head while the alarms bells are going off and your team/stakeholders/end users are in a panic, but if you’re the pro I think you are, you’ll probably be just fine.