F. George McDuffee wrote:
On Mon, 03 Mar 2008 17:21:01 -0600, Louis Ohland
wrote:
I need to document a process. Up until now, they used a simple
timeline, but that was when there was 18 months to make it work. Now 18
weeks is a luxury (closer to 30 days, minus)
Which book is worth getting?
The direct title match books are from the 60s and 70s.
Gantt, PERT, CPM
============
After having been there [and tried to do that] I have some
thoughts/observations/suggestions.
The major reason for the initial success of CPM/PERT in building
the Nautilus submarine was the ruthlessness of Adm. Rickover in
enforcing reporting accuracy and action implementation as
required.
If you have any friends at work, and they are part of the
project, they won't be friends for long. If you do your job
right, expect to transfer or to get a new job on the completion
of the project, successful or not.
== Be aware that CPM/PERT is a technique of the 50s and 60s so
there may well be a "situation" here you should/want to steer
clear of. ==
One drawback of CPM/PERT from management's perspective [if it is
correctly introduced, i.e. rigorously implemented and ruthlessly
enforced] is that it allows no place to hide and very little
opportunity to shift the blame for failure to perform/produce.
A major institutional problem is the refusal of "management" to
accept the results. For example it they want a new product
introduced in 180 days but CPM/PERT pert shows it will require
270 days, after everything is reviewed and tweaked, then there is
something wrong with CPM/PERT, not their "wet dream."
I cannot second this comment too strenuously. About half the
engineering projects that I have been on have been within 10% accurate
in the original estimate, yet have had that estimate whittled down to
meet the date of the next trade show without either adding people,
reducing features, or allowing for a not-fully-working prototype to be
delivered to the show (this in an industry where you _always_ see nearly
a year of lead time between the trade show and the first big rush of
orders).
There is something about human nature that seems to compel upper
management to dictate schedules by fiat (I'm very virtuously avoiding
getting either cynical or mentioning genitive organs here, I hope you're
proud of me). You'd think they'd learn, but at the end there's always
an excuse other than "gee, that took just as long to do as they
originally said -- maybe we should have listened".
I've really only seen the process work well once, and that was because
management was over a barrel and we had a new guy who came in after we'd
scheduled it. He was in a position to go to upper management and tell
them they could choose to do the project as estimated, or they could
choose to wave goodbye, but that there wasn't a third choice. Even
after doing _exactly_ what he said he'd do on the first project, the
second one got talked down halfway through, and we missed our dates.
(I should mention that whatever this guy's popularity was at the upper
management level, all of us folks below him thought -- and still think
-- the world of him. He was ruthless in such an engaging, friendly,
diplomatic way that we were all proud and thrilled to be working on a
successful project rather than bitter and resentful at having all of our
little faux pas revealed. And this was for a guy who _always_ scheduled
deadlines on a Monday morning so if you didn't get it done on Friday
you'd just naturally work over the weekend.)
As I write this I'm thinking of the construction industry, and the fact
that some states are writing contracts that give big day-by-day bonuses
for getting things done early, and big penalties for coming in late. I
wonder if they do better...
some specifics
-- snip --
(2) Gantt charts are reasonably simple, the problem being things
always take longer and cost more than planned.
There are two ways that I know of to cost things out accurately (really
one, but they look a lot different).
One is to look at how long a very similar project took, and copy it's
times _as finally executed_. The other is a method called "wide-band
Delphi" that lets an experienced group of people break a new project
down into know pieces and estimate each piece to get a final estimate.
Of course, to really make this happen you have to suppress your natural
optimism. Everyone tends to ignore how long it'll take to _really_ get
things done; it takes practices to learn to do an honest estimate. And
the estimate is fragile -- at any time, it is all too easy to look at
your own estimate, that you know damn well is just right, and pull it in
without changing how long it'll take to actually do the job. So when
the boss's boss's boss puts on pressure to have the schedule brought in,
it does eventually come in -- but the actual times don't change.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at
http://www.wescottdesign.com/actfes/actfes.html