This much I know

The Observer magazine has a feature titled “This much I know“. It takes an interview with a celebrity who “share the lessons life has taught them” and distills it down into a number of key statements. There is probably some milage in this as an innovation game to play when you are looking for ideas and insights, hopes and fears from a newly formed team.

Ask team members to write statements “this much I know” on post-it notes with Sharpies (because you can’t write many words like that) and see what you get.

For structure you may consider using different coloured post-its to represent PEST themes: Political, Social, Environmental and Technical, or how about CRIT:

  • C: Competitive landscape
  • R: Return on investment
  • I: Internal politics
  • T: Technology.

So for example…

This much I know recently redesigned their website. The  forums and twitter were full of positive comments (C)
People will pay for content. It’s just got to be priced right, relevant and timely to them and easy to pay  (R)
Getting things done here is a nightmare. The process to get approval for any new project is designed to be hard (I)
We’ve got problems with our CMS. Our license is due to expire and the vendor is trying to get us to upgrade. We don’t know what to do (T)

Getting these ideas on the wall will help participants articulate their thoughts and provide a framework for understanding the current reality and mining for new ideas and opportunities.

Why it pays to think about the whole system, not just your local function

Ability to do bulk price mark-downs? Nice to have.

Today we are looking at a large UK supermarket stock control system.  At the end of the day the staff mark down prices on the short-life items (sandwiches etc).  They have a hand held scanner with a belt printer.  Scan item – print label – stick label on item.  Well that’s what the process is supposed to be, only this takes time (20 seconds per item) and when you have a whole shelf to do is a chore (12 items takes four minutes).  Far easier to just write down the new price on a ‘discount label’ with a sharpie and stick it over the barcode (do the whole shelf in less than a minute).

Where’s the problem in that?  In fact three minutes of waste (waiting time) has been eliminated.  Only it is a problem

The customer takes the item to checkout and the mark-down label is covering the barcode.  The checkout colleague tries to peel it off to scan, but it doesn’t peel cleanly.  So she manually enters in the SKU. And the mark-down price.  And this has taken 2 minutes for one item and the queue has grown and because of the ‘one in front’ policy they have to open a new checkout and suddenly that small problem at one end of the value chain is replaced by a bigger costlier one at the front end.

But had we not observed this we would never know that bulk price mark-downs on the hand-held device is not a nice to have, it is million dollar requirement.

A picture tells a thousand words. So prioritize pictures not words

Draw pictures to illustrate outcomes, design the user interface first and use that to prioritize requirements rather than working with written requirements.

In a single image you can convey a simple concept, an idea, a need or a desired outcome far quicker and more accurately than writing it in a sentence.  This is especially so in developing software which more often than not is visually manifest as a user interface.

When we captured requirements in agile, we are effectively conveying a simple concept, idea, need or desired outcome as a requirement.  And we do it in words.  Those slippery things that are so often misunderstood.  Things get really slippery when we try to prioritize those words against each other.  Stories are laid out on the table and the team spend as much time discussing what each story actually means, as giving them priority.  And because they are supposedly independent, you loose the inter-depedencies between them.  Jeff Patton has written some great stuff on this.

So prioritization with stories can be flawed, especially when you are working with a large volume of requirements, say at the outset of a programme of work, and what you really want to do is get an idea of what a first release should be.

Throw out the stories.  It’s too early to be writing words.  Muda.  Create illustrations of widgets and features and functions.  Sketch out on post-its illustrations of the simplest implementation of the concept, idea, need or desire.  On flip chart paper create blank screens that illustrate the interfaces that the requirement will be manifest on.  Identify the stakeholders who will interact with the requirements.  For example the retail website, the operational support application, the finance system.  Now ask the team to stick onto the screens the sketches.

The challenge is to strip back to the minimal functionality that they really need for that first release.    Let them draw extra functionality if they like, but everything must be on post-it notes.  Now pull the post-it notes off, one by one.  What if we removed this? What would happen if it wasn’t there?  Is there something simpler we could do?  Something more elegant?  Is an operational function required to make the website function work? The exercise may be extended with pictures of legacy applications and data elements, again, stripping them back to the bare necessities for that first release.

