Extraordinary but ordinary

“Two-thirds of HR and IT organizations develop strategic plans that are not linked to the organization’s strategy”. Says the father of the Balanced Scorecard, Robert Kaplan.

“This is extraordinary.” He adds. Too right, but that’s the wrong word, it isn’t extra- ordinary, it is ordinary.

It is ordinary for IT to develop an architectural strategy based upon their understanding of “the business” rather than the strategic ambitions of the organization.

It is ordinary to see “a chronic disconnect in organizations between strategy formulation and strategy execution.”

It is ordinary to see fundamental disconnects between IT and “the business”.

Like the bank who were porting their branch banking applications from one technical stack to another without asking the business to define which were strategically important and which were no longer fit for purpose.  Or the FTSE 100 company whose IT organisation built a new web platform and interactive services, in the knowledge that “the business” were developing a complete refresh of their on-line strategy but kept that at arms length (“because the business can never make decisions and we need to fix the technical issues we’ve got” with the current stack.)

Robert Kaplan proposes the “office of strategy management” to address these issues.  It may sound like organisational overhead, but it is hard to argue with a function whose purpose is to “unlock unrealized value by making strategy execution a distinct and recognized competency in an organization”.

And fundamental to this, and what large organizations so often fail to do is “enabling others—operating units and functions—to do their jobs in a way that supports the organization’s strategy”.

IT chalta hai

“Hearing the words ‘I LOVE this…’ from a client is a magical thing”  So tweeted Graham Smith.

Now how often does “the business” say that that to IT?  Rarely I guess.  Why is that?  Why doesn’t “business” love IT?

I think the Indians have got a phrase for this: Chalta hai.

I’ve recently come back from India.  As always it was a pleasure to read the Indian newspapers and weekly news magazines.  In discussing the Commonwealth Games, several columnists in their English language columns made reference to the hindi ‘Chalta Hai‘.  There is no direct translation (hence the columnists use of Hindi) but “it’s all right” or “it’ll do” comes closest.

Chalta Hai is an attitude.  It is mediocrity.  The columnists applied Chalta Hai to service culture and getting things done (or rather the lack of it).  Whilst Chalta Hai may be an Indian affliction, India is not alone.  I’m going to suggest that corporate IT suffers from Chalta Hai.  There’s an industry mindset that success is just getting stuff delivered.  Success is  “it’ll do”.  Mediocrity is a sufficient goal.  To hell with the experience; who cares what the users think, it’s all about delivering functionality and features.  We’re happy if “it’s all right”.  No-one has the desire to hear the business say “I love this!”

Let’s bring some magic into the enterprise.  Let’s introduce a new acceptance criteria to our requirements; that the stakeholder who signs it off says “I love this”.

Vision, passion and personal investment

Something that is common with the start-ups I’ve been involved with, and stories of entrepreneurialism you can read is the passion of those involved.  They have a drive and desire to succeed, backed by enthusiasm and belief for the product they are building.   More often than not, they are personally invested in the project; maybe it is a problem that they feel needs addressing (Dyson), or an opportunity in an industry they are familiar with. It almost always it goes beyond just a job, it is a hunger to bring change and make a difference.  They have a vision, it what drives them, yet they are willing adapt the original vision and move with agility as circumstances dictate.

FlickR started its life as a tool in a role playing game.  The game was not successful and ultimately shelved (fail fast) with the photo sharing capability being developed; the team realised where the value was rather than sticking to a failed big up front plan.  If you go back in time to 1999 and look at how google described itself:

Google Inc. was founded in 1998 by Sergey Brin and Larry Page to make it easier to find high-quality information on the web.

Nothing there about browsers or phone operating systems or word processors or spreadsheets.  Twelve years to go from a search engine to the Google we know today.  Place that lens over most enterprises and how have they managed to adapt to the changing world?  I know of several enterprise projects that are three plus years in, (that’s a quarter of Google’s life) and have still yet to start delivering value.  You don’t get that with start-ups, or places where vision, passion and personal investment drive the product strategy (thinking Apple and Steve Jobs for example).

I’ll lay the fault at Enterprise Culture.  Silo thinking and career progression through the ranks.  So an individual is personally invested in delivering documentation that specifies the system.  When she delivers these she is done.  What happens next is someone else’s problem.  Reward is rarely for delivering the overall vision, why should it?  How often do all stakeholders involved in a project have a strong grasp of the what’s and why’s of what they are doing?  They are only rewarded on the how they deliver the fragment that they are responsible for.

