dancingmango

I’ve only thought of blogging about Lois Vuitton once before and that was on how they positively encourage queueing outside their stores during busy periods. It’s a pretty strong brand that can tell its customer to hang about before being allowed to come in and shop.

This time I’m not blogging about them in a positive light, and nor are many others. Jeremiah Owyang describes the situation they are in well. Their brand has been hijacked by Nadia Plesner, an artist trying to raise awareness about Darfur and how the media considers Paris Hilton with her “designer bags and ugly dogs” to be more worthy of attention than genocide in Darfur. She uses an image of a LV bag in her T-shirts. LV take offence and sue, she refuses to budge and suddenly the image, the issue and LV all hit the spot-light. And in this David and Goliath contest, who is going to come out worst? There can only be one looser.

So why didn’t LV just ignore it, or even as Jeremiah suggests, harness the issue, turn it into a conversation that would paint them in a good light? I’ll argue that it is because they don’t understand risk.

There was always a risk to the brand be de-valued by being associated by asociation with Dafur. And this is what the marketing and legal team jumped on with such zeal. Did no-one think about the risk to the brand of turning this into the issue it has become on the web? Laying out the options and doing a risk analysis would have been a worthy exercise.

Option 1. Assess the global impact of nadia plesner, assume it is minimal and do nothing. Risk to brand: minimal.

Option 2. Follow standard route of brand defamation and sue. Ignore association with ‘good cause’, ignore blogosphere. Risk to brand: potentially significant.

Sadly, it seems that LV ignored the whole concept of risk and went with the default option - sue. They are not alone in failing to assess the risks properly before pursuing a course of action. In IT this approach is endemic. Where is the greater risk? Placing all your eggs in one basket, investing heavily in a desired outcome that will be many months before it sees the light of day. Or take a more gradual approach, investing ‘just enough’ to get ‘just enough’, ‘just in time’. The latter approach is lean and agile. A good agile project is a lesson in risk management, building resillience into the process and testing options as you go. It is organic and evolutionary, (rather like nature), as opposed to the plan and control approach of waterfall which is brittle and will struggle to react to or accommodate risk appropriately. I should write more but there is a day’s work ahead.

Exciting times for us in Hong Kong. The inaugral meeting of Agile Hong Kong is next Tuesday, 5th February. Martin Fowler will be attending, hosting an informal Q & A session. It’s sponsored by ThoughtWorks who will be providing the drinks. Check out agilehongkong.com for more details.

So you’ve run a workshop and generated ideas. There’s a list of points on the flipchart and diagrams on the whiteboard. What now? Write it all up in Word or commit the drawings to PowerPoint?

Stop! Ask yourself why you are doing this? Is it just to record the ideas, to socialise back to the group involved in the workshop? Creating PowerPoint slides is not always an inconsiderable effort. It takes time. That effort is waste.

Think of the purpose of what you are doing. Then take photographs of the flipcharts and whiteboard diagrams, paste them into PowerPoint, and think of how much time and effort you have just saved.

One of the (many) things about ThoughtWorks developers is that, whilst they are passionate about technology, (and will happily argue for hours amongst themselves about the relative merits of REST over SOAP or ruby on rails over django), more often than not when they start a conversation with a client, technology will be at the back of their mind. I think it is safe to say that generally the primary driver in the ThoughtWorks mind is business value:

• Why are we building this application?
• What are the business objectives?
• What will deliver the greatest value in the shortest timeframe?

Once the requirements of the business are understood, and framed in terms of their business value, then (and only then) should we turn to the technology. This can often be a challenging message; IT professionals like to think in terms of architecture and platforms, yet often these constrain the ability to truly deliver what the busines really needs.

The development team may be a Java shop and only does Java, yet the end users live in a world of Microsoft.  So what happens - IT develop user interfaces that expose data in a web browser only for the business users to copy and paste it into the tools of their trade - Microsoft Office.  And because IT only do Java that’s the way it has to be.

Value is lost in this thinking.  It is easy to argue on the cost to expand the team requiring new skills by introducing .net into the architecture.   But what is the cost to the business of time spent through inefficient work practices? All to often IT is an end unto itself, rather than the means. IT needs to remember it only exists to enable organisations. The most refreshing CIOs are those that recognise this. Those who focus upon delivering business value and question every big decision - what value is this giving to the whole organisation rather than thinking in terms of their IT silo. In fact, the sort of way that ThoughtWorkers think.

