A lunchtime interlude

Before I get stated on a discussion of the stack, I'd like to talk about the pleasant lunch I had today with a friend who is a research analyst. I discovered that something which I thought everyone had known for the last decade may not actually be that widespread.

Most organisations tend to spend more on CODB-like activities than necessary, because it is easier to justify, and less on CA-like activities because worth is such a difficult concept.

Since CODB-like activities are in the majority, then the correlation between investment and worth is generally broken.

I have been operating under the illusion that this was common knowledge. The revelation that maybe it isn't may help to explain some of my frustrations with our IT industry.

The ideas of worth which I discussed in earlier posts are not mine, nor are they new - they are an amalgamation of my "collective experiences" from others and in most cases are at least a decade old.

The main problem appears to be that most organisations do not segregate activities (into for example CA, transitional and CODB) and tend to instead use singular approaches to manage activities (such as cost focused). As discussed in earlier posts, this leads to the perverse situation that we tend to spend more than required on the necessities which don't bring value and less than required on things which might.

Customer: "I have $300 to buy some essentials like food and some books on finance. I'm hoping to improve my understanding of the field and therefore my prospects"

Sales Rep: "Certainly, now food is a necessity, something you really need."

Customer: "Of course"

Sales Rep: "Well, I have lots of studies here to show how much food is important to you. Everyone uses it you know?"

Customer: "Really, wow that's interesting. I can see food is really important."

Sales Rep: "Hmmm ... I don't seem to have any reports on why improving your understanding of finance will help you?"

Customer: "Well, it's just this idea I have. It's just a hunch, a gamble."

Sales Rep: "Sounds expensive especially if you don't know what the return will be?"

Customer: "Well, it was just this idea."

Sales Rep: "Are you sure you just want any old food? You look like a dyanmic, go-getting sort of person surely you want to compete with the best?"

Customer: "Naturally"

Sales Rep: "Well this report says that if you increase your intake of blue coloured food, your performance ... as measured by athletes ... will increase. All the top notch people are using it - here's a client list"

Customer:"Wow, oh look I'm definitely more go-getting than Fred"

Sales Rep: "It's more expensive to buy blue food - quality always is - but it will give you the edge over others. I've got some ROI calculations for you and case studies if you like?"

Customer: "That's impressive it certainly explains the value. I can also see all these other people I know buying blue food. It certainly justifies the expense. Listen forget the books, just give me $300 of the blue food."

Sales Rep: "Not a problem. Would you like me to book you a session with one of our consultants to tailor the shade of blue required to create synergy with your own lifestyle and to maximise your advantage?"

Customer: "Sure."

Now, I'm not knocking the necessity to eat a well balanced and satisfying diet, but assuming you are fortunate enough to do so then food is just a CODB of living. If you want to improve life beyond this, you'll to need to look further up Maslow's hierarchy of needs.

It's a glib and somewhat turgid analogy, but It's no different with an organisation.

So when I first came across Paul Strassman's work in the 1990's that IT spending was not correlated to company value - it wasn't a shock, just empirical evidence showing this effect. I was delighted that someone had taken the time and effort to gather the evidence which showed what was plainly occurring in my day-to-day experience.

When much later Nick Carr published his article, I felt elation that finally we had a spokesperson willing to take on the insanity and the industry around it.

With the growth of open source, I expected as a side effect there would be a greater shift towards commoditisation of CODB-like activities and an acceleration in innovation and hence disruption of existing industries. So I was delighted when Andrew Mcafee published his report showing increased turbulence in the IT industry.

I expect that turbulence to increase as the "X as a Service" industry grows.

I was just part of the huge crowd who appreciated these breakthroughs to "sense and reason", who understood that the singular magic bullet approaches, the over-hyping of ROI and the sweeping broom of cost focus combined with an organisational inability to identify worth was at the heart of the problems.

After the discussion today - I'm starting to feel that crowd is either smaller or more quiet than I realised. Maybe I'm missing some critical point or a lot more discussion is needed?

Well, if I am operating under a delusion - it is probably best to continue ...

The SEP boundary and more rough thoughts.

I've been busy for the last few weeks - but I thought I'd post more on the "as a service" field and annoy Robert "r0ml" Lefkowitz (a wonderful and talented person) by introducing more acronyms.