When IT becomes a supplier rather than a partner, no-one has ultimate responsibility for delivering a coherent holistic vision, it becomes a contractual relationship rather than a passionate obsession.  Funding projects is all to often a charade and a nonsense.  The business submit their funding requests (a line item for a potential project) for the forthcoming financial year in the autumn / winter.  Budgets are finalised in the Spring with the new financial year and months have elapsed due to internal budgetting and accounting formalities rather than the ability to respond to the market.  Contrast that with the start up model with seed funding to get started and if the projects shows viability second round funding follows.  If the project is not viable it is suffocated before wasting cash.  (There are interesting perspectives on this leaner model at Beyond Budgetting).

I wonder if in these lean times we are going to start seeing lean thinking applied to enterprises and a start-up culture being nurtured.  There is certainly a growing interest in agile, beyond the practitioners and from C level executives.  But agility in software development is only the first step.  To be really successful it needs to spread through the whole organisation, not just paying lip-service to the word “agile”, but devolving responsibility to individuals and collaborative, cross-organisation teams who can share the vision, passion and are personally invested in getting the right quality products to market at speed.

Tractors, nuclear powerplants and the bleeding edge

It is common for organisations to select a major technology leader (such as IBM or Oracle) and ride their product development cycle.  On client I worked for stated that they would:

“not follow a ‘best-of-breed’ approach, but rather select a major technology leader (IBM)… This means we explicitly seek and accept the “80% solution” rather than trying to optimise for each and every possible requirement. …Shortcomings will be made explicit in order that we can escalate with IBM, and influence their product strategy”.

Influence the IBM product strategy.  Good luck.  This one-size-fits all approach to technology maybe appealing on paper, and certainly has its benefits, you recruit a certain type of developer who has skills in that technology stack, if you are big enough your buying power may get a small voice in future releases that you will pay through the nose for.  But is it the best approach for the business?  A colleague, Stuart Hogg, takes three metaphors for enterprise IT.  The tractor, the nuclear power plant and the bleeding edge.

The tractor. This is the technology that keeps the lights on.  It is commodity software, it is the HR system, email, intranet etc.

Nuclear powerplant. This is the (generally bespoke) mission critical software that drives the business.

The Bleeding edge. This is the platform where you do cutting edge stuff, test and learn.  The ideas may one day be migrated to the nuclear powerplant.

All too many organisations get confused between these three models, loose sight of where they should be investing and plump for a one-size-fits-all technology to do all three.  Thus we see tractor technology trying to do the bleeding edge (Is it possible to innovate at speed with those Big Enterprise Solutions?)  By trying to combine utilitarian computing with strategic and speculative innovation, using the same skillsets, timeframes, processes and models, IT will never truly deliver the value for which it is capable.  Another ThoughtWorker, Ross Petit reiterates this point using a banking metaphor of utilitarian retail banking and speculative investment banking. He divides IT into “utility”, around 70 percent of IT investment (tractor and the nuclear powerplant); and “value add” the other (bleeding edge)30 percent.   Like other utilities such as electricity and water, ‘you don’t typically provide your own. You plug into a utility service that provides it for you’.  In IT that means SAAS and outsourcing and taking a strategic decision to differentiate between the different functions that IT performs.  He concludes:

Separating utility from value add will make IT a better performing part of the business. Because they’re comingled today, we project characteristics of “investment” into what are really utilities, and in the process we squandor capital. Conversely, and to ITs disadvantage, we project a great deal of “utility” into the things that are really investments, which impairs returns.

As a business function, IT has no definition on its own. It only has definition as part of a business, which means it needs to be run as a business. The risk tolerance, management, capabilities, retention risks, governance and business objectives of these two functions are vastly different. Indeed, the “business technologist” of value added IT needs a vastly different set of skills, capability, and aptitude than she or he generally has today. Clearly, they’re vastly different businesses, and should be directed accordingly.

Separating the utility from the value add allows us to reduce cost without jeopardizing accessibility to utility functions, and simultaneously build capability to maximize technology investments. Running them as entirely different business units, managed to a different set of hiring expectations, performance goals, incentive and reward systems, will equip each to better fulfill the objectives that maximize their business impact.

