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:
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.