That didn’t take long did it, and it looks like an initial release candidate. We’ve defined our scope in a way that we do not believe we can cut any more.  Any less functionality would not be a meaningful release.  Now we can get down to writing the stories, focusing our effort on something we are agreed looks right.  We’ve prioritized pictures, outcomes over words; Picture Driven Design.

Customer value proposition model

Customer value proposition model

There may be a niche in the market, but is there a market for the niche?

How do you create a successful proposition?  If the answer was obvious there wouldn’t be so many failures out there in the market place.

It is easy to commence on a journey of product development with a hunch and clearly there is no substitute for validating ideas in the flesh.  That something at ThoughtWorks we do; helping clients test and learn, rapidly building ideas into tangibles that can be piloted at low cost and low risk before investing in significant build and spend.  However, sometimes a little more rigour is required before you commit to commencing a project in earnest.

That rigour needs to be focused.  What often happens is this rigour turns into a research phase that turns into a project itself.  It need not be this way.  There are certain things you can do, certain questions to ask as you set out on the journey of creating a new, compelling customer proposition.  What follows then is a strawman customer value proposition model to help test potential propositions before moving forward with them.  There are three components to the value proposition model; the customer, the environmental context and the organisation or company.

All too often propositions are rooted in the organisation.  They make assumptions about the demand or usage. This model attempts to broaden the analysis and focus upon the customer and the why the proposition will be attractive to them.  The model supports questions that may be asked to help shape thinking, test hypotheses and validate thinking.

I do not propose that this should become a major research exercise  (for example market sizing is a huge effort in itself), rather a tool for asking the right questions, and if the answers are hard to come by, maybe that suggests more thought is required in refining the proposition.

So here goes, a model that provides a framework for considering new customer value propositions.  It’s just an initial idea and I’d welcome feedback and suggestions.


Before you get too carried away with the proposition, a good starting point would be the customer.  Who are they and what do they do.  Let’s remember that your customer is not everybody.  Your proposition in unlikely to be appealing 24/7.  The challenge is to segment your target market and identify the triggers for action.

The persona: Who do?

Personas are a useful tool for bringing the customer to life.  Much has been written about them, but they are a useful tool for extracting broad data into specific stories that describe individuals. Realise that it is unlikely you will design for everybody. Start with the market that you are targeting, how large is it and what is its propensity to spend? Then within that target market segment the target customer base into different profile customers (personas). You need to understand which persona, which customer profile is most important – prioritise them and focus on the highest value.  This may mean deciding between high volume, low margin mass market and low volume, high margin niche appeal.  This decision needs to be made as early as possible to ensure the proposition remains focused and doesn’t try to be all things to all people, satisfying none.

Values, needs, wants and desires

People are not empty vessels waiting to consume and be filled with your proposition.  Their behaviour is driven by their values, needs, wants and desire.  These may be fundamentally rational (to satisfy a basic human goal) or emotional (to demonstrate status). They are cultural and time based.  Thinking in these terms helps you understand how the proposition will appeal to the customer at different levels.  Let’s take an example of this; a new mobile phone.

Before we think about what the product must do, what are the values that the persona associates with the phone. Is our target market a technophile or a technophobe? Jan Chipchase who works for Nokia includes ethnography in his research to understand how people use their phones; women carry them in their handbags, men in their pockets or their belts.

The basic need that the phone must meet to satisfy the customer, she must be able to make and receive calls.  If the product is unable to meet these needs it is not fit for purpose and the phone proposition will inevitably fail.

Just making phone calls meets the need but there are additional wants that should be satisfied for the product to be more compelling.  It’s a hassle to remember the number of every person she rings, the customer wants to be able to store numbers and see the number of the person who is calling.