We didn’t build it because the business didn’t prioritise it

Agile software development is inherently democratic.  Choice over Prescription could be included in the Agile manifesto.  We give the customer the choice, the choice to decide what is most important to them, what will deliver the greatest value and build that first.  We do not prescribe that they must build a complex framework first- the software will evolve, You ain’t gonna need it (Yagni) until you need it.

The problem with this democracy, with this unleashed choice is that, if you don’t have the right mix of stakeholders, the (agile project) customer doesn’t always know what is best.  They are not always the best people to choose.

There is a difference between domain knowledge and what I’ll call ‘experience’ knowledge.  A banker may know the banking domain inside and out, they can tell you the difference between all the different types of balance and how (and where) they are calculated; closing balance, running balance, etc.  But unless they have done any research with customers, unless they have ‘experience knowledge’, when it comes to  a question such as which balance to provide as an SMS alert, their ‘domain’ knowledge is as good as your common-sense.

Imagine software were a supermarket store.  IT are responsible for the construction of the store, the basic layout, the signage, the checkout, the peripherals.  The business are responsible for what goes into the store, the merchanising, the planogram.  The business imperative is to fill the shelves and shift the product.  They want to spend their money to this goal, anything that does not directly support this will be of lower priority.  That is their domain and they will prioritise that over anything else.  If they could fill the store with nothing but shelves they’d probably be happy.

Now imagine visiting the store.  There’s no carpark, there are no shopping trolleys, there’s no emergency exits.  There’s no ramp for disabled customers.  The shelves rise to eight foot high (with no steps to reach the heights), the aisles are difficult to negotiate because of promotional displays between the shelves.  The business is happy, but what about the customer?

In the agile world, nobody is going to pay attention to this stuff unless it is prioritised.  “Sorry, we didn’t build any shopping trolleys because you prioritised building more shelf space over them”.

This sort of thing happens all the time; functional domain requirements trump experience requirements. Why? Because no-one brings experience knowledge into prioritization and planning sessions.

When stating their choice, your stakeholder wears a commercial hat, they are thinking about their targets and those are based upon shifting product.  They are living in thier operational business domain.  But cold commercials are not what shifts product.  It is the experience that does.  Now go back to the democracy of choice on an agile project.  Who is the ‘business’ specifiying requirements? Is it a balanced team? Is their an experience champion with an equal voice?  Is the voice of the customer recgognised?  If not, isn’t about time you got an customer experience champion onto the team.

Pillars of a compelling experience

Pillars of a compelling experience

This is a model I often see in organisations when it comes to their web presence.  A product owner comes up with a commercial proposition, marketing work up the content, IT build the functionality and it is goes live.  With this model, no-one actually owns the customer experience.

Worse, this little temple model is repeated across different commercial propositions so you end up with something that is not very joined up.  I’ve blogged about this lack of joined up thinking before.

Now let’s construct a model where the roof of the temple is a compelling customer experience.

What are the ingredients of this new temple model?  It is still going to be founded upon commercial propositions, but they are going to be overlaid by a culture of test and learn.  That is a willingness and ability to experiment; to realise that what you have developed is never final and is always evolving.  It is about taking the learnings of experiments to inform and improve the experience, or to rapidly refine or kill propositions that just do not work.

Then we have the five pillars.  I describe these in a paper I wrote ages back (pdf here, google books here).

Unfortunately these pillars tend to sit within organisational silos; content and personality are ‘owned’ by  marketing, functionality by IT, and operational excellence (that’s all about fulfilling on the customer promise and beyond) is a mixture of IT and operations.  Usability is a ‘funny one’ in that might sit alone, sit in marketing or sit in IT.  But ultimately it is best placed to direct the horizonal filter of Quality Control.  Quality control is not an additional layer of bureaucracy, rather a cultural component that all the pillars feed into.  It is about ensuring consistency and meaningfulness of the experience.  It is about balancing the commercial needs of the product, with the marketing needs of the message and the delivery capability of IT.

Photo credit: K. Dafalias

About a successful project that was a failiure

On time, on budget, to the scope that was agreed from the outset of development.  A successful project?  Well no actually.  It was a complete failure.

Here is a story about an insurance company with a number of differnet products sold through intermediaries.  Whilst the intermediaries were good at selling single insurance products, they weren’t so good at cross-selling or up-selling other products.  Focus groups with the intermediaries revealed that they didn’t know about all the other types of insurance available through the company.

