dancingmango

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

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.

Thinking about value in terms of advantage and benefit

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.

The user journey

“Faster, slicker, easier to use.  That’s how we sold it to the business.”  It is a common theme, IT have a system that is costly to maintain, hard to extend, is on a dated platform and no longer fit for purpose.  The business are persuaded of the need for a replacement.

This is what happened at an organisation I recently visited.  But it didn’t quite go to plan.  A number of years later and they’ve got an application that is slower, uglier and harder to use.  What happened was the business intent was distilled into requirements (based upon the existing functionality).  Each requirement was captured as a control on a screen.  These were bundled up and sent to India for coding, and the developers went and built a bunch of screens.  They considered interface design but not interaction design.  They focussed upon technical processes rather than user journeys and the resultant deliverable was something that functionally ticked all the boxes (it did what the specifications said it should do) but was ultimately rejected by the people it was intended to help. The code may have been great but that meant little to the business who found the application a pig to use.  Another failed multi-million dollar IT project.

User interface design is more than just screen design, it is about the journey the user takes to accomplish their goals.  Remembering that could have saved this particular organisation a lot of money.

Innovation and funding in lean times

It’s budgeting time with many organisations putting together their budets for 2009. In the current climate IT is an easy target for cutting costs. Stories such as “no new non-core projects till 2010″ and “no project that can’t demonstrate a postive ROI in 12 months” are abound. There is a risk that only focusing upon projects that keep the lights on will do longer term damage to the company. Seth Godin writes:

Wealth is created by productivity. Productive communities generate more of value.
Productivity comes from innovation.
Innovation comes from investment and change.

Annual budgeting cycles combined with inflexible development approaches preclude real innovation. It is hard to justify any cost, especially untested products that brings a burden of risk to the organisation.

There are two solutions that go hand in hand. Agile software development enables IT to release value from production earlier and more often than waterfall development. Rather than significant sunk cost in risky product innovation, it removes waste from the process and focuses upon delivery of working software that is of value to the business, taking the product to market at the earliest possible time.

This is a challenge to the annual budgeting charade where line item projects compete for guessed amounts in return for notional value. (IT put crude guesses – not even estimates- against even cruder descriptions of required features from the business). A better model would be to take that of the venture capitalist, with different rounds of funding. Rather than allocating specific funds to specific projects, far better to ring fence budget for ‘product innovation’. Within this pool of cash projects compete with each other with a pitch for seed funding. Those that are successful go straight into agile development with sufficient funding for a first release (say three to four months). Getting to production (and to market- internal or external) will validate further funding or equally enable the business to make an informed decision and kill the idea – fail fast, fast cheap.

Do Business Analysts Destroy Value?

The usual approach for a Business Analyst is to start with the ‘as is’ situation and then model a ‘to be’ solution.  In understanding a problem, defining the as-is situation can take a number of weeks if not months.  Once the current technology, process and working practice are understood, the BA begins to define the solution.  Inevitably this solution is based upon what has been learned during the as-is analysis, thus the majority of their time is spent dwelling in the current reality rather than what could be.

Where is the value in that?  Where is the value in modelling a solution that is based upon that the current way of working?  What can you really learn about the business intent from the current as-is process?  A process that is based upon technical decisions, practical constraints and inherent complexity that were made at the time the software was built (in the enterprise world that was an average of 7.2 years ago), and hasn’t technology moved on since then?  By specifiying a system in terms of the curent reality the BA is missing a trick, and in the process is failing to add the value that the developement opportunity offers.  Indeed the BA is probably destroying value with over complex specifications that do not get down to the heart of the business need.

If Business analysts really want to create value, rather than dwelling in the past they should start with the “to-be” vision.  What are the desired outcomes of the application?  What should it do? (Not how should it do it).  Challenge existing assumptions, ignore perceived limitations and start with ‘blue-sky’ thinking.  What would we really like the application to do?  What are the customer / user goals and how can the application most eficiently (and delightfully) achieve these.  Think about the what, not the how.  Unlike the usual pattern of analysis, spend most of the time in the ‘to be’ world, only visiting the as-is to ask questions and confirm assumptions.

But that is only the first step of the BA creating value rather than destroying it. Why not go further and question the fundamental business model.  Rather than replace an old system with a new one, is it possible to reinvent the business itself?

Let’s take an example.  The client’s core business was data.  They supplied that data to their customers through an old and cumbersome desktop application.  They employed a service team to visit customers and install the system.  Data updates were sent via CD-ROM.  Their initial requirement was to maintain the desktop application.  The steer was to rebuild its functionality in an updated architecture (only one person in the company really understood how it worked, so updates were infrequent and key-man depecncy was a real concern to the business) develop a new local database and provide the ability to download batch data updates via the web.