Now "as a Service" or "X as a Service" (XaaS as it's often called) is fundamentally about creating a SEP (someone else's problem) boundary. In homage to Douglas Adams, by SEP, I mean the outsourcing of a client responsibility to the provider - in terms of a service, what was once done by a client is now done by the vendor ... it's someone else's problem ... though to be safe, assume it will fail and plan accordingly.

I normally talk about a narrow range of these services, however for the purposes of this post I'll extend up and down the XaaS "stack" to show the concept. This isn't about payment or worth mechanisms (utility or subscription or otherwise) - I'll deal with those another day.

To begin with I thought I'd outline the "stack" and then in a series of posts go through each level in some more detail. These concepts are framed from the viewpoint of cost of doing business activities (CODB) and not competitive advantage or transition.

The "stack", at this moment in time, can roughly be broken into :-

• BaaS - Business as a Service
• OaaS - Organisation as a Service
• PaaS - Process as a Service
• DaaS - Data as a Service
• SaaS - Software as a Service
• FaaS - Framework as a Service
• HaaS - Hardware as a Service
• IaaS - Infrastructure as a Service.
• NaaS - Nothing as a Service (the default position).

The use of these services at any level, for any particular instance, changes the SEP boundary - that which was the responsibility of the customer now becomes the responsibility of the provider.

At the top level of the stack, Business as a Service - the provider is responsible for the business, its organisation (marketing, operations, facilities management, manufacture etc), processes, the data it uses, any software etc. The customer's activities include initial funding and the desire to do something and their main responsibility is for the choice of vendor. This is the concept of virtual businesses, niche or otherwise and is something which I discussed at length with Matt Webb and Suw Charman, sometime last year. Though none truly exist in the space today, it has analogies to the VC market and is worth just noting as a concept.

Next there is Organisation as a Service - with the provider offering a complete organisational function for the business such as marketing, manufacturing, HR, legal, facilities, supply & distribution, finance etc. There are a few examples of these outsourced arrangements.

Process as a Service covers a finer structure, whether it's a marketing programme, translation, lead management, customer support, design, advertising, strategy, manufacture, governance, market analysis, recruitment, billing or payroll etc. Here we start to see a larger number of companies set up to deal with such arrangements either within discrete parts of the organisational structure or as a whole. There are the first signs of utility or subscription models for payment. This process area, often a mix of interrelated internal and external processes, given meaning through the organisational structure, is the remit of business process management. The use of external services is commonly known as BPO (business process outsourcing).

Data as a Service means simply the provision of data. The customer is concerned about the business, its organisation, its processes and how internal data combines with vendor provided data. The provider of such a service is concerned about providing the data and any application, framework or supporting hardware. An obvious example of this today includes business and analyst reports. I specifically call it data rather than information - as data is only given meaning through relational connections within the context of a business.

Software as a Service is a relatively new field (and more aptly called Application as a Service). The customer is concerned about the business, its organisation, its processes and its data. The provider of such a service is concerned about providing the application for the data, the framework the application runs on and the hardware that support this (e.g. SalesForce).

This extends further into Framework as a Service (e.g. Bungee Labs) where the customer is concerned about their code and data whilst the provider takes care of the rest.

Then we have Hardware as a Service (e.g. Amazon EC2) where the customer is concerned with their code, data, frameworks, network configuration, operating environment etc and the provider is concerned with virtual machines or storage etc.

Infrastructure as a Service means simply space and basic infrastructure (such as power, air con, telco etc) which there are countless examples of hosting companies offering this.

Now most of the time this is a pick and mix exercise. Most companies rent infrastructure or at least some element of it and in many cases infrastructure is provided on a utility basis. Some companies have moved higher up the stack and started to shift the CODB-like activities in discrete areas to other providers. The reason for this is that all of these activities are common and suffer from issues of scaling, resilience, availability, management, operations, investment etc and are more economically provided by larger scale specialists.

Now this "stack" is not a fixed model - in my view it's temporal. Over time I expect that SaaS, FaaS and HaaS will all be considered infrastructural services in much the same way that power, water and telco have. However for the purposes of this discussion it is useful to separate them out.