What if the intermediaries could have a portal where they could access all our insurance products in the same place with customer alerts and sales support prompts identifying further selling opportunities?

From this initial idea a benefits case was pulled together consisting of a product definition and financial projections.  In pulling together the benefits case, the potential revenue uplift numbers surprised everyone.  Signing off the benefits case on the new Intermediary Portal was duly signed off, and the product definition was handed over to IT to build.

Being an agile IT shop, the business and developers sat down together and got their heads around the product definition.  It soon became clear that the challenge was one of “single sign-on”.  Each of the insurance products offered were on a different legacy application that required the intermediaries to sign-on with different credentials.  To bring them all together in a single portal was far harder than the simple problem that the initial product definition suggested.

In pulling together the benefits case, a rough estimate had been supplied by IT. Now it was an in-flight project with an initial list of stories, it became clear that they had significantly under-estimated.   Of the twenty different products that the business wanted on the portal, for the budget the business had set aside would deliver barely four products.

With new estimates a release plan was drawn up.  Release one would deliver single sign-on across four products identified by the business as being most profitable.  All the  sales support tools were de-scoped and scheduled for a third release with the second release delivering single sign-on for the remaining products.

Development started, the business stakeholders worked closely with the developers and the First Release of the Intermediary Portal went live with congratulations all round.  Funding for the next release was lined up depending upon the success of the first release.  But that success never came, take-up was less than expected and the cross and up-selling never materialised.

The proposition to the intermediaries as delivered was flawed; the portal had to be all or nothing, single sign-on across four unrelated products was not compelling to them.  There was no sales support.  The intermediaries thought “so what?”  IT had delivered on the business requirements yet the project was deemed a failure.

This story tells a striking lesson. The project failure was due to a lack of joined-up thinking.  The business and IT both had followed their processes and done the right thing.  The business had identified an opportunity, built a benefits case and had this signed off.  IT had run a model agile project with close engagement with the business.  However whilst both stages of the process were locally optimised, they were done in isolation of each other.  Once the (development) train had left the station both sides were committed to delivering the product portal.  No-one returned to the business case, no-one went back to the end users, the intermediaries and asked whether the cut down scope for the first release would actually be of value to them.  More importantly, IT were engaged too late in the process.  The business had settled on an IT solution to the problem without engaging IT.  Had IT been party to the ideation and visioning process they would have been able to raise the risk of the project complexity earlier on.  Indeed they could have killed the project before it started.

Returning to the initial problem; “intermediaries weren’t so good at cross-selling or up-selling other products… Focus groups with the intermediaries revealed that they didn’t know about all the other types of insurance available through the company.”  The problem didn’t need a portal solution. The issue was one of awareness; almost certainly an off-line marketing campaign would have delivered a greater ROI without the need for IT to build the wrong product.

Innovation through the recession

Two men were running through the jungle chased by a lion.  One of them stopped, took off his backpack and took his trainers out.  The other man turned around. “Why are you putting your trainers on?” he asked, “They won’t make you run faster than the lion”. To which the man replied “I don’t need to run faster than the lion…”

In the current market conditions just blindly running won’t get you ahead of your competitors.  And standing still is not a sustainable option.  Those that succeed won’t be the ones that batten down the hatches and retreat to the trenches, history shows it will be those that continue to innovate and cultivate ideas.  During the 1990-91 recession, according to a Bain & Company study, twice as many companies leaped from the bottom of their industries to the top as did so in the years before and after.

“Even though we’re in an economic downturn, we’re in an innovation upturn” said Bill Gates at the time.

In the 1920’s Post and Kellogg’s went into the recession head to head. Post cut back, it reined in expenses and slashed advertising budget.  Kelloggs meanwhile maintained their marketing spend and pushed their newly launched product, Rice Krispies.  Today Kellogg’s are a household name.  Where are Post?

