Smoke Jumping Into Risk Projects

Introduction

"Smokejumper." 

When most people hear the term, they think of brave men and women who hurtle themselves out of aircraft, loaded with gear, ready to battle a raging forest fire when they hit the ground. These smokejumpers have a challenging and dangerous job.  

There is another, less dangerous, smokejumper: the project manager who takes over an in-flight project. These leaders are brought into projects that are in progress and, most often, in distress (sometimes severely). For many reasons, the project is off track, and the previous project manager has either quit or been pulled off. Or, the project was too big and complex for the previous project manager to handle, and they needed someone to come in, take it over, and mentor the junior PM. In any case, you've been told to load up and "smoke jump" into this project ASAP. 

As a consultant, I've spent a good chunk of my career jumping into these types of projects. From experience, I've learned there are certain steps that need to be taken in a certain order. Below is how I approach smoke jumping into an inflight project. 

Smoke Jumping Approach

1. Review the Project Charter

OK, let's start by assuming the project has a charter. I'm surprised how many projects I step into that DON'T. If it doesn't, you have a good idea why the project went off the rails in the first place. Read this before any other documents. The project charter will give you an idea of the project's goals and objectives. Read it carefully and note questions that can be asked later to the different stakeholder groups you'll talk to. Also, look for information that isn't included. For example, I ask about what's supposed to be out of scope. 

2. Review the Last 2-4 Status Reports

If the project's in trouble, you may be reading "watermelon" status reports. They're green on the outside but red on the inside. Conversely, I've read status reports that were brutally honest, pointed out issues, and included return-to-green (RTG) plans. Understand what people were hearing and reading from these reports. Look at how leadership and stakeholders were receiving this information. 

3. Analyse Available Project Documents and KPIs

These could be anything, including the project schedule, risks and issues log, budget, communication plan, requirements, development and testing documents, and anything else available. Sometimes, this can be a library of information, whereas other times, documentation will be next to nothing (I'm used to seeing next to nothing). Review this information to the level of detail you think is necessary to get a feel for what had been taking place on the project.

4. Meetings & Interviews With the Project Sponsor and Key Stakeholders

Want to know why a project was selected in the first place? Go directly to the source! The sponsor or key stakeholders should have the information you're looking for. I tend to ask questions about strategic alignment, project benefits, and issues or hang-ups they've seen with progress thus far. I also ask about what they feel their role is on the project. Some sponsors know, whereas others admit they didn't have time to even meet with the project manager. Try not to let this turn into a "rip on this person or this team" conversation. They often do because they're looking for someone to blame, but that never helps get things back on track.

5. Meet the Team

Get ready for some bitchin'! I've never taken over an in-flight project where the team didn't throw someone under the bus, run them over, then hit reverse and do it again. There will be blame. But there will also be good information. It can be challenging, but try to direct the conversation to project issues, not personnel complaints. Find out about how the project was kicked off and the roles/responsibilities of the team members. Is everyone clear on the schedule and how their contributions impact success? This group can answer lots of questions. If it's a large team, meet with a small subset or break meetings into functional groups.

6. 1:1 With the Previous Project Manager

That is, if they're still around! It's rare, and I only had it happen a couple of times. I've also mentored the previous project manager, so there is a steady of historical information available. Get insight into the project team, stakeholders, vendors, and anything else that may be relevant. Stay humble, and don't blame them for anything that's happened in the past.

7. Re-Plan the Project

This is my recommended last step as a smoke jumper. Treat this as a re-kickoff of the project, reminding everyone it's starting again from a position of knowledge and momentum. This involves not only the team but also the sponsor and key stakeholders. Share the information and lessons you've learned and your plan not to repeat them going forward. Once the re-planning is complete, communicate it broadly! 

One thing I will also note when it comes to re-planning is a communication plan, especially as it relates to status and issue escalation. Because most smoke jumping I've done is for distressed projects, I make sure I have my sponsor on speed dial to call if something's wrong.  You may find stakeholders weren't reading status reports, so find a way to communicate status broadly and in a way people will engage.

8. Carry On!

Once you're done re-planning, it's time to carry on like any other project. Keep engaged with the team, and be sure to communicate status often.

Conclusion

Project smokejumpers. It's not easy to jump in and take over leadership of an in-flight project. But, through information gathering, interviews, and solid re-planning, you can help get the project under control and back on track!