We are notorious for focusing on our sacred “Triple Constraint:” Time, Cost, and Scope. When we begin work on the project plan, and throughout the course of a project, our goal is to accurately anticipate and predict every aspect of the project execution so that the plan we create maintains a high level of confidence; we aim for our project timeline and our budgets to be exact and anticipatory of every conceivable permutation so that upon completion we can look back and say “that happened exactly like we planned” (even as the project endured multiple “Acts of God” that no reasonable person could have imagined, let alone predicted). Project success is even commonly defined as a project coming in within budget, on time, and within scope, but even this isn’t ideal; technically speaking, a project which comes in under budget or early isn’t a success at all, but a failure of the project plan!

“Our goal is to accurately anticipate and predict every aspect of the project execution so that the plan we create maintains a high level of confidence.”

As project managers, our very purpose is perhaps impossible. We are being asked to give an assurance that a project, complete with an infinitude of unknown variables, will succeed. Our very goal is to make the unpredictable confidently predictable. We do this by attempting to turn everything into a data point and create a project plan which acts as a sort of formula: we can then say, with a high degree of confidence, that if the project plan is executed as planned, the desired project objective will be met. Indeed, our very purpose is to turn the subjective and the unknown into an objective formula for success.

“We do this by attempting to turn everything into a data point and create a project plan which acts as a sort of formula: we can then say, with a high degree of confidence, that if the project plan is executed as planned, the desired project objective will be met.”

Is there even a Need to Know Value?

Is there then even a reason that a project manager should need to know what the desired value is? By this model, no. If I need to have a file-storage server constructed, the project team doesn’t need to know what kinds of data will be recorded on the servers, or that the completion of the server will save the company 20% in operating costs. Indeed, knowing this value isn’t value-added for the project management team.

This model looks at the project team as simply an objective process or algorithm which is run to produce a desired outcome. Just as my windows operating system doesn’t have to know what data I will be storing before it creates a folder on my desktop for me or opens up Microsoft Word for me, a project team does not need to know the why in order to execute the how.

Conversely, without the value of knowledge, there also isn’t any conscientious value-added to the project either. The project sponsor can certainly decide that a server room needs to be constructed and maintained at a specific temperature, but without the project manager knowing the need for the project he is only responsible for the effects of his actions relative to the project plan and the given requirements, not the value of the project.

Satisfaction as a Standard

And that is problematic.

The purpose of every project is value. There has never been a single project that was ever completed, or even started, for the sake of anything other than an intended value. Now certainly it has been the case that either the intended value wasn’t obtained, or that the projected created an additional “added value” that wasn’t considered at the on start of the project. That being said, value traditionally has not been an objective of a project, and I’ll even argue that it has been exactly the opposite. A project manager’s first responsibility is to the project, even to a fault.

Value is not Predictable

Value is something which can’t be measured. It’s inherently subjective. And yet there has never been a single project which wasn’t started for the sake of obtaining value. Indeed, if someone found no value in performing a project, a project would simply be a waste of time and resources which could be spent on activities which would give value. The argument is reminiscent of Aristotle claiming that everyone sought the “Good,” for even those who did bad things performed them because they believed, errantly perhaps, that the bad would produce for them a good.

The purpose of every project is to create a greater value or good to the organization. Every project intends to solve a problem or create something which didn’t exist prior to its execution. The very purpose of a project is to produce a change which will result in an increase of value of the organization. But generally speaking projects themselves don’t concern themselves with these values.

And this is the reason why so many successful projects fail.

The failure to identify value results in successful projects failing. Technically speaking, these projects might have executed perfectly. The client may have asked for a specific application to be implemented or a process built, and the project manager may have done just that. But if that application or that process did not fulfill the purpose of the client, was the project really successful?

“The failure to identify value results in successful projects failing.”

A project manager needs to be able to break deliverables into manageable units which can be objectively quantified and qualified. If a project manager was building a widget for a client, she wouldn’t accept a requirement which stated that the color had to match that which “the client can see in his mind, but unable to explain.” But on the other hand, if a client wants the widget to perform a specific action, we are going to list that action as a requirement, and if at any point we realize that the action cannot be fulfilled, the project would immediately come to a halt. A project which we know cannot fulfill a requirement will under no circumstances be successful.

With all projects, unless we consider the value of the project to the organization a deliverable, we are never going to be able to track that value through project completion, guarantee the realization of value, or gauge project success in terms of the value… and that will always result in failure. When planning out and executing projects, value based deliverables need to be identified in project artifacts alongside performance based deliverables so that as a PM we can insure that the final product not only matches the project scope, but fulfills the value requirements of the customer… the very purpose of the project.