marc, Author at dancingmango - Marc McNeill

About a successful project that was a failiure

Wednesday, 18 November, 2009
By: marc

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

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

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

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

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

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

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

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

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

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

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

Put some fun back into your business

Friday, 23 October, 2009
By: marc

Litter bins on the street aren’t the most interesting of objects. The design is pretty standard, with variations on a couple of themes – cylindrical or rectangle and colour being the primary tool of differentiation.

“To throw rubbish in the bin instead of onto the floor shouldn’t really be so hard. Many people still fail to do so. Can we get more people to throw rubbish into the bin, rather than onto the ground”

One answer is to make it more fun. Check out The FunTheory for other ways of improving mundane products by making them fun.

Now think about that mundane product of yours. Maybe it is your on-line retail bank. It is getting tired and it is time for a technology refresh. You’re going through a process of capturing requirements. How about playing an innovation game, but base it on the concept of fun. What could you introduce to your product that would make people smile? What would make people laugh? OK, so after a while the bin would no longer be fun. What makes it fun is the element of surprise. Again, what could you drop into the product that would surprise people. What would a ‘fun’ internet bank look like? Focus on fun and surprise and you might uncover a nugget of inspiration that will make the final product.

What would you save?

Tuesday, 13 October, 2009
By: marc

A couple of weeks ago a colleague’s house burned down. An electrical fault sparked it in the next door neighbours garage, the wind turned and within minutes his house was on fire. His first priority was to get his family out of the house. He had an opportunity to run back in to grab one thing. Something. Anything.

If your house was on fire, what would be the one thing that you would save? (He saved the hard drive with all the family photographs on).

What do you really need?

Monday, 12 October, 2009
By: marc

A couple of clients I’ve worked with recently have been consolidating their application space, decommissioning old technology and replacing it with a new single application with a core user interface. I’ve written about this before but it is worth revisiting. All too often the starting point is the functionality and the features of the existing applications. The client states we must at the very minimum maintain feature parity, and where the business needs, enhance functionality. Starting with the existing applications and as-is processes is a good start, but never where the focus should lie. The focus should be around the business intent; what are the business goals the system is helping the user achieve? Spending time with the end users of the system is enlightening. It is a crude picture, but this shows what the truth often looks like.

There are three systems that have been developed over the years, commissioned by different business stakeholders with different budgets and different delivery teams. Of each of these systems only a fraction is ever used. (This is especially true of vendor products that have requirements rooted in the market rather than the specific needs of that organization. Think about how many of the features in Microsoft Word you use). If there is significant functional redundancy in the applications, there is also duplicate functionality that results from the different development legacies. It is not unusual in such a landscape for the user to enter the same data into each system. Not something you would wish to replicate in a new world.

In building a new application, the place to start looking for requirements is not so much the as-is processes or existing applications. The place to start is the business intent and what the business actually wants the system to do. More importantly, that means starting with an open mind and challenging notions of process complexity. Is the process complex because it really is, or because the current systems make it that way? In my experience, more often than not, it is because of the former. Spend time with end users, see what they do today. By asking seemingly stupid questions, taking a starting position that the process is simple and challenging ‘why not?’ can yield valuable insights. By all means consider the as-is world, but don’t let it cloud your judgment in designing ‘to-be’.

NFR 001: Make it easy to use

Monday, 5 October, 2009
By: marc

Designing an enterprise application. Recently someone was grumbling to me about the statement “easy to use”. They felt it was a worthless statement; what does it actually mean? For them it had no meaning and thus should not be used at all. This is nonsense. “Easy to use” is a worthy statement that should either be treated as a non functional requirement with clearly defined acceptance criteria, or as a measurable KPI. So to start the thinking on defining what easy to use must mean to your project, try using the BDD format of given, when, then:

As an Expert User
Given I have had no training
When I have to complete <insert goal>
Then I will be able to accomplish it in under five minutes

As a Novice User
Given I have had no training
When I have to complete <insert goal>
Then I will be able to accomplish it in under seven minutes

Links

Dan North introduces BDD

Do customers want to customise your site?

Monday, 28 September, 2009
By: marc

