So You Think You’re Good At Multitasking

A good friend of our family is an EMT (Emergency Medical Tech). Somehow, we got on the topic of multitasking. As she put it, if she loses focus and starts multitasking on things not directly related to a patient, someone could die.

That got me thinking, do I multitask? Hell yeah I do!! Every project manager I’ve ever known multitasks. And you know what? We all think we’re good at it!

But let’s be honest, no matter how good we think we are at multitasking, we’re probably not. Though it (hopefully) won’t result in someone’s death, there are impacts to ourselves, the team, and the project we’re leading. Below are some of those impacts. What others might you add?

Loss of Focus. Ever been on a call, mindlessly listening to the team talk while checking and responding to email, then hearing “What do you think [insert your name here]?” Damnit! Splitting your time and attention too much causes you to lose focus on tasks that are important and prevents them from getting done. When having important conversations, you can miss key messages or just say “YEP!” and commit to something you’re not able to do. Chunk out time to focus on one task at a time.

Oh Shit I Forgot What I Was Doing. If you’re trying to do two things at once and then a third and fourth item jumps into the mix, chances are something is going to be forgotten. Maybe you forgot where you left off on item #1. Or, you forgot about #2 all together. Some people are good at keeping track of where they left off. I personally am not. I know others who are even worse than me. If you multitask, you run the risk of forgetting something.

Discombobulation and Anger. One of the side effects of multitasking is overstimulation. Your brain is trying to take in a lot of information. Once it can’t process it all, you become confused, then upset. At that point, we’re prone to lashing out at team members or any other unfortunate soul who gets in our way (if you work from home, it could even be a loved one). When you start to feel that confusion and anger coming on, step back, take a breath, and focus on the most important task to get done.

Increased Stress Levels. Let’s be honest, even without multitasking our lives are stressful. By multitasking, we’re only making a stressful situation worse. Building on discombobulation and anger, if we continually overload our brains with too many inputs at once, our stress levels go way up and risk burning out! Don’t make your life more stressful that it needs to be.

Costs Your Project. If you’re multitasking, you’re probably not focusing on the most critical thing your project needs. Your project team may see you multitasking and do the same thing, thus not getting key tasks done. When project issues inevitably come up, if you and other team members are multitasking, you may not be as creative in coming up with a solution.

Let’s be honest, I can tell you not to multitask. You can read about why not to multitask. Tomorrow by 9AM, you will have probably multitasked a dozen times. We won’t stop doing it, but be aware of when you feasibly can, and when you should focus 100% of our attention on something important. Project managers multitask all the team. It’s in our DNA. But don’t allow it to impact yourself, your team, or your project.

Processing…
Success! You're on the list.

“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.