Project Management

Bloat is not 'good': Stick to the numbers when discussing scope/time/cost dynamic

Ken Hardin breaks down why the PM concept of scope/time/cost has been misinterpreted as "good, fast, cheap" by IT organizations.

Clichés are so annoying because most of them have just enough truth in them to undermine your efforts to analyze a situation and plan a reasonable course of action. The glib business truism I most hate, and have hated for more than 10 years, is: "You can have two of these three: good, fast, cheap."

I heard this one recently at an informal morning coffee for startups and small businesses. I held my tongue briefly (it is the best I can do) until I asked the same question I have been asking in retort to this cliché for more than a decade: "Well, that really depends on what you mean by 'good,' doesn't it?"

In my experience, the project management triangle concept of scope/time/cost has been misinterpreted as "good, fast, cheap" by IT organizations as a reflex defense against scope creep, the great enemy of all projects. The general argument is that by stretching to meet aggressive goals on any of the three fundamental quantitative aspects of a project, you inherently have to impact those aspects in a negative qualitative sense.

The phenomenon often is depicted visually, like so:

valuebubbles112213.gif

This dynamic makes sense, to some degree. IT can't be expected to rush out a feature-rich release in little time and with few resources attached. The problem lies with labeling a feature-rich release as being inherently "good."

A project is "good" for business when the resources expended on it map favorably to increases in revenue or reductions in cost. In many cases, a simplified project that still meets 90 percent of the business goal, at 50 percent of resource commitment, is about as "good" as "good" gets. In other words, bloat is "good" for no one.

I realize that my irritation here may sound a little pedantic, but as someone who has been on both sides of the client/PM fence, let me tell you that the "good/fast/cheap" pushback to line-of-business managers serves only to enforce their preconception that what they are asking for is inherently "good." And business can ask for some pretty crazy stuff.

In this exchange, IT appears obstructionist -- the business is asking for something that is "good," but tech can't provide this quality under the same budget and time pressures that the rest of the business has to face daily? Not a good look for your team.

The best recourse for PMs (and this is almost always the case) is to keep pushback on a purely quantitative basis. The project management triangle (or Triple Constraint, as I prefer to call it) is meant only to express the absolute independency of scope, time, and cost. You can't change one without impacting the other two.

Express that reality to business stakeholders in real hours and dollars, with granular breakdowns on features that you (and hopefully, your pal the business analyst) think are prime candidates for simplification. But don't ever express proposed scope simplification as a cut in "quality". "Quality" is not a measurement of scope; it is a measurement of how well the deliverable meets the defined scope.

The overall success of the project depends on how the defined scope meets the business' goals. The PM office needs to contribute that to success, but that is a much broader responsibility that reaches all the way to senior management.

The best tactic for PMs is to stick to numbers, paint a clear picture of the interdependencies of scope/time/cost, and then hammer home the fact that these interdependencies are immutable.

In other words, "You get what you pay for."

Some clichés are better than others.


About

Ken Hardin is a freelance writer and business analyst with more than two decades in technology media and product development. Before founding his own consultancy, Clarity Answers LLC, Ken was a member of the start-up team and an executive with TechRe...

7 comments
rmycroft2000
rmycroft2000

So according to this the business must always get 100% on the quality parameter as they always know what they want.  Well that is frequently not true as too often they have been sold a bill of goods by some 'visionary' from some git seminar they attended.  So a lot of the time we get to walk back what they think they need into the old reality zone and get to sort actual business needs from the Disney World vision they too often want built.  And as someone who also deals with more of the EE crowd on embedded systems I can tell you they have exactly the same problem with management and I've seen precisely the same kind of issues in civil engineering, so the idea that every other part of the business that is not doing basically repetitive work is always delivering anything like 100% is tripe.

sparent
sparent

Errr... I think you meant interdependency, not independency, of scope, time and cost.

casey
casey

Ken - 

Interesting topic. I would change "Not Gonna Happen" to "Nirvana" indicating an ideal state that is not unattainable, but requires significant effort and balance.


Other than that, nice piece.

ionplesa
ionplesa

Well said! And especially this "The overall success of the project depends on how the defined scope meets the business' goals. The PM office needs to contribute that to success, but that is a much broader responsibility that reaches all the way to senior management."

astansell
astansell

This is a fantastic article!!! Thank you for sharing.

robinfgoldsmith
robinfgoldsmith

The supposed experts who glibly tout ‘pick two’ are sticking anybody foolish enough to believe them with certain failure because customers want all three.Scope is the combination of functionality and quality, because a function needs to have a necessary degree of quality to consider it delivered.You are right that organizations falter by not adequately or appropriately defining scope.In my experience, creep is reduced significantly when scope is defined as high-level REAL business requirement deliverable _whats_ that provide value when met by some product/system/software _how_.

casey
casey

@robinfgoldsmith 

When clients unreasonably (scope-wise) demand that speed, cost and quality factors be adjusted (typically this is a reaction to an initial estimate), I use a "pick one" strategy. 

The discussion usually starts with a knee-jerk response that "all three are equally important". Then we explore, one by one, the implications of their position, until they reach an understanding of how the 3 levers relate to their initiative and where we can mutually agree on the balance. 

If this approach does not yield results (meaning that the unreasonableness can't be overcome) I switch the conversation to change management and scheduling to make sure the processes are agreed to when invariably something goes askew.