[thelist] How do you estimate time for any given project?
Luther, Ron
ron.luther at hp.com
Fri Sep 5 13:57:50 CDT 2003
Les Lytollis noted:
>>I'd also add my +1 to the previous post regarding well-defined
>>requirements - get a set of requirements defined and signed off - phase
>>the development if necessary - get the customer / client to prioritise
>>what goes in to each phase subject to obvious dependencies of each
>>component.
Hi Les,
I pretty much always add a counterpoint whenever the discussion about
well-defined requirements comes up.
Let me try something different today ... I agree completely!
Now let's niggle about what constitutes 'well-defined requirements'.
;-)
It is an absolute pleasure dealing with a client who has an in-depth
understanding of the process under consideration. Someone who can
thoroughly explain the problem. Someone who can enumerate the benefits
of completing the project - (especially during funding cycles.) And
most importantly (for me anyway) someone you can 'negotiate' the form
of the final solution with.
Unfortunately, once in a while I get a client who comes to me with a 100+
page written <don pretentious voice of someone coming down from the
mountain to lay down the law> technical specifications document </voice>
that has already made it through their committee and gotten VP signature.
{They have done all the work - they just want it implemented.} I say
'unfortunately' because, IME, these folks generally overstep their role
in outlining the problem and the attributes required for a successful
solution ... and venture outside their expertise into architectural and
application design. They provide screenshot mockups which they insist
be 100% faithfully reproduced ... even if they mix technologies or happen
to put 'required' input fields on 'optional' popup input screens or fail
to capture elements that are 'keys' in your current db design.
They also often miss things which sometimes don't get discovered
until UAT and (since they already have signoff) then require a round
or two of finger-pointing meetings, change requests, document re-writes,
and deadline extensions. Pretty much all of which are unpleasant.
So I agree with everything you said. I guess I'm just a little touchy
that client and consultant *both* need to consider the requirements as
'well-defined'.
RonL.
More information about the thelist
mailing list