Having the ability to see a photograph of her daughter as a screen saver on her phone is neither a need not a want.  The phone is useful and usable without that.  But the customer desires to personalise her phone by having a picture of her daughter on it.  Desirability is the key differentiator of the iPhone.  It doesn’t need to compete on features, it is a cool device that people talk about.  And here is a key decision you need to make on your proposition journey.  Are you looking to compete on parity or whether you want to make a difference.


  • What is the basic need that the proposition is trying to fulfil?
  • What counts as hygiene?
  • What does the customer need to be satisfied?
  • What does the customer want in addition to being just satisfied
  • What do other competive products do to maintain feature parity (if you feel you really need to compete on features alone – bad move!)
  • Few people would argue they don’t want simplicity and clarity in their interactions with products.  How could your product to make life easier for the customer?
  • What will make the customer feel good in themselves about owning the product?
  • What other products are “cool” or desirable to your target market.  How can you leverage the essence of those products?


So now we are beginning to understand who the customer is, it is time to nest the proposition in terms of their context.  The old maxim that a half drunk bottle of water in a desert is worth its weight in gold, but on the streets of a city is worthless trash, should be remembered.  Even the best of propositions will deliver little value if they not only consider the customer, but also the context in which they apply: time, demand and usage.


So the next step in the model is to ask why, when and how will the customer be attracted to the proposition. What is the trigger that drives the customer to move from awareness (assuming you have that) to action?  There is no point in a financial services company trying to sell me a car loan if I am wealthy enough to own my own car, or I do not drive.  Understand what triggers the customer to be interested in the proposition, when and why this happens.  How can your proposition be at front of mind when the trigger is set.


  • What lifestyle / lifestage events will trigger?
  • Internal events personal to the customer; leaving school, getting a first job, getting married, moving house, retiring etc
  • External events that they have no control over (think about sports sponsorship and tying a proposition to that sport, or tying a proposition to a celebrity e.g. Michael Jackson..)


It is very unlikely that the proposition will be wholly unique.  What is the competitive landscape, what noise will it need to be heard above to capture the consumers attention.  Whilst you may review the immediate competitors to see where threats and opportunities lie, what can you learn from other, unrelated products or domains?  How can you fuse together concepts from outside your immediate focus to bring new innovation to your product?  Scenario planning may come in useful, playing out different outcomes for different timelines other than that which you plan for.


  • What is the competitive landscape?
  • What can you learn about similar but unrelated propositions?
  • Have you considered the political, environmental social and technical influences using the old PEST analysis?
  • Have you considered different scenarios and how your proposition would play out under them; what unplanned disruptors could get in the way, or how could your proposition done differently disrupt the market?

The experience engine

Enough of the customer and externalities, what will the proposition look like and why will the target customer go with it? There are three engines within the organisation that drive the proposition, the experience, delivery and value engines.  So…


To be any good, the product has got to offer basic utility.  It has to do what it says it is going to do.  Sadly, too many products and customer propositions end there.  A utility product will match the consumers needs.  This is where most enterprise software sits…

  • What are the key customer needs that the proposition must fulfil?
  • What is the basic core functionality that must be met, what are the features that must be offered to gain traction in the market place?
  • What features that are typical on competitor products that we could do without?


I could call this next box usability (as this follows the UXD model) but I think it goes beyond just usability.  What is the quality of not only the immediate interface, but also with the supporting functions?  For example, if you have a call centre to back up the proposition, how many layers of IVR are you forced through?

  • Have you considered usability?
  • Is the packaging aesthetically pleasing?
  • The “happy path” customer journey may be well framed, but what about the “sad path”?  What about when things go wrong, what about when customers don’t act in the way you expect of predict them to act?


It is easy to get carried away with a new idea before thinking about what it means to the brand.  Typically there will be a strategic roadmap and whilst the proposition may be attractive it may not fit into where the brand is going.

  • Is the proposition complementary to the overall brand direction or does it require a new brand and identity?
  • Does the proposition support / leverage the brand?
  • Does the brand already ‘do it’ under another guise (are you reinventing a wheel that has already been tried somewhere, sometime in the organisation’s history?)
  • How will it be marketed?


Finally, what is the ‘buzz’ that the proposition will create, what will get people talking and sharing it and how will you create this buzz.

  • Is there a social network component built in that gets people talking and connected?  How will it get people talking in external networks?
  • What will cause people to recommend it to others?
  • How can customers become part of its evolution?
  • What of the proposition will get people passionate, what will drive them away?