IT organisations are retreating to core, keeping the lights on and holding off any “non-essential’ projects, innovation included.  This is a shortsighted viewpoint, but not entirely unexpected.  With project life cycles taking so long, innovation traditionally takes significant investment and time to see results.  Modern lean and agile approaches to IT are a challenge to this entrenched view.  It is possible to innovate at speed.  It is possible to take an idea and turn it into something tangible in weeks rather than years.  Let’s start with the idea.  Where does it come from?  You could get the brightest minds from expensive management consultancy firms, but they take time. And in uncertain times, what do they really know? (I speak with experience having once been a customer strategy management consultant).  Alternatively you could harvest ideas from your customers.  That’s what IdeaStorm does for Dell.  And Mix does for Oracle (built by ThoughtWorks by the way). Don’t restrict this to your customers, building an internal ideas engine in the enterprise yields great results.

So once you’ve got the idea, how do you nurture it from a vision into a proposition that has legs?

Product innovation is all very well, but do you have the capability and the attitude to really do it?  In the current ecomomic climate, unless product innovation is in your DNA, chances are it will need to be accompanied by process innovation.  Why? Because most organisational processes are slow, cumbersome and hinder the agility required to really innovate.

In 2009, if there’s one thing that organizations need, it’s agility. Our economy and the business environment are a steady stream of ups, downs and rapid change; in such an environment, the ability to sense, respond and react are true survival skills!

At ThoughtWorks we do both these things for our clients all the time, helping them introduce aligity into the whole product development lifecycle; product innovation through process innovation.  It starts with helping them rapidly distill their vision into something concrete, then prirotising and estimating what is important before building it at speed with quality to get innovation to market; fail fast or succeed sooner.

Recession doesn’t make the market need disappear. Andrew Rezeghi in this great paper (which is abound with stories of companies who have innovated through recession) argues you should invest in your customers, now they need you most, loyalty hangs in the balance.  Whilst the market may be driving down prices, now is the time to focus on experience based differentiation.  How can you use digital channels to engage with your customers in new and compelling ways?  How can you harness social media and new interaction paradigms to delight and engage your customers?  Ho can you innovate at speed? Go beyond your product and grow roots for lifetime value when the good times return.

Are you managing expectations beyond the team?

There’s this idea called the Disconfirmation of expectations theory that states that having unrealistically high expectations from the adoption of a new IT application will result in lower levels of realised benefits.  Get customers excited about a new product and fail to deliver on it and you will have unsatisfied customers.  And unsatisfied customers are unlikely to use the product to its full advantage.

There is a risk with products developed using agile approaches that they fail to deliver on their initial promise.  The immediate stakeholders know that the product will evolve incrementally, but is this true of the broader audience? Are they aware of the intended regular heartbeat of delivery or are they expecting a fully featured product at the first release.  How are you managing expectations beyond the immediate product team?

Be wary of what you say early on.  Creating a vision is essential but be mindful of how this is communicated. Early demos, proof of concepts, prototypes, wireframes often show a vision of the end goal, several releases into the future.  Words are easily forgotten, explaining that this is an end goal vision is not enough, you must show a vision of what the cut-down product for the first release is and ensure it is appropriately communicated.

Expectations work both ways, it is easy for the business to tell IT their requirements and assume they will be developed in their entireity in one go.  Similarly it is easy for agile developers to expect the business to understand their incremental approach to delivery. The key to success is effective change management; identifying all stakeholders (both core and peripheral) and create a culture of agility that goes beyond the immediate project team.  In a large organisation that maintains more traditional approaches, agile projects must be supported by a well designed communication plan that builds the relationship between both IT and the business. Identify whose life will be touched by the product and develop a strategy for communicating to them.  This doesn’t mean “they can see what is going on on the project Wiki” this means someone taking responsilibity for listening, engaging and evangelising on the product, the project and its goals.

Someone should talk to the minister about agile

So another government IT project fails to deliver.  The National Offender Management Information System had been budgetted to cost £234m (total lifetime cost) and take four years to complete.  Three years in and the costs had spiralled, with a new lifetime project cost estimated at £690m.  The plug was pulled and a new three year project at the cost of £513m was commenced.  Poor project management was blamed, but I’d go further and blame the project approach as well.  The Minister responsible says why;

“As soon as the extent of the projected costs and delays to the project were recognised, we took immediate steps to halt the project and consider the most cost-effective way forward which effectively preserved the work done to date”

So let’s get this straight:

It took three years to recognise that a project to implement a single database had gone wrong

Contrast this to an agile project where progress, costs and risks are continuously monitored.  But what does the goverment do?  Continue with the same approach as before with some new project managers on the job.  And wait another three years before any value will be delivered.

1 of 3