The business analysis could easily capture requirements based upon this vision, yet they would be doing the client a diservice.  It would be possible to design and build a new desk-top aplication that woud be installed by the service team.  The technology would be better, database querries would be faster and customer attrtion would be slowed.  But it would be missing a trick.  The desktop application that IT wanted to rebuild was not where the value was.  The value was in the data.

Understanding what clients actually wanted and how they used the data (they used the desktop application to mine the data then copied and pasted into excel) it was possible to begin to challenge the existing assumptions.  The desktop app had charting and graphing functionality – why rebuild that when Microsoft do rather a good job of that with a product called Excel.  The requirements slowly changed into the ability for clients to pull data into excel via a web service.  It now would be possible to charge for data usage enabling creative new packages to be offered to different customers.  Previously customers had requested for changes to calculations and models to be implemented on updates for the desktop application.  Now the business started thinking about building a community where customers could create and share excel models and calculations on community website.  IT was helping the business create new value, setting aside the current reality and entering a domain of new possibilities.

The business analyst moved on from being a requirements taker to a change agent.  This was possible only with the mind-shift away from paying lip-service to the way the current application worked and thinking in terms of what and what if.

What the customer wants

I’m a strong proponent of engaging the customer in all stages of the design process. But sometimes you need to be careful with what they say and not always believe their first answer.

Ask the customer “what do you want” and the chances are you will get an answer that is rooted in their experiences and expectations. Not what they really want.

“I want an intranet portal“.

No, you don’t. You want a place where your employees can share files and documents.

“I want a google search appliance“.

No you don’t. You want to be able to find documents quickly and efficiently.

Worse is when vendors try and force products onto the customer…

“You want an integrated BI toolset“.

No they don’t. What they really want is to be able to pull some specific data from a legacy application into an excel spreadsheet and insert a graph into a word document.

OK, so it is easy to say that, but how to follow though? How do you actually get the customer to create a vision of what they really want? Well I’d start by not asking them that question. Get them to articulate what their goals are. Then try to understand in what context they will try to accomplish those goals? Think in terms of customer journeys and value outcomes over features. Think about the what, not the how. Start with the “to-be” vision rather than dwelling in the “as-is” quagmire, indeed use a system obituary to kill the as-is thinking. Use visual tools to model your ideas. And don’t get bogged down in detail.

I’ll write more about this in the future…

Will corporate websites remain spotty teenagers or will they grow up to be beautiful?

In the corporate webspace most design is little more than mediocre. Interaction design has changed little since coporations first realised that this is a channel thery should exploit. Web 2.0 is slowly making in-roads with basic use of Ajax functionality, but there is nothing that is really breaking the mould. Despite its infancy (for most organisations ‘e’ is barely 10 years old, Amazon, the granddaddy of eBuisiness is only 13, born in 1995), conservatism rules; the corporate web is just not growing up. It would be easy to blame the technologists for being risk adverse- for having invested in architectures and frameworks that do not allow innovation. REST and all that declarative goodness may be great, but of little interst if you have invested in a propiertary framework that does not support it. But the business is also responsible for tardy innovation.

It doesn’t know what is possible. A miss-understanding of accesibility clobbers rich interactions; “no javascript” becomes the mantra, despite the guidance being “provide alternatives” and progressive enhancements making basic and rich interactions possible with the same code. And maybe as usability testing becomes the norm, and testing concepts with consumers throughout the product lifecycle is baked into the process, this is acutally the final nail in the creative coffin. Let me explain.

When you are developing new features or propositions it is only right that you should conduct market research, talk to your customers and get feedback to refine your ideas. But sometimes you need to ignore what you are being told and challenge the perceived wisdom. Imagine the scenario; you are developing a social networking site. You recruit a bunch of consumers to participate in user testing sessions. They match the socio-demographic profile of your target audience, they use the internet more than five hours a week. You let them loose on your concept boards and prototype. They like what they see, they like the blogs… but commenting? The feedback is that none of them would leave comments. So what do you do? Kill the commenting on the basis that the users who matched your “average” profile would not use this feature.

I’m not saying that if you are building a conventional, transactional experience; a retail shop, a financial services provider, you should not test the proposition with users that match the target profile. But beware that they will steer your thinking into the realm of the ordinary, the expected and the average. Try testing it with trend setters, gamers, teens, mybe even anti-personas to push the boundries and harvest real innovation insights.

And maybe testing the proposition is not needed at all. But don’t leave the design to the comittee or the accountants. Sometimes it is more important to have a real visionary driving the product development. Apple is a great example of this, no more so than with the iPhone bounce. When you scroll down a list, when you come to the end, the last item “bounces”. Where’s the “business value” in this? Isn’t this gold plating in the extreme? The development of this bounce will not have been for free, it will have come at a cost. This could have been a financial (more development effort) it could have been at the expense of another feature, or it could have been time. In most organisations this would not get get through the design by commitee. Apple can do such great things with their UI because they’ve got a visionary at the helm who understands the importance of good design and is passionate about it, and their customers become to expect it.