Delivery engine


A successful proposition needs not only a talented, passionate and committed team to deliver it to market, it also needs a similar team to run it and support it when it is live.  It is a common failing for a rogue “skunkworks” team to emerge in an organisation and develop what appears a compelling proposition, only to have it knocked back and closed down by the “Business as Usual” processes inherent in the organisation

  • Who do you need to make the proposition successful?  What is the team?
  • Who will create the proposition and who will lead it?  Is it IT led or business led?
  • What are the cross-organisational boundaries that the proposition crosses and how will these be eliminated?
  • Who will take ownership of the proposition once it crosses over into the market?


  • What are the processes that will be required to sustain the proposition?
  • If the proposition will require changes to the organisation, how will they be managed, communicated and rolled out?
  • How will the proposition be supported once it is let loose in the market?
  • How will it be communicated to customers?
  • How will you create new sales – sales force.


  • What is the technology that will underpin the proposition?
  • Is it possible to test the ideas using rapid languages such as Ruby on Rails before committing it to the enterprise Java stack?
  • What integration is really necessary and what can be worked around?
  • How can you deliver a beta version in the shortest period of time?
  • How will you avoid heavyweight frameworks and develop incrementally to deliver value early and often?
  • How performant and scalable must the innovation be?

Value Engine

At its most simplistic, how much will the proposition cost and how much revenue will it generate?  Does it offer cost saving opportunities?  Are there intangible benefits that will be accrued?  Ultimately is it a viable proposition that is worth pursuing, or will the cost to develop and run outweigh the value it will add?  Building out a financial model can take time, in the first instance this should be a napkin analysis, a wake-up call to make sure there is value in the proposition before too much time is invested in it.


Every day someone is working on the proposition it is costing you money.  The quicker you can get something to market the faster you will start seeing a return on your investment, similarly the sooner you can “get something out there”, “test and learn” the sooner you can kill a proposition that does not fulfill its promise.

  • How quickly can you get a beta to market?
  • How many people, how many days?
  • What will the cost be to develop the infrastructure?
  • Do you have the skills in house or will you need to go external?

Benefit / Revenue

At its most crude, how will the proposition make money, but there may be more to what we wish to achieve.  Is the proposition actually going to cut costs, a result of regulatory pressures or a CSR initiative?
What are the benefits that will be accrued – both tangible (e.g. financial) and intangible (e.g. social, environmental etc)

  • If you are selling units are you going for high volume low margin or low volume high margin?
  • If it an on-line proposition “advertising” is often seen as the source of revenue.

There are two additional components to the model…


Having a compelling proposition is one thing, it is another to successfully communicate it and roll it out to target customers.

  • In a crowded market place, how will the proposition stand out?
  • What are the brand values it will communicate?
  • What is the story that customers will hear and how will they hear that story?
  • How will customers interact with the proposition, what channels will you use to take it to market?
  • What is the roll out strategy?

Retain and grow

Winning customers is only the first step.  A successful proposition will maintain a long-term relationship with its profitable customers, maintaining the warmth they have to the original proposition and cross-selling and up-selling new ones.

  • How will you retain them and turn them into repeat customers and passionate advocates of the proposition?
  • How will the proposition grow lifetime customer value?
  • What can be cross-sold or up-sold?
  • What can you bundle?
  • How will the proposition deal with churn?

OK, so it’s not a perfect model and by no means complete.  There’s some duplication in the thinking and many questions missing, but as any model it can be used to guide and prompt thinking and ensure there are no elephants left in the room when the first line of code gets cut.  I’d welcome any comments on its usefulness, utility and direction.

SOA, architecture without foundation

Service Orientated Architecture (SOA) is something that is easy for the lay person to understand.  (Try getting a techie to explain REST and you will see the attraction of SOA to the business person – it’s understandable!)  Understandable, in my non-techie hands, is dangerous.  I am entirely unqualified to pass judgment on it, but there are a couple of  things I’ve observed and have been on my mind when I’ve seen SOA nastiness going on.  So excuse me whilst I wax lyrical.

