Introducing Value-Driven Project Management

In my ramblings on Values, it came to me that it is relatively easy to redefine "traditional" and "agile" project management in terms of Values.

Traditional project management has the values of "fixed budget", "fixed scope", "fixed delivery date". Sure, the project manager can vary these (iron triangle), but they are the only values that traditional project management recognizes. (I know, thats an oversimplification of traditional project management).

Contrast this with agile project management. It has values of "maintainability", "time-to-market", and "feature prioritization".

No wonder the two are so hard to reconcile! But that is not the point of this post.

I am proposing a new style of project management, "Value-Driven Project Management". This new style encompasses both Agile and traditional project management - they are two subsets that focus on specific sets of values.

At the core of Value-Driven Project Management is the notion that all of the practices of project management exist only to support the values. An example is in order...

Lets consider "risk". Traditional project management devotes large amounts of effort to risk management. This is because the values are inherently risky - "FIXED budget", "FIXED scope", "FIXED delivery date". Let us contrast that with Agile project management, which has far fewer risk management tools (spikes, tracer bullets). The simple Agile risk management techniques, support the value of "time-to-market".

There are many more values than the ones I have mentioned. Too many to mention, but consider "high initial quality", "low development cost", "certain set of core features", "performance measures". Both traditional and agile project management fall short of addressing these values. And when you ignore them, they suffer. We need to help our clients to identify and prioritize their values. Only then can we truly design appropriate project management strategies.

Once we know the values, we need to be able to pick and choose our practices in a way that supports those values. We must pick practices that will combine to provide the client with a satisfying project experience, much as a chef must pick ingredients that combine to provide a satisfying meal.

Let me bash Agile project management for a moment. I have little doubt that Agile project management is one of the most efficient strategies for delivering software (because it prioritizes features). However, it does not directly address "quality" as a Value. Because of that, it is difficult for teams to know how much of the quality practices (TDD, code reviews, automated acceptance tests, formal QA) they should be applying. All it takes is a conversation to identify the value of quality to the client (relative to other values), and then a team can motivate the quality-effort.

That brings me to the final point of this post - it is all relative. The iron triangle is an ugly and blunt tool, but it is correct in the sense that you have to choose certain values above others. That is still the nature of project management.