Also this stack isn't just related to the use of digital information. Manufacture is a process which at its core turns data and raw materials into a product (inputs to outputs). The use of rapid manufacturing techniques, on demand manufacture and fabrication technologies are likely to make significant changes in this area and lead to commoditisation of the manufacturing process - another topic, another day.

The key issue to bring up at this point is the concept of portability between service providers or fungibility of any particular service at any level of this stack. I describe this idea as "fungitility". Robert would be proud of me or maybe not.

Fungitility

Adjective
From the Latin fungi 'perform, enjoy' and utilitas 'usefulness'

The freedom and portability to move from one service provider (including internally) to another without hindrance (including excessive cost, time or effort), without boundaries and predicated on the existence of an equivalent service or services.

Whilst there are obvious cost benefits to moving CODB activities to a larger scale specialised provider, there is a risk associated with a lack of fungitility. Having supply and distribution or your CRM service or your governance processes locked into one provider can create significant risks should the provider either change pricing, personnel or even suffer a major outage of some form.

Fungitility reduces this risk and it is why open, free and common standards provided by multiple common resource or service providers are essential.

Before I go, I want to re-emphasise this is only to do with common or ubiquitous types of necessary activities and processes. This is only to do with CODB, which should be focused on cost and fungitility. The ideas of Taylorism are only applicable to commonly repeated activities and at a service provider level this means ubiquitous within the industry.

A novel and new activity, a potential source of competitive advantage (CA), may make efficient use of some CODB-like activities. It might even be a commonly repeated activity within an organisation - however by its very nature it is not suited for a service provider. It is neither ubiquitous nor necessary (in the short term). For such activities I would promote the use of worth based and VC-like techniques.

I've now outlined the topic, created my new word - and so I'll deal with each section of the "stack" in detail over the next few posts.

[Amendment, June 2008: I never found the time to do this. If you want to know more on my views then there are videos of my presentation from OSCON in 2007.]

