The Cost-Speed-Quality triangle

Mundane Pointless Stuff I Must Share (MPSIMS)
#1

In project management, there’s this thing (which is generally true) that you have three factors: cost, speed(of implementation) and quality - and you should pick the two that are most important to you.

In reality though, you don’t pick two - you pick a blend that emphasises two, without completely neglecting the third. Mundane and pointless it is, but this bit - the outcome of the extreme cases - had escaped me until just recently.

If you pick two (and insist on them being absolute), the following happens:

[ul]
[li]If you insist on absolutes for speed and quality - that is, shortest possible time, highest possible quality - the cost increases exponentially. You will choke when you see the budget. You can’t afford it.[/li][li]If you insist on absolutes for quality and cost - that is, highest possible quality, lowest possible cost, the time required to implement it increases exponentially - You’ll never get there. It cannot be achieved.[/li][li]If you insist on absolutes for cost and time - that is, lowest possible cost, shortest possible time, the quality drops to near zero. You will not be able to use the end product. It will be broken by design.[/li][/ul]

In my experience - the third category is the most common - i.e. “do it fast and cheap - we’ll come back and beat you up about the poor quality later”

#2

I face a similar conundrum when buying classical music CDs (yes, I still buy CDs) except that the factors are: cost, quality and size i.e. I try to get acclaimed (according to my ears and critical consensus) recordings that are cheap and don’t take too much space on my shelves.

I’m absolutely certain that I spent way more time browsing CDs on various websites than actually listening to them. The Chase Is Better Than The Catch…

#3

And in the real world there are time-related costs - a project can’t run on endlessly and remain inexpensive.

And the source of much trouble. Those who say they don’t care about quality rarely mean it.
I once met a guy with a good business fixing heavy construction machinery (bulldozers, cranes, etc. - serious stuff). He said most of his jobs were under time pressure (it’s expensive to have a vital machine out of service) and were almost always accompanied by the instructions to “fix it quick and cheap”. He’d nod and go to work.

He said his guiding rule was “work at a sensible pace; use parts and supplies as if they are free and the machine is your own.” This nearly always produced happy customers.

#4

Too true - in fact, there is probably symmetry on the other two cases as well - that is:

Absolute on speed and quality doesn’t just cost a lot, it’s probably impossible, because time is required to engineer quality

Absolute cost and time doesn’t just deliver a poor product, it delivers no product.

These are the same people that tell me “Listen, I accept the risks, just make sure they don’t happen.”

#5

As a QA Representative at a large (formerly government) organization, I can tell you that project leaders don’t give a shit about quality.

Time and cost is all that matters. QA gets involved after the fact and nothing ever works out as planned.

#6

Most of the places I’ve worked insist on all 3 being top priority. Best quality, fastest time, lowest cost.

When it is pointed out that the point of the famous equation is you cannot physically have all three at “best” value, management takes the position that I have a morale problem.

#7

Sometime, when two groups within an organization are positioning to work on the same project, you have the following:

Group #1: We can complete the project in 18 months for $3 million
Group #2: We can complete the project in 2 months for $10 thousand

Program management knows the second group is full of shit but, hey, what if they pull it off? We’ll be highly-compensated heroes!! Of course, Group #2 gets the nod (and proceeds to take 3 years and 10 million to finish)

#8

I used to have a manager who liked to say: “Customers only want three thing. They want a Cadillac, they want it yesterday, and they want it for free.”

I had another manager who liked to say: “Nobody will remember how long it took you to finish the job, but they will remember how happy they were with the results.”

Obviously these are somewhat contradictory, but I think they are both frequently correct.

#9

We use the same paradigm in market research: “Fast, cheap, and accurate…you can have two out of the three.”

And, yes, more often than not, clients lean towards “fast + cheap”. And, then, later, some of them complain about the relatively low accuracy of the data.

#10

Ah yes, the “Golden Triangle”.

It’s a law of economics, and it cannot be broken (long-term, that is).

#11

One problem is that the metrics are open-ended.

