“Smoke Jumping” Into an In-Flight Project

“Smokejumper.”

When most people here 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 very difficult 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 a multitude of reasons, the project is off track and the previous project manager has either quit or been pulled. In any case, you’ve been told to load up and “smoke jump” into this project ASAP.

I’ve learned from experience there are certain steps you should take when jumping into this project fire. Below are the steps I use. Note I put them in order of how I jump in, and there will always be times to rearrange as necessary. My biggest recommendation is no matter what, always make re-planning LAST. Understand the project’s current state and some of the history. Knowing that will make re-planning more effective.

Review the project charter. OK, let’s start by assuming the project has a charter. If it doesn’t, you have 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, as well as any other information provided. Read it carefully and note questions that can be asked later to the different stakeholder groups.

Review the last 2-4 status reports. If the project’s in trouble, you’ll probably be reading “watermelon” status reports. They’re green on the outside, but red on the inside. Understand what people were hearing and reading from these reports. Again, you’ll probably have some questions when talking with others later.

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

Meetings & interviews with the project sponsor and key stakeholders. Want to know why a project was selected in the first place? Need to learn more about a project’s specifics? Go direct to the source! The sponsor and/or key stakeholders understand strategic alignment, what benefits the project provides to the company, and issues or hang-ups they’ve seen with progress thus far. Try not to let this turn into a “rip on this person or this team” conversation.

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 roles/responsibilities of the team members. Is everyone clear on the schedule and how their contributions impact success? Lots of questions can get answered with this group. If it’s a large team, meet with a small subset or break meetings into functional groups.

1:1 with the previous project manager. That is, if they’re still around! It’s rare and I only had it happen once. Ask them about the history of the project and what was coming up next. Get insight into the 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.

Re-plan the project. This is my recommended last step after you understand what has been taking place up until now. Gather the team, including the sponsor and stakeholders, understand current state, and set realistic goals and timelines. Sometimes an end date is already set due to a business need or compliance requirement, which the team must react to. Others, the delivery date has some flexibility. Make it a formal re-kickoff and remind everyone of what was learned in the past, but focus on delivering in the future!

Carry On! Once you’re done re-planning, it’s time to carry on like any other project. But in this instance, you have some good lessons learned prior to your smoke jumping in so the same issues and mistakes don’t pop up again!

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!

Processing…
Success! You're on the list.

Reasons Why Your Project Team Hates You

Ok, I’ll admit, HATE is a strong word. Extreme dislike (which is basically the definition of hate) sounds a little better.

The first project manager I ever worked with I couldn’t stand and extremely disliked. He showed up once a week, told us we weren’t doing our jobs and should be fired, and left (see Project Manager Pop-up). He also threatened to go directly to the VP if we didn’t complete our work on time. Yeah, we hated him. After a few months of this, I suggested an approach to make things go faster. He turned red, through the project plan at me and said “If you can do better slick, go for it!” That was my first project 20+ years ago. Even though I really didn’t like that guy, I guess I should thank him for taking my career in a different direction.

Every project manager has their own unique personality and style. These personalities and styles may rub some team members and stakeholders the wrong way. Can’t make everyone happy. But, there are some things project managers do that will make their teams hate them! Here are the top reasons I’ve seen and experienced.

Quick to Take Credit, Quicker to Direct Blame. This is one of the quickest ways for your team to hate you. I worked with a program manager who, in front of the executive committee, told everyone that HIS efforts got the program done. He also blamed individuals when things went wrong. If you’re the type of project manager who takes all the credit and quickly assigns blame, your team will hate you! A lot. Instead, be quick to praise the team and just as quick to accept blame. Sometimes you have to fall on your sword for the greater good!

Yell First, Talk Later. Because projects are complex, constrained, and unique, mistake-free projects are the exception, not the norm. Shit’s gonna happen! When they do, if you allow for an emotional response and start yelling and/or blaming, your team will hate you. They’ll also refrain from bringing problems to you in the future. Instead, check your emotions and THANK team members when they bring issues to the forefront. Don’t be the person who yells when any little thing pops up.

