dancingmango

Bad experience #1.  Got a mail from Skype telling me that because I’ve not used their service for a while they are going to “expire” my credit.

Skype Credit expires 180 days after your last purchase or SkypeOut call. If you’re not using your balance we need to expire the credit sooner or later to comply with normal business accounting rules

Eh?  I’ve topped up my account with money, what rules are these that confiscate it for not having made a skype call in a while?

Bad experience #2

So I want to visit Skype and see exactly how much I am going to loose, and take a good look at the rules.  I’m using a vodaphone 3G card.  I link to a skype URL and…

Eh?  Skype is “restricted content”.

On what grounds is that I wonder.

Let’s get a few things straight.

• Analysis and documentation are not synonymous.
• “Big up front design” (the agile zealot’s hell) and analysis are not the same.
• The holy grail of self documenting code (”the code is the documentation”) means bugger all to people who ask for the software to be built in the first place (people for whom a class is something they went to school in).

The Agile Manifesto states “Working software over comprehensive documentation”. Note the use of the word “comprehensive”. It doesn’t state “working software over documentation”. It also states (and this is all too often forgotten) “That is, while there is value in the items on the right, we value the items on the left more”. It is essentially pragmatic, do just enough that is necessary to allow you to be successful. This is most important in the field of analysis.

On all but the smallest of projects where you have a customer who knows exactly what she wants, is available at a moments notice to the developers and can communicate a clear vision to all involved, you are going to have to invest in some analysis. I’m not talking about writing-a-bunch-of-stories-analysis, I’m talking about understanding the business context, producing a product statement, segmenting customer needs. Maybe it is crafting an aspirational visual representation of the end product, wireframes, an information architecture, an imaginary product “fact-sheet”.

I’m not saying do reams of analysis for the sake of it. I once worked on a government project where I spent three months specifying requirements and designing business processes for a scheme that was inevitably going to change when new legislation came out. That was stupid. Just enough analysis is not only volume and content, but also its timeliness. It would have been sufficient to identify the broad scheme requirement as something in the pipeline with the detail to be fleshed out when it was required. That way we would know about it up front, and act upon it when required.

Developers are smart people, they don’t want to write code for the sake of it. They ask questions, why are we doing this? “Individuals and interactions over processes and tools”. Nothing in that line about not using documentation. Just the right type of documentation to help facilitate the conversation. “Individuals and interactions” lack permanence - the business guy doesn’t want to explain the who’s and why’s to every new developer that comes to the project. They expect to state the project background once and it to persist through the project. (Ask a business guy to repeat this stuff more than once and he’ll soon get annoyed).

Bottom line: Do up front analysis and be proud of it. Make it just-enough in a format that is appropriate (so why is it suddenly OK that it is on the Wiki rather than in a Word document on the corporate LAN?) Get it out there!! Stick it on the walls, let everyone see the business objectives, who the users are (personas), the competition, the wireframes, the product mission statement.

Imagine.

I go into a store and a salesperson helpfully shows me the product, but I’m not yet ready to commit. She offers me a great deal, I’m tempted, but I want to check it out on the web. She says “great!” scans the products and prints me of a personal card with a short unique identifier and a unique website URL. I search the competitors, the salesperson was right, she was offering me a really good deal. So I got to their online shop and enter the URL and there is the tailored deal that the salesperson told me about. It has even got her name on it (so I know he’s going to get some credit for the sale). I get through to the checkout screen. I enter my personal details and I’m just about to buy, but I’ve got a question about the terms and conditions so I take a pause in filling out the form. There’s a number on the website and I get through to the call centre. I don’t have broadband so I loose my connection. The voice at the end of the phone knows who I am and where I am up to. I’m ready to commit… but she apologises, she doesn’t have any in stock. I’ll have to wait seven days. But I could pick it up from the store tomorrow if I want (or even a store close to where I work) or I can get the store to deliver if that would be more convenient. I’m delighted. The next day I go to the store and it is waiting to me. The sales person smiles. She didn’t take my money, but she ultimately made the sale and she’ll be rewarded for it.

