dancingmango - Marc McNeill

User interface is a disruptive technology

Thursday, 2 April, 2009
By: marc

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

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

Are you managing expectations beyond the team?

Monday, 30 March, 2009
By: marc

There’s this idea called the Disconfirmation of expectations theory that states that having unrealistically high expectations from the adoption of a new IT application will result in lower levels of realised benefits. Get customers excited about a new product and fail to deliver on it and you will have unsatisfied customers. And unsatisfied customers are unlikely to use the product to its full advantage.

There is a risk with products developed using agile approaches that they fail to deliver on their initial promise. The immediate stakeholders know that the product will evolve incrementally, but is this true of the broader audience? Are they aware of the intended regular heartbeat of delivery or are they expecting a fully featured product at the first release. How are you managing expectations beyond the immediate product team?

Be wary of what you say early on. Creating a vision is essential but be mindful of how this is communicated. Early demos, proof of concepts, prototypes, wireframes often show a vision of the end goal, several releases into the future. Words are easily forgotten, explaining that this is an end goal vision is not enough, you must show a vision of what the cut-down product for the first release is and ensure it is appropriately communicated.

Expectations work both ways, it is easy for the business to tell IT their requirements and assume they will be developed in their entireity in one go. Similarly it is easy for agile developers to expect the business to understand their incremental approach to delivery. The key to success is effective change management; identifying all stakeholders (both core and peripheral) and create a culture of agility that goes beyond the immediate project team. In a large organisation that maintains more traditional approaches, agile projects must be supported by a well designed communication plan that builds the relationship between both IT and the business. Identify whose life will be touched by the product and develop a strategy for communicating to them. This doesn’t mean “they can see what is going on on the project Wiki” this means someone taking responsilibity for listening, engaging and evangelising on the product, the project and its goals.

Personal branding is more than stoking your ego

Thursday, 26 March, 2009
By: marc

It is easy to knock social media and building a prescence and profile on the web as little more than stoking the ego. “I’ve got more Twitter followers than you”, “I’ve got more facebook friends, more subscribers to my blog, more linkedin contacts…” But there is more to it than that. The way you use social media should be about building you as a brand.

Take a look at David Armano’s excellent presentation on Brand U.0. Celebrities have brand, and with that comes influence. Similalry people like you or me who develop their brand start to have influence. And that influence gets you places. At ThoughtWorks we are recruiting for a new Information Architect role. Rather than describing the role in terms of skills and competencies, the starting point has been ‘we need a person “like that”‘, pointing to to both particular people within ThoughtWorks, and also on the broader web, looking at LinkedIn profiles, blogs etc. If you have a brand you have already made yourself stand out. In these challenging times your profile is not about your ego, it is about your future.

Have you considered the cost of context switching

Tuesday, 24 March, 2009
By: marc

One of the great things with running a project with Microsoft Project is that it enables you to allocate resources to activities and you can assign the time they work on each activity. A resource can then work on several projects at the same time, 50% on project A, 50% on project B.

With this ability it is easier to accommodate multiple projects that the business request. Rather than having to say we can’t start on a project in six months when the current one finishes, we can run both projects at the same time, using the same resources. We can do things in parallel rather than in series.

Only it doesn’t really work like that.

One of the great things with running a project with Microsoft project is that it enables you to allocate resources in a way that hinders productivity, effective planning and quality.

The problem is with context switching and the overhead that multi-tasking brings. This article succinctly describes the problem.

No matter how efficient you think you are, multitasking comes with a high cost. Because we’re people, we don’t swap out the content of our brains as easily as a computer does, and we definitely don’t swap in the old state when we’re ready to return to the original task.

Gerald Weinberg, in Quality Software Management, Vol. 1, Systems Thinking (Dorset House, 1992), estimates the context-switching cost among three tasks to be 40 percent. That means that 40 percent of your available work time is spent on non-task activities. The rest of the time is split among the three projects. So, if you thought that in a 45-hour week, you could spend 15 hours on each of three tasks, don’t kid yourself. You’re really spending eight hours on project A; eight hours on project B; eight hours on project C; and 24 hours context-switching, figuring out where you were and what you have to do next. The time spent on each project works out to about half of what you expected.

So whilst it is easy to appear to please business sponsors by taking multiple projects on at the same time, and the model of working in parallel rather than in series being a politically favourable approach, in fact the costs of multi-tasking far outweigh the benefits.

DRM stupidity

Monday, 23 March, 2009
By: marc

A year ago we arrived in Hong Kong with no TV, but a Mac Mini, broadband connection and a stack of DVDs from the UK. When the DVDs were all watched we turned to the local video shop to hire or buy DVDs. Only they would not work. Hong Kong is in a different region to the UK. The DRM of dinosaur logic does not allow you to be an international traveler. If we wanted to buy new DVDs in Hong Kong we would have to make a decision to effectively throw away our UK DVDs. And it was then that we really discovered Bit Torrent…

