2 Guaranteed Causes of Project Problems

How you initiate a project—or how it is initiated by others—matters.

Many things that happen or don’t happen at the beginning of a project can set that project up for problems later.

Don’t let this reality intimidate you or prevent you from getting a project started. Neither a new nor a seasoned project manager can prevent all project problems; some problems come with the territory. But a seasoned PM can typically prevent more problems, especially in types of situations they’re familiar with.

At my organization, our project management team has observed two types of project initiation oversights that create subsequent issues so consistently it’s nearly guaranteed. We explain them to our teams whenever the opportunity arises so everybody is on the lookout and can help prevent them. I’ll explain what they are and why, so that you too can be on the lookout for these situations and have two more types of problems you’ll be able to prevent.

Treating Your Project as a “Small Project”

The issue with “small projects” is not a criticism of anybody’s project categorization system, and if you have clear, well-understood definitions of small, medium, and large projects, good for you and your company.

My team encounters issues when “it’s just a small project” becomes an excuse to not initiate a project using standard processes. For a small project, the often-unspoken logic goes, it’s not worth spending the time contacting all the regular people, asking all the regular questions, getting it set up for tracking in all the regular systems, etc. That stuff will take longer than just contacting all the critical task-doers and asking them to “fit it in real quick.”

This approach may get the desired results occasionally, but in my team’s experience, it usually backfires. At my organization, some of these “small projects” have taken the MOST time and resources to get done due to all the rounds of re-work and backtracking. A PM coworker of mine did some pretty impressive data-gathering to demonstrate that this was the case across all the projects we’d done during a particular year.

We used to have quite an epidemic of “small project” thinking at my organization when we were at an earlier stage of appreciation for the role of project management. Patient teaching by project managers, with kindly-presented examples of times that going through the established processes has worked well and times that skipping them has gone poorly, has reduced this issue quite a bit.

It helps when you can get people to see that running down a list of project considerations and deciding most of them don’t apply can actually go pretty quick—you just need to take that little bit of time to go through that list and/or have a conversation with a project manager. It’s a tiny time investment that can prevent time- and resource-intensive issues later.

As I said, teaching the people around you about this concept and its pitfalls as teachable moments arise can help a ton, if you stick with it over time. If “small project” thinking is an issue at your organization, you may also have the related issue of people who try to avoid doing sufficient planning at the beginning of a project, and if so, my blog “When Others Resist Planning” may help.

Failing to Define Roles, Especially Approvers

Project managers are more commonly aware of the issue of poorly-defined roles. Any role that isn’t well-defined can lead to the practical issues of work that doesn’t get done, work that’s done by the wrong person or at the wrong time, work done by someone who didn’t have the right information to do it correctly, etc. It can also quickly lead to emotional conflicts because someone’s understanding of their role can be connected to a deep sense of personal satisfaction or identity.

But here I’d like to focus on the issue of poorly defining who has ownership or decision-making authority over which parts of your project (who’s the “approver” for what), since in my experience, lack of clarity around this type of role creates the biggest problems for projects. I’ve seen failure to define approvers lead to the longest delays, the most awkward conflict, and the most rework.

Delays come when nobody knows who’s supposed to make a decision, so nobody does. This usually stops a project in its tracks. I can’t tell you how many times I’ve seen an email to multiple people where one person asks, “how’s this?” and nobody responds and everyone just waits. As an experienced PM, I now realize in those moments, “shoot, the approver wasn’t clear, I need to take a step back and get a decision made about who is supposed to make this decision.”

But it’s awkward if you haven’t clarified the approver in advance, because you can end up giving certain people the impression they have more authority than they do. How does it feel to say what you think should be done, and then be told, “oh wait, sorry, you don’t get to make that decision”? Better to have known your role in the first place and either kept your mouth shut or known you would just be offering your opinion that someone else could take or leave.

Rework can be extensive when the team is humming along as though one person gets to make certain project decisions, and after large portions or perhaps most of the project is finished, somebody else (often somebody higher in the company) says, “this quality isn’t acceptable” or “this is off-brand” or “this isn’t a strategic fit for our company” and the team has to start the project over in a totally different way. I’ve seen more than one project play out this way during my career. It can be an art to know exactly which decisions need to be elevated to your project sponsor or someone higher in the company…but at the same time, it doesn’t have to be, because you can use language and parameters to define these decision-making roles in advance for the project at hand.

People don’t always have the patience for role-defining conversations, but usually I find they’ll at least give you the time of day to get everyone on the same page about who makes what decision. If the issues created by failing to establish approvers sound familiar to you, I have several options for how you might go about clarifying these roles in my blog “5 Practical Tools for Getting Decisions Made,” and you might also find a RACI chart to be a useful authority-clarification tool.

While the right-fit approaches to remedy my two guaranteed causes of project problems may vary by setting, recognizing them and educating others around you about them goes a long way. Be clear about the value of putting in a little extra work in these areas during project initiation, and both you and your teams will see how much smoother things can be as your projects unfold.