Do we need to get rid of the “Magic –or Iron– Triangle”?

Fast, good and cheap – choose any two. – internet proverb

Or, according to another source > SPEED, QUALITY, PRICE – Pick any Two > – James M. Wallace / Paul Dickson 1980

The Magic of the Triangle

As a quick search on Wikipedia will point out a somewhat more appropriate name seems to be “project management triangle”, but still, with all the ambiguity of the term “magic triangle”, many people equate it with the aforementioned unholy trinity of speed, quality and price and a quick Google search showed that at least in September 2024 they were not alone.

Unfortunately the project management triangle is a model that holds true only under very specific constraints.

Looking at some sources like for example the 2012 IEEE paper that analyses original sources back to 1987 we find some interesting points. First of all, it is important to note that according to theses sources the project management triangle consists of the edges Cost, Scope, and Time while Quality is the area of the triangle.

If we take this literary than we could actually improve the quality by increasing cost, scope and time. (e.g. let’s double time, scope and cost and we quadruple the quality). Obviously it’s not that simple.

Furthermore, unlike in geometry, in project management cost, scope, time, and quality are measured in different units and can not easily be converted into each other.

Especially the simplicity of the relationship between cost and quality has been questioned quite publicly by people like W. Edwards Deming with his concept of “Total Quality Management” or even more poignant by Philip B. Crosby with the catchy book title “Quality Is Free (1980)”

Which quality is negotiable?

We see the tradeoff between price and quality all the time in everyday life. * Is it better to buy the cheap drill bit that will wear off after two holes or to buy the expensive one that will last for hundreds of holes? * Is it better to buy the cheap wine or the expensive one? * Is it better to buy a cheap chair that can be afforded today but will only last a year or an expensive one that will last for many years, but can not be afforded sooner than year?

If we look at these everyday questions, most of us humans start to think in different categories of qualities. For example durability, cost effectiveness, utility and so on.

Once you start to differentiate which category of quality you’re talking about many conversations about “cost vs. quality” become much clearer. (Thinking in project management triangle terms this would make the specific “quality” one of the parts of the scope axis)

Product quality vs. production quality

The last point I would like to stress in this article is the differentiation between the quality of the product (you can make a cheap tool out of cheaper materials) and the quality of the production (you can work with unfitting tools yourself or deprive your employees of good education.)

The important thing here is that while * product quality –or lack thereof– directly affects the customers experience, * production quality directly affects your own bottom line – the worse your production quality is the more it hurts your bottom line.

Like in the drill bit example - when you ship cheap drill bits, the customer will need to replace them earlier. But if you use cheap drill bits on your own manufacturing line you will have to replace them more often, resulting in additional work for you and downtime with accompanied lost revenue.

And if you think that is only true for manufacturing, think of well written, easily understood software vs. the nightmare we see all to often where the complex, unstructured and undocumented code base leads to a simple change taking weeks to implement. Wich in turn looses a couple of potential buyers or creates effort for manual workarounds.

Therefore, when it comes to production quality the “cheap vs. good” adage actually can be quite harmful. In most cases lowering production quality will make the total cost go up.

’till next time Michael Mahlberg

Does PDCA equal “Plan the work, work the plan (and control that)?" – I don't think so!

I don't know how this came about, but a little while ago a friend of mine (whom I highly regard, both personally as well as as a project manager) came up with the notion that PDCA implies planning, having the plan executed (do), checking the results and (re)acting if they are not up to standard.

Maybe I am mistaken and that is, what Deming really means, but the way I understand his text and for example this talk by deming himself it is quite the opposite.

The way I understand it, it is an almost direct implementation of the scientific method:

• Plan: Formulate a hypothesis and design an experiment for its verification (on a controllable scale, including the definition of an expected outcome)
• Do: Execute the experiment (in a more or less controlled environment)
• Check: Verify the results from the experiment with the expected outcome
• Act: Either implement the changes from the hypothesis or don't! – Depending on the outcome of the experiment.

Am I wrong in my interpretation?

Cheers Michael

Scrum-But or Inspect and Adapt?

For a couple of years now I have heard people condemning projects as “Scrum-But”, mostly without even looking at the projects. And sometimes even without any reference to what they consider to be a scrum-but.

“but” what?

As you probably can imagine after my last two posts, I am especially suspicious if people do that without looking into the scrum guide. I keep experiencing people proclaiming something is a scrum-but because of all kinds of misconceptions. Sometimes “they don't have 2 week iterations” (the scrum guide calls for “a time-box of one month or less”) or because “they don't use Unit-Tests” (the scrum-guide states that “Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.”)

While it might be preferable to have shorter timeboxes (as the agile manifesto clearly states: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” [emphasis added] ) and that it is much easier to have a thoroughly tested product if one does have automated tests including unit tests, this is more about common sense (or agile experience) – but definitely not part of scrum.

Apart from the fact that more often than not, the same people carry the battle cry of the agile credo inspect and adapt as a default answer to most everything, there is a certain irony in the fact that nowadays we seem to have a kind of method police around scrum while the first value pair of the preamble to the agile manifesto reads “Individuals and interactions over processes and tools.”

If you do it, do it right

Oh, and don’t get me wrong. If you want to call it scrum: go by the book. But by the right one!
And remember that “Scrum is a framework for developing and sustaining complex products.“). And while on a programming level the “Instantiation of such a [software] framework consists of composing and subclassing the existing classes.”) the fact of the matter is that the same is true for a process framework – you have to define the specifics for your environment to be able to use it!

So – how do you shape your process?

till next time
  Michael Mahlberg

Why “the iron triangle” (of project management) isn’t

Over and over, people quote the iron triangle of project management - relating verbatim to the elements time, scope and cost from the wikipedia article or by the slightly less formal adage “Cheap, Fast, Good – pick any two”.

Surprise: It is not a triangle

Anyone who looks closely at the concept – or just reads the first paragraph on wikipedia – quickly realizes that the “triangle” has at least a fourth side: quality!
(But the term “devil’s quadrangle” has not yet found it‘s way into wikipedia)

And as handy as the tool “iron triangle” may seem in arguments, it really should be used with caution. Especially arguing about the quality constraint is very common in my experience. By relating to the “pick any two” adage people try to argue that “with the new time constraints we have to compromise on quality.“ And apart from the fact that “quick and dirty is very un-agile” this approach completely ignores the fact that compromising on quality usually does not get the job done more quickly but generates severe issues for the ensuing product.
The agile answer to this conundrum is to negotiate on scope instead of quality. That is what most sane people would do with tangible objects as well. I might go with a motorcycle (smaller scope) when developing a car isn’t feasible under existing time and budget constraints. But I definitely would not go with a car where “somewhere between 20 and 40 percent of the nuts and bolts are not tightened correctly” (less quality).

To me it seems much more rewarding to manage scope than to try to compromise on quality.

till next time
  Michael Mahlberg