I first heard this as:
Good, Cheap, Fast: pick any 2
Does anybody know the origin of this phrase?
I can see how one can do (Cheap, Fast, not Good) since it seems possible from
complaints in this newsgroup that this is the dominant paradigm. How do you
manage the other two?
- (Fast, Good, not Cheap) Maybe hire the right number of very good (very
expensive) people, with the right infrastructure support?
- (Good, Cheap, not Fast) This one I'm really puzzled about
--
http://www.qucis.queensu.ca/home/dalamb/
Actually, if one believes the many stories about customer complaints
regarding software, the paradigm would seem to be (not Cheap, not
Fast, not so good)! Most places I worked would say that customers
think software projects cost too much, take too long, and fail to
deliver what was needed/expected/promised.
> - (Fast, Good, not Cheap) Maybe hire the right number of very
> good (very expensive) people, with the right infrastructure
> support?
Basically, I think this would characterize it or hire a larger
number of good but less expensive people. (For some, "fast" may
be that the project comes in on time.)
> - (Good, Cheap, not Fast) This one I'm really puzzled about
Hire a smaller team than one might expect for the job, reducing
cost factors that way and give them longer to work on it. The
smaller team takes longer but has better communication, often
less internal rework.
Simple, if you want it to be good and need it to be cheap, don't expect
it to be fast: it won't be!
Regards,
--
Eric G. Roesinger, SW Engr. : I'm speaking for myself, not my employer!
RF Comm. Product Development : -----------------------------------------
Audio & Communications Dept. : Practice, is no different than : Mt.27.:.
Thomson Consumer Electronics : theory in practice, in theory. : 45-54 :
>I first heard this as:
> Good, Cheap, Fast: pick any 2
>Does anybody know the origin of this phrase?
I believe it originated in the printing industry.
Cheers,
Bill
Bill Bolton billb...@acslink.net.au
Sydney, Australia
Look at Putnam and Myers "Measures for Excellence" (Yourdon Press 1992).
Their data finds a strong negative correlation between development effort
and schedule. Modest increases in schedule can dramatically reduce total
cost of development. They also identify a maximum manpower buildup rate
that for any given organization is nearly constant. Their conclusion
is that for any given project and organization, there is a given fixed
minumum development time, which is also the most expensive.
For an example system of 60 kloc, the minimum development time might be
13 months, with a total effort of 78 manmonths and a peak staffing of 9.
The same project could be accomplished in 14 months, with a total effort
of 51 manmonths, and a peak staffing of 5, or in 15 months, with an
effort of 38 manmonths and a peack staffing of 4.
Of course, as I do with most software estimating researches, I think
he's reading more accuracy into his numbers than are really there,
but the core ideas, there is a minimum time beyond which schedule
_CANNOT_ be squeezed, and that there are significant productivity
efficiencies that can be gained by planning for a more relaxed
schedule, are both basically true.
--
.sig under construction
- get an amazing amount of quality from a long and expensive project,
- Increase quality and shorten schedule by spending more,
- Get something useless to market very quickly and cheaply, etc, etc.
This is a useful tool, by the way, not a biblical edict. You don't
ALWAYS have to spend more to increase quality and shorten schedule, for
instance. But it DOES describe the way things usually work, and I find
the triangle useful when trying to get a customer to prioritize their
requirements (as in, "which 2 of the 3 are most important to you?").
And when you're trying to get out of a hole, you can usually move
towards two of the points at the expense of the other.
- Dave -
David Alex Lamb wrote:
>
> In article <349929...@tagsys.com>,
> Ladislav Bashtarz <ladi...@tagsys.com> wrote:
> >
> >i tell my clients that they can have it;
> >
> >1) cheap
> >2) fast
> >3) supporting their business
>
> I first heard this as:
> Good, Cheap, Fast: pick any 2
> Does anybody know the origin of this phrase?
>
> I can see how one can do (Cheap, Fast, not Good) since it seems possible from
> complaints in this newsgroup that this is the dominant paradigm. How do you
> manage the other two?
> - (Fast, Good, not Cheap) Maybe hire the right number of very good (very
> expensive) people, with the right infrastructure support?
> - (Good, Cheap, not Fast) This one I'm really puzzled about
I would agree with you up to a point; your example assumes wildly
varying productivity for the 3 schedules, but you might not have
intended it to be taken literally :-)! My experience has been that it's
an inverted bell curve for cost, with the left side of the bell being
flatter than the right. In other words, there's an optimum cheapest
schedule that's longer than the minimum. As you shorten the schedule
towards the minimum, cost goes up, but not dramatically. As you
increase the schedule from the optimum, cost also goes up; more
dramatically, in my experience, because you're keeping infrastructure
and support around longer for the project.
The other problem is often people are re-assessing schedule in the
middle of a project, when they already have a certain staffing level.
From that point any increase in schedule ALMOST ALWAYS increases cost,
even if only because it takes some non-trivial time and effort to allow
the people you don't need anymore time to move to another project!
It's one person's experience; note I haven't seen any studies along
these lines!
- Dave -
Well, I remember using it around our company in 1976 or so. I
don't know the origin, but would bet it is in some project
management book somewhere.
|> I first heard this as:
|> Good, Cheap, Fast: pick any 2
|> Does anybody know the origin of this phrase?
|> I can see how one can do (Cheap, Fast, not Good) since it seems possible from
|> complaints in this newsgroup that this is the dominant paradigm. How do you
|> manage the other two?
|> - (Fast, Good, not Cheap) Maybe hire the right number of very good (very
|> expensive) people, with the right infrastructure support?
Or more than the "right" number of really good people. As the number of
devlopers passes the optimal number, there is a productivity increase,
but it's diminished, due to communication overhead.
|> - (Good, Cheap, not Fast) This one I'm really puzzled about
Imagine a single truly brilliant programmer slaving away. Eventually,
the product will ship, and be of high quality. But it will take a
while.
His observation is that projects that planned for longer than minimum
development time were noticably cheaper than projects that planned
for the minimum development time. A longer time for the same amount
of work means fewer programmers, hence less communications cost,
less training costs, fewer development and testing machines, reduced
office support overhead, etc. Beyond that, lack of schedule pressure
means that the developers can identify common substructure, resulting
in more reuse and a more cohesive architecture.
Of course, this assumes an actual project plan. Unplanned projects
can have no meaningful prediction of cost. If the whole of the
plan is for the programmers to work until its done, with no
real definition of just what done is, it may never get done,
and costs can be very high then.
--
.sig under construction
I struggled for a long time to figure out how to represent these kinds of
tradeoffs. In my book, "Creating a Software Engineering Culture," I describe
an approach involving 5 dimensions of a SW project: cost, features, quality,
schedule, and staff. On any project, each of these dimensions can be a
constraint (fixed value, no latitude), a driver (prime objective of the
project), or a degree of freedom (project manager has some degree of
latitude to trade those dimensions off against each other to accomplish
the driver within the constraints). They can't all be drivers or constraints!
I use a Kiviat diagram as a simple, qualitative way to represent how
much flexibility the project manager has in each dimension, to make the
project succeed. This is just a tool for having important conversations
about what the key project objectives are, and what the project manager
can stretch, bend, and trade off to achieve those objectives.
--
Karl Wiegers kwie...@kodak.com
Eastman Kodak Company phone: (716) 781-9152
343 State Street fax: (716) 724-7434
Rochester, NY 14650-0546
Opinions expressed here are almost certainly unique to me.
--
Anyone read this (besides myself)? I've had the chance to hear
Karl speak twice about the ideas in the book as well: '97 SEPG
in San Jose and the ASQ 7th Int'l Conf. on S/W Quality in Mont-
gomery (AL).
Yes; I think it's a great book. Lots of useful insights in t.ti.