Work

I was recently involved in a prioritisation exercise. The application included a UI that presented large numbers to users in financial institutions. The business owner (sadly there was never any question of acutally talking to end users) had complained about how easy it is to make mistakes when adding loads of noughts to a sum – and pondered that it would be great if when the user tabs away from the field that long number is entered, that comma seperators should appear:
i.e. he types 1435245001.00 and on tabbing away the number appears as 1,435,245,001.00.

Cool! It’s captured as a requirement and we move on.

When we go through our prioritisation, it is considered to be a “nice to have”. With a bulging requirements list and estimates squeezing the list, this requirement is initially an early one to go. After all, what business value does it add? But this is where the planning process must be iterative.

The effort to implement this requirement is nominal. Whilst the “business value” is considered nominal, the value to the stakeholder who requested it is emotionally signficant.

When we showcase the story that demonstrates the ability to work complex financial algorithms based upon the number the user enters, the stakeholder will nod his head and say “great”. It does what he expects. But how good will he feel when he sees the commas appearing? Little cost to implement, zero identifiable business benefit, but significant stakeholder emotional benefit.

As a project, when the key stakeholder leaves the showcase, how would we prefer him to feel?  “yep, that’s what I want?” or “Gee those guys are good”?!

Success is rarely delivered by one part of the organisation; it requires the collaboration of different departments working together. Yet there is all too often a separation of responsibilities that can hinder the efficient development of ideas. Worse, there is no single owner of the business case resulting in business value being lost.

A crude model illustrates this. The “business” holds the business case. They are focussed upon the benefits case. IT are treated a factory to build the mechanisms that will support proposition and are thus focussed upon the costs. The customers (who ultimately use the proposition) are held at arms length and not involved in the development of the proposition.

There can often be a tension between the business benefits case and the IT cost to deliver. The cynical view of the waterfall approach is that Business want it all, IT promise it all and their relationship deteriorates as the project nears its scheduled completion; IT cannot deliver on time or budget, the business has to make unplanned compromises and ultimately the customer suffers. The Agile approach goes some way to mitigating the risk of relationship breakdown. Painful messages about what can or cannot be delivered are communicated early on, enabling informed decisions to be made. However if the organisation is structured with clearly defined boundaries it is far harder to make truly informed decisions. As soon as scope changes, the business case will change. What often happens is that IT adjusts the numbers on the cost side, but the benefits case remains unchanged. If the business has spent many months working on the benefits case it is difficult to make changes on the back of an afternoon’s reprioritisation exercise. There is a solution to this. Taking an inclusive approach to proposition development and delivery; having all parties involved from the outset.

Here’s another crude model. Rather than being separated, the different stakeholders converge. There is a cross-pollination of ideas and understanding. The business case is shared, iteratively and incrementally developed. Customers are engaged in the process; providing market insight and testing the user experience. There is nothing new in this model, although I rarely see it working from the project outset. Often two of the three circles converge; the challenge is to get all three overlapping. I’m pleased to say at ThoughtWorks, increasingly when we initiate projects we are doing this.