Problem 1. IT haven’t got a clue.

My (lay) understanding of SOA: IT build ‘services’ that can be consumed by different applications.  SOA enables us to remove duplication and build the foundations for a scalable architecture that will accommodate changing requirements as the business evolves and grows.  Herein lies the problem; IT build ‘services’, second guessing what the business actually needs from said service.

Exhibit One:  Customer Details Service. It exposes details of customers to any application that will use information about customers.   It was designed by the architect in isolation based upon what IT believe a Customer Details Service will be required to do (e.g. the nature of the fields, the domain etc).  This is even though no application has been built, yet alone specified for (“we just know we are going to need customer details”).  It’s putting the cart before the horse.  But IT go ahead and build the service anyway, because they own SOA.   At a later date the business articulate requirements for a new downstream application that requires Customer Details.  It’s the Corporate Business whose domain is Corporate Customers.  But what happens?  The service doesn’t quite meet their requirements.  The fields are wrong.  The Customer Details Service fits the domestic consumer model but not the corporate customers model.  What gives? More likely than not the downstream application.  The corporate customer has to be shoe-horned into the domestic customer service. I’ve seen this done.

Lesson 1. Don’t build SOA in a void.  Get out of that architectural ivory tower and engage with the business (if you can get them to listen – see next point). Better still engage in Guerrilla SOA.

Problem 2. The business haven’t got a clue.

One of the sad realities of the corporate world is that walls that have sprung up and created internal silos that are difficult to bridge.  As the business, the consumer of technology, I want IT to deliver to my requirements, no more, no less.  If I am in the domestic consumer part of the business, frankly I don’t care about Corporate customers.  I’m fighting for my budget, and hell, if this SOA thing is going to cost more than doing a closed application that fits only domestic customers, that only I can use I don’t care.  I’m not going to pay for a “Customer Details” service that does anything except give me what I need to know about my customer.

Lesson 2. The architects should facilitate the discussion.  SOA is as much about your business vision as it is technical architecture.  Unless the business grasps what you are trying to do, drives the solution and requirements are both local and global, before long you’ll see some grand services that few use in the core and chaos is the periphery where the real business is done.

Bottom line?  All too often architects fail because they tend to focus upon the architecture part of SOA rather than the services.    Unfortunately, because of the siloed nature of so may organisaitons, unless it is driven by the architects it is unlikely to gain traction.  If there is a maxim that should be followed when considering SOA in an organisation, it is probably instilling the notion of ‘think local, act global’.

User interface is a disruptive technology

Last year, according to Gartner, with belts tightening, technology executives need to focus upon disruptive technologies (that cut costs).  The top ten list of disruptive technologies makes strange reading.  How will social computing and mash-ups cut costs (enterprise 2.0?)  Most interestingly, coming in at number six on the list is “user interface”.  Now let’s leave aside the fact that a “user interface’ is hardly a technology (it is how technology manifests itself to the user) I’m interested by the fact that it can be considered to be disruptive. What is disruptive about user interface design?

But think a little further.  What is really disruptive is the realisation that good design is more than just adherence to functional requirements; good creative design is more than ‘bells and whistles’ or ‘gold plating’.  A good user interface will cut costs by enabling the internal user base be more efficient and productive.  A good user interface will enable customers to succesfully complete their transactions / goals.  In a world where poor UI on enterprise applications remains, maybe user interface is indeed a disruptive technology after all.

How long does it take to start. I mean really start?

Let’s assume that you are not bought into the whole agile thing.  That doesn’t mean you can’t look at your IT organisation and identify waste and fat in the process.  How long does it take from the business having an idea and requesting IT to build something to the developers actually starting to code?

This seems to be common: The initial ‘idea’ is fed into the PMO team, it is documented with a high level scope, rough business case and napkin estimate of +/- 100%.  Elapsed time (i.e. the time from the first email or conversation requesting the requirement through to the initial scope document being circulated and approved): two weeks, value added time (i.e. the time actually spent thinking, doing or deciding); two hours.  The project, having gained approval in principle, is then prioritised.  Some organisations actively monitor thier project protfolio, others do it annually, with the business having to put in project requests when the budgets are set.  Mid-cycle and the project is unlikely to take off.

