The easiest way to ruin a project is poor Project Management. Regardless of the quality of the developers if the project is properly managed it is very easy for a good project to go bad. One tool often used to manage a project is the Build Estimate. This document/tool is used to simply outline each task of the project and the time needed to complete said task. However it is very hard to determine how far you need to break up tasks in addition to creating a reasonable estimate.

The Basics of the Build Estimate

Before beginning on my personal opinion on how to create a build estimate lets start by a simple outline of the document and its goals.

What is in a Build Estimate

• Tasks – The first and most important element of the Build Estimate are tasks. These items identify what needs to be done for the completion of a project or a phase of the project.
• Time Estimates – Secondly we have the time required to complete a task, it is important to create the estimate utilizing a common unit of measure which, in most cases is 1 hour of a persons time. For example if you have 3 developers and you plan for a task to take a full week using all their time you would have 120 hours or 15 days depending on if you use hours or days as your unit of measure.
• Scope of the Estimate – Often not included in Build Estimates I personally feel it is the most important factor. Often when working on a team you send information through emails that often get forwarded or communicated to others in the company. It is very important you specify the scope of the document if you are putting together an estimate of developers time and not Project Managers, Testers, etc. it is very important you specify that so others don’t see the estimate and assume that you include test time in your build time.

What are the goals of a Build Estimate

The single purpose of the Build Estimate is to provide at a glance the total hours/days/weeks needed to complete a project based on a single developers resource. This allows Project Managers and other individuals to see how many resources need to be applied to a project to have it completed by the target delivery date. An added benefit is that the build estimate outlines for you the total cost to build the project.

Prerequisites for creating a Build Estimate

Before you can start creating your Build Estimate you need to know the requirements of the project as well as the scope. If your project has multiple releases are you estimating the hours of the whole project, each individual release, or each component of the Project. At the very least I find it helpful to group requirements by components or major features, as it then allows me to easily add up total hours of different features for a release to determine the estimate of a release.

My Standard Build Estimate

In addition to the actual estimate I often include a nomenclature sheet that defines what each column represents. The common item most people get confused on is the Build – Test column as I use this to specify the time needed for a developer to do unit and integration testing of their code, not the time needed for Quality Assurance. A second item I also will sometimes include is a requirements spreadsheet that outlines which tasks are prerequisites for other tasks, this way if release planning is ongoing everyone is aware of what tasks need to be completed to delivery a desired feature.

Understanding my Build Estimate

• Component – This column is used to group tasks together, for example in a Web Application I often break it down to Administration, Reports, Shopping, Static Pages, or similar.
• Task – Identifies each specific task for the given component. This can include Database setup, SQL, Java Development, and etc. This is perhaps one of the most difficult items to identify as it is easy to group tasks together or to get to specific, a good rule of them that I often use is start with the requirements list each requirement as a task then systematically go through them and break up complicated requirements to sub tasks or create tasks for necessary items needed like database setup.
• Build – Mgmt – In a project there is always time necessary for management of both developers and communication of project status. The Build – Mgmt column I use to represent time that will be spent on meetings and similar tasks that will utilize developers time but won’t be used on actual code development.
• Build – DEV – is used to define the time necessary to simply complete the task without any testing.
• Build – Test – is the time needed for the developer to test their code to make sure the task is completed. This includes unit and integration testing however it does not include time necessary for Quality Assurance.
• Total Hours – should be self explanatory as the total time needed to complete this task.

How to properly estimate a task

It is very hard to estimate the time needed to complete a task as many factors take place. The main two to keep in mind is the average skill of the developer and understanding the requirement. If you find yourself not understanding the full scope of a task then don’t simply throw numbers down take the time to discuss it with developers and managers to get an accurate estimate. Also if you yourself are a developer then it does make it easy to start putting in time on what you think it would take you, be mindful that if you have other members on the team then they may take longer on the task. The rule of thumb I personally utilize is how much time would I estimate for myself to complete then either add half or double based on how complicated the task is or how many dependencies it is based on.

Summarizing the Build Estimate

When all is said and done anyone should be able to pick-up the Build Estimate and determine the effort in building a project without knowing the details of the project. These estimates are most useful when there are multiple projects a development team is responsible as it allows managers to readily identify at what capacity the team is working and how new projects or changes to requirements of existing projects affect the delivery dates of other projects.