Friday, January 4, 2008

The Project Magic Triangle 2.0

Standard project theory has this view of the project that it is a triangle. The triangle corners are Time, Cost and Quality and the PM's job is to find the perfect balance between these forces and in that way create results. I believe this model is a model of the past and needs to be ratified - but just slightly. The reason is that these days a project's purpose is first and foremost to create business value and customer value, and needs to be directed by quantified effects related to these.

The Business Model and The Project
I have never found one definition that captures the whole concept of a Business Model, and as is stated under the term on wikipedia[1], there really is no common definition. What I have found is that a true business model must cover three areas:
  1. It must cover how value is created for the owner / prime stakeholder

  2. It must cover how value is created for the customer

  3. It must cover the resources (time, competence, cost, material) needed to create value
For projects - we have Cost and Time which is relatively easy to quantify and Quality is often the magical factor (some define it as defect density, others though customer satisfaction surveys, still others though). In the figure below the two triangles are shown. See the conflict?




The Magic Triangle 2.o:

So let's combine these triangles to make it more logical.

Quality becomes the the Customer Value. Measures must be centered on the customer and will typically be measured though values such as customer satisfaction indexes (CSI's), usability measures and service quality measures. The project charter should have clear and measurable goals for these. These are the first part of the project's effect goals.

Time is really just a function of Shareholder Value. If you come to market mith a solution faster, you will (in most cases) have an advantage. Cashflow will come faster. The shareholder value is most often formulated as a business case (BC) with NPV/IRR values. Measures are typically bound to the BC such as sales volume, market share, cost effectiveness, revenue per customer. These are the second part of the project's effect goals.

Cost is the only part that stays the same compared with the old triangle. You might want to extend it to Resources because that incorporates a great deal more such as competence and location but in reality everything can be bought.

So the main problem with the old model is pedagogical. When you show the CTQ triangle many projects I have seen, they suddenly live in a box. Nothing than the balance between these three factors (as they have traditionally been defined) matter and you end up with a project that succeeds on these. But the effects of the project are an utter failure outside the box. For sales and customer satisfaction the project did not deliver.

To many this may seem elementary. "This is how we do it anyhow!". I agree, many projects have this focus or partly this focus. Many organizations demand BCs for their investments - but many then forget than customer value is just as important. In the "Agile Software Development" movement there has been a considerable and good focus on the cutomer - though the business value has been a little less discussed. You need to balance these forces.

So think RSC (Resources, Shareholder Values, Customer Values) instead.


[1] http://en.wikipedia.org/wiki/Business_model

No comments: