prioritisation

We didn’t build it because the business didn’t prioritise it

  • Monday, 25 January, 2010
  • By:

Agile software development is inherently democratic.  Choice over Prescription could be included in the Agile manifesto.  We give the customer the choice, the choice to decide what is most important to them, what will deliver the greatest value and build that first.  We do not prescribe that they must build a complex framework first- the software will evolve, You ain’t gonna need it (Yagni) until you need it.

The problem with this democracy, with this unleashed choice is that, if you don’t have the right mix of stakeholders, the (agile project) customer doesn’t always know what is best.  They are not always the best people to choose.

There is a difference between domain knowledge and what I’ll call ‘experience’ knowledge.  A banker may know the banking domain inside and out, they can tell you the difference between all the different types of balance and how (and where) they are calculated; closing balance, running balance, etc.  But unless they have done any research with customers, unless they have ‘experience knowledge’, when it comes to  a question such as which balance to provide as an SMS alert, their ‘domain’ knowledge is as good as your common-sense.

Imagine software were a supermarket store.  IT are responsible for the construction of the store, the basic layout, the signage, the checkout, the peripherals.  The business are responsible for what goes into the store, the merchanising, the planogram.  The business imperative is to fill the shelves and shift the product.  They want to spend their money to this goal, anything that does not directly support this will be of lower priority.  That is their domain and they will prioritise that over anything else.  If they could fill the store with nothing but shelves they’d probably be happy.

Now imagine visiting the store.  There’s no carpark, there are no shopping trolleys, there’s no emergency exits.  There’s no ramp for disabled customers.  The shelves rise to eight foot high (with no steps to reach the heights), the aisles are difficult to negotiate because of promotional displays between the shelves.  The business is happy, but what about the customer?

In the agile world, nobody is going to pay attention to this stuff unless it is prioritised.  “Sorry, we didn’t build any shopping trolleys because you prioritised building more shelf space over them”.

This sort of thing happens all the time; functional domain requirements trump experience requirements. Why? Because no-one brings experience knowledge into prioritization and planning sessions.

When stating their choice, your stakeholder wears a commercial hat, they are thinking about their targets and those are based upon shifting product.  They are living in thier operational business domain.  But cold commercials are not what shifts product.  It is the experience that does.  Now go back to the democracy of choice on an agile project.  Who is the ‘business’ specifiying requirements? Is it a balanced team? Is their an experience champion with an equal voice?  Is the voice of the customer recgognised?  If not, isn’t about time you got an customer experience champion onto the team.

It’s bad said the doc, case of business locked in, customer locked out.

  • Wednesday, 15 July, 2009
  • By:

The customer is the oxygen that keeps a business alive.  No. The customer is more than just the oxygen that keeps the business alive, (my mother was recently on a life support machine with Guillian Barre Syndrome; she was getting oxygen but paralysed, unable to move.  With that condition you see that life is more than just about breathing oxygen).  The customer is more than just corporate oxygen, it is the reason a business lives for.

Shareholder value means nothing if the organisation doesn’t provide value to the customer.  Yet  I see far too many organisations who fail to grasp  the importance of their customers.  They prioritise their internal processes and policies to the detriment of customer satisfaction.  They focus upon narrow propositions that represent organisational silos rather than meeting the broad needs of the customer.  Innovation is morphed into ‘requirements’ that are performed by ‘actors’ in multiple volumes of ‘use cases’.  To my mind, too many organisations are struck down by corporate Guillian Barre Syndrome.  The brain knows what is going on but is powerless to act.  It feels pain, it senses something is wrong but is paralysed, it cannot move.  Prisoner in its own body.

If that is the diagnosis, what is the cure?  There are many, but a starting point would be to place the customer at the heart of your design.  Don’t start any proposition without the customer experience at the core.  Create personas and walk through customer journeys.  Use scenarios to develop your thinking.  Broaden the scenarios to introduce what-if models.  If it is an internet offering, sketch out the screens, if it is a service, sketch out the touch-points with your people, processes and technology.  Don’t allow the proposition to be talked of in the abstract, work with the concrete.  Would a persona accept the experience your proposing? Would she accept that pricing model? Does that journey make sense? You do not need to spend weeks and months documenting the exercise.  A couple of days with the right people in the right room with white boards, post-it notes and business-speak banished from the proceedings should deliver far more fruitful insights than playing document-tennis with revision after revision after revision. You may even kill the proposition before you invest too much time on it. Or better still identify a better, customer-centric proposition waiting in the wings.

Where’s the vision

  • Wednesday, 10 September, 2008
  • By:

Experience suggests that a project without a vision is like a rudderless ship. A clear vision from the start is essential to the success of a project. It is like the corporate mission statement. It is not the project objectives (objectives are generally SMART – you shouldn’t be looking to measure the vision), rather an articulation of how the end goal of the project will touch the lives of it’s ultimate recipients; the customer or the user. What the project will do for them (not the business, not for IT, but the customer, consumer or user).

The first step then is to get the vision agreed on. Luke Hohmann’s innovation games such as product in a box are a good way of distilling the vision. Next step is to keep it live and visible. Don’t just have it buried away in the project Wiki, but have it stuck on the walls where the team work. And then use it as a frame of reference when those difficult questions arise around scope and priorities.

Why is this important? (Via Leisa Reichelt), Peter Merholz shows how Google started out with a vision for their calendar.

The vision…

The google calendar vision

And what it meant for the product when it went to market…

Google didn’t start with a bunch of features of functionality (“Drop dead simple to get information into the calendar” – that’s hardly a requirement any BA would be proud of), but by having this vision, a statement of what the product would mean to the end user, and referrring back to it when scope or design decisions had to be made, they ensured that the end product delivered real quantifiable value.

Was it just a simple database query?

  • Friday, 23 November, 2007
  • By:

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.

It’s how you ask it…

  • Thursday, 28 June, 2007
  • By:

Prioritising requirements

You’re running a workshop and the group have come up with a bunch of new propositions. You want them to vote on which ones to take forward to the next stage. Or maybe you’ve identified a bunch of functionality and features and you want the group to prioritise what they’d like to see built first. What question you ask the group next is critical to the answer you will get.

You need to frame the question appropriately and make it clear to the group the criteria by which they are making their vote…

Do they need to be thinking about “do-ability”, the ease to implement, or do they need to be focussed upon the innovation and the idea itself. Should they be considering the cost to implement, time to market, return on investment, or should they be thinking about the art of the possible; the “blue sky”; the destination, regardless of the journey to get there.

Which line of thinking they should use will depend upon where you are in the process. Get them thinking about practicalities of implementation too early and you are likely to dilute the vision. Too late in the process and you will have candidate propositions or features that by their complexity or uncertainty will never the light of day.

So two tips. Before you ask the group to vote, or to prioritise, clarify the objectives and the critiera by which they are to decide. Maybe ask them to assume a ‘persona’ and vote in the way they’d expect the persona to vote, for example a customer will have different priorities to a developer.  Whose vote is it anyway?
And after they have made their vote make sure you manage the group’s expectations. Don’t let them leave the room thinking what they’ve decided upon is final and binding. It rarely is.