U.S. vs us ...

In some European technical circles, the U.K. is sometimes considered not relevant to Europe and just a poor cousin of America. This poor cousin attitude is often reinforced by the claims from numerous bandwagon hopping analysts that if you want to make it big then you need to go to Silicon Valley.

Contrary to such blatant stereotypes, the U.K. (and Europe as a whole) has a thriving technical and entrepreneurial community with companies such as Dopplr, Last.FM and Xing to mention but a few.

Despite this, the government body UK Trade & Investment, has provided financial support to web mission 2008 for "20 UK Web 2.0 companies [to] travel to San Francisco to explore new opportunities for growth with key people in Silicon Valley".

As Ryan points out, whilst the intention is good, the whole web mission basically declares that "we don’t have what it takes over here”. The reality is we do, so why not invest in a U.K. based activity and promote the start-up culture here?

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

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.

Worth based development

Butler Group's master class was better than I hoped for. Tim Jennings and Martin Butler gave some interesting presentations on IT value, measurement of value and in general what is wrong with our industry - too much focus on cost, with no clear measureable value.

The content was similar to a discussion group I had a Foo camp last year.

Take home messages were

1. No correlation between IT spending and business value.
2. No correlation between IT spending and cost reduction.
3. Strong correlation between knowledge capital and business value.
4. IT in general is focusing on cost and automation, where it should be focusing on knowledge capital.
5. Big gap between Executive and IT in general.
6. In general there are no clear measurement of business value in IT projects.
7. Difference between Competitive advantage, Cost of doing business and Transition of projects.
8. Focus should be on worth first (or as I would say what's important to users).

and much more. Overall great.

Today the duck count was up to 8.

Hacking DNA and all that jazz

Recently returned from e-Tech (http://conferences.oreillynet.com/etech/) and have been fascinated by the remixing DNA concepts proposed by Drew Endy.

It is a new approach in my book, and I'm torn between using my spare time for :-

A. hardware hacking (hardware hacks from the far side - James, see http://www.nature.com/news/2005/050314/pf/050314-14_pf.html)

B. DNA remixing (see http://web.mit.edu/endy/www/scraps/talks/03.15.05.ETech/)

C. 3D fabrication (manufacturing via inkjet like technology).

D. Living.

E. Beer.

Choices, choices, choices.

Away tomorrow to a Butler Group symposium on measuring IT value. Could it be that finally people are catching on to worth based development (WBD)? A move away from the flawed fixed price or hour charging mechanisms which pervade our industry?

A fair dollar for a fair dollar.

Open source and XP (agile not windows) have made headway, everyone is catching onto commodity pricing of IT as a service (salesforce.com and all the web services being setup etc). Maybe soon those few project which are of competitive advantage will use WBD?

Internal venture capital mechanisms to fund new IT projects and a focus on value where value is important and cost where it is cost of doing business?

I've high hopes for tomorrow. Expect ranting soon.

Today I had 6 ducks left in my pond.