Fantasy? It shouldn’t be. Thinking in terms of the customer experience and the customer journey is only the first baby step. The giant leap is to get IT bought into it and implement a solution that is not going to cost the earth and take years to (not) deliver.

And that’s where ThoughtWorks comes in. We thrive on getting everybody together and using creative, collaborative and highly visual techniques we quickly get everybody to consensus on the vision we want to move forward on. Because we are an IT company, we understand the opportunities and constraints with technology. But most importantly because we use lean and agile techniques to delivering technical solutions we are responsive to change, flexible with emerging requirements and can focus on getting things done – the baby steps – whilst working towards the giant leap that will win lifetime value for customers. Hmmmm. That’s beginning to sound like marketing blurb.

Let’s imagine a mobile phone provider that that has an on-line presence as well as a high street retail network. Their current website was built several years back on legacy technology; it is slow and has a conversion rate lower than industry norms. Along with having poor usability, the current shopping cart functionality does not support the concurrent usage figures that are hitting the site. The business takes the output from their web metrics and throw these at IT and demand improvements. And a new IT project is born. Rebuild the existing site on a new platform. They get a design agency to handle the look and feel. The functional requirements are built upon the existing functionality and chunked into functional silos:

• Content managed brochureware site
• Phone selection
• Tariff selection
• Shopping cart
• Order management

A typical project process. That is flawed. It is starting with a functional premise. An alternative is to think in terms of the customer and customer journeys.

We can start by asking who the customers are. Almost certainly the marketing department has a customer segmentation model - this is a good place to start. That may give us basic attitudinal and behavioural details on customers, but we need richer data. How do customers shop for phones? So we go and spend time in the stores and observe how people buy them. It soon becomes clear that the choose phone - choose tariff buy model is a journey that is only taken by a certain number of customers. Other customers come into the store with intentions - they don’t know what phone or tariff they want, but they know what they want a mobile phone for. Other customers come into the store asking lots of questions, they are doing research; they leave the store with the sales guy’s number, and costs for a couple of phones and tariffs. We look at the competition and see how they sell phones. We look at Amazon and eBay and expedia and see how other retailers sell products and experiences on the web. We synthesise our research and suddenly we have a whole bunch of new requirements. Gasp! Scope creep. Indeed if we list them out into functional silos again:

• Content managed brochureware site
• Lifestyler phone selection wizard
• Save a quote
• In-store quote save for on-line fulfilment
• On-line purchase for store fulfilment
• Phone selection
• Tariff selection
• Shopping cart
• Order management
• Etc

The business is excited and IT is despondent. When the business announce the date all this must go live by, the letters of resignation land on the IT directors desk and they start looking for contractors. It does have to be this way. You can have your cake and eat it.
Rather than thinking about vertical functional silos, we should think about horizontal slices through the functionality. Slices that support customer journeys. We can start with simple journeys to start and build complexity as we prove our process and new platform, mitigating technical risk as we progress.

The first release probably needs to demonstrate the new platform works: we can deliver on time; that a new shopping cart interfaces with our legacy warehouse order management system; etc. What’s the bare minimum we can do that does this and delivers business value. How about a microsite that sells a single product. Customers are directed to the microsite via a URL published on a flyer handed out in the stores.

As a customer who has picked up a special offer N80 deal flyer, I want to buy a Nokia N80 on a pay as you go contract

Our acceptance criteria:

Given I enter my personal details and credit card details When my credit card details are validated Then send order to warehouse to dispatch phone and activate contract.

We can decompose this requirement into discrete requirements, “stories” of sufficiently small size and estimate them. We’ll soon get a project velocity and because it is only a small release expectations, risks and dependencies will be easy to manage. We’ve not had to wait for months to get something out, everybody is happy.

We identify that a profitable segment of the market are the aspirationally clueless. People who want a mobile phone, realise they are a minority who don’t have one but are too afraid to admit they have no idea what they want. So we build a new customer journey.