PTO Does Not Equal “Pretend Time Off.” Everyone needs to take time off to rest and recoup. When you kick off a project, I recommend having a PTO calendar. When someone does take time off, you can be proactive and ensure their tasks are covered. That way, your team member can take some relaxing time away without anyone needing to call them. Don’t be the project manager who calls someone to ask for information while they’re at the beach! Plan ahead.

Micromanage Every Task. Projects are broken into tasks. Those tasks are completed by team members. These team members are really good at what they do. So if they’re good at it, why are you constantly looking over their shoulder to see if work is getting done? Micromanaging is just going to piss them off! Look at it from a Trust and Verify; trust the work is getting done and also verify it is.

Lean on a Small Group of Team Members (or just one). “Ah shit, the (project manager’s name) is calling me again!!” On our projects, we have those team members or team member who we rely on. They’re smart and dependable. Because they are, we go to them with questions and ask for information. And we go to them. And we go to them. And we go to them again until they’re tired of hearing your voice. Eventually, they’re not going to want to talk to you! If you have questions, try to ask them all at once versus calling the person 10 times a day. They’ll appreciate it.

Give Up Gossiping! Every company, department and team has gossipers. Think about the last time gossip you heard that was even true. Because project managers talk to so many people, they have the opportunity to spread lots of gossip. Let me tell you; don’t do it! If the gossip is untrue, you’ll be equivalent of a manure spreader, and your team will hate you for it. When you hear gossip, keep it to yourself. Better yet, ask questions and try to stop it!

Project Manager Pop-up. Ever play “Whack-a-Mole” where this little fury creature pops up and you hit its head to make it go back down? This is similar. The project manager pops their head up, tells the team what to do, gets upset with them for whatever reason, doesn’t take the lead to help resolve issues, and then disappears. They’re not leading. Instead, they’re just popping up and popping back down just as fast. Your team won’t like you if this is how you operate! Don’t be a mole; Lead!

Again, Hate is a strong word. But at the same time, we’ve probably seen actions project managers take that cause a team to really not like them. This is my list. I’m sure you have other things that rub you wrong also. What would you add? But ultimately, don’t be a project manager your team hates.

Processing…
Success! You're on the list.

Be Honest With Your Project Team

“C’mon, just level with me. Be honest!”

Ever hear those words before and not quite know how to respond?

If you’re in a senior leadership position, there are times being honest isn’t an option.  For example, if there are layoffs, reorg, acquisition, and any other number of circumstances. Any mention, the rumor mill will take off and morale will go down. Not to mention, you may have signed a legal document (NDA) so you’re breaking the law!!

There are other times, especially when it comes to your projects and programs, where honesty is the best policy (I’m sure you’ve heard that phrase before!). These can be uncomfortable conversations. Nobody wants to hear about problems. But as a project leader, you can’t fix problems on your own and need the team to assist. If you do (and I’ve seen some PM’s try to fix all issues themselves), you may just make it worse!

Here are 3 key reasons to be honest and bring issues front & center:

  1. Builds Trust. Trust comes from communication. You’re not afraid to communicate both good news and the bad. Your team trusts you’ll tell them what’s going on. Without honest communication, trust breaks down.
  2. More Brains = Better Outcomes. Projects will always have issues arise. The more smart people you have working on tough problems, the better the results will be. Smart people can’t solve problems they don’t know about!
  3. Bad News, not Good News, Travels Fast and Gets Worse.  Have you ever heard the phrase “Good news travels fast?”  Well, it’s true, but bad news travels a LOT faster. Bad news also does not get better with age.  Sometimes that bad news is known well before it becomes an issue, but employees weren’t comfortable discussing them with leaders.  Build a culture that rewards, not punishes, getting problems out into the open where the team can solve them.  

Honesty is the best policy! We can’t come clean with all information all the time. But when it comes to our projects are program, be honest with your team! Honesty will build trust, result in better outcomes, and reduce the bad-news grape vine.

