What problem does this project solve?

Have you ever delivered an entire project, on time, on budget, and still heard "that's not quite what I expected"?

After more than 15 years working in project management, I've learned that frustration almost always comes from the same gap: nobody asked, clearly, what problem this project solves. And that question needs to be asked well before the project starts.

The point of origin

When we take on a project, we rarely receive a problem. We receive a solution someone else already chose.

I've lost count of how many requests arrive like this: "replace this system, because it's bad" or "this process doesn't serve us anymore." The explanation of the actual obstacle, the expected situation, or who's waiting for it, rarely comes along with it.

(The situations described here reflect personal perceptions accumulated over a career, not those of any specific company.)

The risk is treating a perception, a remark, or an emotion as if it were factual reality. The result is usually months of work spent solving the wrong problem.

Harvard Business Review has already called attention to this risk: in the article "Are You Solving the Right Problem?", Dwayne Spradlin argues that organizations tend to rush toward a solution before diagnosing the problem in depth.

That's why thoroughly exploring the current situation and questioning the request isn't disobeying the sponsor. It's protecting their money. Any serious sponsor expects that from whoever is running the project.

Two paths to understanding a problem

In project management, a problem is an obstacle someone faces and needs action to overcome, or a gap between reality and what was expected. In practice, these two forms show up together more often than you'd think.

The first step to dealing with either one takes courage. The second is putting into practice the most effective tool a project leader has: talking to people.

If the problem is an obstacle

Go to whoever faces that obstacle day to day and explore three points:

Write down what the obstacle is. Watch the person facing or suffering it right now.

Write down the effort or actions that person already takes to overcome it today.

Name the discomfort they feel: pain, anger, boredom, impatience, anxiety.

If the problem is a gap between reality and expectation

Here the exploration calls for evidence, not opinion:

Go see and feel the reality up close, where it actually happens.

Write down the facts that prove this reality: every day, sometimes, how many times.

Gather concrete evidence: video, photo, record.

Write down the data that backs up this reality: list, table, number.

Write down the name of whoever expects this reality to be different.

Identify where it's documented that this person expects that.

Writing, listing, naming, putting it on paper. This isn't bureaucracy. It's what keeps you from burning a huge amount of resources solving the wrong thing.

Who already does this well

Elon Musk is known for questioning every specification inside his companies. He goes back to the actual person who requested the requirement and digs into the real reason behind it. I've written about this practice in this article.

Do this now

Take the most important project you're investing your energy in today. Write in one sentence: "what problem is this project solving?"

Then check whether that sentence just turned into a description of the deliverable. If it did, there's a good chance you're solving the wrong problem.

That's the first hard question to answer well before starting a project. The second, for those who already started the right way, I'll bring in the next article: what changed in the business after this project?

Best, Leandro | PMP | PMO and Project Manager