dancingmango

Petition

I’ve written in the past about the government’s abysmal track record on IT development.  I met with the local MP to discuss the issues but he didn’t really get it; he sent me away to write a policy paper for him which I really had time for…  So good news that someone is doing something about it with a petition on the Number 10 website.

In his recent update on the progress of the petition, Rob Bowley mentions the Rural Payments Agency project.  I can’t attest to either have been an ‘expert’ or to have had a salary anything near what he mentions, but I was a consultant on that project so nod in informed agreement.  That experience gave me a benchmark to compare ‘bad’ ways of going about an IT project to compare with the ‘good’ world of lean and agile that I now inhabit.

Please sign the petition.

Are you prepared for the dip?

So you are refreshing or rebuilding your website.  You are introducing new functionality and features, and sweeping away the old. You’ve done usability testing of your new concepts and the results are positive.  Success awaits.   You go live.   And it doesn’t quite go as you expected.  You expect that the numbers and feedback will go on an upward trajectory from day one, but they don’t.  What you should have expected is the dip.

In October 2009 Facebook redesigned the news feed.  Users were up in arms, groups were formed and noisy negative feedback was abound.  A couple of years back the BBC redesigned their newspage, “60% of commenters hated the BBC News redesign“.  Resistance to change is almost always inevitable,  especially if you have a vocal and loyal following, you can expect much dissent to be heard.  What is interesting is what happens next.  Hold your nerve and you will get over this initial dip.  We’ve seen a number of projects recently where this phenomenon occurred; numbers drop and negative feedback is loudly heard.  But this dip is ephemeral and to be expected.  The challenge is in planning for this and setting expectations accordingly.  Telling your CEO that the new design has resulted in a drop in conversion rate is going to be a painful conversation unless you have set her expectations that this is par for the course.

Going live in a beta can help avert the full impact of the dip.  You can iron out issues and prepare your most loyal people for the change, inviting them to feedback prior to the go-live.  Care must be taken with such an approach in the sample selection o participate in the beta.  If you invite people to ‘try out our new beta’, with the ability to switch back to the existing site, you are likely to get invalid results.  The ‘old’ version is always available and baling out is easy.  Maybe they take a look and drop out, returning to the old because they can.  Suddenly you find the conversion rates of your beta falling well below those of your main site.  Alternatively use A/B testing and filter a small sample to experience the new site.  That way you will get ‘real’ and representative data to make informed decisions against.  Finally, don’t assume that code-complete and go-live are the end of the project.  Once you are over the dip there will be changes that you can make to enhance the experience and drive greater numbers and better feedback.

Bunch of grapes or bunch of arse?

“We’ve got to have the ability to enable customers to share”
Random London Taxi driver spouting opinion on social media
“‘ere,  you say you’re in IT, whatcha make of this Facebook and twitter malarky? That Stephen Fry, what a tw@t, I don’t care that he’s just woken up and brushed his teeth. Now that QI, its a fix. He’s not so bright, he doesn’t know all the answers etc etc etc….  I’ll tell ya, Facebook and all that sh!t is a bunch of arse”.

“We’ve got to have the ability to enable customers to rate and review products”
Random UK customers in a focus group
Facilitator “So if I gave you all these user reviews for the product, or a review by Martin Lewis, who are you going to go with?”  Group: “Martin Lewis…  yeah, I trust him, no idea who these people who write reviews are… what’s in it for them?…  they are paid by the company aren’t they (cynical agreement etc)”

“Blackberrys are the business users phone”
Random teenagers in shopping centre talking about their mobile phones
“You’re nobody if you don’t have a Blackberry”  (Ummmm, aren’t Blackberry’s the business person’s phone?)  “You’ve got to have one coz of the Blackberry PIN for texting”

Sometimes you can get hung up in your view of the world, you make assumptions about the way the world works.  Yet it can be refreshing to go out onto the street and canvas ideas and feedback.  That may be as simple as striking up people on the street (people love to talk), or running focus groups for no particular research purpose other than taking the pulse of what people think.  Or it may be spending time on the shop floor.  Get out of the office for a day and have fun seeing your customers, consumers of your idea, in the wild.  I’m not saying you take the word of a taxi driver, a comment from a single focus group or an anecdote from a shopping centre as gospel, but it might make you think and spark some new, unexpected and contrary ideas

A leap of faith

We recently pitched to a prospective client.  We told a story of how we believed their customers would use the new product they had sketched out in the RFP; we told a ‘day in the life’ and brought it to life with illustrations.  We walked through our approach to tackling projects and described our experience on similar engagements.  One of the bid team described his experiences and what the client could expect and we guaranteed that he would be on the project.  We let them have a rate card, and an indication that, comparing what we knew of the project with others that we have successfully delivered, what they indicated they wanted in the RFP was in the range of their budget (which we knew).  We let have them directly relevant references who were ready to take their calls.

What we didn’t do was produce them a project plan, nor a definitive cost.  Given the paucity of information in the RFP there was just not enough to go by; it would be a lie if we came up with a number, there were too many imponderables.  Yet that was what they craved the most.  Most of the questioning was friendly and we answered well, however one question sticks in my mind: “From your presentation, you are asking us for a leap of faith to engage you”.  Well yes, we are.  But is that any different to the way you engage any new contractor?  It is always going to be a leap of faith; even if you engage one of the big trusted brands with an established reputation.  Sainsburys and NHS took a leap of faith when they engaged my old employer Accenture; they probably felt they had done all the necessary due dilligence and were partnering with a proven, reputable organisation, but in those two instances good things did not result.

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.

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?

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.

What do you see?

A cleaner and a doctor both watch a surgeon perform a complex operation on a patient.  Both watch the same operation, yet each sees a completely different thing.

Are you aware of how different people will see the product you are building?

What would Sally do? Personas for retail financial services

Personas are ‘pen portraits’ that bring to life users or customers of a system, service or product.  Giving a personality and back story to your customers helps keep your thinking true to their real needs and goals.  Rather than using  ‘user’ or a segment descriptor such as ‘empty nester’, or ‘this is what I would do’, what would Sally do?

Here’s a set of personas for financial service organisations, geared towards the retail / B2C market.  Sally is included (Shes skint).