[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