Discussion on:

Use this process to estimate a project's effort hours

I have found it wise to begin estimations well in advance of a project. Do not do it last minute. I am not writing of true emergency projects here. Take your time because there are always those projects holes and missed assumptions that can add hours to a thing. Walk around your estimate, think about it, then discard it and look at it again.

If you are doing client work, try to avoid THE DEADLY PROJECT CREEP scenario. This is where a project starts out with a given beginning and end goal, and slowly has parts and segments added to it as users put in new wish lists desires and management would ALSO like to have this done too (since you are on site at 2:15 in the morning anyway and we are PAYING you enough) so that your simple or defined project becomes the equivalent of building the Empire State Building. In a snowstorm.

1 - 7 = guess
8 if you think you guessed wrong twiddle.

The big problem with this is step eight all too often becomes reduce contingency and rework in order to make the project saleable. And the assumption that your technical types will wave their wands and get, at least, you out of the mass grave you just dug is never documented.

Guess , do some work, guess again, do some more work, guess again. The guesses will get more accurate as you go along. That way you don't get to 1 week from completion and get 'surprised' by another 10 weeks work.

Still using Waterfall estimation concepts in what is generaly a much more agile environment.

Nice documented checklist of what most project managers try to do intuitively.
Free tools to help estimate the work effort are posted here:
http://www.pptmagic.com/projectmgm.htm

I had a potential client who wanted an overhaul on his website, but he didn't have everything set in stone.

However, he wanted a quote, and I wanted to provide it for free, as that sort of thing is usually what people look for. He couldn't understand why my price was so high, though, as I guessed at the high end of the spectrum. Better to bid high and refund some of the money than to bid low and ask for more.

Initial consultations may now be free, but I won't allow myself to go into too much depth without some kind of down payment for reviewing the system. I bet I put in at least ten hours looking over the system, only to have the potential client take his business elsewhere. (I refused to work on a website and not upgrade the security risks, i.e., SQL Injection holes and the storing of credit card numbers (including CVV2 codes!) and passwords in plain text within an Access database.

are there estimation mechanism for SOA projects?

When bidding on a project, I usually take what I consider to be a 'reasonable' estimate and then double it.

I've never come in at under the actual time, but haven't gone much over either -- enough to eat anyway.

The real problem is to get management to BUY a fair and reasonable proposal.

Ever hear something like, "You want 120 man-days for this project? We only budgeted for 40! Can you do it in that?"

I found these suggestions very insightful and I used this process regularly to estimate projects. It works.

As an independent consultant, and I assume many post here, how many of us have experienced Project Hell where our best work estimate falls to pieces because of unexpected point failures along the way? Those projects that just grow because of unknown failures and things that go bump in the night? I do not enjoy, and sometimes take a considerable hit, from these hellish events.

Those projects that you estimate should take 4 hours but really take 14 hours because of (oh, for example) power supply that dies along the way, system issues, software issues, bad motherboard affecting some other issue, etc.

My BEST effort, then, is to accept these little wars as unwinnable - and bill for the four lousy hours or whatever my initial estimate was, swallow the rest and have a stiff drink at the end of the day.

To come up with quote for how much.

To see how you are doing.

Unfortunately many seem to think that these two requirements can be served by one set of figures.

During my time in corporate IT, we had a full weekend upgrade from Novell 3.12 to 4.11 and that was a process all of it's own. We did not quote per se, but we spent a full 2 hours writing down the steps, inclusive of 4 hours of ArcServe restore (which we almost left out) so that we did have a time-measurement to use against how far along we were.

The upgrade went magnificently by the way.

Nice article.

eConcinnity.com is currently looking for estimation experts. If you are interested, please submit your credentials to them at http://www.econcinnity.com. You can join and work online in part time mode.

Thanks

Is there a method to estimate non it projects like process transition projects, or projects involving M&A etc?