Smart meters. What will happen Vs. what could happen

Smart meters. What will happen Vs. what could happen

Smart meters are the Next Big Thing at the Energy companies.

Over the next 11 years every household in Britain will receive Smart Meters, one for gas and one for electricity. This project will be one of the largest infrastructure projects to have taken place since the Second World War.

So says NPower.

I’m going to get a Smart Meter? Whoppeeedo!

Whilst the idea is compelling to the companies themselves, I don’t see them answering the question “so what” in a particularly compelling way.  They try, talking about “providing you with much more information on your energy consumption allowing you to be more fuel efficient and save money”, but really. So what?

(This calls to mind a quote from Jurassic Park where the Jeff Goldblum character says “Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should”.)

Just because I can control my boiler from my iPhone when I am away from home…. well why should I? What is the point? What is the customer need that smart meters are fulfilling?

That is not to write off smart meters. But what else could they do? What new business models could they inspire?

How about introducing gamification to the way people monitor their energy consumption.  What if the customer could win recognition as being the most energy efficient in their street?  What if gamification could be used as a reward for more energy efficient behaviour?  What if it enabled people to trade their energy usage within their social network?

Lot’s of big ideas but I don’t hold my breath so see anything innovative coming to market anytime soon. Marketing departments may dream of such things but I don’t see them gaining traction when IT are tasked with rolling out functional requirements for mundane, pedestrian and unimaginative use cases.

Yet might there be a different way?

Dear Energy Provider. What if you carve out a niche within the larger smart meter project to build a test and learn capability? A capability that can rapidly develop ideas and take them to market as experiments, product betas. A place where technology is less of a concern than the idea. Many of the usual non-functional requirements can take a back seat as you take the concept to consumers. a place where the idea has to prove itself cheaply for real, or fail fast.

An interesting aside, the way that Mumsnet have developed a community site that attracts 25k per day:

Essentially, we started with a blank piece of paper, viewing ourselves as a platform provider, with the understanding the site had to be developed in collaboration with mumsnetters at every stage.

The most important factor has been letting the community direct progress and listening to what they want – almost all innovations, new site and product developments at Mumsnet are derived from members suggestions.

This happens on a day-to-day basis: we view the site as an ongoing beta or focus group. Most recently this has led to our ‘Off the Beaten Track’ section, covering sensitive issues which which users’ requested not to be indexed by Google. Their feedback and suggestions have also been instrumental to the design of our soon-to-launch mobile app.

What if, instead of rolling out Smart Meters to customers and extolling the virtues of how good the pedestrian things they do are, what if the energy providers derived new product innovations based on the smart meter technology through their customer suggestions.

And thinking more radically, what if they unlocked their data that the smart meters provide and let the community develop innovations (as with the UK government’s Open Data initiative).  There’s lots of new business models, new ways of working. But again, I don’t hold my breath for anything inspiring anytime soon.

Image credit: Todd Smith

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

Do you modify your approach according to context?

I look in the rearview mirror.  Blue lights flashing. Maybe he’s been called out to respond to a call and will overtake me.  No, he’s flashing me.  Instinctly I’ve slowed down, I look at the speedo, it is in KM/H and I’ve not been paying attention to the roadsigns, but it is clear that I’ve been going too fast.  So I pull over.

The question in my mind is what to do next.  I’m in Australia, driving an awesome road, the Great Ocean Road that just asks for a car to be driven (OK, it’s hardly an Grand Tourer, it is a compact Hyundai Getz).  The brain is racing, pumped by adrenaline and fear.   In the UK I would get out of the car, go to the back of it and talk to the officer.  You’ll be asked to do this anyway “Would you kindly step out of the car sir”…  The last time I hired a car overseas was in the US in Atlanta.  Driving through the deep south I got pulled over and I jumped out of the car. Bad move.  “You’re makin’ me kinda nervous’ the cop drawled with his thick southern accent.  He spread me over the ‘hood’ to search me and ended up taking me down to the station, something that was straight out of the Dukes of Hazard, and handed me a huge fine to pay.

So I’m slowing down and thinking do I do the UK thing and jump out, or do the US thing and stay in the car?

I decide to stay in the car.  The right move.

So that’s an interesting story, but what does it have to do with the themes that I usually blog about?  Adapting your approach based upon context.