Have you ever added a custom tool bar on your office set up? Have your non-techy friends and family changed the background image on their desktop or changed their screen saver. Is there a demand for customisation?

So here’s the question. Do people really want to make your homepage look the way they want it to? Is there a demand for iGoogle and netvibes customisation? They look cool and are attractive to the geeks in us, but do they have mass market appeal? Is there any research out there on the take up of user customisation?

“…back when Windows 95 was released, users could easily change My computer to something more personal. Apple users had been able to do this for many years, and many of them did name their computers. But few Windows users took the opportunity to do this, suggesting that they saw the computer as more of a tool than something with which they wanted to have a personalized relationship.” (David Malouf)

Just because we can doesn’t mean that we should. When you log into your bank account it could look like netvibes, complete with BBC news feeds and YouTube videos (you decide what you want). But should it?

Why should your customers see your website as something to have a personalized relationship with, especially if you don’t engage them with a personal relationship throguh your other channels?

Agile nursery

Friday, 25 September, 2009
By: marc

My daughter has just started at nursery school. Daddy, she asked me, do you do show and tells? Ummm, yes Olivia, we do. But we call them showcases. Daddy, when you start work in the morning do you sit in a circle? Ummm, yes Olivia, we do. But we don’t sit down. We call that Stand-ups. Daddy, do you draw pictures? Yes, we do, we call those wireframes. Daddy, do you play with Lego? Yes, we call that the lego game. Olivia. Yes Daddy. Do you want to come and work with us?!

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

Friday, 21 August, 2009
By: marc

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.

You need to accelerate and change gear to get up to speed

Thursday, 20 August, 2009
By: marc

Velocity is a simple concept to grasp when planning and managing an agile project. It is one of the first formula you learn in maths (or is it physics), speed equals distance over time. On a project the distance is scope, measured in the number of ‘points’ you need to complete. So if the team has a hundred points worth of scope and a velocity of ten, they will complete distance (scope) in ten weeks. It’s a simple calculation, but is dangerous and wrong. It fails to take into account acceleration.

Just in the same way that it takes a car time to accelerate to a meaningful speed, so a project takes time to reach it’s planned velocity. To reach 60 miles an hour takes ten seconds and means moving through the gears. You don’t put your foot on the accelerator and suddenly find yourself doing sixty. Nor do you put the car into forth gear and expect to move without stalling. It is the same in agile projects. Velocity is misunderstood; you cannot expect to have your planned velocity immediately without acceleration. Similarly, putting a fall sized team onto a project is like trying to start in forth gear. You will stall.

When planning an agile project you need to consider acceleration. The first iterations will be slow as you come up to speed. Secondly you need to be in the right gear for where you are at. Start in first (small team) and change gear (ramp the team up) as the velocity requires it. Better to have the engine screaming in first (change gear) than to have it stall before it’s even got going.

Sadly, this means the simple pictures on burn-up and burn-down charts are wrong. They need to take into consideration acceleration and appropriate gearing. And that is advanced maths.

How do you answer the phone?

Friday, 14 August, 2009
By: marc

IVR, (that’s the automated routing of phone calls) is an unpleasant reality of multi-channel service. Let’s assume that you are committed to using it, how much time have you spent in creating the messaging. Two examples of trying to put a more human touch to something that is inherently not human and machine driven.

Firstly the Halifax. Listen carefully to what happens after you key in an option. You here a key click. You are then prompted to enter your account number. “thanks” the voice says, “I’ll just enter that”. And you hear a clackerty clack of data being entered into a keyboard. BUT YOU ARE A MACHINE!!! It is a nice touch, but it is trying to make an interaction that is clearly not human more personable.

Second example is the Financial Obudsman. “Thank you for calling” says the voice. Not a stock, model voice, but a real voice, “I hope we’ll be able to help you. My name is Walter Merricks and I am the Chief Ombudsman…” The message is clearly a recording. There is no attempt to be anything but a recording, but giving the voice a name and explaining the nature of IVR is a real human touch. Even better, the narrative about recording the call- it is not scripted from the IVR manual. It talks to the customer in language they understand.

If you must be mechanical in your communications with customers, be human, be transparent, but don’t try and pretend to be what you are not.

Links
Halifax | Financial Obudsman