Processing…
Success! You're on the list.

Can John Cleese’s Advice Help Solve Those Tough Project Issues?

Let me start by saying, if you don’t know who John Cleese is, look him up. Watch a couple of his Monty Python skits. Then c’mon back to this article!

About six months ago I was talking about the movie “Monty Python and the Holy Grail” with a couple coworkers. Someone mentioned John Cleese’s book on creativity. Given I’m not what I would define a creative person, didn’t give it a second thought.

However, at a high school swim meet a month ago, I was talking to another parent about a variety of topics between our kid’s events. She’s a super-smart data analyst in a healthcare actuary department. She loves data and the story it can tell.

As we talked, she said her department had been asked for more and more information. Some of the problems the department is trying to help solve have a big impact on the organization. That’s why when she said their VP asked everyone to read the book by John Cleese called “Creativity: A Short and Cheerful Guide”, I was intrigued. Because the department was full of analytical people who wanted to be “right” versus “close enough”, they never got things done or made decisions. The VP wanted more creative approaches to problem solving, and thought John Cleese could help.

Long story short, this conversation prompted me to buy the book and read it on vacation. The book was short and cheerful as the title says. But, I also found it informative. With the right team and some creativity, those really tough project management issues can be solved. Here are three take-aways I got from the book and how they could relate to project management.

Do Work Before Bed. Ever heard the term “sleep on it?” Basically, if you sleep on it, you delay making a decision or taking action until the next day. Some will call this procrastination. I think, however, if we do some work before bed, our minds put in work overnight.

John Cleese notes if he puts in some work before bed, he often has a little creative idea overnight, which contributes to a solution to the problem he’s trying to solve. For years I’ve kept a notebook on my nightstand for the same reason. If I have a problem and am thinking about it before bed, I’ve been known to wake up in the middle of the night or in the morning with an idea. If I don’t write it down immediately, I’ll forget. This doesn’t work for every problem I encounter, but I’d guess about 25% of the time something pops in my head at night! Maybe ask some of your team members to do the same. Who knows what people will dream up (literally)!

Avoid Paralysis. Paralysis comes from the worry of making a mistake.  If you think you’re wrong, stagnation happens because you’re afraid of being wrong.  But, if you’re trying to be creative, there is no such thing as a mistake.  You can’t know you’re going down the wrong path until you’re on it! 

How many times has a project issue come up where someone says, “Well, that might work, but it might not.”? Then there’s more discussion, followed by nothing happening. Instead, that “might work” scenario could in fact be wrong, but it could also open doors to other solutions. It’s a risk to start down the path, but it’s more risky to remain stagnant. Give it a try! As Einstein said, if we know what we’re doing when we’re investigating something, then it’s not research.  

Don’t Get Bogged by Process. When you’re trying to creatively solve a problem, don’t get bogged down in process. Think of your process as what’s done in normal (or at least near normal) circumstances. When it comes to creative problem solving, there’s not a lot of process to fall back on.  New things can be confusing and unfamiliar.  That’s OK.  It’s normal.  Instead, let time be your ally as you think through it.  Eventually, clarity will emerge!

I worked for a company that provided SaaS products. A potential new client liked our products, services, and ongoing support. However, they wanted to make one “small” change that would require a change to the overall architecture. Given this client would jump our revenue 70%, we had to dive in. The enterprise architect said NO WAY, can’t be done! It won’t fit in with our standard processes. So we drew our architecture on the board, and noted places it would change. He then went outside and had a couple smokes, came in, looked at his board, and some ideas came to light. He said it was a crazy idea, but ultimately it worked.

I never imaged I’d say John Cleese and Project Management in the same sentence, but hey, if the shoe fits!! Project issues come up all the time. Some are small and quickly resolved. Others require some creativity. Sometimes, you’ll need to sleep on a problem to see if your mind sorts it out overnight. Avoid analysis paralysis and start taking action. Finally, don’t get bogged down in process. Ultimately, with creativity and the right team, everything can be figure-outable!

Processing…
Success! You're on the list.