As an aspirationally clueless I want say what I do and how I live my life and have a suitable phone selected for me.

OK, not the finest story, but you get the point. This story might take elements of the phone selection and tariff selection functional silos, but just enough to realise the required functionality. Because we are building around customer journeys, just enough to realise customer intentions that support those journeys we build only what is required. We are not building by feature list. We don’t over promise and under-deliver. We are building trust with all stakeholders. Surely this is the better way to build software, thinking about customer intentions and incrementally delivering to support more complex customer goals. Sadly, people all too often get fixated by feature lists. Because that is what they are used to. Because that is how products are sold. But isn’t there a marketing 2.0 where we sell experiences and go beyond the product. Isn’t that what Virgin does? But I’m probably off on a tangent.

The physical manifestation of agile stories are a description of the requirement (in the form “as a [user], I want to [goal], so that [reason]”) written on an index cards with the acceptance critiera written on the reverse. The developer can pick up the card and work with it. Once the acceptance critiera are met it can be put in the pile of completed cards. If at any stage of the process we are not happy with the card, given that it is only a “promise for a conversation,” it can easily be torn up and rewritten. Tearing up cards is a powerful statement. We don’t like what we’ve written? That doesn’t matter, rip it up and start again. That works well in the opening stages of a project, but sooner or later the cards will be copied into a spreadsheet and this is where the problems start. We become attached to the story; good project management discipline demands we keep an audit trail of what we do. Suddenly it is not so easy to rip up the card. Maybe the initial story did not truly represent the requirement. More often than not the story title, and detail will remain the same, but a notes column will be spawned in the spreadsheet and the change to the story will be entered as narative in this column.

Clearly this is not a satisfactory way of doing things. Part of the agile coaching process has to be around the flexibility of requirements, and this includes refining, rewriting and splitting stories as the project progresses. The underlying scope of the project will remain the same, however inevitably the estimates will change. This is often difficult to accept if you are versed in traditional project methodology. At the beginning of waterfall projects you have certainty, clearly defined requirements and a plan to guide you by. It is towards the end of the project where deadlines slip, scope is managed by change requests and IT is cursed as being unreliable, untrustworthy and the breaker of promises. The reverse is true with agile. There can be a whif of unreliablity in the early stages of the project, particulalry if there is no clear plan. This is excerated with an excel storylist that changes by the day. The difference is that you are more likely to succeed in delivery when going with the agile approach.

The bottom line has to be an acknowledgement that there will be pain during the opening weeks of a project. Stories will be ripped up - delete them from the spreadsheet and don’t bother to keep an audit trail. Agree that the story list will be in a state of flux for the first few weeks. And once the project is settling down, once we have a better understanding of the project and are happy with stories, only then should we use formal PM tools with confidence.

Hello. I’m a developer. I’m going to build your product. I do what the BA tells me.
Hello. I’m a business analyst. I’m going to articulate requirements for the developer. I listen to the product owner.
Hello. I’m the product owner. I’m responsible for what goes in it. I’m going to tell the BA what it should do. I listen to the sales Manager to find out what features the product needs.
Hello. I’m the Sales Manager. I know what features my customer wants, I listen to them.

Hello. I’m Head of Procurement. I’m responsible for selecting the product. I tell the Sales Manager in the product company what we want. I know what we want because I listen to the Division Managers.
Hello. I’m the Division Manager. I want a product that does %%&***£$%£ to drive my sales. Give me a product that does that.

Hello. My name is Sally. I use the product. You know, the thing I really like about it is $%$£$$£^. And here’s a list of what I really hate. Give me a bit of $££%£$”£ and I’d be so much more productive. But noone listens to me.

Hello, I write this blog. I’m an interaction designer. I’ve just sat with Sally for the morning and seen what she’s done. And you know what - we’re getting this wrong. What she really needs is ########. That would really add value.  And it’s is far simpler, quicker and cheaper to deliver than what your guys were proposing.

