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

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.