I’ve been asked recently to share some tactical examples of common project pains - “what would that really look like on a particular project or in a particular organization” - so this post is a chance to think through three of the biggest leading causes of project setbacks, and explore how they might actually show up at a particular organization.
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 in all the conversations, meetings, and discussions. The background, the vision, and the “why” behind the decision is something Evan is not caught up on.
Rarely have I encountered any examples of anyone deliberately neglecting 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 10 year target… It’s possible that those conversations took place among the executives or the senior leaders, and the project manager simply wasn’t in the room.
How to prevent it? As sponsors, it becomes critical when we’re engaging project leaders to invest time and energy in communicating the backstory 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.
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.
It was not an intentional omission, no harm was meant at all, but when your colleague reaches out in frustration two weeks later 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 meant. But sometimes delays, setbacks, rework, redundant work or missed work all exist because of ineffective communication.
The best solutions involve deliberate time and tools for ensuring the backstory on why we’re doing this project, as well as managing up-to-the-minute details about what we’re doing, how tasks are getting done, when, and by whom.
Role responsibility mismatch has the dubious honor of being the second leading cause of project pain.
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.
How to prevent it? Make sure action items include owners and due dates! I remember learning that “an action item without an owner and a due date is a pipe dream, not an action item.” Even your best-laid plans that list out all the things that need to be done – if they don’t include a named individual to complete each task - simply won’t get done.
An individual is named to a role and to certain tasks within the project, but that individual does not have the tools or the availability to complete the task as described, and they do not have the skills required. So when the time comes for the task to be done, the person assigned to do it is unable to do so. Further delays ensue when that person is uncomfortable saying they can’t do it.
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 in a conversation with that other individual.
It’s ironic that we call it a “two way“ conversation – all conversations between two people should be two way! Bring the list of items that the individual is responsible for, and engage in a conversation with them about 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.
This 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.
Ineffective risk management is the third leading cause of project pain.
Let’s say, for sake of argument, that there’s a project in the 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 instead was state our risks clearly, assign an owner, and talk about them regularly. “If key decisions are not made by March first, we won’t have time to effectively market the event to draw attendees for the original May 1st target event.” We assign Jace as owner of this risk, and Jace puts meetings on the calendar to give us a chance to make the desired decisions.
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 gotten 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 manage project failure? Let us know in the comments or on social!