A Solid Launch Consulting

Successful Leadership Comes From Leaning Into Your Own Style

Archives for January 2021

Is It Sabotage?

by

I was talking with a friend the other day. He is working on a renovation project. The team gathered requirements, reviewed options, had a lively discussion (or three), made decisions and then sent the final plans to the architect.

If you’re a PM you know what’s coming…

Yup, 2 days later, one of the team members sent an email to everyone: “I don’t think this is going to work. Here’s what we should do instead…”

UGH!

I felt so bad for my friend. And I could complete empathize!

It happens all the time on a project, unfortunately.

But why do certain people always seem to sabotage a project? And what can we do to prevent it?

The “why” is pretty easy: we’re human. And being human means we’re subject to frailty and influence…and we don’t always do what we should, even if we know better.

Here are some common reasons for the late entries:

  • Shyness. Some people don’t like to speak up. They work up the courage to speak but it’s well after the deadline
  • Introversion. As opposed to shyness, these folks may not speak up in a meeting, but need some time to reflect. And they may feel more comfortable writing or meeting 1:1 to discuss
  • Power. Let’s face it. Some people – consciously or unconsciously – feel the need to step in and take over. They may believe they have the better answers and it’s “my way or the highway”
  • Temperament. This one feels like Power, but it’s more about how they communicate. I know plenty of folks who honestly don’t realize they’re disrupting the very thing they’re trying to accomplish – they think they’re helping by bringing up additional suggestions or solutions, regardless of who they’re stepping on or how much re-work they’re causing

Having these late additions go unchecked can disrupt the project and the good will of the rest of the team. People may even leave the team completely – they refuse to work with the “disrupter”.

And as the Project Manager, if you don’t rein in the late entries your reputation takes a hit, too.

Each case is unique, but given the four common reasons above, there are a few pretty simple ways to minimize the occurrence, or at least the disruption:

  • Set up a short meeting with the known disruptor pre-decision meeting. Ask their thoughts and if there are any risks they see. Make sure to bring up these risks during the meeting so they’re addressed
  • Set up a meeting with the disruptor post-decision meeting. Ask for feedback again – you can play on the “did we cover it all” angle
  • Hedge your bets by giving the decision a “draft”. Give the final decision a buffer period for “new information”. I use this one with requirements. Sometimes we’ll schedule a “soft freeze”, knowing things will come up right after we freeze the requirements – even without a “saboteur” on the team!
  • Simply don’t allow it. Politely but firmly tell them it can’t be changed without \approval from the executive team. This one is tough to do unless you’ve planned for it. I always set up a change control process early in the project: process, documentation, decision-making. And make sure everyone is aware of this process throughout the project

Identifying project risks is important, no matter when they are raised. Our goal is always to bring the project forward, with everyone on board. Seeking to understand why a team member gives you a late entry helps lead you to the most appropriate response.

Are You The Hub? Or Just A Spoke?

by

I usually lead software implementation projects. They have the classic waterfall stages (Initiate, Plan, Execute, Close) with gate decisions that close one stage and open the next.

This morning I was thinking about a recent project. I was hired to help two teams come together to complete a series of milestones.

While it’s definitely a project, and I can “see” the stages, there is no need for rigid gating. Classic project management is not necessary and if I was strict about it, the project would probably fail.

What is completely essential, however, is the leadership component.

All teams need that person who sits at the center of the project and coordinates, communicates, raises risks, and links people to solve problems. That go-to person who understands the elements and how they fit together…the one who keeps everyone moving forward to achieve the goal.

Here’s an analogy: if the project is a wheel, the Project Manager is the hub and the team members are the spokes.

Each spoke has a particular function, a singular touchpoint to the wheel – the project itself. But the hub touches all the spokes and connects the spokes to each other. The PM is the hub that keeps everything working together, and this function is what allows the wheel to turn.

Our goal is to bring the team successfully from point A to point B. Whether we are in a project that uses Waterfall, Scrum, Lean, Hybrid, or none of the above – it’s our commitment to keeping the wheel spinning that powers its success.

If you’re in a situation that doesn’t fit “classic” project management, know that it’s okay. Keep your focus on providing that connection for the team. Add the elements that help reach milestones. Be strict or set aside formality when it makes sense.

If you do that, your project will run more smoothly. Your leadership allows the team to focus on their own roles – they can get the actual work done on the project, knowing you’re keeping that wheel turning.

Does That Mean…Yes? Or No?

by

The other day my husband Steve asked if I was ready to go for a walk. I replied, “And the dog’s more than ready!”

He said “that’s not what I asked. Are you ready?”

This tends to happen to us. He’ll ask a question. I’ll read into it and give a reply that assumes the answer.

But if he doesn’t hear the actual answer, he can’t interpret what I’ve said. And that is frustrating for both of us.

If I’d simply added 1 word, if I’d answered “Yes! And the dog’s more than ready!” he would have understood and been able to receive the further information. Instead, I assumed he understood that my “and” covered the answer.

We all know what happens when we “ass-u-me”.

As I have a tendency to do this at home, I need to be extra careful to avoid “assuming and extrapolating” at work, too.

Communication with our stakeholders should be concise, as we all have full plates already. In an effort to be brief, to not waste our reader’s time, we naturally make assumptions in our emails, documentation, reports, etc. However, being too concise increases the chance of misinterpretation.

Here are three key methods to keep your communication clear:

  • Answer the question first. If you’re replying to an email or writing a summary report, there was an initial question or intent you’re responding to. First answer the question, and only then add relevant information
  • Use formatting techniques. Specifically, use bullet points to group together information. But here’s the key: use a header topic to explain the information. (For example, these bullet points are under a header topic that says the grouping is all about clear communication.)
  • Re-read your document for assumptions. Do you remember your elementary school teacher telling you to write like you’re explaining to “someone who has never heard of the topic”? That remains good advice! Especially in our distracted world, our team members don’t always pay attention to the details. This is a good way to orient them to the subject before you give them important information

Clear communication takes effort. It’s a balance between data and human nature. If we are going to respond to a question, we must answer it in a way that the person asking can understand and absorb. No assumptions.

Am I ready to walk the dog? Yes. Is he excited, too? Absolutely! Time to get his leash…

Practice Makes…Perfect Practice

by

Last week I wrote about starting to run Facebook Lives and how uncomfortable they feel. But, knowing that this is the only way to get better at them, my attitude must be “practice makes perfect” and press on.

Well, I had a comment about my post from Brent, who said that “practice actually makes perfect practice.”

He clarified that practice can only take you so far. You need the experience in a real-world situation.

I agree!

When you lead a meeting, for example, you can prepare for every contingency you can think of, but you just can’t predict everything your team will ask or what objections they may have.

Here’s another example: eventually need to stop running scenarios and actually go Live with your project. There is a point at which you stop reducing technical risk and simply increase the cost of delay. No project is perfect. Something unexpected will happen!

My take is this: when we practice, we eliminate the biggest risks. When we prepare for questions or complete all required testing, we take those issues right off the table. Then, when we’re in that real-world situation, we can focus our attention on the smaller group of unknowns.

So it is actually your practice that makes it possible to better deal with the unknown.

At the end of the day: prepare, execute, adapt.

Prepare as much as you can to eliminate risk.

Execute as you prepared.

Adapt to resolve new issues.