Firefighters are like local celebrities. Who doesn’t love a firefighter? Believe me, whenever my husband and I meet new people, and they find out he’s a firefighter… ugh… let the swooning begin. They get so excited! Most people immediately assume that daily, my husband is in full gear atop a three-story ladder saving people and putting out fires.
But do you know what firefighters mostly do?
They sit around waiting for bad things to happen. In fact, they train for bad things to happen. They plan on bad things happening.
A lot of professions do this: Police officers, ER medics, dispatch operators, first responders, the military. So many professions plan and train for what to do when bad things happen. Yet, for some reason in our cozy office (or home office) settings, we often prepare for the best case scenario and assume everything will go exactly according to plan. No one will get sick, no one will have a family member pass away, no one will get injured, and certainly no one will take another job during this project.
So we inevitably plan a super tight schedule and assume everything‘s gonna be just fine.
How often has that worked out for you? My guess is you’re not even batting .500.
So how can both project managers, team leaders, and stakeholders take ownership in real-life project planning? Here are three actions you can take to prevent your project from being derailed by road blocks:
1. Hold a pre-mortem
If you haven’t read “Performing a Project Premortem,” posted by the Harvard Business Review in 2007, I recommend checking it out.
The name is a little macabre, but boy, it’s such an effective tool! In short, before you start the project, you get the project team and stakeholders together and ask: “What if we fast forward to the end of this project, and it has failed spectacularly? What went wrong?”
Then—with frank honesty and transparency—the team looks ahead over the duration of the project and brainstorms anything that could go wrong. It could be related to finances, politics within the company, issues with stakeholders, resource allocation, you name it.
Once you’ve identified what could go wrong, you’ve basically done a rigorous risk analysis, and you can begin to to plan—looking that worst case scenario straight in the eye and not fearing it. Rather, you’re planning for it. And better yet, the key stakeholders are aware of these risks too!
2. Pad the timeline
This recommendation is so granular that it seems silly to mention, but it’s highly practical. If you’re on point for preparing the timeline, simply add a few days (or weeks!) to each phase. A good PM or team lead should know the nuances of not only the project, but also the working styles and contexts for each team member.
How do you determine how much to pad? This is my highly scientific, research-based opinion: when there’s no way to calculate it, then go with your gut.
If you’ve been at this for a while, then you know this stuff. You’ve seen it happen. You’ve been around this block before.
Best case: you don’t need the slack, and you hit your deadline early. Worst case: you need the slack, you use it, and the rest of the project is not derailed (or derailed as much) because you had the good foresight to pad the timeline.
And when you discuss the timeline with stakeholders, don’t skirt the issue if they ask why certain parts will take so long. Just be honest.
In the past, I’ve said things like:
“Life happens. And over the course of the next nine months, there’s no way to guarantee there will be no distractions or interruptions will occur, so I’ve added a few days/weeks to each phase.”
Then show the stakeholders where that slack is built in. If they really want to push back, you can then have a more focused conversation about scope, time, and cost, and bring them into the planning details to resolve their concerns. You have nothing to hide. You’re doing your job.
3. Lower your “bus factor”
If you’re new to this term, bus factor basically means: If you walked outside and got hit by a bus and someone else had to fill in, how easy or hard would it be for them to do so?
Although it’s a really subjective term, a bus factor of, say, 2, means that you’re doing a pretty good job of sharing your work with others, training others as needed, ensuring the team is aware of your progress, and documenting what you’ve learned.
A bus factor of 10 means that if you went on an unexpected hiatus, it could take the team days, weeks or even months to catch back up to where they need to be.
When working in IT with a bunch of crazy-talented developers, it would not be uncommon for me to hear one of them say, “I’ve got to lower my bus factor here.” Then he (in this case, it was a he) would spend a day or two documenting, updating wikis, and doing what he needed to to ensure all knowledge of this subject wasn’t lost if he was suddenly unavailable.
Using simple collaboration tools like Google docs, Dropbox, or even shared encrypted password apps (like 1Password) will help ensure that if one team member gets derailed for a while, other team members can step in and figure out how to keep moving forward.
Basically, whether you need all these ideas, or just a couple, keep in mind: projects, as in life, don’t always go according to plan. It’s appropriate, healthy, and necessary to plan for that and to mitigate the risks you can.