Controlling Software Development Costs

How to contain software development costs? Often the heart of the matter is the original estimate.

The “bible” on estimating is Estimating Software Costs   by T Capers Jones.  He has been writing on this subject for years.

Jones’ main premise is that large, complex projects require automated estimation tools. They tend to be more accurate than manual estimation methods and more conservative when inaccurate. Manual estimation methods tend to be less accurate and too optimistic. He backs this up with real world data.

My own experience has shown that manual methods can be used on small projects (say less than 5000 lines of code) when you break up the project into phases with short development durations. I believe that this is the underlying power of agile and timebox methods. As the number of lines of code increases, the functional complexity increases exponentially. Manual estimation methods usually assume more linearity, so as the lines of code increase, the difference between the linear projection and the exponential project rapidly increases.

When you are working with an original manual cost estimate and encounter real world complications the result can be massive cost overruns.

So what can you do if plopped into the middle of an on-going project experiencing cost overruns?

There are several major options: increase the budget, cut the scope (even to zero thus killing the project) or break the project up into multiple phases or even multiple projects.

Before deciding on which path to pursue, take stock of these issues:

  1. Endeavor to get a more accurate estimate of the remaining work. Truth really matters a lot at this point.  If you can’t get access to an automated tool, at least have all team members give realistic bottom up estimates of all remaining tasks.
  2. Assess the remaining technical risk. Did the project fall behind because of underestimated complexity? Is the original toolset still a viable solution?
  3. Have new requirements surfaced that  significantly change the scope or duration of the project?
  4. Assess the political support for the project. Has the team credibility been so damaged that faith in achieving the objectives has been lost? Do some team members need to be augmented or even replaced?
  5. Has missing an important deadline or failure to meet a key objective now changed the business value of the results of the project?

Change is now the name of the game. Knowing which levers of change to pull, now becomes the manager’s critical job.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s