I was just a humble consumer wanting to do the right thing but was denied this by the entertainment industry and their flawed business model. (Indeed rather than preventing piracy DRM encourages it). Now our own Prime Minister has experienced the same thing after being given a collection of Region 1 DVDs by Obama that he cannot watch because they are unplayable on his Region 2 DVD player.

“Maybe this experience will help the British government understand how many of the entertainment industry’s efforts to strengthen intellectual property controls do little more than irritate legitimate consumers.”

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

Thursday, 19 March, 2009
By: marc

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

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

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

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

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

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

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

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

What’s a URL?

Wednesday, 18 March, 2009
By: marc

Do you know what a URL is and what to do with it? It sounds like a stupid question, of course you know what a URL is, everybody does! But you’d be wrong. Having observed countless users interacting with websites, it is striking how many people enter the URL into their search engine. My hypothesis is that the URL bar in the browser is something technical and best left alone. But don’t just take my anecdotal evidence for it, look at the top 500 search engine keywords– in the top 20, four are URLs that could have been typed into the browser address. Look at the keywords in your web analytics, almost certainly (if yours is a B2C proposition), your URL will come in the top ten keywords for your homepage.

Lesson number one: people are not as tech savy that you think they are. If they don’t know how to use URLs, what other assumptions are you making about your customers in the product you are developing?

Lesson number two: your URL is not as important as your ability to be found in the search engines. It is refreshing to see an increasing number of companies not giving any URL in their print or TV advertising, rather “search for us on google using <insert term>”. But before you go off engaging SEO snakeoil merchants, the basics of optimising your website for search engines (SEO) are hardly rocket science (especially if you are an already trusted brand), and Google let’s you in on a lot of their secrets which is 80% of what any SEO company will tell you. Only google give it to you for free.

Someone should talk to the minister about agile

Thursday, 12 March, 2009
By: marc

So another government IT project fails to deliver. The National Offender Management Information System had been budgetted to cost £234m (total lifetime cost) and take four years to complete. Three years in and the costs had spiralled, with a new lifetime project cost estimated at £690m. The plug was pulled and a new three year project at the cost of £513m was commenced. Poor project management was blamed, but I’d go further and blame the project approach as well. The Minister responsible says why;

“As soon as the extent of the projected costs and delays to the project were recognised, we took immediate steps to halt the project and consider the most cost-effective way forward which effectively preserved the work done to date”

So let’s get this straight:

It took three years to recognise that a project to implement a single database had gone wrong.

Contrast this to an agile project where progress, costs and risks are continuously monitored. But what does the goverment do? Continue with the same approach as before with some new project managers on the job. And wait another three years before any value will be delivered.

Thinking about value in terms of advantage and benefit

Tuesday, 10 March, 2009
By: marc

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

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

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

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

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

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

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

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

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

Experience let down by a jobsworth

Monday, 9 March, 2009
By: marc

I flew back into London early on Monday morning from Singapore on a Qantas codeshare with British Airways. The in-flight BA experience was flawless, after thirteen and a half hours in the air we touched down fifteen minutes early. No problems with passport control and then I hit baggage collection.

The baggage carousels weren’t turning. A number of arrived long haul flights were listed with an ‘awaiting carousel’ message. Frustration was in the air. I wandered towards the British Airways service counter interested to see how BA were handling this customer experience issue. Not very well was what I saw.

“Look! just stop complaining and let us do our job” shouted the ‘Team Supervisor’ at an irate customer who had been waiting for almost an hour. Rather than providing information, transparency and honesty, the face of BA was shouting at customers with a ‘jobsworth‘ attitude. All that good work on the plane was lost. A dozen or so customers witnessed the rude abuse that the employee was ranting. This maybe acceptable if you are Ryanair and your brand is not built upon customer experience, but for BA it most certainly is not.

Stories of bad customer experiences are like viruses. Ian McKee describes a study that suggests that “overall, if 100 people have a bad experience, a retailer stands to lose between 32 and 36 current or potential customers”.

Unfortunatly my phone battery was dead, otherwise I would have recorded the interaction for your viewing pleasure. Then it would not have been a dozen people who witnessed the terrible customer service. More than 366,000 people have viewed South West airlines seven hours on the tarmac (and google returns almost 19,000 results for “south west airlines 7 hours on plane tarmac“). Employees need to understand that they are brand ambassadors, in a world where video cameras are ubiquitous poor customer service goes beyond the word of mouth, it now becomes viral.

Bruce Temkin shows the below ‘experience wheel’ that lego use for designing customer experiences. It is relevant as it touches the airline experience, mapping all the customer touchpoints, and what the make or break moments are. This is a useful exercise that BA could learn from. Delivering a compelling customer experience with your core services is no longer enough, anywhere that your brand touches customers must be excellent.