What to Look and Listen For
In the spirit of making businesses and workdays better, we often look for the things that make people and projects, well, bad. Usually it’s at least one (sometimes more if things get really messy) of these things: communication breakdown, role and responsibility mismatch, or ineffective risk management. I’ve been asked recently for some tactical examples of these–“what would that really look like?” on a particular project or in a particular organization. Let’s take a closer look to give you some specific things to look and listen for so you can get ahead of situations that have the potential to make your and your team’s workdays harder than they need to be.
1. Communication breakdown
The biggest cause of project failure is communication breaking down. Top-down messages don’t get through, bottom-up messages of concern don’t get through, left-to-right, side-to-side messages don’t get through, etc.
Let’s say that a leadership team has made a decision to explore a new product line, a new customer target, or a new geographical region. Those leaders have been in countless meetings having discussions about this, and somewhere meeting minutes get published or a decision document gets created to say “this” is the direction we’re headed. Now when that leadership team goes to engage a project manager, Evan, to make that project happen, it’s really easy for them to forget that, although Evan has been around in the organization for years, he is new to this conversation. Evan wasn’t included in all the conversations, meetings, and discussions, so the background, the vision, and the “why” behind the decision is not something Evan has been privy to.
I do not often encounter situations where someone deliberately neglects to share pertinent information with someone they’ve asked to lead a project, but all too often I see examples of simply forgetting that we need to educate and bring others along.
The lengthy discussions about the trade-off between cost and time on this particular initiative, or the passionate way the story was told about serving a particular customer group, or the simple clarification about how this project sets us on track to achieve a five year or ten-year target…it’s possible that conversations around whatever the spark for the project or initiative may have been took place among the executives or the senior leaders, and the project manager simply wasn’t in the room.
How to prevent it? It becomes really critical for sponsors to invest time and energy in communicating the backstory when we’re engaging project leaders-the “behind the scenes” of how we got here. If we don’t, that project manager will be ill-equipped to deal with questions along the way. They may be missing pertinent information that would help them bring other stakeholders along in the journey, and they may miss out on what could serve as a rallying cry for the rest of the team.
Here’s another example – let’s say that you and a colleague are both working on the same project. At 4:35 on Friday afternoon, you get an update from someone outside your organization that the piece they were going to do is delayed. Maybe you exchange a quick message with them, and then head out for the weekend - all good intentions of closing the communication loop on Monday morning. When Monday morning comes along, there’s a combination of a two-hour late start due to snow at your kid’s school, and a hot topic from your leader that takes all of your focus. By Monday afternoon, you’ve settled into the groove of the week, having completely forgotten to share with your team member that there’s a delay on the vendor piece.
Fast forward two weeks. Your colleague reaches out in frustration that they don’t have the last piece that they needed, and it would’ve been nice to have had some heads up. You sheepishly acknowledge that you did have a heads-up, it just didn’t get communicated.
How to prevent it? A better approach would have been to have a shared issue log or a shared action item log where it would have been simple to capture the update while you were on the phone with the vendor.
In both of these cases, no harm was intended. But delays, setbacks, sometimes rework or redundant work, or missed work all exist because of ineffective communication.
The best solutions involve deliberate time, tools, and systems for ensuring that we’re communicating effectively and completely, whether it’s the backstory on why we’re doing this project, or the in-the-thick-of-it details about what we’re doing, how tasks are getting done, when, and by whom.
2. Role/Responsibility mismatch
Next up in our list of things that create pain on projects is role and responsibility mismatch.
Here’s one I’ve seen pretty recently. A group of stakeholders agree to a project, and conceptually they agree to the list of tasks that should be accomplished. But since the list of to-do’s does not include anyone’s name, and no individual is assigned responsibility for any given task, two weeks go by, and absolutely nothing gets done. That's never happened on your team, has it?
I remember learning that “an action item without an owner and a due date is a pipe dream, not an action item.” You can spend hours brainstorming every single task and detail that will go into a project–the most glorious list you’ve ever created–but if nothing on that list includes a named individual to complete each task and a due date, none of it will get done.
Something else I’ve often encountered is that we make our list, we assign a task to a person… but that individual does not have the tools or the availability to complete the task as described, or they do not have the skills required.
How to prevent it? If you are in a situation where you or a team of people are assigning work to another individual, the best practice is to engage that very individual in a conversation to figure out what they need, how much time they need, and if what your asking from the person you’re asking is within the realm of feasibility.
This two-way conversation doesn’t have to be long and drawn-out or arduous, it simply requires that both of us are present in the moment with a mutual desire to ensure shared understanding. Discuss their availability to complete the tasks, their understanding of what “complete” looks like, their skills and capabilities to complete those same tasks, and ensure that everyone is on the same page about the timeline and quality expectations. That’s how you get stuff done without it slipping through the cracks!
3. Ineffective Risk Management
The third leading cause of project pain is ineffective risk management
Picture this: there’s a project in our organization that is not very big, not very exciting, and doesn’t get a lot of attention. Let’s say, even further, that because no one is particularly interested in this project, nobody’s keeping a super close eye on it. Let’s say a group of well-intentioned team members start off on the right foot with the project. And let’s say that they even go so far as to create a list of the things that could potentially prevent the project from being successful. Pretty high on that list is everyone’s awareness that no one is particularly excited about this project, and it doesn’t always get the attention it deserves.
Fast forward a few months, when we discover that decisions that we needed to make haven’t been made yet because this uninteresting project had been deprioritized, and now there’s no way to get it done by the desired timeline.
How to prevent it? What we should have done months ago was state our risks clearly, assign an owner, and talk about them regularly. “If key decisions are not made by March 1st, we won’t have time to effectively market the event to draw attendees for the original May 1st target event.” We assign Jax as owner of this risk, and Jax puts meetings on the calendar to give us a chance to make the desired decisions to keep thing moving. (Are you sensing a theme of assigning ownership?)
Or how about this one: we’re doing a project that includes a task we’ve never done before. The person responsible for the technical work, Zane, raises a hand and says, “we’ve never done this before; there could be unexpected complications.” But someone else on the team says something like “Oh, Zane, you’re such a worrywart! We’ll be fine!” Fast forward to the second week of the technical work, where Zane’s fears turn out to be very well founded. Since we can’t miss the deadline, and there’s no more time to “figure this out,” we wind up paying a premium for an expert who can do the work at the last minute.
How to prevent it? When Zane’s hand went up, what we should have done was say, “Thank you, Zane, for raising that concern! What kind of testing or analysis or trial runs can we perform to drive out some of the uncertainty around how complex this thing is?”
If we had just been intentional about our risk management, and taken action to make things less uncertain, this project would not have gone that far over budget.
So there you have it, three leading causes of project failure with specific examples, including how we could have done even better. How about you? How do you prevent these common types of pain points? Join the conversation in social media or in the comments below!
