Fixed Pricing Trouble Tickets
The way to look at production support and application maintenance is not to look for the end product but to look for the basic unit of repetitive work.
Now production support becomes easy to tackle.
Production support is driven by trouble tickets which need to be processed as per certain service level agreements.
Level 1 Tickets: Logged by end users. Processed by application Helpdesk operators. If Helpdesk operators are not able to resolve this using the resources available to them, they log a Level 2 ticket.
Level 2 Tickets: Logged by Helpsdesk operators. Processed by a support team that has in-depth knowledge of the application in question. If a code fix is required to resolve these tickets, a Level 3 ticket is logged.
Level 3 Tickets: Trouble tickets that requires a code fix for resolution.
Resolution of these trouble tickets are usually governed by service level agreements which prescribe specific time limits for carrying out various actions on these tickets.
A fixed price contract in this case would be a fixed price per ticket. The moment the contract is priced this way, the buyer is no longer leasing capacity but is now contracting for results!
Application maintenance is the hardest to tackle.
Application maintenance includes both code changes required to service Level 3 tickets as well as code changes required to implement enhancements to the application. The former can of course be priced on a per ticket basis. It is the latter that is troublesome.
Enhancements can come in all shapes and sizes. They could be as small as adding one extra field to a screen (and all changes cascading from that) to as large as 10000 person hours required for adding a major functionality. Hence, any fixed price for this need necessarily bound the scope in terms of effort; this is nothing by capacity leasing!
One alternative is to take advantage of the fact that application maintenance results in the delivery of new releases of the software. We can then go back to our original line of attack of focusing on the end product – in this case a new release. Each release can be treated as a application development engagement and fixed priced.
Trouble with this approach is a proliferation of contracts (many applications come out with 3 – 4 releases in a year). The process of estimating each release, obtaining a fixed price bid, getting budget approval, signing the contract so on and so forth is something that most customers are unwilling to subject themselve to. It makes sense to go with a capacity lease arrangement, with the option of asking for a temporary increase of capacity for some releases.
Another alternative, which works well for mature applications, is to provide the vendor with a history of enhancements over the past 2 – 3 years and then ask them to extrapolate that to arrive at a fixed price for future maintenance work (without any effort upper bound). This alternative is beginning to become popular with buyers as they see this as a clear way of transferring budget risks away from themselves on to the vendors. As the golbal economic deterioration advance, this approach is likely to become more and more popular.
Are there any factors that slow down the broader adoption of these fixed price models? I will discuss that question in my next post.
I guess the bigger players of the Indian IT are working on this and are coming out with what they call as “Value Based Pricing” or in simple terms “Pay-as-you-go” pricing model. I believe the more grave issue is how do these companies move up the value chain and from a mere a “Manpower Providers” to a “Solution provider” and start acting as a catalyst in its customers business growth.
There are multiple weighty terms you use here which need careful analysis:
“Value Based Pricing” means “my price is proportional to the value my service delivers to you”; the more the value the higher the price. This is also referred to as “outcome based pricing”.
“Pay-as-you-go” is very different and is focused on converting CapEx to OpEx. Cash flow is the primary consideration. This is more applicable to licensed software products. Indian software services have always been “pay-as-you-go”, i.e. monthly billing.
Viewed in this context, to become a “solution provider” one has to move from pay-as-you-go to outcome based pricing. That is the main argument of this series of posts.
As for “acting as a catalyst in customers business growth”, I feel it would be rather presumptuous of Indian IT guys to make this claim. While we can support business growth, the prime drivers for business growth are always the customer’s product/services combined with marketing & sales. We do not have first hand knowledge of either of these and that limits our effectiveness in driving out customer’s business growth.
I guess there is enough talking points here for a separate blog post! Thanks for triggering the thought process.
I am a little distant from the IT world and am currently dealing with a trasactional business process where I am seeking to implement a Fixed Price per month model. The challenge however is to define the end deliverable that will trigger payment. Do you have any suggestions?
For a transactional business process, transaction-based pricing (x dollars per transaction) is more appropriate than fixed price. This is because transaction volumes may vary month to month. Only if this variance is predictable (i.e. average monthly transaction volumes over the contract period is known and certain), you should consider fixed price. In that case, you would simply multiply average monthly transaction volume by rate per transaction to arrive at the fixed price per month. Some months you will loose and some months you will gain, but over the entire contract period you will make the topline and bottomline you desire.
In addition, you could consider taking a certain “success fee” as an outcome-based gain share. To illustrate “if we can improve your inventory turns by half a percent over 12 months (i.e. outcome), then we will take 10% of the resulting working capital reduction (i.e. gain share) as a success fee.” This success fee is over and above your transaction-based pricing and illustrates your skin-in-the-game.