A while ago I met with the CIO of a company whose core business is in complex instrumentation hardware.  They were looking to diversify their offering, take some of their products out of the hands of specialist practitioners and into the broader marketplace.  Core to the success of these new offerings was usability; their devices required complex set-up and calibration.  Their question; how do you redesign an expert system for novices?

Seeking an answer they hired a customer experience consultancy to gather insights, understand the new segment needs and create wireframes for the new application interface.  But the consultancy couldn’t fit with the way the company worked.  They would run a workshop with the client for a couple of hours then go ‘back to base’ to do the thinking and designing and return to present their designs, well thought out and well polished.  Yet every time they would come back they had got something wrong.  That approach may have worked for a website, but for this complex product they were getting it wrong.

We were asked for our advice.  I started by saying that I thought they should stick with the incumbant,  whilst we would love the business, both parties had invested a lot and learned a lot in the past few months and it would be a folly for us to come in and have to start from scratch.  The answer was to get both sides into the same room, a war room, and thrash out the designs.  Forget about their formal methodology and way of doing things.  If you they were both in the same building they didn’t need that formal staccato present  – review – sign-off process.  They could continually innovate.  That is certainly the way we would do it, yet the CIO thought the incumbent would be resistant to changing their ways.
The theme that joins these two stories?  It’s about reading the situation, knowing the culture and context you are in and adapting your approach and behaviour accordingly.   And that applies as much to agile practitioners as Big Methodology people.  know your audience, understand the context then pick your battles; think big, start small scale fast, remember that change won’t occur overnight.

Innovation games

Innovation games are a great way of engaging stakeholders, getting them to collaborate and think creatively around solutions to problems. Here are a few I’ve recently used. Introducing a persona helps focus the attention.

What happens if?
Ask participants to construct a back story for the persona. What have they done in the last year. Describe each touch point they have had with your brand or product. Now introduce a crisis moment. Lost a job, got a terminal illness, won the lottery. What happens? How does the experience with each touch point change?

Build a widget
Again, give the group a persona to help focus their attention. Now give them half an hour to build a widget that would solve a problem the persona has. Give them paper, post-its sharpies, coloured pencils. This is agile right. Now present back – They get two minutes to provide the context, pitch the product. Then one minute to demonstrate how the widget works. Open the widget to questions. How will it work….

You’re all crooks
<Insert your industry> are crooks. What new laws would you introduce to clean up their act? (OK, this feels uncomfortable but it may help get people thinking about how consumers perceive the industry and how the customer experience could be improved. For example you are crooks because you hide details in small print, introduce a new law on transparency. What would that mean you would change?)

Kill the sacred cows
Every business has sacred cows or elephants in the room; things that are done because they’ve always been done, not to be challenged, considered immune from criticism or are too risky or dangerous to change. Ask participants to identify these, putting them on post-it notes. Now imagine that they no-longer exist. What could you do now that you couldn’t do when the sacred cows were in place?

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.

If software was an airline

All airlines are the same.  They fly the same planes to the same airports for (roughly) the same prices. What differentiates them?  Attention to detail.  It’s not just the functional detail – it’s the experiential detail that really makes the difference.

It’s the same with software.  If the application you are building was an airline, which airline would it be?  All to often developers focus on the plane, building something to fulfil the utility of getting people from A to B.  Yet the customer doesn’t care about whether it’s an Airbus A330 or a Boeing 777, what they care about, and what they remember is the experience they have.

(This can be a useful exercise at the outset of a new project, ask stakeholders to imagine their finished applciation was an airline, what brand would it be?  This helps anchor expectations; are you building a full service Singapore Airlines or a no-frills EasyJet?)

What is the story?

One of the problems with IT development is that it is tactical and piecemeal in its approach. Functionality is added in response to competitor or broader market activity. Expect to see an increasing number of brands doing something ‘social’ (and tactical) on the web, but don’t expect these new initiatives to be (strategic) seamlessly integrated into the existing digital channel offering.

This piecemeal approach extends to larger initiatives as well. In refreshing the website or developing new digital channels such as mobile and TV, IT will typically build out features and functionality prioritised upon their perceived individual business value regardless of what the sum value of the proposed release is. (Focusing all your effort of building functionality that delivers to your bottom line will seldom be as successful as you predict if it is not supported by features that meet the customers needs).

