It is important to point out a possible conflict of interest that may come up if a custom software vendor does work for two customers who compete with each other. That conflict of interest can occur if one customer pays the vendor to develop a software solution and then the other customer who competes with the first customer asks for a very similar solution. In that case, is it ethical to provide the same code to the second customer, possibly at a discounted rate, when the first customer paid full price for that code?
This is particularly prevalent in software development because a vendor may be hired specifically they have expertise in a particular industry. In fact many software vendors, the smaller ones in particular, specialize in particular industries. Such vendors are almost bound to run into potential conflicts such as this.
A more complicated problem occurs if the software vendor assisted in developing the specifications for the solution. What happens if the vendor helps one customer devise some ingenious and innovative idea that provides that customer with a competitive advantage? Is the vendor allowed to suggest any aspect of that idea to a competitor of that first customer?
The answer: clearly not.
How do you avoid such conflicts? Some customers may request that the vendor sign a legally binding contract preventing them working with competitors, at least over some well-defined time period. In that case it is not a problem.
But if the vendor is, in fact, presented with this problem, I believe that there is only one solution. That solution is to prevent the same project managers, programmers and engineers from working for both customers.
If you instruct the technical staff to avoid discussing such ideas, you’re putting them into a very difficult and possibly impossible situation. How do you separate generic technical ideas from specific ideas?
So the only answer – separate your technical staff into different groups for each competitor.
Note that this is not necessary if the customers are not competitors. I worked for a company that provided ID card solutions. Some of the ideas that were developed for issuing employee ID cards for a telecommunications company were used for a large bank. Some enhancements paid for the large bank were proposed to the telecommunications company. Both companies benefited and neither company paid for any code development that also helped a competitor.
Tuesday, May 12, 2009
Friday, May 8, 2009
Who owns the source code?
For the non-technical reader, the “source code” can be one file but much more often multiple computer files containing text from which the binary files (consisting really of just ‘1’s and ‘0’s recognized by the computer) are created. This “text” is really, of course, the computer program itself. It is written following strict rules of syntax based on the particular language selected for developing the program. Though the source code files contain text, and can generally be read with Notepad or other text reader programs, they are not generally simple text files and are typically accessed only through the software development environment.
The binary files created from these program files are what the computer actually executes. Anyone who has the source code and the appropriate software development tools (primarily a compiler) can recreate the binary code that makes up the solution.
In summary, the “source code” provides in a human readable form the intellectual property that the software vendor is providing to the customer.
So the question of “who owns the source code” could be rephrased as “who owns the intellectual property”.
This question is relevant to any discussion of the reusability of custom software code.
Equally clearly this is not an issue with standard software programs. In those cases, the vendor pays for the development of the software so they own the intellectual property and, therefore, they own the source code. (Obviously I am ignoring open source code programs with that statement.)
But in the case of a custom software development project, the issue is a bit more complicated. In such cases the customer is paying for the custom code that is being developed. So shouldn’t they have a right to a copy of that code?
If you buy a custom-designed house directly from an architect, you are surely allowed to have a copy of the blueprints!
In my mind, the answer is “Yes!” The customer does have a right to a copy of the source code. I ran my own consulting company for a number of years and I never hesitated to give any customer who asked a copy of the source code that I developed. (I was only asked once to do so.)
While this is my opinion, other custom software developers have a different view.
It is important to note that there are some inherent dangers and genuine complications in giving this code to the customer.
The first danger is that the customer may make changes to the program, unknown to the vendor, but still expect the vendor to support it.
I personally saw an example of this.
In the early 1980’s, I provided consulting support for a number of small companies. That was back in the computer Dark Ages when personal computers were first becoming generally available. Much of what I provided used a program called dBase III. That program was “interpreted” meaning that it was compiled into ‘1’s and ‘0’s as it ran (during ‘run-time’). There are multiple disadvantages to such programs (including needing to purchase a copy of the dBase program for every workstation and the fact that such programs run much slower). But the biggest disadvantage of such programs, relative to the current discussion, is that the source code is readily available to the user (as long as they know a few basic rules about how to access it).
If they have access to it – then they can change it.
I had a customer call and complain about a problem that they were having with one of the programs that I wrote. I stopped into their office to fix it. I quickly found that someone had modified the source code that I provided! It was those modifications that weren’t working. I found out why they wanted those changes and repaired the program appropriately.
In a large corporate environment, there is a clear and present danger in allowing the customer to make such changes. Fortunately, most customers understand these dangers and don’t have any more desire than the vendor to allow such changes by the customer’s representatives. Moreover this sort of problem tends to be easy to spot (the size of and the date-and-time stamp on the binary files will be different, for example). In addition, I can’t imagine a customer who would argue with a vendor who billed for fixing a problem caused by someone working for the customer who modified the program.
A second potential danger in providing the customer with a copy of the source code is that you are possibly enabling the customer to become a competitor of yours. The customer can potentially take what you wrote and resell it, possibly making small changes as they do so but still using the intellectual property that the vendor created as the basis for what they sold. I believe this danger to be minimal. People interested in such custom software are probably people who compete with the customer who has the original code. The customer is unlikely to wish to enable their competitors.
But this possibility, however unlikely it is, can be handled by contract terms within the contract agreed to between the customer and the vendor.
A third problem is that the source code will generally include reused code that was developed initially for another customer. In that case portions of the source code were paid for by other customers. So if you provide all of the code for the customer, it is likely that you are giving the customer intellectual property that they didn’t pay for.
Once again, there is a solution. It takes a bit more work, but the source code that the customer did not pay for can be provided in a binary form rather than in the original source code form.
A final problem is that the source code can be given to another vendor and that vendor can take over the development and support of the program. Again I consider this to be a relatively small danger. The original vendor is bound to be much more familiar with that source code and should, therefore, be able to be very competitive with anything that any other vendor could provide.
But clearly there are dangers and complications in providing this source code to the customer. That is why many vendors believe that the customer should NOT be given that code.
But there is a legitimate reason for the customer to want a copy of the source code is that there is a dangerous situation: the customer needs to have some reassurance that their program can be modified if the vendor goes out of business.
How do you handle that situation?
There are companies that provide the ability to put the source code into escrow. The source code is hidden until (and unless) the vendor gets out of the business.
There is a cost associated with this. That cost should be built into the quotation provided to the customer.
The biggest danger of such escrow accounts that I have witnessed is that while the initial solution is safely put into escrow, any updates are not necessarily included. It should be the responsibility of the project manager to make sure that all updates are put into escrow if such an account has been established for a particular customer.
The binary files created from these program files are what the computer actually executes. Anyone who has the source code and the appropriate software development tools (primarily a compiler) can recreate the binary code that makes up the solution.
In summary, the “source code” provides in a human readable form the intellectual property that the software vendor is providing to the customer.
So the question of “who owns the source code” could be rephrased as “who owns the intellectual property”.
This question is relevant to any discussion of the reusability of custom software code.
Equally clearly this is not an issue with standard software programs. In those cases, the vendor pays for the development of the software so they own the intellectual property and, therefore, they own the source code. (Obviously I am ignoring open source code programs with that statement.)
But in the case of a custom software development project, the issue is a bit more complicated. In such cases the customer is paying for the custom code that is being developed. So shouldn’t they have a right to a copy of that code?
If you buy a custom-designed house directly from an architect, you are surely allowed to have a copy of the blueprints!
In my mind, the answer is “Yes!” The customer does have a right to a copy of the source code. I ran my own consulting company for a number of years and I never hesitated to give any customer who asked a copy of the source code that I developed. (I was only asked once to do so.)
While this is my opinion, other custom software developers have a different view.
It is important to note that there are some inherent dangers and genuine complications in giving this code to the customer.
The first danger is that the customer may make changes to the program, unknown to the vendor, but still expect the vendor to support it.
I personally saw an example of this.
In the early 1980’s, I provided consulting support for a number of small companies. That was back in the computer Dark Ages when personal computers were first becoming generally available. Much of what I provided used a program called dBase III. That program was “interpreted” meaning that it was compiled into ‘1’s and ‘0’s as it ran (during ‘run-time’). There are multiple disadvantages to such programs (including needing to purchase a copy of the dBase program for every workstation and the fact that such programs run much slower). But the biggest disadvantage of such programs, relative to the current discussion, is that the source code is readily available to the user (as long as they know a few basic rules about how to access it).
If they have access to it – then they can change it.
I had a customer call and complain about a problem that they were having with one of the programs that I wrote. I stopped into their office to fix it. I quickly found that someone had modified the source code that I provided! It was those modifications that weren’t working. I found out why they wanted those changes and repaired the program appropriately.
In a large corporate environment, there is a clear and present danger in allowing the customer to make such changes. Fortunately, most customers understand these dangers and don’t have any more desire than the vendor to allow such changes by the customer’s representatives. Moreover this sort of problem tends to be easy to spot (the size of and the date-and-time stamp on the binary files will be different, for example). In addition, I can’t imagine a customer who would argue with a vendor who billed for fixing a problem caused by someone working for the customer who modified the program.
A second potential danger in providing the customer with a copy of the source code is that you are possibly enabling the customer to become a competitor of yours. The customer can potentially take what you wrote and resell it, possibly making small changes as they do so but still using the intellectual property that the vendor created as the basis for what they sold. I believe this danger to be minimal. People interested in such custom software are probably people who compete with the customer who has the original code. The customer is unlikely to wish to enable their competitors.
But this possibility, however unlikely it is, can be handled by contract terms within the contract agreed to between the customer and the vendor.
A third problem is that the source code will generally include reused code that was developed initially for another customer. In that case portions of the source code were paid for by other customers. So if you provide all of the code for the customer, it is likely that you are giving the customer intellectual property that they didn’t pay for.
Once again, there is a solution. It takes a bit more work, but the source code that the customer did not pay for can be provided in a binary form rather than in the original source code form.
A final problem is that the source code can be given to another vendor and that vendor can take over the development and support of the program. Again I consider this to be a relatively small danger. The original vendor is bound to be much more familiar with that source code and should, therefore, be able to be very competitive with anything that any other vendor could provide.
But clearly there are dangers and complications in providing this source code to the customer. That is why many vendors believe that the customer should NOT be given that code.
But there is a legitimate reason for the customer to want a copy of the source code is that there is a dangerous situation: the customer needs to have some reassurance that their program can be modified if the vendor goes out of business.
How do you handle that situation?
There are companies that provide the ability to put the source code into escrow. The source code is hidden until (and unless) the vendor gets out of the business.
There is a cost associated with this. That cost should be built into the quotation provided to the customer.
The biggest danger of such escrow accounts that I have witnessed is that while the initial solution is safely put into escrow, any updates are not necessarily included. It should be the responsibility of the project manager to make sure that all updates are put into escrow if such an account has been established for a particular customer.
Friday, May 1, 2009
Code Reusability in Custom Software Projects
Without doubt the most appealing economic reason to get into the software development business is the extremely low cost of reproducing your product compared to the potential selling price.
An excellent example is the first significant database program for PCs – “dBase”.
In the mid-1980’s, a company called Ashton-Tate sold a version of their database management program called “dBase III-Plus”. The program was so popular that within a short time the company was able to write off all of their development costs. At that time, the manufacturer was receiving something like $325 per copy from dealers.
But because the development costs had been fully depreciated, their cost to produce each copy consisted of the cost of a box, a manual, a few floppy disks (yes, floppy disks) and for every few thousand new users probably a new technical support person. Total cost for producing each copy, probably about $25.
If your cost to produce something is $25 (or so) and you can sell it for $325, you are basically printing money.
Which is what we all want to do. I don’t have access to Microsoft’s costs but they undoubtedly have some software products that are in the same category.
But dBase was a “standard” product, not a custom software solution. Can similar things be done with custom software?
Partially, yes - you can do some of the same things. But it is much more difficult. Furthermore, the key word is “similar”. You can never do exactly the same thing for two different customers.
Probably the best examples showing the problems are the various Enterprise Resource Planning (ERP) systems that have developed. If you are unfamiliar with ERP software packages they basically run the company when they are fully implemented. They do no less than control all of the resources, information, and functions of the business.
The most well-known vendors for such software packages are Oracle, SAP and a few others. Those companies provide “standard packages”. But all of those packages require customization because no two companies work with identical processes and types of information.
What is the cost to customize it?
In nearly every case it is more than the cost of the basic package itself. Here’s a summary from Wikipedia:
“For most mid-sized companies, the cost of the implementation will range from around the list price of the ERP user licenses to up to twice this amount (depending on the level of customization required). Large companies, and especially those with multiple sites or countries, will often spend considerably more on the implementation than the cost of the user licenses -- three to five times more is not uncommon for a multi-site implementation[1].”
Any sort of custom software works in the same way.
However there is a difference in complexity. Existing companies, of necessity, already have functions, data and resources and processes built around those.
A new custom software package performing a completely new function within a company won’t have to be integrated with existing processes. In many cases, there will be fewer changes.
But you should expect that there will be some amount of customization. The reason that the customer is buying a custom software package in the first place is so that they can get something that matches, as closely as possible, the way that the company wishes to operate.
Some managers within software development companies don’t recognize that solutions delivered for different customers should always expect to be different from each other.
It is always a good idea to have managers responsible for developing custom software to have custom software development experience themselves. But that is not always the case.
Some such managers only have experience working on standard software development. That, by definition, does not require customization.
Other managers, surprisingly, have no software development experience.
But all of those managers have their eyes on the ultimate prize: the dBase example given above; reselling something for more than ten times its cost.
Furthermore, the extent to which you are going to develop reusable code is the extent to which you need to do market research on the features that should be included in the basic part of the product. When you are developing the initial database design and other features it is a good idea to have the final goal in mind.
As is the case with any business, it is important to understand the market and the product that you are selling.
Here is a true story example of how not to do it.
I worked for a company that developed systems using plastic cards. One set of applications for plastic cards are loyalty programs (like the airline “frequent flier” programs). If you reward people for using your products and services they will tend to prefer your products and services over those of a competitor that doesn’t offer rewards.
It turns out that even hospitals might have a reason to use such a program. I won’t go into the details except to say that such programs can be effective when dealing with expectant mothers in particular.
One sales person for this company recognized the existence of this market. He suggested a plan for developing such a system.
First, we would deliver a system at cost for one customer.
Second, we would deliver additional, identical systems at 50% of cost to other customers. With little or no development costs for those additional systems, we should make significant profits.
Right?
The problem was that we developed the first system while only talking to that first customer. We never had any discussions with the second customer. Then when we dealt with the second customer, that customer wanted something quite different. The applications were only similar at a high level. In fact, probably only about 60% of the code that we developed for the first customer was reusable in the application developed for the second customer.
That’s not an insignificant percentage. But it was still well below the expectations of the managers of the company where I worked. Simply put, the second project lost money because the cost of developing the application for the second customer far exceeded their expectations. So they lost interest in continuing down that path.
My guess is that if they would have sold the application to a third customer, the percentage of code that could have been reused might have been around 80%. Then it would have been continuously higher for each additional customer as new features were added by each new customer. In the long run it might have been a successful strategy.
The primary problems were that the sales people were not familiar with the specifics of what the customers wanted and that the managers were not familiar with custom software development. The managers were used to selling “boxes” – hardware. That’s not changeable. They didn’t understand that customers purchase custom software precisely because it is changeable.
[1] http://en.wikipedia.org/wiki/Enterprise_resource_planning, referenced on March 26, 2009
An excellent example is the first significant database program for PCs – “dBase”.
In the mid-1980’s, a company called Ashton-Tate sold a version of their database management program called “dBase III-Plus”. The program was so popular that within a short time the company was able to write off all of their development costs. At that time, the manufacturer was receiving something like $325 per copy from dealers.
But because the development costs had been fully depreciated, their cost to produce each copy consisted of the cost of a box, a manual, a few floppy disks (yes, floppy disks) and for every few thousand new users probably a new technical support person. Total cost for producing each copy, probably about $25.
If your cost to produce something is $25 (or so) and you can sell it for $325, you are basically printing money.
Which is what we all want to do. I don’t have access to Microsoft’s costs but they undoubtedly have some software products that are in the same category.
But dBase was a “standard” product, not a custom software solution. Can similar things be done with custom software?
Partially, yes - you can do some of the same things. But it is much more difficult. Furthermore, the key word is “similar”. You can never do exactly the same thing for two different customers.
Probably the best examples showing the problems are the various Enterprise Resource Planning (ERP) systems that have developed. If you are unfamiliar with ERP software packages they basically run the company when they are fully implemented. They do no less than control all of the resources, information, and functions of the business.
The most well-known vendors for such software packages are Oracle, SAP and a few others. Those companies provide “standard packages”. But all of those packages require customization because no two companies work with identical processes and types of information.
What is the cost to customize it?
In nearly every case it is more than the cost of the basic package itself. Here’s a summary from Wikipedia:
“For most mid-sized companies, the cost of the implementation will range from around the list price of the ERP user licenses to up to twice this amount (depending on the level of customization required). Large companies, and especially those with multiple sites or countries, will often spend considerably more on the implementation than the cost of the user licenses -- three to five times more is not uncommon for a multi-site implementation[1].”
Any sort of custom software works in the same way.
However there is a difference in complexity. Existing companies, of necessity, already have functions, data and resources and processes built around those.
A new custom software package performing a completely new function within a company won’t have to be integrated with existing processes. In many cases, there will be fewer changes.
But you should expect that there will be some amount of customization. The reason that the customer is buying a custom software package in the first place is so that they can get something that matches, as closely as possible, the way that the company wishes to operate.
Some managers within software development companies don’t recognize that solutions delivered for different customers should always expect to be different from each other.
It is always a good idea to have managers responsible for developing custom software to have custom software development experience themselves. But that is not always the case.
Some such managers only have experience working on standard software development. That, by definition, does not require customization.
Other managers, surprisingly, have no software development experience.
But all of those managers have their eyes on the ultimate prize: the dBase example given above; reselling something for more than ten times its cost.
Furthermore, the extent to which you are going to develop reusable code is the extent to which you need to do market research on the features that should be included in the basic part of the product. When you are developing the initial database design and other features it is a good idea to have the final goal in mind.
As is the case with any business, it is important to understand the market and the product that you are selling.
Here is a true story example of how not to do it.
I worked for a company that developed systems using plastic cards. One set of applications for plastic cards are loyalty programs (like the airline “frequent flier” programs). If you reward people for using your products and services they will tend to prefer your products and services over those of a competitor that doesn’t offer rewards.
It turns out that even hospitals might have a reason to use such a program. I won’t go into the details except to say that such programs can be effective when dealing with expectant mothers in particular.
One sales person for this company recognized the existence of this market. He suggested a plan for developing such a system.
First, we would deliver a system at cost for one customer.
Second, we would deliver additional, identical systems at 50% of cost to other customers. With little or no development costs for those additional systems, we should make significant profits.
Right?
The problem was that we developed the first system while only talking to that first customer. We never had any discussions with the second customer. Then when we dealt with the second customer, that customer wanted something quite different. The applications were only similar at a high level. In fact, probably only about 60% of the code that we developed for the first customer was reusable in the application developed for the second customer.
That’s not an insignificant percentage. But it was still well below the expectations of the managers of the company where I worked. Simply put, the second project lost money because the cost of developing the application for the second customer far exceeded their expectations. So they lost interest in continuing down that path.
My guess is that if they would have sold the application to a third customer, the percentage of code that could have been reused might have been around 80%. Then it would have been continuously higher for each additional customer as new features were added by each new customer. In the long run it might have been a successful strategy.
The primary problems were that the sales people were not familiar with the specifics of what the customers wanted and that the managers were not familiar with custom software development. The managers were used to selling “boxes” – hardware. That’s not changeable. They didn’t understand that customers purchase custom software precisely because it is changeable.
[1] http://en.wikipedia.org/wiki/Enterprise_resource_planning, referenced on March 26, 2009
Wednesday, April 29, 2009
Margin Analysis during Quotes
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.
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.
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.
Thursday, March 26, 2009
Estimating Tasks for the Project Plan
Once the initial project plan is completed with tasks listed, it is time to estimate the time required for the implementation.
First, you should have the people who will performing the various tasks estimate the time required for those tasks. In most cases, because the majority of the tasks involve software development, it will be the programmers who will be making the quotes for the majority of those tasks.
In any case, the best estimate for each task comes from the person who will be performing that task. Clearly they will be best able to evaluate the amount of time required for that task.
But there is another benefit. If you get the estimate for the amount of time to complete the task from the person who will actually perform the task, then you get an implicit commitment from that person to perform the task in that amount of time. On the other hand, if someone else (such as the project manager) estimates the amount of time required for a particular task but that estimate turns out to be too low, the programmer won’t have the same level of commitment. In that case, after all, it is only someone else’s quotation.
In some, probably many cases, you won’t know at the time of the quote who will be performing a particular task. In that case I recommend having the functional manager quote the tasks. When you do that you are at least getting a commitment from the manager of the person who will have to perform the task. If you can’t get either one, then do the best you can. But build some contingency into the schedule.
I recommend that all task estimates should INITIALLY be made as though they had to be performed from scratch, even though in some cases you may be duplicating something that has already been done. Assuming that everything is done from scratch gives you the worst-case scenario. Note that it is still important to factor in risk and make other adjustments. I talk about those later.
First, you should have the people who will performing the various tasks estimate the time required for those tasks. In most cases, because the majority of the tasks involve software development, it will be the programmers who will be making the quotes for the majority of those tasks.
In any case, the best estimate for each task comes from the person who will be performing that task. Clearly they will be best able to evaluate the amount of time required for that task.
But there is another benefit. If you get the estimate for the amount of time to complete the task from the person who will actually perform the task, then you get an implicit commitment from that person to perform the task in that amount of time. On the other hand, if someone else (such as the project manager) estimates the amount of time required for a particular task but that estimate turns out to be too low, the programmer won’t have the same level of commitment. In that case, after all, it is only someone else’s quotation.
In some, probably many cases, you won’t know at the time of the quote who will be performing a particular task. In that case I recommend having the functional manager quote the tasks. When you do that you are at least getting a commitment from the manager of the person who will have to perform the task. If you can’t get either one, then do the best you can. But build some contingency into the schedule.
I recommend that all task estimates should INITIALLY be made as though they had to be performed from scratch, even though in some cases you may be duplicating something that has already been done. Assuming that everything is done from scratch gives you the worst-case scenario. Note that it is still important to factor in risk and make other adjustments. I talk about those later.
Subscribe to:
Comments (Atom)