Let’s assume PMO agree the value of the project, next step is high level design.  Analysts capture high level requirements, ascertain what the business really wants and refine the business case further.  IT puts some high level estimates against the requirements, with a +/- 80% confidence.  Elapsed time: eight weeks.  Value added time two weeks.  With a refined business case to take to PMO or the steering commitee all that has changed now is that we have some more detail and a guess on what it might cost.  We are ten weeks down the road and we still have not made a decision whether the project will commence.  This due dilligence is notionally about reducing risk and keeping costs in check, but in reality, what value has been added?

Now it is time for detailed design.  Another (elapsed time) eight weeks of analysis, drilling down into the requirements.  Documentation follows workshops, only now the specification is no longer speaking the language of the business.  Use cases, UML, it’s all getting slightly technical and the business are not really sure what they are reviewing.  Let’s call it another couple of weeks of actual value that is added.

Eighteen weeks elapsed time, countless meetings, momentum and still no decision on whether project will start, let alone a line of code being written.  But the business case is really taking shape and IT have got the estimates down to a 20% confidence limit.

The project gets the go-ahead, but it is not yet time to start coding.  Technical design needs to take place, four weeks of architects architecting and documenting the spec.  Six months has elapsed (of which maybe a month was actually doing stuff that positively contributed to the success of the delivery) and finally the developers start writing code.

What value did that six months deliver?  Requirements, design, business and estimates.  Yet we all know that the requirements will change, and with that the business case.  The estimates will be way out, but we’ll justify the process of estimation because they would have been right it the requirements hadn’t change during the build…

Knocking the process is easy.  What’s the alternative? Start with a burning desire to release something of value at the earliest responsible moment.  Get the business in the same room as the analysts and the architects and get them to articulate their vision.  Use personas and more importantly scenarios and customer journeys to drive out the business vision.  Ask the analyst to capture the business intents on index cards.  Lots of whiteboarding, visualisation and pictures to inform the thinking.  Don’t dwell on the detail, this is about capturing the intent of the system, what are the desired outcomes that it will deliver, how will it impact the lives of all the people who will touch it.  Next step is to prioritise these outcomes.  Collate these into the minimum set that would make a coherent and compelling product that you could go to market with.  For the business case make basic assumptions on the revenue that this feature set will deliver (or what costs it will save) and ask the architects and developers in the room to do some high level estimates.  The whole process should take no more than a week (you could get a first cut done in a couple of days) and there is your initial business case.  If we accept that estimates are little better than guesses and things will change anyway, if we have an initial realisable goal that we have demonstrated will deliver value, why not go straight into development.  By actually ‘doing’ you will minimise risks that you can only predict on paper, and value will be delivered so much quicker, indeed you should be able to have something to market, generating revenue in the same timescales that you otherwise spent planning and analysing.  And if you still want to do waterfall, you’ve got a smaller number of requirements to analyse and design for, again, delivering value sooner.

Thinking about value in terms of advantage and benefit

A product rarely sells itself.  What sells a product is the advantage it brings and the benefits it delivers to the customer.  It is the benefit of the product that sells rather than the product itself. What is the advantage of the requirement you are stating, and what is the benefit it will bring the customer?

Let’s start with a product.  Think broadband.  It’s dull.  Put 10MB in front of it and it is still dull.

Now think about the advantage that 10MB broadband brings.  The advantage is that it is fast.  Lightning fast.

Now think about the benefit which that advantage brings.  The benefit is that you can download an MP3 tune in seconds rather than minutes with your old dial up connection.  You are no longer selling broadband, but the experience that it brings.

Let’s consider IT requirements to be products.  A dull list, a thick document gathering dust. How do you prioritise one requirement over another?  What is more important?