Once upon-a-time there was no such thing as “legacy” in IT. It was a time when systems were shiny and new and development was Greenfield (and green-screen). We’ve moved on, IT has grown up and legacy systems are abound. Version numbers increase, licenses expire, software is no longer supported. “Upgrade” and “migrate” become priorities on the CIOs agenda.Because upgrades and migration projects have an IT focus, they generally remain in the ownership of, and funded by IT with the business only playing a peripheral role. After all, the requirements are already known; just move (aka “port”) everything that is “as-is” to the new “to-be”.

The reality is all too often slightly different.

It is a common misconception that “porting functionality” is a simple re-write. Here’s an example of a bank who was engaged in migrating its legacy applications onto a new, single stack environment. There were 39 legacy applications that supported 280 processes.

The original business case conducted by the IT organisation was built upon the assumption that 100% of the functionality could be ported. When these figures were shared with the business they baulked. They were incredulous that IT could be building something new, and building all that was wrong in the existing processes on the new platform. What they didn’t have was a business case that articulated what the cost “wrong” was. So the project was put on hold, no longer could it be soley in the ownership of IT, the business needed to ratify the requirements.

The business took an enlightened approach to requirement ratification (they got me involved!) We ran a series of focus groups with key stakeholders, then went into the field undertaking what I could pompously call ethnographic research. We spent time shadowing staff on the ground, observing staff-customer interactions, watching how they interacted with the technology, what applications they used, how long they spent on them and what bank processes they touched. It rapidly became clear that much of what IT was proposing to “straight port” was not fit for purpose. Simple, core bank processes took up significant customer time. For new staff to get up to speed with the basket of applications, it took weeks, if not months.

What soon became apparent, (as expected by the business), only a fraction of the overall functionality offered to the bank users was actually used. Indeed of the thirty nine applications that users had access to, five were redundant; their functionality was never used or was replicated elsewhere. When looking at banking processes that the applications covered, almost a quarter were ripe for redesign. Initially there was resistance to this figure; after all, the processes existed “as-is” and the bank was working with them. The original business case did not justify the significant additional cost that redesign over port would offer. But the ethnographic research gave grounds to challenge this. We could point to the time that users spent interacting with the technology rather than interacting with the customer. The underlining processes were not necessarily broken, but their technical implementation hindered staff work effectively. For example, on opening an account for a new customer the bank employee more time keying data into the application than talking to the customer. This prevented a conversation; the first personal touch point the bank had with a customer was a poor experience. And focussing upon form filling rather than the needs of the customer left both parties potentially unfulfilled.

Worse for the bank, when an existing customer informed the employee of a change of name and address (i.e. just got married), the employee would visibly sink in their chair. Again. rather than engaging in a conversation, congratulating the customer, talking about their new financial needs following their change of life, they had to update the same information in six different places. The technology was an impedance. And thus a cost.

What if we could reduce the time spent entering data into the system? What if there was time for conversation? Time to probe the customers financial needs…? We could model different scenarios whereby this initial customer meeting could drive revenue with cross sell opportunities. Furthermore, if we could reduce the time spent with each customer and thus increase footfall there would be an opportunity to reduce costs. For example, assume the request for a change of address generates a new home insurance lead, model different conversion rate scenarios and we have a business case for improving the change of address process.

To demonstrate the art of the possible, we created a functional prototype. This started with lo-fi sketches, testing these with users before moving to an HTML prototype that supported different journeys through key processes. This was tested with users in a usability lab. We got bank staff to come in, gave them tasks to complete in a role playing scenario (e.g. Here’s Jon, he is a new customer. He wants to open a current account…) With no training, everyone who played with the prototype was able to accomplish their goals, something that was impossible on the current applications (that remember, IT just wanted port). For the most data-entry intensive process, that of completing a new customer account opening, we were able to reduce the time taken by more than 30%. And this was for novice users who had never used the system before. We now had metrics that we could input into the business case, to further strengthen the case for redesign.

