The single most important thing to know before creating a quote is the actual number of hours that will be needed to complete the development and implementation. (You also need to know the cost of anything else that is needed to complete the project for the customer.) I have already discussed all of the various factors to use when finding those hours. Note that any contingencies due to risk should be recognized and included in this initial cost evaluation. If there are risks and associated costs that would be present if they become actual issues, then they should be factored in as costs at the initial cost evaluation.
The project manager has the ultimate responsibility for the accuracy of the estimated cost of the project.
Once you are confident that you know the actual costs of developing the solution, you then need to consider the other factors involved in developing the actual price that you quote the customer.
Let us look at those factors.
First of all, each company should have a business model that they have developed indicating the profit level that they expect from their custom software projects. One such marginal profit level that I worked with at one company is 50%. In other words, when you made an estimate for that company, you took the estimated cost and doubled it and used that value as the estimated price to charge the customer. In the simplest scenario, you simply apply the business model multiplier to your costs and – voila – you have your price quote.
A second factor to consider is whether or not some profit will be made from the sale of equipment (hardware) or other things such as service that would be associated with the use of the custom software. Based on my own personal experience, there are tines when this is important.
One company for which I managed custom software development projects made 90% of its revenue and well over 90% of its profit from equipment and not from software. At that company I worked on some projects where $100,000 software costs could produce $1 million of hardware revenue with profits well in excess of $100,000. In such cases, a good business argument could be made to “give” the software away as sort of a “loss leader” since the company ends up with a net profit. (Hardware profits are also much more reliable than the profits on custom software development projects.)
A third factor is that for custom software, often the amount of revenue received for enhancements can far exceed the initial development cost. I have seen estimates stating that, in many cases, the customer’s cost for the initial software development may be only 10% of the total investment in that software product over the life time of that product.
That’s been my own experience as well. I worked for a few years as a self-employed consultant. I wrote a program for a consulting (head hunter) firm to do their payroll. I charged $2000 for that initial development. (It was a very long time ago.) Over the next four years I billed that customer for more than $50,000 for enhancements to that program. It ended up doing much more than payroll. But in that case the ratio of the initial software development revenue to the final revenue was a bit more than 1:25.
While I don’t believe that it makes sense to give the initial software away, you should still consider the extent to which it can be expected to lead to future revenue due to enhancements.
The reason that the customer bought custom software is to have the software support the way that they run their business. Over time businesses change the way that they run. The extent to which the software that you developed supports their business is the precise extent to which the software will have to be enhanced as the customer’s business changes and, hopefully, grows.
This is a key consideration. Back when I was self-employed, I initially did a lot of things to find new customers. Eventually I found 33 customers for which I did billable work. However after about two years I found that I could keep busy by merely fielding requests from those customers for enhancements to the software that I had developed.
It’s important to remember that because it is custom software, the only vendor that the customer can effectively go to for enhancements is the original developer. Even if the customer has a copy of that source code (a subject that I discuss elsewhere) the original developers are the ones who understand it best. So there can be little doubt that they can do the best job of modifying it. Even if the original quote was competitive, quotes for enhancements won’t be.
The extent to which this should be a factor is dependent on the extent to which the software is used on a day-to-day basis. Things like ERP programs are constantly used and will be undergoing constant enhancements. At the other extreme a program that is used rarely, possibly as infrequently as once a year, and then only affects a small group of individuals probably will have very few, if any, enhancements added.
A final consideration is whether a particular customer has an idea for a software program that other customers might be interested in. This should only be a consideration if the vendor has a good marketing department that can do legitimate research into such issues. But in such cases working with a customer to develop a very useful program would make developing a similar piece of software for other customers much easier. In my experience this is the most problematic consideration. But it deserves discussion.
In summary, when establishing a price for a custom software solution the process should be:
Define the requirements in detail.
1. Develop the best possible cost estimate, factoring in risk and anything else that might affect that cost.
2. Apply the default profit margin.
3. Consider lowering the margin if extra revenue for hardware and service sales is likely.
4. Consider lowering the margin if the software is going to be a key piece of software used constantly by the customer. In that scenario the customer will probably pay much more for enhancements over time.
5. Consider lowering the margin if the software being developed has generic features that might make other customers interested in using something similar. This is the most problematic consideration and should only be done if the software development company really has a good marketing department.
All of the considerations should be well documented. It is good to keep a history of such quotes and use them to help evaluate other quotes that will be made in the future.
Wednesday, April 29, 2009
Friday, April 24, 2009
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.
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.
Wednesday, April 8, 2009
SMOP
"SMOP" is an acronym that I learned about early in my career. It stands for:
"Simply a Matter of Programming".
It highlights one of the major differences between hardware projects and software projects.
In just about any hardware project, a new enhancement or change inevitably involves some sort of extra payment to an outside company. If you are manufacturing vacuum cleaners and a customer asks for an exta long power cord, it's more than likely that you will have to purchase that cable from another manufacturer.
In other words, your company will have to write a check to another company.
Software development using an internal staff (which is nearly always the case, especially for custom development) isn't like that. In most cases it only involves having one or more programmers spend a few extra hours writing some more code and one or more testers testing that code. It's just a matter of SMOP - no purchases outside of the company are needed.
If, for example, the customer decides that they would like a new report, and the data needed for that report is already in the database, it might take only a day or so to add that report. Possibly it may take even less.
Customers know this as well as anyone.
What they will often do is actually talk to the individual programmers in order to try to get them to add such features. Such things are particularly common during an installation.
It is up to the Project Manager to make sure that the customer and the Project Manager's own managers don't allow this. Changes require change control. They must be paid for. If you don't do if for every single change then you will lose control.
A problem comes up because there is an administrative cost with documenting a change through the standard change control process. With some minor changes the cost to write up the change request, estimating the cost, having it approved and then updating the speciffication might exceed the cost of making the change itself. That is a solvable problem as well.
Just as companies open puchase blanket orders with vendors in order to allow a large number of smaller purchases without the normal administrative overhead, you can do a similar thing with software changes. You can have the customer agree to have a "blanket change" cost and track costs against that. If the entire budget is not spent, then the customer gets money back at the end of the project. If the "blanket" cost is exceeded then the customer needs to write another check. Even in this case the specific changes need to be tracked. At a minimum the specification for the project must be updated so that it accurately reflects the solution that was delivered.
It is important to emphasize that "bug fixes" don't fall into this category. If the specification for the project says that something must work in a particular way and the customer can demonstrate that it doesn't work that way, then the vendor is obligated to make it work that way at no additional charge.
But an enhancement is something that is different from what the spec says. All of those must be paid for.
The key point is to establish this understanding at the very beginning of the relationship between the vendor and the customer. The software developers need to understand this as well as the customer does.
If this is not understood by everyone, there is a very real possibility that the project will overrun its budget.
"Simply a Matter of Programming".
It highlights one of the major differences between hardware projects and software projects.
In just about any hardware project, a new enhancement or change inevitably involves some sort of extra payment to an outside company. If you are manufacturing vacuum cleaners and a customer asks for an exta long power cord, it's more than likely that you will have to purchase that cable from another manufacturer.
In other words, your company will have to write a check to another company.
Software development using an internal staff (which is nearly always the case, especially for custom development) isn't like that. In most cases it only involves having one or more programmers spend a few extra hours writing some more code and one or more testers testing that code. It's just a matter of SMOP - no purchases outside of the company are needed.
If, for example, the customer decides that they would like a new report, and the data needed for that report is already in the database, it might take only a day or so to add that report. Possibly it may take even less.
Customers know this as well as anyone.
What they will often do is actually talk to the individual programmers in order to try to get them to add such features. Such things are particularly common during an installation.
It is up to the Project Manager to make sure that the customer and the Project Manager's own managers don't allow this. Changes require change control. They must be paid for. If you don't do if for every single change then you will lose control.
A problem comes up because there is an administrative cost with documenting a change through the standard change control process. With some minor changes the cost to write up the change request, estimating the cost, having it approved and then updating the speciffication might exceed the cost of making the change itself. That is a solvable problem as well.
Just as companies open puchase blanket orders with vendors in order to allow a large number of smaller purchases without the normal administrative overhead, you can do a similar thing with software changes. You can have the customer agree to have a "blanket change" cost and track costs against that. If the entire budget is not spent, then the customer gets money back at the end of the project. If the "blanket" cost is exceeded then the customer needs to write another check. Even in this case the specific changes need to be tracked. At a minimum the specification for the project must be updated so that it accurately reflects the solution that was delivered.
It is important to emphasize that "bug fixes" don't fall into this category. If the specification for the project says that something must work in a particular way and the customer can demonstrate that it doesn't work that way, then the vendor is obligated to make it work that way at no additional charge.
But an enhancement is something that is different from what the spec says. All of those must be paid for.
The key point is to establish this understanding at the very beginning of the relationship between the vendor and the customer. The software developers need to understand this as well as the customer does.
If this is not understood by everyone, there is a very real possibility that the project will overrun its budget.
Subscribe to:
Comments (Atom)