So when it comes to thinking about new features and functionality, where’s the best place to start? I’d suggest collaboratively, thinking around the customer. Collaboration is important to ensure that everyone starts with the same vision. It needs to be shared it with the broader audience, the product teams, IT; anyone whose day to life life will be touched by the project when it starts. I’d argue that you cannot start this soon enough. You don’t need to spend time doing analysis, interviewing all stakeholders individually, coming up with a document that is circulated and reviewed and re-written (with all the delays and waste that such a process incurs). Start the process getting all those stakeholders off-site for an afternoon and get the thoughts out on the table.

Commence with a presentation that introduces thinking in terms of customers and customer journeys. The below SlideShare presentation does this for the airline industry, addressing a new customer experience across channels. I acknowledge that it is pretty simple and doesn’t touch on half the ideas that airline executives may have. That is the point, it is just enough to get people thinking about different customer types and their touchpoints without getting bogged down in detail. This is what we want the participants of the off-site to share.

[slideshare id=912224&doc=airline-deck1-1231817842408345-3&w=425]

Once we’ve been through the presentation we break out into small groups a, each taking an individual customer (or persona) and build up a story; a day in the life of… (It is important not to forget the internal users of the system). These breakouts last 15-20 minutes with ten minutes for the team to play back their findings. As they build out a richer picture of the customer interactions they are asked to sketch out what the user interfaces may look like. The process is rapid, intense and iterative, but always focussing upon the customer journey; how will the customer realise their goals. When the teams tell their stories an analyst captures the essence of the requirements on index cards. The final exercise is to lay all these cards on the table and ask the team to group them into similar areas then prioritise them according to their perceived importance. In an afternoon you will have achieved four things. Firstly, you will have captured a vision for the new product in less than a day, with all stakeholders understanding not only the vision itself, but also the process that developed it and the concerns and issues that different parts of the business have with it. Secondly you will have an initial prioritised roadmap for its development. This will change, but it is a good strawman to circulate. Thirdly you will have introduced all the stakeholders together – projects succeed or fail based upon the strength of relationships and getting people engaged from the start will go a long way to creating shared ownership. And finally you will have generated energy, engagement and traction; to do the business case and to get the project started, recognising that just one part of the business having a vision is not going to bring it to the life that they dream.

Words are slippery things

Want to prove it? Take a sheet of paper. Tear it in half (under the table so I can’t see).  Now show the two halves.  You tore it in half side-ways didn’t you.  I tore it length-ways.  Same instruction, same materials, completely different result.

Are you experienced?

“For you who have had the experience, no explanation is necessary. For you who have not, none is possible.”

I’m going to attribute that saying to Ram Dass, a Harvard professor who via psychedelic experiences ended up a spiritual teacher in the Eastern Tradition.

The problem with too much software/web design is that it is produced by people who have just not had the experience, or do not see the experience as relevant to their organisation or domain. They just don’t “get it”.

(“For you who have an apple product, no explanation is necessary, for you who have not, none is possible?” Cue “it’s an enterprise application we’re buiding, not a ****ing iPhone”).

If we want to build memorable and compelling products, we need to focus upon the experience. To dwell on the feature list or functional requirements is to build mediocrity. Nothing wrong with mediocrity if you don’t want to delight your customers or increase the performance of your workforce. Without considering experience you will miss innovation and added value.

So how to focus upon experience? Get your team to undertake different tasks to get under the skin of what customers go through.

Telco product?
Spend time in a retail outlet and watch different customers buy phones
Go into all the phone shops on the high street and ask the rep “hello, I want a mobile phone”. Suspend all your knowledge about phones and tariffs. How do they sell?
Leave your blackberry at home for a day (how dies it feel? How does it change what you do?)
Download instruction manuals from different phones from manufacturers websites

Travel product?
Go into a travel agents and ask for a holiday “somewhere hot and cheap in February”

Credit card product?
Ask to borrow money from someone you don’t know (how does it feel?)
Apply for a credit card at another bank
Collect all the Credit Card / loan direct mail and emails that you and you get sent over a week, photo / scan all the credit card advertisements you see in a week
Go into a car sales room and look to buy a car on credit

Supermarket product?
Get behind the till for a day (In the UK, at least a few years ago, all senior executives in both Tesco and Sainsburys spent time in the stores over the Christmas period)
Ask a shop assistant to help you find an obscure product that is not in stock
Go into a store with a shopping list and a single bank note, (no credit cards)
Go to the pharmacy when it is busy and ask to buy the morning after pill

