why projects fail

The Most Expensive Mistakes Happen Before Kickoff

If you want to understand why projects fail, stop looking at the final status report. By the time a project turns red on somebody’s dashboard, the real failure may be months old. I’ve spent more than 37 years around projects, programs, executives, consultants, government agencies, and corporations. Again and again, I’ve watched organizations discover problems during execution that were actually created before anyone built the first schedule. The expensive mistakes happen before kickoff.

That’s also why rescuing a troubled project can become so expensive. Once execution starts, you’ve hired people, signed contracts, committed budgets, announced dates, and created political expectations. Changing direction now costs money and reputations. Before kickoff, changing your mind is cheap. After kickoff, somebody has to admit the original decision was wrong.

The Status Report Is the Last Place Risk Shows Up

A status report tells you what people are willing—or finally forced—to acknowledge. Risk existed before that. Someone knew the deadline was political. Someone questioned the budget. Someone knew two executives wanted different outcomes. Someone noticed that the person being held accountable didn’t have the authority to make the necessary decisions.

None of that necessarily appeared in the status report. That’s because risk doesn’t begin when somebody changes a box from green to yellow. It begins when somebody says, “We’ll figure that out later.”

Three Decisions Before You Have a Plan

Before arguing about Agile versus Waterfall, buying software, or building a 400-line schedule, settle three things:

What are we actually trying to accomplish?

Not the deliverables. Not the activities. What business outcome makes this project worth doing?

Who owns the outcome?

One person needs to know that when this succeeds or fails, the finger ultimately points at them.

What can kill it?

Not a ceremonial risk register created because the PMO requires one. Identify the handful of assumptions, dependencies, decisions, and constraints capable of destroying the initiative.

If leadership cannot answer those three questions, you don’t have a project yet. You have a meeting.

Accountability Is Not Responsibility

Organizations confuse these constantly. Responsibility can be distributed. Accountability cannot. Ten people can be responsible for pieces of an initiative. When something crosses organizational boundaries, however, somebody must have enough authority to make the decision. Otherwise, everyone owns a piece and nobody owns the result.

Think about the clarity of a straightforward commercial transaction. Even a prostitute and her customer generally manage to establish the fundamentals: what we’re doing, who’s doing what, what it costs, and when the transaction is finished. Then corporations put twelve executives in a conference room and somehow leave without answering any of those questions.

Maybe we shouldn’t be surprised why projects fail.

Risk Culture Doesn’t Live on a Poster

Every company says it values transparency. Try delivering bad news on a Tuesday afternoon. That’s the test. A real risk culture exists when the person closest to the problem can say, “This assumption is wrong and we’re in trouble,” without spending the next week defending themselves for saying it.

Executives don’t need teams that make dashboards look green. They need teams willing to tell them the truth while there is still time to do something about it. The fastest way to hide risk is to punish the first person who identifies it. Do that a few times and you’ll have beautiful status reports right up until the project crashes.

Give Me Ninety Minutes

When I look at an initiative, I don’t need three weeks of workshops to determine whether something smells wrong. Give me ninety minutes with the right people. Start with the outcome. Ask each decision-maker independently what success looks like. If five executives give you five different answers, stop. The schedule isn’t your biggest problem.

Then ask who owns the outcome. Don’t accept a committee, steering group, department, or governance board as an answer. I want a name. Next question: What can that person actually authorize without asking someone else for permission?

Now identify the three things most likely to prevent success. Ask what assumptions must remain true for the plan to work. Ask which dependencies are outside the team’s control and who owns those relationships. Then compare those answers with the schedule, budget, and risk register.

Finally, ask what nobody in the room wants to tell the executive sponsor. That last question can be worth more than the other eighty-nine minutes combined. Projects rarely wake up one morning and decide to fail.

We build failure into them through unclear outcomes, divided accountability, hidden assumptions, artificial deadlines, and risks nobody wants to discuss. Then we hold a kickoff meeting. Six months later, somebody changes the status to red and asks what happened. If you really want to understand why projects fail, don’t start at the end. Look at what everyone agreed to—or failed to agree to—before kickoff.

Let’s Git-R-Done this week!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.