[thelist] How do you estimate time for any given project?

Luther, Ron ron.luther at hp.com
Fri Sep 5 13:25:03 CDT 2003


scott wolpow noted:

Hi Scott,

To estimate time on a project I generally put together a 'rough map' of 
what I think needs done and how I think I would get it done.  Then I 
take a swag at how long that would take me, add in some buffer and deliver 
the estimate.

Now to kibbutz on your specific project.     ;-)

>>The company produces extruded metals. That forms the first part of the 
>>SKU. Then comes the length, then the type of finish, followed by color 
>>if needed. In the future there will be also room for fabrications to it.

I do quite a bit of mfg reporting system work. [First reaction: Ugh - a 
part numbering system with embedded 'intelligence'.  That's usually a 
sign that this will be extra work.  Working with 'dumb' part numbers 
and a part master file containing the relevant attributes is generally 
a lot 'cleaner' design. Still 'doable' - just more work.]

>>They need to track how many of each SKU they have on hand, how many on 
>>reserve, how many are on order from the factory and how many are in transit.
>>I mention all this because the client failed to be specific in what they 
>>wanted. 

I'll take a guess that they are looking for you to rebuild their MRP system 
in a nice 'friendly' web environment so they can get custom dynamic reporting. 
{On-Hand and (incoming) In-Transit are "supply".  (Customer) Reserve and 
On-Order are "demand". The two generally meet in MRP so you can do the ATP 
order promising, the pegging, and the shortage reports.}

>>They gave me print outs of what they wanted. (It began as a three 
>>month project and  1 year later we are getting towards a working Beta. 

Yeah. MRP projects can be real buggers.

Here's one idea for a potential shortcut ... you could have them schedule 
the mainframe reports to run 'batch' and build a process to load the output 
into your web app.  That way (a) you don't have to rebuild the mainframe 
logic from scratch, (b) your app will always 'balance' to the system, and 
(c) you can concentrate more on presentation and customization rather than 
replicating what already exists.

>>To estimate you must first find out exactly what they need, for all products. 
>>My clients would neglect to tell me key info. It is because they are so 
>>familiar with the items they do not see it. 

Yup - that happens too.  One approach might be to talk to someone higher up 
on the food chain who might have a more 'strategic' than 'tactical' view 
of the operations -- sometimes they can be more helpful filling in the gaps 
and giving you a clearer vision of the *why* folks are asking for what they 
are asking for.  Another approach is to pick up a book or class or two and 
try to learn more about the mfg process -- the better you understand what 
they need and why, the better job you can do.  Yet another approach might 
be to cut the scope down - choose one product and one report and concentrate 
on beating the bugs out of that. Tell them you are planning a "phased 
introduction" ... that way it makes it sound like you have a plan.  ;-)

HTH a bit,

RonL.
("Oh? Well, we'll get to *that* in 'phase ii'.")



More information about the thelist mailing list