Starting a meeting or workshop with new people will almost certainly commence with introductions.  Usually I will ask participants to say not only who they are and what department they are from, but also why they think they are at the meeting.  If someone is not sure, or says “because my boss told me to attend” there might be an issue.

Last week I attended a workshop run by a couple of our developers from China.  Because paired programming is a fundamental practice to what we do, they asked the participants to do paired introductions.  Participants paired, were offered a minute to talk to each other and then introduce their colleague.  Because the team already knew each other, they didn’t need the minute to prepare.  As each participant introduced his colleague, he emphasised the persons strengths and good points.  At the end of the introductions there was a tremendously positive vibe in the room which set the meeting up for success.  It might have taken a little longer than just doing the straight introductions, but the value was clear; get people to introduce their colleagues - it breaks the ice, promotes the positive (and as a facilitator gives you another hook by which to remember people).

There once was a time that on Christmas eve that I’d be crawling round the pubs getting the worse for wear.  Older and a maybe a little wiser; I’ve just committed a major fraud - I’ve downed the sherry, nibbled at the carrot and filled my daughters stockings with presents - Santa exists.  Honest.

And now I can’t help myself.  I check my mail and scan the blogs I subscribe to and I read something that makes me nod my head in agreement - Robert Hoekman laying into user centred design.  He is so right - most projects don’t have the time for the luxury of doing user-centred design properly.  That is not to say that it can’t be done.  Thirty days to develop personas?  How about thirty minutes?  You can be agile and do user-centred design, at ThoughtWorks we do it all the time.  I’m looking forward to his follow up posts.

So the sensitive personal details of 25m people has been lost and there is a huge political furore over it.  Whose fault is it?  As far as I can see, (and this is my personal opinion,) blame must lie with IT, specifically the IT contractor and either the contract they work with or the perception of that contract.

The National Audit Office asked HM Customs and Excise for child benefit in “desensitized form”.  Sensitive details were specifically asked to be removed, ostensibly to make the file size smaller.  This would require a bespoke query to be run.  It was deemed too costly so it was assumed that a full extract of the data would do.  The fact that this was then burned to a CD, posted unregistered mail and lost is not the point (that is stupidity).  What is the point is the IT contract prohibits the business (in this case the governmental offices) to do their job properly.

What sort of contract demands extra payment for a simple database query for “NI numbers, child benefit numbers and children’s names in order to select a risk-based sample of cases to audit as part of anti-fraud work“?

Surely this is an extra request that an experienced database analyst could easily run in the course of a day?  If not you must ask why not - is it because the database is badly designed with nested tables and stored procedures and stuff that would make a decent DBA go eugchhh (I’ve seen that happen).  If this is the case, the IT contractor has done a bad job; if an electrician worked in your house and left a mess of an electrical installation, would you keep employing them, even if they were cheap?

Maybe however it would not have incurred a cost and this was just the perception;  “we must not… run additional scans/filters that may incur a cost to the department”.  If this was case it suggests a breakdown in the relationship between the business and IT, with tendency towards the  confrontational and transactional rather than co-operation and partnership.

Organisations that outsource their IT often fail to realise what the true costs are.  Anything outside the terms of the contract is a change request.  It is not unusual for the request itself to incur a cost (someone has to write the documentation, specifiy the design, estimate the effort) before a line of code is written.  (At one organisation I worked with that had outsourced their IT function, I was told that to add some basic client-side field validation to a single field on an application form on their website was likely to cost in the region of £60k).  The business starts to believe that everything costs and IT becomes a hindrance and a vicious cycle commences.

How could things have worked differently?  Let’s say the HMRC IT department was run on more lean/ agile lines.  With agile it embraces change.  The request comes in (let’s assume such requests are not regular occurances) and in the morning stand-up the BA describes the request and asks the developers for its feasibility in a word.  Someone says “yes, I ran a simiar querry last month, it’ll take me ten minutes”.  (In reality double or treble that estimate), but it will not have an imact on the developers ability to get thier prioritised work completed.  Alternatively the developers say “given the database structure we have inherited that’s a  lot of effort” or the project manager says “another request?!  pritoritise it like the others!” and it is prioritised in the weekly iteration planning meeting (pushing something else out) and then it gets done.

My hope is that when the inevitable investigation takes place, they don’t just look at the policies and procedures, but also at the underlying structure of the way that IT is managed.