[Amendement, April 2014: The *aaS terms have changed since this was written, HaaS became IaaS, FaaS became PaaS and there's more confusion than ever].

36 hours to kick start your new venture.

For all those budding captains of industry out there, you have a mere 36 hours to submit your application to Seedcamp.

Saul has been doing some great things in the UK, but this is a spectacular opportunity for some young entrepreneurs.

Future stuff .... Worth Part VII

The creation of standards and providers of those standards at all levels of the stack, will allow for the formation of competitive utility computing markets.

This will have multiple effects, not least of which is the balancing supply and demand more effectively than today's situation and the creation of a downward pressure on price.

They will also allow for the formation of brokerages - swapping your service between providers to obtain the best cost - and exchanges whilst simultaneously undermining subscription type models for service provision.

They will also enable developers to focus more on building the new rather than repetition, as well as reducing some job categories in IT but also creating others.

Most importantly these markets will provide a direct relationship between what we use and what we pay.

This should challenge the ideas that every company needs to store everyone's data, further encourage the growth of SaaS, the creation of open business procedures, configurable virtual niche businesses and so forth.

It may also force more businesses to look closely at the worth of something in order to determine their choices and priorities, as by their very nature utility environment are more worth based.

The more you consume, the more it costs you.

Client: "We'd like to build this internet thingy - how much will it cost?"

Supplier: "Can you give me details on what you want and how many people will use it?"

Client: "Sorry? we want to know how much it will cost?"

Supplier: "The service is charged on a utility basis - so it depends upon how much you use it"

Client: "We don't know that, it all depends upon what happens, what people will want and how popular it is. We need to get the cost sorted in order to get the budget and determine the ROI"

Supplier: "Well the cost will vary with success of your internet thingy - do you have an idea of the worth of this activity?"

Client: "no"

Supplier: "there's your problem."

Commoditisation and web 2.0 .... Worth Part VI

The process of commoditisation is simply the movement between the novel, rare and new to the common, ubiquitous and necessary. As such the nature of a system changes in the process from for example potential high worth, scarce, risky, non standard and non-essential (source of CA) to low cost, ubiquitous, low risk, standardised and necessity (CODB).

Much of IT is CODB. That is why we are starting to see the first utility like environments for IT appear (whether at the HaaS, FaaS or SaaS level). However such environments whilst they often contain necessary services for any business at a lower cost than the build your own variety, generally they are neither low risk nor standardised.

Low risk in this context would mean multiple providers of the same service which you can swap between, as opposed to the implementation details of any one provider. To be able to swap between services you need not only standardised services but multiple providers and the freedom to move data, application or framework (depending upon which level of the stack you are talking about) between the providers.

In this context open source is a necessity to provide not only the base standards but also an operational means of implementing that standard. It is neither a tactic or a strategy.

However, open source (and in this context I mean ideally GPLv3 over other licenses) is not sufficient, you also need some form of additional information to ensure the users of such services that they aren't being locked-in, or that this provider is really compatible with another or they can run their own installation should they wish to.

This can only be achieved through monitoring and the use of trademarking, by an authoritative group providing assurance to end users that this provider meets the standard, that any primitives have not been modified and that what you run with one provider will work on another.

The idea of utility computing, running on others infrastructure etc are bundled with other concepts into the term web 2.0. However, the importance of the term is not the details but that it describes that there are some fundamental shifts from an old world to a new world.

There are changes occurring between users and companies, ownership of information, producers vs consumers, conversation vs product, virtual vs real business, the spread of the idea of openness into business, hardware and other areas, the commoditisation of sections of IT and in particularly the web 1.0 components of it.

It's all about the new stuff, creative destruction and new sources of CA and worth.

Is it a buzz word? Yes, but it's a timely intervention to enable us to start letting go of the things which matter but we shouldn't be concerned about.

It's all about progress, which is the only true sustainable source of worth.

--- Update April 2013

General notes

Depressingly, almost six years later, we are still talking about the issues of interoperability, trademarks and competition in the compute utility space.

The terms have changed, HaaS has become IaaS, FaaS has become PaaS and compute utility has become "cloud" but the concept remain the same. Progress has been slow in the open source world.

My personal blueprint .... Worth Part V

The general blueprint I use when dealing with such issues is as follows. First, I divide IT projects into three categories - CA, Transition and CODB. Then for each category I take a different approach :-

With CA like projects (i.e those which are novel and new in the industry, few examples in the wild, minimal whitepapers, some percieved value and relevant) then use more of a VC like approach (IT Finance) or Worth based development. Focus on worth and dynamic like processes for development (e.g. SCRUM, XP etc).

With CODB like projects (i.e. those which are common in the industry, necessary, lots of examples, lots of whitepapers, even conferences on the matter) then focus on cost reduction, standardisation and static like processes (e.g. Prince2 etc).

With Transition like projects (i.e. those betwen CA and CODB) then either:-

* If new to the field then calculate potential worth, risk and costs and then it's a judgement call - wait and adopt or disrupt.

* If already in the field then attempt to move your service to become the standard product for the industry and hence reduce cost of migration.

Now this is my method, there are many others ... this is not about which method is better. I used my own blueprint to illustrate what I believe is an important point:-

the type of approach which should be adopted depends upon the nature or the class of the problem you are trying to solve

It's not about one approach, a magic cure to solve all problems.

Transition .... Worth Part IV

The most difficult area of IT to deal with, is those systems which are neither novel and new (i.e. some examples of the service are already in existence) nor common and ubiquitous.

Now what is key here, is to know how you to got to this position.

If you created a CA like system which is now being copied by other competitors (presumably because of your success) you run the risk of the cost of migration.

This is where someone releases a product that becomes the standard in your industry and you are constantly maintaining and upgrading your service to keep up with the standard. You will almost certainly in the long run have to switch to the standard - so your costs will be the switch and the cost of continuing your own in-house product until you made the switch. This cost can be very significant.

The best tactical approach to secure the most value in such a situation, is to release your service as a product when other competitors start copying your service. Give it to someone to sell, give it away, open source it etc. If your service becomes the standard, then there is no cost of migration. Open source is potentially a powerful tactic in this context.

Now, if you are instead a laggard into this new field and you see that some of your competitors have such a service whilst no standard product exists then you have two choices. The disruption game or the wait and adopt approach.

Both you'll have to balance carefully in terms of worth, cost, risk and migration effects.

In the disruption game - you try to be the first to release a product and to get that product adopted as the standard. Steal your competitors teams, pay them to develop and release a modified version etc. It's a risky play and it all depends upon the service - whether it could become some form of strategically important platform, like a universal airline booking system? How much influence do you want to purchase over its future direction? etc

The wait and adopt, is just that. Don't do anything and wait until a standard product is released, then adopt it.

In this class of problem, the ROI syndrome is very much secondary to the pure tactical play.

Cost of Doing Business .... Worth Part III

If a service is common, ubiquitous and necessary - then it is termed a cost of doing business. The market or potential is well known, there are plenty of other examples, whitepapers, case studies etc. As such it is much easier to identify the potential benefit of the service and hence its worth - it should also be much clearer over what is needed being a much more well defined problem space.

In such circumstances, the worth of the service is meaningless as all your competitors are using equivalent systems and you need such a system just to keep a level playing field. Any actual worth generated (additional sales or cost reduction) will be passed onto your customers or will simply help maintain your existing market share. Any growth, if there is any, will be over the laggards to this field and probably at best temporary.

In such cases, your focus should be cost alone - as standard as the industry has (either product, or utility based service) and as cheap as possible.

Unfortunately, the existence of so many whitepapers, case studies etc and the ease at which a potential worth can be calculated, makes it easier to often justify larger expense especially when the product is configurable to meet the individual requirements of the business.

About five years ago, I saw the sales sheet for one particular product as sold to around sixty different organisations in London. The product sold was identical, but the price (normalising to a standard number of licenses) varied from $100K to over $2M for the same thing!

It's a testament to the sales people involved, but it's the equivalent of :-

Customer: "I'd like to buy that TV"

Sales Rep: "Excellent, what's your name?"

Customer: "Simon"

Sales Rep: "That'll be $300"

Customer: "Actually my name is Peter"

Sales Rep: "That was naughty of you ... well then it's $100"

Customer: "What if I'm called Harry?"

Sales Rep: "$3,000 - would you like us to modify the knobs so they turn faster or slower according to your need?"

Sales Rep: "We have a whitepaper here on how this will improve your channel switching over Simon & Peter"

Customer: "Is it extra?"

Sales Rep: "I'll arrange for a visit from one of our consultants to determine your exact requirements"

Let's not also forget the dreaded upgrade cycle and also the abyss which is the non standard upgrade path, whereby those modifications you asked for (for reasons of improved channel switching or conforming to your current way of doing business etc) forever cost you more everytime you upgrade.

Unfortunately, all those whitepapers provide support to the potentially higher benefits of a common and ubiquitous service. This often make people feel more comfortable justifying higher expenditure from the ROI calculation ... which is exactly the wrong sort of behaviour desired.

The rule of thumb here should be cheap as chips, ideally cheaper than everyone else and no modification. You need the service in order to compete but your focus should be on price and standardisation - any thought of strategic value should be banished from your mind.

Competitive Advantage .... Worth Part II

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."

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."

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.

The ROI syndrome .... Worth Part I

I haven't posted for a bit, so I thought I'd post some personal and somewhat unpolished views on worth, utility, web 2.0 and why it's all connected and why we are entering a major transformation of the IT industry.

To start with I'm going to explore the concept of worth within corporate IT.

Most organisations seem to be shockingly bad at determining the potential worth of an IT service. This is something I've been harping on about for over a decade and it usually starts with the following conversation.

Client: "We'd like to build this internet thingy - how much will it cost?"

Supplier: "Can you give me details on what you want and how many people will use it?"

Client: "Sorry? we want to know how much it will cost?"

Supplier: "I'll tell you once I know the details and how much it will be used?"

Client: "We don't know that, it all depends upon what happens, what people will want and how popular it is. We need to get the cost sorted in order to get the budget"

Supplier: "Ah, the old ROI syndrome"

The old ROI syndrome

Most organisation have ROIs (Return on Investments) that internally they need to achieve, and IT projects need to show an ROI - whether it's value added or cost saving.

Now the ideal way to deal with this, is to calculate the worth that a new service will bring (sales, cost saving, risk etc) and then calculate the maximum you can spend based upon the ROI required and finally determine what your spending focus should be. The problem is that calculating worth of something can sometimes be very difficult, it depends upon popularity, usage, what your are trying to achieve and other factors and hence most ROI calculations tend to be based upon the cost of something.

Now there are three class of problem - CA (competitive advantage), Transitional and CODB (cost of doing business) - I'll deal with each one of those in turn over the next few days.