Please feel free to check them both out at:

Estimating time for Web Projects more accurately: Part 1

Estimating time for Web Projects more accurately: Part 2

Thanks,

Sam

The two major problem I’ve had with estimates so far are very similar to those on the desktop I experienced in my early years. There is the client who hands me a mock-up or says “I want to clone the functionality of xyz.com”.

They generally do not appreciate my asking more questions and trying to pin the work down (”what about the next page?”, “how do you want the foobar to look?”, “how do you want it to act?”). I don’t see what is wrong with trying to get it right the first time.

The only advise I’ve received is to do a basic job upfront and then get the client to pay to refine it. Sounds sloppy to me at best. I guess I have to just grin and bear it until I have enough history that I can go by the past.

When substantial design is involved the uncertainty on this step is sometimes impossible to resolve. Generally the client’s expectation then starts to influence the proposed timeline at this point.

As others posted, it really helps if:
- you’ve done the same kind of thing before
- you can break it down further and get as much certainty as possible
but I usually find scheduling is the last frontier for most substantial works.

But I find a good starting point is always to reference previous similar projects, or projects that contained similar tasks. For instance, by tracking all the estimated and actuals of past projects can give you an average percentage that each phase took and you can use this average as a good guide. For example, by collecting stats like these for my past ten projects I was able to identify trends like:

* The Site IA and functional specification usually took around 8% of the total project time to complete and get approved
* Functional specification 5%
* Design 30%
* Back-end development 30%
* Front-end development 15%

And so on…

Using these averages, and with a client’s maximum budget, you can begin to immediately allocate a rough amount of time to each phase and then break out each in more detail, but with the roughly allowed hours available known beforehand. With this initial capped limit in place, you can estimate not only your costs but also the most cost-efficitent solution based on the budget, rather than going in with a blind quote that may be way to small or too high.

Of course, this is dependent on knowing the client’s budget beforehand, not always possible, but more possible than most seem to think if you just explain you want to deliver the best solution for the price.

The greatest thing you can do for a project is NOT estimate when you will be finished with the entire project up front. If your client will accept this, you can provide them with an estimate of what you will accomplish this month. And then you will estimate for the next month. And so on until you can see the finish line more clearly. Not only does this give you much more focused development and the ability to break the project into manageable pieces, but it gives the client the ability to make changes rapidly and see the results.

Here are some guidelines for better estimating, regardless of whether you develop in an “agile” or “waterfall” style…

1) The smaller the task, the more accurate the estimate. However, breaking something into tons of tiny little tasks tends to cause people to forget things that are important. So break down one level at a time.
2) When estimating tasks, allow 1 hour, 2 hours, 4 hours, and then multiples of 8 hours. The rationale here is that larger tasks should be more grossly estimated, where as smaller tasks will be easier to understand and accurately estimate. Small: set up and test FTP server, 2 hours. Large: implement auto-renamer function for files in the FTP directory, 24 hours.
3) For every task, consider not just the performing of that task but also the testing and verification of that task. For a task like “implement auto-renamer function for files in the FTP directory”, add a related task for “test auto-renamer function”. In development, # of test hours = # development hours is a good place to start.
4) The most common reason for underestimation in a task is uncertainty. If you are uncertain about a task, get more clarification on it before estimating. If you can’t get it, then you can apply the padding that mark was talking about — but reasonably. Take the worst-case scenario you can think of and use that.
5) The highest impacting reason for underestimation is CHANGE. If you estimate A and your client adds in “something simple” here and “something simple” there, you are now looking at B, but your estimate says A. Always provide re-estimations when there is ANY change. Providing those estimates to your client will help them understand the impact to cost and timing. If you are in a fixed-bid project, change should go through a FORMAL change review process.
Hope this is helpful…. thanks for the article, great to have people pushing for better understanding of estimations. One thing that’s really helpful to remember is that “estimation is guessing”. Too many people say that once an estimate is given, you should be held to it. This leads to insane padding and overcharging (or profit loss, depending on how badly the project goes), and is not good for the client and is not good for the vendor.

The greatest thing you can do for a project is NOT estimate when you will be finished with the entire project up front. If your client will accept this, you can provide them with an estimate of what you will accomplish this month. And then you will estimate for the next month. And so on until you can see the finish line more clearly. Not only does this give you much more focused development and the ability to break the project into manageable pieces, but it gives the client the ability to make changes rapidly and see the results.

Here are some guidelines for better estimating, regardless of whether you develop in an “agile” or “waterfall” style…

1) The smaller the task, the more accurate the estimate. However, breaking something into tons of tiny little tasks tends to cause people to forget things that are important. So break down one level at a time.
2) When estimating tasks, allow 1 hour, 2 hours, 4 hours, and then multiples of 8 hours. The rationale here is that larger tasks should be more grossly estimated, where as smaller tasks will be easier to understand and accurately estimate. Small: set up and test FTP server, 2 hours. Large: implement auto-renamer function for files in the FTP directory, 24 hours.
3) For every task, consider not just the performing of that task but also the testing and verification of that task. For a task like “implement auto-renamer function for files in the FTP directory”, add a related task for “test auto-renamer function”. In development, # of test hours = # development hours is a good place to start.
4) The most common reason for underestimation in a task is uncertainty. If you are uncertain about a task, get more clarification on it before estimating. If you can’t get it, then you can apply the padding that mark was talking about — but reasonably. Take the worst-case scenario you can think of and use that.
5) The highest impacting reason for underestimation is CHANGE. If you estimate A and your client adds in “something simple” here and “something simple” there, you are now looking at B, but your estimate says A. Always provide re-estimations when there is ANY change. Providing those estimates to your client will help them understand the impact to cost and timing. If you are in a fixed-bid project, change should go through a FORMAL change review process.

Hope this is helpful…. thanks for the article, great to have people pushing for better understanding of estimations. One thing that’s really helpful to remember is that “estimation is guessing”. Too many people say that once an estimate is given, you should be held to it. This leads to insane padding and overcharging (or profit loss, depending on how badly the project goes), and is not good for the client and is not good for the vendor.

If you think it will take one minute, say two hours. If you think it will take two hours, say four days. If you think it will take three days, say six weeks. The unexpected WILL happen and you WILL need that extra time.

And if you come in closer to your original estimate, well, it’s always better to under-promise and over-deliver than the other way round.

what I want is just personal opinion of those who
did simular things before or any hint would be helpful.

ok, here it is:
———————————————
The company give financial consulting services to clients. Three kinds clients of exist in system. There may be “one time” or “long-time” (many years)clients. Every month generate
bills and prints them and credit clients’s pay-card. Although bills and reports may
be generated at any time. Clients details and all reports are stored in system(?!)

Clients’s payments prosseced by external finanicial propgram that output receipts.
Receipts’s details are entered by human operator to system (client’s pay-card updated).

Clients assigned to office workers. In the end of each day worker enter how much time she spend on every of her clients. System has to watch that
all work day would be distributed between clinets, i.e. no idle time.

Manager produce various reports from colelcted data. This is critically important
data for defining profitability of client.

There are about 20 users of the sytems. This is one system for all of them. As some function should be allowed for some type of users, then
access to system defined by user status. They all may work with system at the same time.
————————————————–

Customer wants this application be done in MS Access, as he understand something in it and wannt to tweak with it sometime afterwards.
I think VB is better decision….so any opinion on this topic would be also helpful.