> -----Original Message-----
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> There is screaming and wailing and gnashing of teeth if the
> estimate is "too big".
Long post follows, but I find this stuff interesting. I'll shut up after
this. :-)
I've found time estimate discussions are usually proxies for something else.
In right-side-scheduled projects, where the "right side" of the project
timeline is basically fixed, rationally or irrationally, when the project
leader is asking you for an estimate, she's usually asking you for a list of
things that can be cut from the scope (I'm not claiming this is a
revolutionary discovery). The sooner you can get to *that* discussion, the
better the negotiation and management goes from there. In pretty much every
time estimate discussion I've had, it's gone either like this:
Manager: Give me an estimate for the frobnicator piece.
Me: {various calculations} Three months.
Manager: Three MONTHS? That's {however much it is} man hours! That's too
long. Can you do it in five weeks? We need this project done by February.
Me: {honestly thinking} Well, I'm uncomfortable with five weeks;
realistically speaking, I could probably pull it off, but I wouldn't hav--
Manager: Well, what can we do to bring this thing in by February 17th?
[ding ding ding; turns out time estimate is not needed; switch to scope
discussion here]
Me: Hmm; how about trimming back the customizable frobnication interval?
That should knock some time off.
...or like this:
Manager: {looking sad and scared} OK, we signed a contract with BigCo last
week. My hands are tied. I have a wife and child to feed and I'm concerned
about my job. We must deliver this project on May 12 or we all get fired.
How can we do this?
Me: {sympathetically sad and scared} Well, that means that {both of us stare
at project diagram with a big black vertical line on May 12} THIS piece has
to take four weeks, and THIS piece has to take three weeks...
{much playing with crayons or their sophisticated electronic equivalents
ensues; red lines and green milestones and burnt umber critical paths and so
forth are drawn and redrawn}
Both of us: There! A diagram that shows that we can hit May 12!
Manager: Go. Start coding. I'll do what I can to find out what you need to
code. Meanwhile I'll run this vaguely
insulting-to-me-because-it-reduces-my-job-to-drawing-pictures-to-support-som
ething-that-will-not-happen-as-methodically-as-presented diagram up to
senior management so they will continue to employ me. And I will try not to
get in your way.
Me: OK; good luck. I'll try to anticipate requirements and not get angry at
you because it's not really your fault either.
[dynamic scope negotiation occurs hereafter, often referred to as change
management, with varying levels of formality]
Sometimes you'll hear, "But it has to be done by September and we can't cut
*anything*. Can't we just add more people?" The old saw, "Nine women can't
make a baby in a month" usually helps here and adds a bit of humor to the
otherwise dreary process. :-)
Incidentally, engineers (myself included) are at fault on the scope end as
much, oftentimes, as project managers or business types are on the time end:
we often claim that we can't trim scope because hey, that would cripple the
application, or, why bother even *releasing* the application if it can't do
this Great Trick? Usually, I've found that if I swallow hard and dig in
hard enough I can find spots where scope can be cut.
There must be some educational reading out there for *real*-world project
management, where there *can't* be any deadline negotiation because (pick
one):
(a) the business folks have already started marketing the product
(b) a salesman doing his best to help the company has promised something to
a client by a certain date
(c) a multizillion-dollar contract has been signed with a date window as a
necessary condition
(d) a trade show featuring the product is coming up in June
I guess I'm talking about books or links that do not tell you to iterate the
schedule (nice, desirable, rarely possible) or to plan in padding time
(absolutely impossible in nearly every case) to get around the issues. Does
anyone know of books or links on this subject? Feel free to send them to my
email address to keep the list clutter-free.
Cheers,
Laird
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
