Clients that need software built always want to know how much it will cost them, and a lot of times (at least as we have experienced at Intellectual Apps) they want to have this information before work begins. In order to get a “realistic” estimate of how much it will cost to build the piece of software, agencies would elicit the requirements and then based on that come up with an estimate of the cost. Client has a cost for getting their software built while the agency is happy they got the project. Great!

The Problem

Work starts and in a couple of weeks (in some cases days), the client asks for some features to be included in the project. If a change request management process was put in place before the project started then that process kicks in to evaluate the impact of the change and its priority. Long story short, the client will always find a reason to have more features added and will expand the initial scope by several features. In my experience building software systems over the past 12 years, I have never seen a software development project start and end without the scope expanding. In essence, software development is an exploratory journey, things become clearer only after embarking on this journey. This is simply a fact of software development.

The issue with the scenario described above is that the agency hardly ever gets a corresponding expansion in the cost of the project (which determines their income). Since more features mean more time and effort, the agency simply suffers. One may argue that the change request process be tighter in an attempt to discourage clients from expanding the scope but this rarely works. There is a very high tendency for a client to take the features they are trying to introduce more seriously than all the others put together, refusing to let the scope of the project expand is like taking a sweet from a child, they become upset.

Fixed-cost-custom-software-development projects will always be plagued by expanding scope. Software development agencies generate revenue by offering professional time and effort, so the moment a project takes longer to complete with no corresponding payment for that extension, the agency looses.

It comes down to two things

1. Clients want to know the cost of building software before the project starts so they know the total amount they will end up spending.
2. It is also not the fault of the client that new requirements come up, it is simply the nature of custom software development.

So how should this be tackled?

From how I see it there are two options:

1. Client gets a cost upfront but scope remains fixed (scope never stays fixed, trust me).
2. Client is free to make what ever changes needed to the scope but pay for the time it takes to build it out.

Option 1 hardly works and leads to all sorts of problems. The waterfall approach is closely associated to this way of building software and the fact remains that it is very hard, near impossible to know and freeze all the requirements for any piece of software upfront.

Option 2 on the other hand is best suited to deal with the uncertainties of software development. It does require the client’s trust in the agency and without trust, it just won’t work. With this option the agency asks the client how much they are willing to “invest” in the software rather than how much it will “cost”. Simply using the word “invest” turns things around as this forms a foundation for the client and the agency to work as partners in exploring a software solution to the client’s problem.

Core to this option is the need for the agency to know their burn rate such that, the agency can easily determine how much it costs them to have a team working on a software solution for a short period of time (say a week, two or even a month). Even though the client is willing to invest x amount of money this approach helps in mitigating the financial risks associated with any software development project by requiring that payments be made for short periods of time to work on parts of the scope of the software. If everything works fine to the satifaction of the client, only then will the next set of requirements get dealt with. The client is free to make adjustments as they wish, as long as they can pay for the time spent by the agency.

Summary

Determining the cost of a software development project based on “perceived” requirements is more likely to lead to a project failure. The nature of custom software development is such that a lot of the requirements stated at the start of the project turn out to be incomplete, and once clients get a clearer picture of what they want (after work has started) they expect the project to accommodate such. If the cost of the project was determined based on the initial scope then it becomes very hard to convince the client to pay more.

Based on the fact that custom software development is actually a process of discovery and building, the cost of any project is best based on time. Software development agencies will need to know how much is needed to keep the team running for say a month and let the client invest funds into getting them to work for a defined period of time. Within this period of time, the agency works on whatever the client feels is of the highest priority to them.

Cost estimation techniques should not be confused with software development methodologies. For example a client can pay for 12 weeks worth of development time and the agency applies a waterfall software development methodology in developing the solution. Also note that certain approaches to building software work best with certain techniques for cost estimation. In my opinion, Agile software development methodology works best with cost estimates based on time.