As with most things we have to do in our daily lives, there’s a right way to budget for projects, and a wrong way. The wrong way would be to pull a random number out of the air and hope for the best – although, sometimes that may be the only way to get the data you need to budget correctly next time around (as the saying goes, “Failure is just practice for success”).

Failure may not be an option, though. If you’re working on a crucial project that your company’s revenue (and your job) depends on, then you’ll need to get it right the first time. So, I suggest following these steps for creating your project budget so you can actually set yourself for success, rather than failure.

Step 1: Start from the top with historical data. Hopefully you have already been tracking time against similar projects and have historical data to work from. BECAUSE THIS IS THE MOST IMPORTANT, MOST ACCURATE METHOD IN THE HISTORY OF THE COSMOS! Project time data should be split across project phases, such as:

  1. Requirements
  2. Specifications
  3. Design
  4. Build
  5. Test
  6. Document
  7. Deliver

These phases exist in all projects from software to architecture. The secret is that for similar projects, you will find that the first phase or two will usually have a consistent percentage of overall project time. For example, you may find that in your company, Phase 1 (Requirements) usually takes 10% of overall project time. If you spent 50 hours gathering requirements, then boom! That means this is a 500-hour project.

Step 2: Ask an expert. Someone in your firm has done this before. Ask them how long it should take to do a project like this if things go about as well as they usually do. People love to be the expert. Don’t be shy. They’ll love to help you.

Step 3: Use another metric. Projects produce something – lines of code, miles of road, square feet of architecture. If you have an estimate of that number, you can compare it to like projects from your company’s past to produce an estimate ratio for this project. If the last five projects took 9 person-hours per line of code and we think this is 1000 lines of code, then it will be 9000 hours.

Step 4: Triangulate the above. Now you have 3 estimates. Average them, or see if one stands out as weird and figure out why. Often the “expert” estimates will be low for example. Make a judgment on what your top down estimate will be from the consolidation of these three estimates.

Step 5: Start from the bottom with your task list. OK, so that was the top down method. Now we’ll do bottom up. Take out your project plan with the task list (this is key, if you don’t already have a task list). Break the project into subprojects and subtasks.

Step 6: Estimate each task

  1. For each task give it your best guess about how long that will take. Don’t forget to take time for breaks, lunch, etc. into consideration.
  2. If you have no idea on some of the tasks, get help from someone who does; but keep them on point. No rambling. “How much will it take for this and only this task?” “Well what if you did know?”
  3. Keep in mind the power of the “what if you did know?” question. It always makes people pick a number. This is just an estimate here. It doesn’t have to be perfect.

Step 7: Add them up. Now you have a task list with estimates for each task. How do they add up?

Step 7 ½: Compare the answer from #4 and #7. Now it’s time to compare your data. The two estimates should be close. If not, why not? Where are the outliers?

This may be a time-consuming process if you don’t already track enough project data to make accurate estimates; but here’s the good news: once you have a good process for project budget estimation (as outlined above) AND you religiously track your time on your projects going forward, creating your project budgets will be easy-peasy.