How to estimate a project

Estimating software projects seem to be something of a black art. A lot of has been asked and written about it. However, there is little bit of a method to it as we figured out over past few years over lot of projects.

Since no two software projects are alike, it is not possible to know, accurately, how long something is going to take in advance. So, the only way to really know is to actually start doing the project. And that’s what we do. Well, sort of.

The description below is specifically for developing a web application using Rails. However, the method should be broadly applicable.

  • The first step of course is to understand the requirements. You should at the bare minimum ask the following questions:
    • Who are the users
    • What is the main problem that is being solved
    • Apart from the user facing interface what else is required to run the system – probably an admin interface
    • Ask for or create mocks or wire frames or just sketches of the pages. As many as you can.
  • Create database design: Based on the understanding of the requirements, create the database design for the application – basically create the Rails models.
  • Create routes file. Of course it will hard to create the final one but go as far as you can.
  • Once you have the routes, you have some idea of how many controllers and views you will need. List them out or just count them if there are too many.
  • Looking at the complexity of the application and each page (see your wireframes), you will have to come up with a number: how many action-views you can implement in 1 day. Remember to include business logic (consult your models), controller/action code, views integration and any Javascript required. Also, add time for testing.
  • Sum up the time for coding all the controller/actions including any admin interface. If you require any 3rd party integration add them here since they are most likely not reflected in your front-end driven estimate.
  • Add time for server configuration, deployment, setting up monitoring, repository, etc
  • Add some buffer, say 10-30% if requirements are not clear and calculate the upper bound. Say, your original estimate came to 20 weeks and you think requirements are liable to change, add a buffer of 20% and your final estimate is 20 to 24 weeks.
  • Calculate the total and present your estimate. Typically, with the estimate document you should list down all major requirements in your own words. Then, put down the lower and upper estimate bounds along with the cost and number of developer expected to work on the project.

Some more tips:

  • Estimate only small tasks. If you have big task in your list, break them down and re-estimate or at least classify items which are hard to estimate and point them out while presenting the final estimate.
  • Evidence based scheduling is an excellent technique is an excellent way to estimate a running project.

Post a comment