| At a recent software development conference, I overheard a discussion involving a project which had run substantially over budget and schedule. The question posed was what did the group learn about how to avoid such overruns. The Answer? Break the project down into the smallest possible units, and then estimate the time needed for each unit. This was apparently the belief and strategy going into the project as well, however the belief was now that the units the project was broken into for purposes of estimating, were not small enough.
There are a few things wrong with this approach. If you take this to it's extreme, and break a project into ever smaller units, you will eventually arrive at single lines of code, or statements. You would have in effect coded the entire application. This front loads a tremendous amount of effort into something that is almost certainly wrong, and therefor at best useless, and more likely detrimental to the project. The second problem is that you are going into the project with no clearly defined concept of how long the project should take. With no goal, the developer has nothing to aim for. Coming up with a solution which can be coded in 6 months is no more a success or failure than a solution which takes 3 months. Giving the developer or architect something to aim for is critical if you don't want runaway costs.
I propose that the proper method is to estimate the costs and schedule before you begin to break the project down further at all. How? By looking first at the project as a complete whole. Every project has an inherent amount of complexity. You estimate the costs by measuring this inherent complexity, and adjusting for offsetting factors. For example setting up a relatively simple social networking site might have a complexity factor of 80, however by utilizing existing technology you would offset this, thereby reducing the amount of complexity you actually have to build. So using this example you might end up with a formula like the following:
Social Networking site: 80
Drupal: -40
Organic Groups: -30
Net Complexity: 10
The net result after adjustments is what you base your estimate on. So in this case we have a complexity factor of 10, which might equate to 80 hours of development time and 3 calendar weeks. At this point and only at this point should an architect or developer begin looking into mapping out the project plan, architecture, and actually breaking the project down into units. The saying "necessity is the mother of invention" is apt here. By having a schedule and cost to shoot for at the start, those items become part of the requirements, and one more thing that needs to be solved. If it is not defined as a requirement from the outset, then it should come as no surprise that schedules and budgets are regularly violated.
I know this works, because I have done it, time and time again. Truly, there is no reason to exempt IT projects from the rules of schedules and budgets that the rest of the universe operates within.
Only registered users can write comments.
Please login or register. |
