Software Pricing and Software Risk
Most of software created today is bespoke software. Code that runs in one organisation and is never resold or passed on (and sadly hardly reused). This entry is about pricing the creation of bespoke software. It is not about pricing of standard software. That is a topic others have to fight over. So what pricing models are out there? We make the simplifying assumption, that you have an idea what effort is required and that we can ignore market forces (like: "this is the price we pay for this service here").
At the two ends of the models are "time and material (TM)" and "turn key projects (TKP)". TM is the delivery model corporate developers typically work with (yes there are cost centers, so it might be different in your company), while TKP is the sole model used when software projects are tendered out.
In a TM model finding the price is pretty easy: effort + profit margin = price (remember we exclude the market forces in this examples).
The calculation is simple, since any change in requirement, any unforeseen complication just leads to more billable hours. Everyone loves this model... except the customer. In this model 100% of the risk is on the shoulders of the project sponsor. Naturally project sponsors or customer want to limit the risk. So they push for fixed deliverables and turn key pricing. This seems to be a sensible approach. However the way a contractor is calculating the price of the software becomes very different. First: the internal pricing is always TM since you pay your staff a monthly salary. So when accepting a TKP there is a substantial added risk that the contractor has to bear. Risk translates to money. So the calculation suddenly looks like this:
While it looks like that the profit margin took a dent, typically the risk margin is added to the project costing (especially when it is an internal cost center). So the real picture looks more like this:
Since Risks can be expensive both sponsor and customer try to minimize the risk. The usual approach is to flesh out detailed specifications what needs to be done, what is included and what is out. These specification then are the ultimate benchmark to decide if the contractor has fulfilled the obligations and gets paid. In other words: the system is completely specified before work commences. With some notable exceptions it is consensus, that big up-front design doesn't work. This insight hasn't reached the teams that design tender specifications. In my personal experience: the systems users appreciated most when delivered where the ones that had the least in common with the original design specifications (but that might have been just my dumb luck
).
Update: Jesse Davidson from Madberry.com notified me about the demise of stsc.hill.af.mil and shared the Background story. Interesting read!
Let us stay for a while with the fiction that you could specify a system up-front. There are more ugly things at work. Specifications typically have different levels of requirements expressed in the language of the specs. So we have "should", "shall", "must/must not", "guaranteed". On the sponsor site there is a tendency to demand strong guarantees for the work to be delivered. There is a strong urge to be very specific. This has two very nasty effects: first it stifles agility/flexibility. If in the due course of a project a detail requirement turns out to be obsolete, irrelevant, contra-productive it can't be removed without rewriting the contract. Secondly it increases project risk and therefore project cost (if everything goes well the vendor will be very happy, since a non materialized risks adds 100% to the profit). A very typical mis-perception is: the more detailed a specification is, the less risk occurs. The reality is quite different. In a recent requirement document was stated "reports must in 95% of the cases open within 8 sec". It is as precise as it can get. The engagement manager slapped a huge risk factor on it: he had no performance data available that could guarantee him that the reporting tool (mandated by the client) can do that with the estimated amount of data. So he set aside a lot of time for code that pre-computes the reports, so this requirement could be met. The business users actually wouldn't care. They want the few reports they use every day very fast and would be quite happy to wait longer for the other stuff as long as they can continue working with something else until the report is completed. So a spec "response time optimized for the flow of work, operations that take longer should be able to run in the background" would have added more business value and lowered the risk.
So at a certain point adding details to a specification will make the software more expensive.
The relation between detailed specification and risk in real life systems looks more like an inverted bell curve (but my mastery of graphic software is still limited).
So Instead of detailing the features and deliverables up-front and heading down Niagara, what can be done?
Well. I'm a strong believer in craftsmanship and compassion. For me the Agile Manifesto has an answer. But how to squeeze that into a tender process or a fixed price bid? Seems impossible isn't it? With a little leap of faith however it can be accomplished. First would stand the insight, that software development is a communication exercise (or as Alistair puts it: a cooperative game), that needs to go through multiple iterations. A contract could specify the overall goal for the system (e.g. storage and retrieval of warehouse information) and the business drivers. It could then map out the known assumptions and the known unknowns.
Then instead of specifying the features it would specify the process: Work artefacts, communication structures, release cycles etc. As safety valves the process could have exit clauses for one or both parties at the end of an iteration. Every iteration would verify or alter the system assumptions to stay current.
There are quite some resources out to get started. Here is a small selection:
At the two ends of the models are "time and material (TM)" and "turn key projects (TKP)". TM is the delivery model corporate developers typically work with (yes there are cost centers, so it might be different in your company), while TKP is the sole model used when software projects are tendered out.
In a TM model finding the price is pretty easy: effort + profit margin = price (remember we exclude the market forces in this examples).
The calculation is simple, since any change in requirement, any unforeseen complication just leads to more billable hours. Everyone loves this model... except the customer. In this model 100% of the risk is on the shoulders of the project sponsor. Naturally project sponsors or customer want to limit the risk. So they push for fixed deliverables and turn key pricing. This seems to be a sensible approach. However the way a contractor is calculating the price of the software becomes very different. First: the internal pricing is always TM since you pay your staff a monthly salary. So when accepting a TKP there is a substantial added risk that the contractor has to bear. Risk translates to money. So the calculation suddenly looks like this:
While it looks like that the profit margin took a dent, typically the risk margin is added to the project costing (especially when it is an internal cost center). So the real picture looks more like this:
Since Risks can be expensive both sponsor and customer try to minimize the risk. The usual approach is to flesh out detailed specifications what needs to be done, what is included and what is out. These specification then are the ultimate benchmark to decide if the contractor has fulfilled the obligations and gets paid. In other words: the system is completely specified before work commences. With some notable exceptions it is consensus, that big up-front design doesn't work. This insight hasn't reached the teams that design tender specifications. In my personal experience: the systems users appreciated most when delivered where the ones that had the least in common with the original design specifications (but that might have been just my dumb luck
).
Update: Jesse Davidson from Madberry.com notified me about the demise of stsc.hill.af.mil and shared the Background story. Interesting read!
Let us stay for a while with the fiction that you could specify a system up-front. There are more ugly things at work. Specifications typically have different levels of requirements expressed in the language of the specs. So we have "should", "shall", "must/must not", "guaranteed". On the sponsor site there is a tendency to demand strong guarantees for the work to be delivered. There is a strong urge to be very specific. This has two very nasty effects: first it stifles agility/flexibility. If in the due course of a project a detail requirement turns out to be obsolete, irrelevant, contra-productive it can't be removed without rewriting the contract. Secondly it increases project risk and therefore project cost (if everything goes well the vendor will be very happy, since a non materialized risks adds 100% to the profit). A very typical mis-perception is: the more detailed a specification is, the less risk occurs. The reality is quite different. In a recent requirement document was stated "reports must in 95% of the cases open within 8 sec". It is as precise as it can get. The engagement manager slapped a huge risk factor on it: he had no performance data available that could guarantee him that the reporting tool (mandated by the client) can do that with the estimated amount of data. So he set aside a lot of time for code that pre-computes the reports, so this requirement could be met. The business users actually wouldn't care. They want the few reports they use every day very fast and would be quite happy to wait longer for the other stuff as long as they can continue working with something else until the report is completed. So a spec "response time optimized for the flow of work, operations that take longer should be able to run in the background" would have added more business value and lowered the risk.
So at a certain point adding details to a specification will make the software more expensive.
The relation between detailed specification and risk in real life systems looks more like an inverted bell curve (but my mastery of graphic software is still limited).
So Instead of detailing the features and deliverables up-front and heading down Niagara, what can be done?
Well. I'm a strong believer in craftsmanship and compassion. For me the Agile Manifesto has an answer. But how to squeeze that into a tender process or a fixed price bid? Seems impossible isn't it? With a little leap of faith however it can be accomplished. First would stand the insight, that software development is a communication exercise (or as Alistair puts it: a cooperative game), that needs to go through multiple iterations. A contract could specify the overall goal for the system (e.g. storage and retrieval of warehouse information) and the business drivers. It could then map out the known assumptions and the known unknowns.
Then instead of specifying the features it would specify the process: Work artefacts, communication structures, release cycles etc. As safety valves the process could have exit clauses for one or both parties at the end of an iteration. Every iteration would verify or alter the system assumptions to stay current.
There are quite some resources out to get started. Here is a small selection:
- Alistair Cockburn and the Crystal Clear method (I blogged about it before)
- Agile Estimating and Planning
- An Agile road map.
- Charts, Charts, Charts
Posted by Stephan H Wissel on 01 September 2007 | Comments (1) | categories: Software