Agile introduces ‘stories’ as the requirement product.  They are written in the format ‘As a <role>, I want <a feature>, so that <some benefit is achieved>’.  It is the ‘So that’ which is usually the hardest part to articulate, yet it is the most important part of the story.

Liz Keogh describes how prompted by Chris Matts her preferred narative reads:

In order to <achieve some value>
As a <role>
I want <some feature>.

Applying the marketing thinking to how the story will “achieve some value”, don’t just define that value in the advantage it will bring, rather also consider the benefit it will deliver to the user.  The two are different.  There maybe a business advantage to delivering some feature, but if the benefit to the end user can’t be articulated, it’s real value must be questioned.

Design vision

Don’t be fooled into thinking that you don’t need to do any design when you adopt Agile.  Agile development strives to deliver business value early and often, focusing on getting working software to market as soon as possible rather than dwelling in documentation and ‘analysis paralysis’.  But let’s be clear, “business value” and “working software” are not the same thing.  You can quite easily get something into production that fails to generate revenue, decrease costs or whatever other yardstick you use for ‘value’.  What differentiates the two of them is design.  I don’t mean big up front design that details all the features and provides a concrete spec, I mean a design vision that articulates what the product goals are and a roadmap for getting there.  And what is a design vision?  A short statement of intent is a good place to start, and soon after a user interface mocked up in pen and ink.  It is cheap and easy and helps bridge the path from idea to execution.

Was it just a simple database query?

So the sensitive personal details of 25m people has been lost and there is a huge political furore over it. Whose fault is it? As far as I can see, (and this is my personal opinion,) blame must lie with IT, specifically the IT contractor and either the contract they work with or the perception of that contract.

The National Audit Office asked HM Customs and Excise for child benefit in “desensitized form”. Sensitive details were specifically asked to be removed, ostensibly to make the file size smaller. This would require a bespoke query to be run. It was deemed too costly so it was assumed that a full extract of the data would do. The fact that this was then burned to a CD, posted unregistered mail and lost is not the point (that is stupidity). What is the point is the IT contract prohibits the business (in this case the governmental offices) to do their job properly.

What sort of contract demands extra payment for a simple database query for “NI numbers, child benefit numbers and children’s names in order to select a risk-based sample of cases to audit as part of anti-fraud work“?

Surely this is an extra request that an experienced database analyst could easily run in the course of a day? If not you must ask why not – is it because the database is badly designed with nested tables and stored procedures and stuff that would make a decent DBA go eugchhh (I’ve seen that happen). If this is the case, the IT contractor has done a bad job; if an electrician worked in your house and left a mess of an electrical installation, would you keep employing them, even if they were cheap?

Maybe however it would not have incurred a cost and this was just the perception; “we must not… run additional scans/filters that may incur a cost to the department”. If this was case it suggests a breakdown in the relationship between the business and IT, with tendency towards the confrontational and transactional rather than co-operation and partnership.

Organisations that outsource their IT often fail to realise what the true costs are. Anything outside the terms of the contract is a change request. It is not unusual for the request itself to incur a cost (someone has to write the documentation, specifiy the design, estimate the effort) before a line of code is written. (At one organisation I worked with that had outsourced their IT function, I was told that to add some basic client-side field validation to a single field on an application form on their website was likely to cost in the region of £60k). The business starts to believe that everything costs and IT becomes a hindrance and a vicious cycle commences.

How could things have worked differently? Let’s say the HMRC IT department was run on more lean/ agile lines. With agile it embraces change. The request comes in (let’s assume such requests are not regular occurances) and in the morning stand-up the BA describes the request and asks the developers for its feasibility in a word. Someone says “yes, I ran a simiar querry last month, it’ll take me ten minutes”. (In reality double or treble that estimate), but it will not have an imact on the developers ability to get thier prioritised work completed. Alternatively the developers say “given the database structure we have inherited that’s a lot of effort” or the project manager says “another request?! pritoritise it like the others!” and it is prioritised in the weekly iteration planning meeting (pushing something else out) and then it gets done.

My hope is that when the inevitable investigation takes place, they don’t just look at the policies and procedures, but also at the underlying structure of the way that IT is managed.

1 of 2