If a service is novel and new (a potential differential, a source of competitive advantage) - then the market or potential is unknown (there are no other examples, whitepapers, case studies etc) and hence the likelihood for any sales or benefits is also relatively unknown.
There is a lot of uncertainty - it's novel and new.
Since you can describe the service roughly but you can't quantify the benefit easily, the tendency is to get several quotes for the system and then choose the lowest price with the supplier you feel most comfortable with.
What then tends to happen is the cost is used with the ROI required, to calculate what benefits the system must bring - often referred to as targets. As long as these seem comfortable and someone can magic up some data to support it then it's ok.
There are some massive problems with this approach:-
- The supplier is focused on delivering to a specification rather than delivering a product or service which generates the highest possible benefit.
- The client is focused on getting the product or service they specified at the lowest cost, without really knowing what the final end result needs to be. If it's a novel and new service then the process of development is also a process of discovery for the client in this new market.
- The calculated ROI based "worth" has little or no correlation to actual worth, it's a function of cost alone.
Tell tale signs of this are the vagueness of the specification, the inability of the client to specify likely usage of the service and a wandering focus in terms of functionality. However the problem here is not the client but that a static process is often being used to deal with a dynamic problem. The client invariably cannot specify the system upfront as they have little or no reference point to compare against - they can't say "give me something like they've got" or "one of those", they don't really know what it is.
The result is almost always the same :-
- Changing specification causing arguments between client and supplier over specification and rising cost.
- The system is either a major success - in which case the additional costs are soon forgotten about - or the system is mediocre or a failure, in which case a blame game often ensues.
Any blame game which does evolve generally centres around :-
- The client believes the supplier failed to deliver or be flexible
- The supplier believes the original idea was daft anyway (something they would never have built themselves) or the client kept changing the specification.
If none of the above is familiar to you, then I'll assume you either don't work in IT or business or you have never built anything new or you've been very lucky.
Modern approaches use much more dynamic techniques (agile development like XP and SCRUM) to deal with the uncertain elements of the functionality. Both techniques appreciate that this is a discovery like process for the client as well. However, both still focus on the delivery of a product rather than delivery of worth - which after all is what is supposed to be happening.
The reason for this is often because of the whole pricing structure and contract which is often in place between a supplier and client.
Now there is an alternative - worth based development (WBD) - which is something I've used heavily since 2002. It can work but it also has pitfalls. Under WBD you agree an arrangement where both the supplier and the client make money from the value the system generates - the cost of building and managing the system being borne by the supplier.
The conversation should constantly revolve around worth and ideally be :-
Client: "We'd like to build this system to sell widgets for $100, we reckon this will sell lots"
Supplier: "It's risky, the data looks good and ok we will build this and charge you $5 for each widget sold."
Supplier: "It's risky, the data looks good and ok we will build this and charge you $5 for each widget sold."
Client: "agreed"
Unfortunately it rarely works like this. First because the client needs to identify and agree a measure of worth (which businesses generally are pretty poor at) and provide figures to justify this measure and second because the supplier needs to be satisfied of the risks and upside involved and of the commitment of the client to make this work.
From my experience the conversation often tends to be one of the following :-
The ROI gambit
Client: "We'd like to do this thing"
Supplier: "How will it make money or create value?"Client: "Can you tell me how much it will cost to build it?"
Supplier: "Do you know how it will make money or create value?"
Client: "Can you tell me how much it will cost to build it?"
Supplier: "Do you need the cost for an ROI calculation?"
Client: "Yes, how did you know?"
Supplier: "Would you like a fixed price contract?"
Client: "Yes please"
You really shouldn't do this gambit
Client: "We'd like to build this system to sell widgets for $1000, we reckon this will sell lots"
Supplier: "It's a daft idea and not worth us taking the risk. Would you like a fixed price contract?"
Client: "Yes please"
We're not sure we want to gambit
Client: "We'd like to build this system to sell widgets for $100, we reckon this will sell lots"
Supplier: "Ok, it looks good and I agree but I'm not comfortable that your committed to promoting this?"
Client: "Well we haven't decided whether to promote it yet"
Supplier: "Well if you don't, I won't get paid as it won't sell .. would you like a fixed price contract?"
Client: "Yes please"
The clueless gambit
Client: "We'd like to build this system to sell widgets, we reckon this will sell lots"
Supplier: "Ok, it seem like a sensible idea but what are these widgets worth?"
Client: "We haven't decided that yet"
Supplier: "Well, what is the market like?"
Client: "We don't know that yet"
Supplier: "Would you like a fixed price contract?"
Client: "Yes please"
Within large organisations, you also tend to hit the budget constraint barrier. For example ...
The budget gambit
Client: "We'd like to build this system to sell widgets for $100, we reckon this will sell lots"
Supplier : "It's risky, the data looks good, the upside is good and ok we will build this and charge you $5 for each widget sold."
Supplier : "It's risky, the data looks good, the upside is good and ok we will build this and charge you $5 for each widget sold."
Client: : "Fantastic"
... add time
Client: "hmmm, we've sold 100,000 widgets"
Supplier: "Yep, we will charge you $500,000"
Client: "hmmm, but I've only got a budget for $500,000"
Supplier: "and you just sold $10,000,000 worth of widgets"
Client: "Yeah, but I've only got a budget for $500,000. Can you switch it off please?"
Supplier: "You want me to switch a revenue and profit making system off?"
Client: "Yep, I need to go through another budget approval. It takes six months."
... and you're back to square one. All of the above problems I've hit and yes, I've been asked to switch off profit generating systems for the client because of arbitrary budget limits. That awkward conversation that despite a system making tens of millions in revenue for the client can we switch it off because we've exceeded some budget limit.
This is why many of the outstanding new services, which tend to get bought out by large organisations, tend to be built by smaller organisations, funded to create a risky but new venture with staff motivated around generating value or worth.
Large organisations tend to lack any internal VC function or Financial risk function for the development of the novel and new in IT. They lack the processes needed to make this happen and as such they tend to treat all IT as the same and normally as a cost function.
So anything which is a potential CA in a large organisation, tends to have a rough ride as the ROI syndrome comes into force and everything focuses on cost rather than worth.
--- Update 20th July 2013
Read this lovely post on value based pricing (which is the same thing as WBD) - http://sixrevisions.com/business/earn-more-on-projects/
Yes, it works sometimes but others ... oh boy.
--- Update 8th October 2015
Outcome based techniques is simply the next incarnation.
--- Update 8th October 2015
Outcome based techniques is simply the next incarnation.
