How to See and Stop Project Failure Before the Effort Starts

This is the June 2024 Pragmatic Manager Newsletter, from Johanna Rothman. The Unsubscribe link is at the bottom of this email.

A newsletter reader asked me this question: Are there common reasons that projects fail?

There are. These reasons aren't just for product development projects, but for any effort that has some risk and requires a collaborative team to complete. Here are the most common failure modes I see:

• Starting a project with scarcity. That scarcity might be in people, insufficient time or time to experiment, or the necessary tools.
• Expecting people to do this new work when they have a chance. Yes, the multitasking problem.
• Separating people into silos, not working as a collaborative cross-functional team.

Often, one of these will create the other two problems. That's what happened to Ginger.

Explain the Scarcity

Ginger, a project manager, is supposed to start Project D. However, the testers are still full-time on Project B, the architect has an emergency fix on Project A, and two of the developers are still on Project C. Worse, Project D must share the lab and the tool licenses with Projects A, B, and C. (These are supposedly agile projects, but the feedback loops are quite long.)

Ginger's management wants to release Project D in the next quarter. But Projects A, B, and C will take at least six weeks to complete.

Ginger explained the team could:

• Work as a team on one or two things at a time, swarming their way through the product. They would be slower, but they would finish work.
• Get more lab machines.
• Wait to start Project D until Projects A, B, and C finished.

That's when she showed them the various Costs of Delay that the managers requested. Everything would take longer and everything would cost more if she started Project D.

Clarify Why Scarcity Occurs

Too often, scarcity occurs because management focuses on the individual and their work, not an overarching goal for a team. Too many agile teams do this, too, just with the questions they ask.

When teams ask about yesterday's or today's work, they, too focus on the individual. Instead, your team (regardless of your approach) can ask this one question: What's the most valuable thing we can do today to make progress?

If your team is still asking the original standup questions about any one person's work, you can change that.

I've focused so far on the team reasons. But there's one more big reason: not making binary decisions for the project portfolio.

Make Binary Decisions for the Project Portfolio

So many organizations have more of an appetite for work than they have teams to do the work. I'm the same way in my business, so I know exactly how this feels. But teams can only do one project at a time.

Ginger knows the risks of splitting this one team into several projects. Chances are excellent that as soon as the architect finishes Project A, some developers and testers will also have Project A work. What are those people supposed to do first? Finish their work on Projects B and C, or finish—really finish—Project A?

Who decides?

The project portfolio decisions define the strategy for the company. Only the senior leaders know when it's time to change the strategy.

Starting a project with scarcity is a symptom of other problems. Fix them first.

Fix The Problems Scarcity Exposes

If your managers want you to start a project with scarcity, ask this question: Is this the most valuable work we could do right now?

If the answer is Yes, use all your influence, negotiation, and blackmailing skills to say, “Then give me what I need so we can do it right. Let's stop the other work and fully commit to this work.” (Maybe not blackmail. But definitely use your Voice of Reason.)

However, if the answer is No, then say, “The pieces of the team and I can support another project that's more important. When that's done, then, that's when we can start this project.”

That's a real challenge and absolutely worth it.