Call it a pattern, a heuristic or a rule of thumb. A fundamental one of those to ensuring usability is consistency. This may be external consistency - for something behaves in the software in a similar way elsewhere. A good example might be the ‘x’ button in the top right hand side of an open window. It is universally a call to action to close the window. If the designer created a button labelled “C”, and placed it on the left hand side this would result in confusion. It is not consistent with the users’ expectations from using other applications. The second type of consistency is internal - do things behave in a consistent manner throughout the application? This may be both in behaviours (e.g. buttons with the same titles perform the same action), and in look and feel - a website has a visual identity and coherence, assuring a continuity of experience.

There may be examples of where internal consistency is not possible. For example a brochureware site that uses a third party for fulfilment or payment. Paypal is a good example of this - the user is taken out of the shopping experience and into a paypal experience. This can be successful if there is clear signposting and use of the paypal imagery on the shopping site to assure the user.

So what happens when you have a large, legacy website that you acknowledge to be pretty poor in the usability front and want to introduce new functionality, or want to rebuild it. If you play the consistency card too strongly you may continue to be consistent with the old design and behaviours. This begs the question, is it better to introduce something that is internally inconsistent, but fundamentally better? This becomes even more an issue when you look to rebuilding your site in an incremental fashion.

As an information architect I can help you design your site architecture - the look and feel, navigation structure, user journeys etc., but this will probably be in its entirety. To build this new site will take time, and assumes a “big bang” whereby a completely new site will be (re)launched. Yet there are probably business imperatives to fix specific areas. If we build in an incremental fashion, and take the agile approach of focussing upon delivering business value, we are not going to have a fully redesigned site to go live with. We are probably going to have (for a short while at least), some parts of the site that are new and some that are old.

Going back to my original question, we can either build this to be consistent with the old site, or do something tangentially better. If we do the later it will probably be significantly inconsistent from other parts of the site, or the original parts of the site. It is in this scenario that I am inclined to throw away the consistency pattern. You may have internal inconsistency if you have a clear roadmap to throwing the old and the new functionality / design is proven to be usable, accessible and intuitive. With this the case, the interaction behaviour and visual identity of the new functionality must become the benchmark to which future functionality is consistent with. And you must clearly signpost to the user what is going on; customers will generally be forgiving if they understand that the changes are in their interests.

It sounds clichéd and old hat, but it is true. Truer now than ever before; the web is an enabler for new ideas. It provides you with the tools for disruptive innovation. Sadly for too many organisations it has become a hindrance.

A recurring theme with many organisations is the length of time it takes to take an idea to market. Especially in retail financial services, where you would expect lead times to be short it is not unusual for innovations to take a year to implement. This seems crazy, it’s not as if there is a physical product to manufactured.

So where are the hold ups? More often than not, they are rooted in the organisational structure. Innovative products often cross business boundaries; whilst customers only see the a single brand, different product teams only see what they are responsible for. They have own objectives that often conflict with other parts of the business; gaining agreement and consensus across all parties can often be a time consuming and painful experience that slows and often kills innovation.

Then there is the technology. Changes to systems have to be scheduled (along with every other request). Unproven ideas are put to the back of the queue. The business starts to perceive IT as a hindrance rather than an enabler and lines of conflict are drawn up.

Channel is the next hurdle to cross. Typically a face to face channel or telephony will be easiest, but getting something on the web? Now a new area of the business needs to be involved, the Internet Channel Team who interface between the business and IT. They’ve got to design web pages, get the creative done, produce requirements for technology to build (and schedule into deployment for which the dates are even further into the future), do usability testing… Long lead times are inevitable.

And then, before the innovation sees the light of day, someone new comes in to rationalise the product portfolio, the innovation doesn’t quite fit in with their new priorities and it is quietly ditched. This half hearted attempt at innovation has taken a year, cost in excess of a million and has come to nothing.

There has to be a better way.

There is. Do things at speed. You can start by sticking some amphetamines into ideation phase. Someone’s got an idea; identify who has a vested interest in it succeeding (or failing) and get them into a room to thrash it out. This doesn’t need to take long. Workshops are best limited to 90 minutes at a time (after that people get Blackberry withdrawal symptoms and loose interest). But if all the stakeholders are geographically dispersed, a structured day’s off-site might be the best solution. Avoid letting people dial in or video conference, this is one meeting where people have to be there in physical presence. Also avoid having too many people in the room, especially when forming ideas (there is a trade-off between having the right people and too many people to make the process unmanageable). Start with the users, the customers, the people whose lives will be changed by the idea. Scribble out personas -describe who they are, what their goals are, the perceptions of your company, of technology. Print out pictures of people that represent the personas, rip out photos from magazines, anything to bring them to life. As the idea takes shape, turn it into pictures. Draw out the customer experience. What would the persona do at each stage. Far better to do this than write it down in a document that can be open to interpretation. Illustrate the touch points. What does technology need to do. (Can we be pragmatic and use roller skate implementation rather than getting bogged down in an integration quagmire?)

