💾 Archived View for nader.pm › project-success captured on 2024-08-25 at 00:11:23. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

What's project success?!

Nader K. Rad, 2024-06-25

We do talk a lot about project success, but we don't spend enough time defining it. I'll criticize the two common definitions that cover almost all alternatives and then offer my own suggestion.

Definition 1: time, cost, and quality

Some people consider a project successful when it's delivered on time, within budget, and with the desired level of quality. This definition doesn't work because it's based on how optimistic or pessimistic the initial estimates of time and cost are. The more pessimistic they are, the more "successful" the project would appear at the end. This, of course, doesn't make sense.

Definition 2: impact, value, benefits, etc.

The new trend is to talk about impact, value, benefit, satisfaction, and the like. What the proponents of this option miss is the difference between these two:

The success of the output of the project
The success of the project

These two are COMPLETELY different because what we do in the project is only one of the things that contribute to the success of its output. It's also about portfolio management, operations, and other products and services in the organization.

It means that we can have

a successful project whose output is unsuccessful, or
an unsuccessful project whose output becomes successful.

I've seen both cases, especially the second one.

Let's say you have an excellent idea for a privacy-friendly social network:

You run a project to build the platform and start operating it. Its impact and benefits are moderate.
Now, imagine that the exact same thing was done by Elon Musk or another famous person. Suddenly, its impact and benefits would become hundreds or thousands of times greater.
Imagine the exact same thing being done by Amazon: Its impact and benefits may become much greater because of the other products and services it has that can reinforce each other.
Finally, imagine the exact same thing being done by Google or Facebook: its benefits may be negative because of its incompatibility with their other products and services.

Impact, value, and benefits are all about how the project's output works in operation. This goes beyond the project itself and involves many other layers of management.

It doesn't make sense to label a project as successful or unsuccessful based on what happens outside the project.

My definition

When we talk about project success, we practically want to have a label for what we want to repeat in future projects. So, when defining success becomes too complicated, we can simply talk about what we want to repeat in future projects and why.

For me, a successful project should meet the following two conditions:

Uses the available resources efficiently
Cares about the well-being and professional growth of its team

The first condition covers time, cost, and quality on the one hand and benefits/value on the other. How do we measure it? We should compare it with hypothetical cases. Yes, it's not easy, but difficult is better than superficial and wrong (I'm referring to options 1 and 2). Besides, these things never really work with measurements, but as sources of inspiration, and for that, this is more than enough.

The second condition is something that is missing in other definitions, but I strongly believe should be considered. Some may say that caring for the well-being of team members is justifiable because it helps improve performance in the long run, but I believe it should be done as a matter of principle rather than for utilitarian reasons. It's simply an ethical responsibility of the project manager to care about the well-being of the team members.

Update 1

Some people won't consider a project successful unless its output is successful as well. I don't accept it for the following reasons:

Many people other than the project team members are involved in the success of the product, in a timeframe longer than that of the project. We can't evaluate the performance of all those people and call it "project success", which practically implies it's an evaluation of the performance of the project team. Remember that the project lifecycle is a subset of the product lifecycle.
In some projects, such as IT development, the project team knows a lot about the way the product would work in production and can get involved in managing its outcomes. However, that's not the case in all projects; e.g.,
The team that builds hospitals knows a lot about its construction, but doesn't know much about the whole healthcare ecosystem and can't get involved in managing its outcomes.
The team that works on an oil and gas project knows about what they do, but they are not experts in world politics and can't get involved in managing its outcomes.

So, I wouldn't consider outcomes in the definition of project success because 1) it goes beyond what the team does, and 2) the team can't even do anything about it in some (or many?!) projects.

Instead of making it part of the definition of project success, we have standard mechanisms to encourage the team to get involved and contribute when it's possible.