Coming up with accurate time and resource estimate is one of the toughest skills of a good tech manager. It is an under appreciated skill, but vital to a project’s success. In the ‘real world’ this one area requires many skills. It is necessary to have a deep knowledge of the project and technologies to be used, familiarity and confidence with your available resources as well as an intimate knowledge of the ‘outside’ forces. Outside forces on a project include other projects, vacation and resource availability, and finally all the stake-holders in the project. This could be your client, your boss, or perhaps another group in your company. This piece of the puzzle is usually the largest wild card when making an estimate.

Hopefully, you are working on a small, manageable project or feature. As I mentioned in a previous post, no web project should take 9 months to a year of development. Delays are one thing, but if the project plan calls for over 6 months of specs, development, and QA, the project should be broken down to more digestible pieces immediately.

I speak from experience here. In 2008, we completely redesigned our website. We looked to change both the front-end and back-end infrastructure and add every feature we could conjure up, but when the estimates rose into the 9-12 month range we scaled back the project. This reduced risk, and allowed us to provide an accurate estimate to the project’s stakeholders.

After 8+ years of creating estimates for both internal and client based projects, I have a basic formula. This formula works for billable or developer hours. This is not a ‘Time to Completion’ estimate. Those estimates require knowledge of the company, other projects on the development queue, and resource availability.

Here is the ‘secret sauce’:
When I have a project, I break it out into tangible subsections. Design, HTML/CSS front-end work, back-end work, middle tier, and database interaction. For each of these areas, there are questions that every manager must ask. These will be specific to your business and type of work. An example could be “will this project require third party data, or a registered user database? Do we need to put this particular feature behind a login? Or what technologies are we using or need to interact with?”. Knowing the right questions to ask comes with experience.

At this point I take the resulting pieces, and come up with hourly estimates.
Any feature or additional piece of functionality adds complexity to the whole project. They do not stand on their own. Let me explain. Say a particular widget takes 2-4 hours to develop on its own. And a poll or survey takes another 4 hours. Imagine a project comes across your plate that needs a poll, and also links to this ‘widget’. Simple addition would say this is 4-6 hours, but you know linking these 2 technologies will take more development, and add more complexities to maintain. Maybe it affects another poll or feature you deployed last week, and now that too has to be incorporated into this new poll+widget idea. So in reality, this new idea might take 8-10 hours to complete.

You can easily see how the owner of this idea will not understand the additional hours needed if they are not technical or involved in the big picture. Selling these additional costs is another difficult part of the reality or practical development. Its very hard to explain the nuances of the development processes to the non-technical parties involved.

Because of added and unforeseen complexities like these, I use the following hourly increments when creating estimates.

All items take the following time (measured in developer-hours).

• 2, 4, 6, 8, 12, 16: These increments work for 80% of feature additions.
• Anything over 16 hours proceeds in increments of 8 until 40 hours. (24, 32, 40)
• After 40 hours (1 week of one developers time), start to increase by 12.

(This is because anything over a week now has a higher probability of being affected by outside sources now. I can easily shield any developer on my team from outside distractions for 1 week, but its impossible to push off a person entirely after that. You may absolutely need them for something else with a higher priority or deadline.)

• After crossing 60 hours, I increase by 16 hours at a time.
• We usually stop at 120 hours.

Very few projects get estimates past 80 hours anymore, but its not impossible. After 120 hours, we break the project into smaller, more digestible pieces of 80 hrs and under. I recently estimated a very large project at 300 developer hours, but it was really 3-4 smaller projects of 60-100 hours each. With practice you will find natural ‘breaks’ in a project for estimates. Maybe its database, back-end, and front-end. Etc…

I have spoken about realistically breaking down into 6 month turnarounds, which is usually a maximum of 120 hours of developer time. You will definitely have to tweak this for the way things work at your company, but the hourly incremental formula has worked for me for years, and always provides accurate billable estimates. Also don’t forget to add in a little padding for 3rd party projects, where you do not control all the project deliverables, and you shouldn’t get burned by a low ball estimate when it comes time to bill.

You may also need to estimate design and project management into your estimates depending on where you work. This method concentrates on the area I have the most expertise in, Web Development.

None of this is a science, rather it is an art, and there are no guarantees projects will come in under budget using these methods. This is particularly hard for us to come to grip with in the technology field. We like accuracy and concrete formulas by nature. However, I find these guidelines have provided fairly accurate estimates for me for years. Remember to keep records and compare your actual time with your estimates, and you will be able to achieve more accuracy over time.

Does anyone else use a similar or perhaps a completely different process for estimating developer time? I’d love to hear about it and discuss.

image by HikingArtist.com

Related posts:

1. good development teams share information Sometimes its hard to effectively share everything among all members...
2. Software: 6 Questions to Ask Yourself When Deciding to Build or Buy A common dilemma of many tech managers and businesses in...
3. Iterative Development is Effective Here at SmartMoney, we have been using iterative development techniques...
4. Knowing your users will help make effective decisions If you are reading my blog, there is a very...
5. Keep Teams Lean Developing effectively starts with the team. Of course projects requirements,...

Related posts brought to you by Yet Another Related Posts Plugin.

Filed under:
dev team, experiences by bill breen