Now is where it gets interesting. There once was a time when you would need to invest time and money into producing a heavyweight business model and business case for the innovation. You still need a business case, but at this stage it probably doesn’t need to be too robust; make some basic assumptions then test it. All too often business cases are built on flaky assumptions; build something quick, test it and get real data to build your models on. Again, this is about doing things at speed; a couple of weeks after the first workshop there is no reason why a small team of developers can’t be actually building something to bring the idea to life. So the team is using Ruby on Rails to build a proof of concept. There may be disquiet that this doesn’t fit into the current technology stack - doesn’t matter, it is a proof of concept. Six weeks later the proof of concept is done. It is not a static, prototype that demonstrates linear page flows, it is fully featured and fully functional. It can be usability tested (but more likely you were doing that on wire frames alongside the build). What then? In two months you’ve taken your idea and turned it into something tangible.

Why not put it into the market for real. Whilst IT might not want this Ruby “thing” on their stack, that doesn’t mean it isn’t possible and can’t be done. Large organisations have a testing ground of consumers inside a secure environment - their staff. Use them to beta pilot the idea? Friendly customers are delighted to be part of product development - put it out to a small and selected group of customers, and have some smoke and mirrors processes to handle fulfilment. The objective is to prove the viability of the idea, get data to make informed decisions and make your collective mind up quickly. To fail fast or succeed cheaply.

A couple of weeks ago the share price of BP plummeted because the CEO “did a Ratner” and criticised the company. Essentially he was criticising his company for being inefficient. “There is massive duplication and lack of clarity of who does what”. Yet is this so uncommon? Spend some time in most FTSE 100 company and I’m sure you’ll soon discover duplication, inefficiency and waste. It seems to be the consequence of scale; a growing company gets organised around business units and these inevitably become inwardly focussed and support a silo mentality. These silos soon cease to have a single minded focus upon the stakeholder that matters most, the customer, and instead focus upon the good of themselves.

For example, the organisation may have a number of different products. These are organised into product lines with each product having its own targets. The product lines then start competing against each other; it is not in the product managers interest to consider anything outside increasing the profitability of her own product line. So if this means cannibalising the market share from other product lines so be it. Her bonus depends upon the success of her products.

Undoubtedly she needs IT support. Here comes more inefficiency. Whilst a similar technology may be used by another part of the business, it does not entirely meet her requirements. So a new product is built. Throw in outsourcing and inefficiencies are abound. It is not in the interests of the vendor to strive for simplicity. (Read PG’s excellent analysis of the problem with outsourcing IT).

Then you’ve got “channel” The Web Team, the Mobile Services team, Telephony, Retail Stores… Again, each has their own P&L and targets, each competing against each other. The talk may be of a seamless cross channel experience, but when the staff in the Stores are remunerated based upon sales they make, what is the incentive to direct the customer to the website to complete the transaction? Better loose the sale than do that.

Once a product has been sold it requires support - another bunch of stakeholders with their own (muffled) agenda. Customer acquisition is more costly than customer retention, yet the focus is usually upon the former, regardless of how wasteful this may be.

And what of the “Gold” team, looking after our “best” (read most profitable) customers. Another bunch of stakeholders with their own priorities, requirements and bottom line. All different parts of the organisation competing against each other. It’s not a team effort with a common goal (maximising customer and shareholder value), it’s a battle lining business unit against business unit with a common enemy of IT.

Is there an answer to organisational inefficiencies? There’s a solution to everything if you’ve got enough time and money. But for a start I’d love to know of a company that has scaled and has maintained a true focus upon the customer. That doesn’t internally compete for their customers share of wallet. That is transparent and shares knowledge effectively, where duplication is unknown. That uses IT strategically to support the business meet its common goals. An organisation that remunerates according to total value earned regardless of where it was fulfilled. An organisation that, regardless of the fluff in the annual report really does deliver value for the shareholder and customer, and waste is the common enemy.