When you say quality, how much exactly do you mean? A 1% defect rate? 0.01%? 0.0001%? Achieving the maximum possible quality requires sacrificing both time and cost, which is one reason why aerospace projects tend to be both expensive and long.

Likewise, extremely cheap things require sacrificing both time and quality. Quality since cheap things require cheap materials, and time because optimizing the process takes iteration.

And finally, time requires sacrificing both quality and money, for basically the opposite reasons as the above. It doesn’t matter how much money you throw at a project; you can only speed things up so much before you lose quality. Likewise, speeding things up will cost you no matter how much quality you sacrifice.

That said, for reasonable values of the parameters, the maxim is fairly accurate–say, pick two that achieve 75th-percentile values, and the third will be at the 25th percentile. If you need something at the 99th percentile, you only get to pick one.

#12

An issue that keeps coming up, or maybe I keep seeing it due to actually having a background in Quality, is that people commingle multiple definitions:

  • matching specs. This is what “quality control” checks.
  • “high” specs. This is what people mean when they say a Ferrari is better than a Skoda.
  • matching the user’s needs at a cost (time, money, whatever) the user is willing to pay. This is where I get people facepalming when I ask what would they prefer if they lived in a farm: a Ferrari, or a John Deere? (So far nobody has picked the Ferrari).

I get a lot less whinners if I can get people to understand that in order to define our goals we’re using the third definition, not the second one. We’re not aiming for “so pretty”, we’re aiming for “it works”.

#13

Yep. This was the biggest disconnect/disappointment/source of disillusionment I experienced between what I was taught in college and corporate life. Throughout my years working on my CS degree, I was taught the importance of writing quality code and turning out accurate results. It took me around 20 years to get over the bitterness of discovering that management never gives a shit about quality. I occasionally got in trouble for delivering late or proposing things that would cost too much, but I never, **ever **in that freaking long career, got in trouble for shitty work. Even after turning in stuff that didn’t work completely according to spec! It was always “ship it, we’ll work out any complications later”.

Now that I’m a BA, it’s… still the same. I often write incomplete requirements and the devs have to guess because they push the development to start (and sometimes finish) before I do. Makes a crap ton of work for the poor QA team (and everybody, really). But is that an issue? Not the least little bit.

#14

I worked my career in purchasing, and had that framed on my office wall. :rolleyes:

#15

In my particular case, it’s not so much about defects (because defects are pretty much places where the product fell short of the design), it’s broken earlier - it’s about applying some effort and rigour to the design process in the first place.

The products I often have to support don’t have defects, because they don’t have a formal design - a customer talked to a manager, who talked to a director, who went straight to the software vendor and said “just bloody build something that does [vague description] - we need it fast and cheap. Get going!”.

Three days later we (the internal IT service) get a product release with:
No design spec
No release notes, except ‘this will need a lot of testing’
No test plan or scope
No configuration notes
No clear notion of what anybody actually asked for

We pretty much have to reverse-engineer the damn thing just in order to tell the end users what it supposedly does - and we don’t get much out of the software vendor, because the folks there are all busy rushing to squeeze through the next massive turd in the pipeline, because the process that led to this release has already started again with another.
And the vendor is never held accountable for the difficulty in implementing/releasing it - that’s my job.

It’s a culture problem at the highest level of management, and not amenable to reason or change.

#16

Hate to say it, but I fear you’re right. The dysfunction that permeates so many management cultures here in the US (and probably elsewhere) is this eternal focus on the short term…you gotta *do something *about it and NOW. Sadly, pulling the trigger on an ill-conceived and underfunded project that’s doomed before it starts creates the appearance of motion/action and fits the bill for ‘doing something now’.

#17