Extend your team
Bring in representatives from completely unrelated parts of the business to participate in brainstorming sessions. Building a “youth” social networking website? Get someone from legal or corporate finance to join in. (Get’s you thinking along the lines of extreme characters – here and here [pdf]). Working on a complex exotic financial instruments? Get a few PAs to join in. You may learn something (that your product is too complicated and even you can’t explain what it really is).

I’m sure you can come up with better exercises. The object is that with this collection of experiences and related emotions new ideas can be brought to the table. They can offer insights from another, different perspective, providing more chance of business innovation being realised. More importantly, if you have an emotional attachment to the product you are building through real experience, you are more likely to build a better product that will fullfil the needs of and goals of the target audience in the way they want. The day your enterprise application team all have iPhones will be the day you start building better enterprise applications. For them, no explanation will be necessary. They’ll just “get it”.

What if an RFP was an Open Day?

We recently completed writing a response to an RFP. It weighed in at just under 100 pages with almost 34,000 words. OK, so there was a lot of copying and pasting going on, but that is not an insignificant amount of effort. Multiply that by the number of suppliers who were invited to respond; add the time taken for the client to produce the RFP itself, then review responses and answer questions and it is clear that RFPs consumes a lot of everybody’s time. With the winner taking all, that is a lot of wasted effort. But hold! That is only the first stage! The list of suppliers is whittled down and a beauty parade follows. Yet more effort is spent by two or three vendors turning their word document into a bunch of PowerPoint slides. A favoured supplier is identified and a process of negotiation follows, based upon estimates and what little information the supplier knows. Finally the supplier is selected, inevitably their are surprises on both sides when the engagement starts.

So the RFP process is a standard (but inefficient) way of doing business. What if it was done a different way?

One of the more significant decisions you make in your life (if you have children) is where you will send them to school. It is not a decision you make lightly as it will have a major influence on how your child grows up in the world. In the UK the government provides data (league tables) but this can only tell you so much; there is more to education that the statistics tell (which are historical and do not necessarily reflect the current reality your child is going to face). You will probably ask around – seek the wisdom of the crowd. Undoubtedly the community can identify good schools and bad schools. But the best judge of a school is to go there, to look around, to meet the teachers, to see the children. Do you trust the leadership of the head? Would you be happy for this person to teach your child, would you like your child to play in this playground, (and more importantly) grow up with these children?

So why not apply this thinking when looking for a supplier to build you an application? At the end of the day, projects succeed on personalities and relationships. Will the vendor get on with the buyer? The RFP tells you little about that. What if the RFP process was like seeking a school for your child? What if you had a project open day where you welcomed suppliers in, got to meet them, and maybe even got them to compete against each other.

What if you had three intense days when the business, IT and prospective invited suppliers come together to define the project and complete against each other in teams to come up with the “best” solution.

What if you provide the suppliers with details of what you are looking to achieve and request a basic qualifier – company details, profitability etc (the stuff that goes on every RFP) and a list of clients they have built similar products for (not exceeding one page of A4 per client). And for costings you ask them to provide you with their proposed rate card.

What if you then invite all suppliers to a large venue with a space for everyone to gather, and break out areas for the individual suppliers to work in. You start with background and presentations from the business and from IT. You tell the story of what you want, the vision, a description of the current technology, constraints, assumptions, known risks, integration points, etc. You provide some initial direction as a large group, but then breakout into supplier teams, interspersing each team with your people – from IT and the business. You provide technology (access to your systems, whatever is needed) and domain expertise. What happens next is up to the suppliers. They then have two days to impress.

What if at the end of each day each supplier presents their output to the whole group. The following morning you outline what you like of the outputs and ask the teams to take that as input to work on. Then at the end of the last day each vendor puts in an anonymous sealed envelope with their estimate (resources required to build the application). Can this triangulation technique be any less accurate than the estimate given on the back of several pages specification in an RPP?

If we accept that IT projects are about people, implemented by people, then the benefit of this approach is that you get to work with the supplier and experience the relationship first hand, rather than through documents and practiced PowerPoint presentations. And for the supplier it reduces the time taken to respond and will be more enjoyable for those involved. After all, don’t people prefer to do rather than write about what they do?

1 of 2