And that’s when I left the project. Some functionality was still ported, but the focus shifted from an IT owned project to a business owned programme of work.

This case study demonstrated the fallacy that porting functionality should ever be a simple task that can be driven by IT. It provides an excellent opportunity to audit what you have got and make things better. Almost undoubtedly there will be a compelling business case for doing something more drastic than an IT owned project to make changes to the underlying technology. And the best way to demonstrate this? Ask the people whose lives are impacted by the technology. Use prototypes to test ideas of change. And take measurements.

(I’ve been on holiday, hence the ability to write long blog entries. In case you were wondering!)

Taking a look different UK banking web sites a consistent theme seems to appear. There is a fundamental mismatch between public brochureware site and the secure transactional site. Banking brochureware sites are generally (but by no means universally) reasonably good. Their look and feel has evolved over time. No bank (yet) offers a web 2.0 look and feel but some get close. Lloyds TSB has a very clean and polished feel.

The LTSB site is customer focussed, indeed the “interactive demo” of their internet banking offering introduces different personas to explore different scenarios. Can we expect their internet bank to offer a compelling customer experience? To be driven around customer needs?

Well maybe. But there is more to a compelling experience than just usefulness and usability. There is something about the aesthetic execution of the proposition. What it looks like. Attention to detail, creativity… sadly missing with the transactional site. Is it the case that the agency who worked on the public site went nowhere near the transactional site? Probably. After all the skills and ownership needed to build a website are different from those to own and build what is effectively a business application. The primary stakeholders in the public site are marketing; the primary stakeholders in the transactional site are IT and operations.

Lloyds TSB are not alone. Smile are an internet bank. But take a look at their tables. In 2006 who still uses cell borders and padding?

First Direct are another bank whose primary channel is the web. And yet they exclude more than 30% of customers who would wish to have a relationship with them but do not use the browser they choose to support.

Barclays have got a great new brand that manifests itself on their public site, yet this has not worked its way down to their transactional iBank. Don’t get me wrong, iBank is pretty good (the interaction design was created by experts – ahem, I thank you – and was extensively usability tested. But this was in the dot-com boom times when we still had to get over fears over internet security). Yet six years later, apart from some changes to the stylesheet, little has changed.

On the HSBC net home page they are almost saying our site is so slow you need to do something about it with your browser.

My hunch is that there are a couple of things going on here. Firstly, most banks implemented their internet banking applications during the dot-com boom. They were as much a reaction to the times as a strategic imperative. being rushed out bolt-ons to legacy banking applications. Almost a decade later and little has changed. And where legacy systems are being overhauled – SOA are three big letters in the banking IT world, I wonder to what extent changes to the customer experience are tabled on the agenda.

It makes sense for the brochureware site to be owned by marketing. With ownership marketing are free to choose a creative agency to implement a brand compliant look and feel. IT’s primary involvement in building anything was in commissioning the Content Management Solution (and updating the propriety software when the licences inevitably expire and the current version is no longer supported. The brochureware site can therefore evolve; it is probably built and maintained by people who understand the web. That is why these sites should by and large be cross browser and DDA compliant. So this brings me to my second hunch; the question of ownership. The public site is owned by marketing, the transactional site is owned by IT and operations. And their priorities are quite different. Whilst marketing people generally aim to have a polished look and feel, with a good attention to detail and an understanding of the customer intentions, the priority of IT is rather different. IT thinks in terms of requirements. And the look and feel is “gold plating” that is de-prioritised when deadlines slip.

It is time to bring all the parties together. Anywhere large IT projects are on the CIO agenda, “Infrastructure renewal”, “Service Orientated Architecture,” “Legacy refresh” etc. These should provide the marketing organisation the opportunity to address the customer experience and refresh the interactive experience of the transactional web site. Bring it up to date. And maybe soon we’ll start to see Bank 2.0 applications. Hopefully sometime before Web 3.0 becomes vogue.