The company I currently work for does internal software that we sell time/access to external customers on. So it’s sort of a hybrid of internal/external software development. We have a very nicely organized IT/Dev division. We also have a large team of business analysts (including myself). However, the BA’s belong to the marketing division, not IT/Dev. The IT/dev teams know and use project management. The BA’s - and more importantly our management chain - haven’t a clue what PM is or why it might be useful. This results in projects where our requirements documents fall way behind the developers because they have to move the projects forward while we BA’s are fighting to get our highest level “here’s the idea we’d like to develop” documents through our management approvals before we can then write the detailed requirements. You can imagine, I’m sure, what our cost-quality-time ratio is.

It feels very much like the developers drag us by our nostrils through the SDLC. It blows my mind to work under this organizational structure and especially on the side that hasn’t a clue.

#18

Another variable we have to contend with is the incompetence of the end user and/or onsite “techs” we insist on contracting, I’m pretty sure the hiring process consists of one question…
“Does interviewee have pulse”

We can ship the OST or end user either a brand new unit, or one I’ve repaired back to factory spec and guaranteed that very same unit (or one just like it) will be back in less than a month, for one or more of the following reasons;

1; end user doesn’t know how to properly configure or use the unit, they will return it as “DOA”, when it’s sent back through QC, NOTHING will be wrong with it, I will similarly find no issues, ID-10-T error, nothing more, I’ll clean/bag/tag it and return it to good stock, it’ll be back soon, yet another NTF…

2; end user will have utterly trashed it, to the point it can’t be repaired, liquid spills, caked with crud, physically damaged, perhaps with unrepairable frame damage,
A unit that was basically brand new when it left my work area will be rendered into scrap. (And they’ll claim it was “DOA” too, accusing us of sending it out that way :mad:)

3; disassembled inappropriately by onsite “tech” in a ham handed attempt to steal a part or parts from it (we sell the repair parts as well, if they needed a part they could simply order the part they need, no need to cannabalize a good unit), oftentimes damaging or destroying the new unit in the process, then sending the unit they destroyed back as “DOA”

As an example, they order a portable ruggedized thermal printer we repair, a model very difficult to repair, we do it and we do it well (good and fast), this unit is extremely service hostile, if not disassembled very carefully, multiple components will be destroyed, simply by opening the casing.

It’s gotten so bad with them wrecking multiple units that I’ve started deliberately making them impossible for the onsite techs to take apart, they don’t need to take them apart anyway, that’s not their job.

The first step is to replace the Phillips head screws with Torx head
Second step, fill the screw heads with UV-cured epoxy resin, it can only be removed with a special tool
Third step, put “warranty void if removed” stickers over each of the screw holes…

Haven’t had any more unauthorized disassembly attempts on that model since, even if they remove the void stickers, they give up when they realize they can’t unscrew the screws

So, the choose any two choice is all well and good,
Until you have end-users or “techs” wrecking all your hard work and trying to blame it on you…

#19

I actually was involved in a “Time + Cost” project.

Hell, I’ll mention the name: (no I won’t)
Their AR system was hopelessly patched garbage that could not keep up with requirements.

The IT dept said: 3 years, $5 Million.

The Hero User Dept. manager found a brand new A/R system by a brand new company for $125,000.
He figured it would take only 2, maybe 3 contract programmers to install and write interfaces (1986). I was one of them.
The thing (CICS COBOL VSAM) would not compile.

My calculation was 32 hours to run the daily cycle.

It had file I/O counters (yes, it was still in development).
The VSAM file definitions used a space definition I had never seen: Number of Records. Their “Customer Master” file had been defined as having 40 records.
It had a Parm file for various tables - we had 80 of one record type.
The I/O counters on the program which ran 90 minutes had read those 80 records 2.2 MILLION times.

The hero manager was still bragging about how he showed those over-paid assholes in IT up.

Three years and $6 Million later, it still didn’t work.

They gutted the thing of all the bells and whistles they wanted, just to shorten the run time and declared victory.

“Cheap Fast Good” - Choose TWO has been around for decades and still there are people who believe all three can be had if just there is a silver bullet somewhere.

And now the insanity has spread to the political world…

#20

Entertaining movie about the subject, Fast, Cheap and Out of Control

My wife is fascinated by the Mole Rats.