A set of goals that are mutually contradictory. The canonic example is "good, fast, cheap: pick any two". Good software written quickly isn't cheap; good software written cheaply takes time; software written cheaply & quickly isn't good.
- short, memorable, unique -- used for global identifiers (e.g., domain names/URIs/network addresses, variable names). Originally stated by ClayShirky as ''Memorable, Global, Non-political -- pick two" in http://shirky.com/writings/domain_names.html
- time, cost, quality -- good, fast, cheap in absolute rather than comparative form.
- lots of features, low cost, high quality, available soon -- software requirements
- faster, stronger, drugfree -- not the Olympic motto
- diverse, free, equal -- qualities of the ideal media landscape [http://shirky.com/writings/fcc_inequality.html]
The USA's National Aeronautics and Space Administration (NASA) implemented a "faster, cheaper, better" policy in 1992, with mixed results. The MarsPathfinder
was a success; the MarsPolarLander
was a failure.
The failure was not one of goals but one of communication and coordination.
I have heard otherwise. Somebody decided to skip some tests that may have uncovered the suspected landing gear trigger problem in the name of cost savings. However, even with a lower success rate, it still may have been the more cost effective approach. But, there are also political considerations. Failed probes makes a nation look bad regardless of probe cost. Thus, we may be paying a "face tax".
They also decided to ignore some warnings from the manufacturer, the day before the ChallengerDisaster?
. The cover-up would have succeeded, if not for RichardFeynman
I've always heard this as On time, under budget, zero defects, pick two
. In my experience most companies end up only picking one anyway. -- IanPhillips
I don't think this is true as stated. Projects can be cheap, fast, and good. It may not generally attainable, and requires suitable definitions of cheap, fast, and good, but saying that it cannot happen is false. All successful projects are CheapEnough
, and GoodEnough
I think the correct statement of the rule is that you can set constraints for at most two of the variables; the value of the third will be determined by those constraints.
In software, it has been argued that the standard three variables are not enough to get a proper handle on a project. There are FourVariables: time, cost, quality, and scope. Pragmatically, quality is non-negotiable, since low quality code can't be developed faster than high quality code for any project of non-trivial scope. Therefore, the decision is really "cheap, fast, big -- pick any two.
[Note: This "good, fast, cheap -- pick any two" phrase is used as an idiom which is multi-cultural, easily understandable and implementable]
To imply that such goals require a choice of two of three is the result of an anarchy mentality, which sees organization, precision (good) - rapid development, and coordination (fast) - and - economy, quality (cheap) - as being incompatible such that compromise and trade-offs rather than professional planning, execution and management is preferred. Anarchists prefer to minimize essentials such as organization, coordination, and quality as restrictive to a anything goes and let me be, my part's alright mindset.
To imply that all such goals are possible is the result of an archist mentality, which believes that it can decide all variables at the start, either to somehow get the team to overperform (i.e. get cheap via a DeathMarch) or to simply blame them for the inevitable failure. You can
manage all three (or four) variables simultaneously, but to arbitrarily declare all of them is to reject reality itself. If you want a big project (large scope) good, fast, and cheap, that's going to depend on your definitions of 'good', 'fast', 'cheap', and your scope.
If you need to set three of those variables to extremes, the fourth will be extreme to match. If you need to set all four of those variables to extremes, your project is a failure before you begin.''
For more see: ManagingAfterDeployment