Evaluating Risk during Custom Software Development Quotes

Risk is a bigger factor in custom software development than it is in standard software development projects. When developing a standard software product the vendor has determined which features are to be delivered as a part of the standard software program. If, during development, you discover that a particular feature becomes too difficult or expensive to develop, you can often remove if from the feature list that you had originally planned on delivering.

This isn’t true of every feature. There are some core features of standard software development projects which MUST be included if you want any sales at all. For example, if you promised to have the new software run on a particular operating system (maybe a new version of Windows from Microsoft) you can’t renege on that promise and, therefore, you will have to deliver that capability even if it takes quite a bit more time and effort than you originally expected. But many times other features, at least those which do not affect the core competencies of the program, can be removed from the feature list. This is something which has to be determined with the marketing team. There may be some disappointed customers who are expecting a particular feature, but it may not affect sales very much. Often with releases of standard software the release date is almost as important as the features that are included.

There is, very obviously, a limit to how much you can do this.

On the other hand, when developing a custom software project, especially if the customer is an external customer, you have made an explicit promise to deliver everything that is described in the SRS. There are no exceptions.

So how do you factor this into the cost quote? What are the risks?

First, the largest risk associated with custom software development is scope creep – additions to the scope of the project after the specification has been approved and the project estimated. Customers are buying custom software because they can’t get everything they want from any of the standard software packages available. So they expect to be able to customize the software such that it exactly matches their needs.

If you want a satisfied customer – and we all want that – we need to allow some variation to a project as it is installed. It’s effectively impossible to write an SRS in sufficient detail that the customer will be able to completely define the requirements. Also many of the sorts of changes that they will want to make may be trivial to implement.

For example, the customer may decide that they would like to use a slightly different character font for their error messages. That might take only a few minutes to implement. If the SRS, understandably, doesn’t go into the detail of specifying the font for those messages, how should you handle that?

The real problem is that this really is a “slippery slope” issue. If you allow one or two minor changes, the customer will continue to ask for more and more. Some of the changes may seem quite simple to the customer, but many will require serious testing. That testing takes time and costs money.

I worked for one company that was extremely strict about any changes. Even something that took but a few minutes to implement required that the full change order process be used. I never saw a customer who complained about that – but the customers had been “trained” to expect it. So that process works, at least in my own experience.

But as an engineer, I personally thought that it was inefficient. I hate inefficiencies.

To resolve this I recommend that you talk to the customer and get an understanding that some changes – many of them cosmetic - will be needed during implementation. You then add an agreed upon number of hours to the quote to cover those. But you keep track of the hours spent making such changes. If the time set aside for them is exceeded, you get an agreement to pay for more hours.

Alternatively, you can get an agreement from the customer to accept a bill for such changes on a Time and Materials basis after the implementation is completed. Note that all of those changes still need to be documented and tested appropriately. But such a system avoids the administrative costs of formally issuing quotes that might possibly also include numerous individual purchase orders and invoices.

The second factor to consider as a risk when quoting a custom software development project, is to recognize that programmers are optimistic. You should get your hourly quotes directly from them (because you get an implicit commitment when you do that) but I’ve never met a programmer who didn’t think that they couldn’t do something in less time than someone else would take. (I would actually be suspicious of any programmer that didn’t feel that way.) So a multiplier should be applied to the number of hours you are given by a programmer. Different programmers are more realistic (or less optimistic) than other programmers so once you’ve worked with a particular programmer and discovered their level of optimism you can “fine tune” your multiplier a bit. When you have no experience with a particular programmer, a good rule of thumb is to double the number of hours that you’re given.

Only in very rare cases will a programmer overestimate the amount of time required to develop a software program. The only exceptions I’ve seen have been when they find some previously developed code that they can use directly or that only takes minor modifications to use in the new app.

With that in mind, if you have the time to do so and/or if the quote is particularly important, as in a competitive bidding situation, it makes sense to look at the specification and compare it to previous projects that the same development team has worked on before. If there have been similar projects in the past, you can cut the multiplier you used on the hours down a bit because it is likely that they will be able to reuse some of the code.

You should always discuss the estimates with the functional manager of the programmers before formalizing them. Ultimately that manager (as well as the project manager) will be responsible for meeting the quote. The individual programmers are not held as responsible. Nor should they be.