business analysis

Business cases are works of fiction. Try storytelling instead.

Business cases are works of fiction. Try storytelling instead.

  • Monday, 27 January, 2014
  • By:

Instead of PowerPoint, use storytelling to paint a picture of what you want to achieve.

A business case is little more than an educated guess. It’s a description of a current state, what you plan to do and what results you expect. It’s a prediction of what might be and will almost certainly be wrong. Framing it in this predictive language makes it unbelievable, and doesn’t allow discourse around what is likely to go wrong. Sure, you’ll have some RAIDS, risks, assumptions, issues, and dependencies, but these are generally lists to be glossed over. The focus of the business case is how are we going to make money.

A business case is a business document that exists to persuade stakeholders to back your idea. It’s a rationale plea to ‘back me” based on backward looking facts for forward thinking fiction.

Two points.

One. Stop the pleading, quit asking for permission. You believe in what you are presenting so assume it is a done deal. Describe it as such. Assume that your case is so great that approval is a given. Tell that story.

Two. Let’s be honest. It’s little more than a work of fiction. So use that admission to your advantage.

It we treat the future-state as a fiction, yet to be written, what’s missing in the business case is a narrative. Narrative is storytelling. Tell your business case, your idea, your pitch as a story. Write it in the past tense as though the product has been delivered. Tell the history, of what happened, who was involved. The pitfalls that were encountered. The problems that were faced. Describe the project in retrospect. Imagine your future self, basking in the glory of the successful delivery of the product (with some bumps along the way – it won’t really come in on time, on budget will it?!) Your future self looks back and recounts in prose the story. Beginning, middle. End.

Go all the way back to the start; what problems did the team want to address? What was the opportunity that was seen at the time. And why was the project commissioned? It was the story that did it. The team bought into the story; the inspiring narrative that painted a picture of what the journey might be like, warts and all.

So ditch the Word document business case template, throw out the PowerPoint slides with their bullets and charts. Imagine the future and craft a story that paints the picture of what you and your team achieved. There’s your business case. That’s why we are passionate and driven to do this. Stories are hard to kill.

Is success best measured by tickboxes or delight?

  • Friday, 22 October, 2010
  • By:

Product owners get hung up on the features, a shopping list of requirements rather than considering what is actually important to their customers.

Imagine it is 2007, there is no Apple, you are a new entrant developing a product that will go head to head with Nokia’s flagship phone the N95. You are the product manager who is responsible for the success of the product. You are focused upon beating Nokia; you’ve made it your business to intimately know the N95, you can recite the list of features it has from memory. You have a meeting with your design team and they break the news. They tell you the spec they have come up with.

“Let me get this straight” you say. “You are telling me that the phone you are proposing we take to market will have no Card slot, no 3G, no Bluetooth (headset support only), no decent camera, no MMS, no video, no cut and paste, no secondary video camera, no radio, no GPS, no Java…”

“Yup” the team say.

How do you feel?

Ditch the feature list that you’ve fixated upon in your quest to beat your competitors flagship product?

Only the brave would avoid the tick box mentality and strive for feature parity as a minimum requirement. Would you really throw out 3G, GPS and a decent camera; the real innovations in the market place?

The first generation of iPhone was released in June 2007, three months after Nokia’s flagship handset the N95. On paper, when you compare the phone features side by side, it is a sorry looking list. As a product manager would you rather have the iPhone or the N95 on your resume?

Below and here [SlideShare] is the story in pictures.

Why it pays to think about the whole system, not just your local function

  • Monday, 30 November, 2009
  • By:

Ability to do bulk price mark-downs? Nice to have.

Today we are looking at a large UK supermarket stock control system.  At the end of the day the staff mark down prices on the short-life items (sandwiches etc).  They have a hand held scanner with a belt printer.  Scan item – print label – stick label on item.  Well that’s what the process is supposed to be, only this takes time (20 seconds per item) and when you have a whole shelf to do is a chore (12 items takes four minutes).  Far easier to just write down the new price on a ‘discount label’ with a sharpie and stick it over the barcode (do the whole shelf in less than a minute).

Where’s the problem in that?  In fact three minutes of waste (waiting time) has been eliminated.  Only it is a problem…

The customer takes the item to checkout and the mark-down label is covering the barcode.  The checkout colleague tries to peel it off to scan, but it doesn’t peel cleanly.  So she manually enters in the SKU. And the mark-down price.  And this has taken 2 minutes for one item and the queue has grown and because of the ‘one in front’ policy they have to open a new checkout and suddenly that small problem at one end of the value chain is replaced by a bigger costlier one at the front end.

But had we not observed this we would never know that bulk price mark-downs on the hand-held device is not a nice to have, it is million dollar requirement.

What do you really need?

  • Monday, 12 October, 2009
  • By:

A couple of clients I’ve worked with recently have been consolidating their application space, decommissioning old technology and replacing it with a new single application with a core user interface. I’ve written about this before but it is worth revisiting.  All too often the starting point is the functionality and the features of the existing applications.  The client states we must at the very minimum maintain feature parity, and where the business needs, enhance functionality.  Starting with the existing applications and as-is processes is a good start, but never where the focus should lie.  The focus should be around the business intent; what are the business goals the system is helping the user achieve?  Spending time with the end users of the system is enlightening.  It is a crude picture, but this shows what the truth often looks like.

Three systems, duplicate functions, redundant functionality

There are three systems that have been developed over the years, commissioned by different business stakeholders with different budgets and different delivery teams. Of each of these systems only a fraction is ever used.  (This is especially true of vendor products that have requirements rooted in the market rather than the specific needs of that organization.  Think about how many of the features in Microsoft Word you use).  If there is significant functional redundancy in the applications, there is also duplicate functionality that results from the different development legacies.  It is not unusual in such a landscape for the user to enter the same data into each system.  Not something you would wish to replicate in a new world.

In building a new application, the place to start looking for requirements is not so much the as-is processes or existing applications.  The place to start is the business intent and what the business actually wants the system to do.  More importantly, that means starting with an open mind and challenging notions of process complexity.  Is the process complex because it really is, or because the current systems make it that way? In my experience, more often than not, it is because of the former.  Spend time with end users, see what they do today.  By asking seemingly stupid questions, taking a starting position that the process is simple and challenging ‘why not?’ can yield valuable insights.  By all means consider the as-is world, but don’t let it cloud your judgment in designing ‘to-be’.

A picture tells a thousand words. So prioritize pictures not words

  • Friday, 21 August, 2009
  • By:

Draw pictures to illustrate outcomes, design the user interface first and use that to prioritize requirements rather than working with written requirements.

In a single image you can convey a simple concept, an idea, a need or a desired outcome far quicker and more accurately than writing it in a sentence.  This is especially so in developing software which more often than not is visually manifest as a user interface.

When we captured requirements in agile, we are effectively conveying a simple concept, idea, need or desired outcome as a requirement.  And we do it in words.  Those slippery things that are so often misunderstood.  Things get really slippery when we try to prioritize those words against each other.  Stories are laid out on the table and the team spend as much time discussing what each story actually means, as giving them priority.  And because they are supposedly independent, you loose the inter-depedencies between them.  Jeff Patton has written some great stuff on this.

So prioritization with stories can be flawed, especially when you are working with a large volume of requirements, say at the outset of a programme of work, and what you really want to do is get an idea of what a first release should be.

Throw out the stories.  It’s too early to be writing words.  Muda.  Create illustrations of widgets and features and functions.  Sketch out on post-its illustrations of the simplest implementation of the concept, idea, need or desire.  On flip chart paper create blank screens that illustrate the interfaces that the requirement will be manifest on.  Identify the stakeholders who will interact with the requirements.  For example the retail website, the operational support application, the finance system.  Now ask the team to stick onto the screens the sketches.

The challenge is to strip back to the minimal functionality that they really need for that first release.    Let them draw extra functionality if they like, but everything must be on post-it notes.  Now pull the post-it notes off, one by one.  What if we removed this? What would happen if it wasn’t there?  Is there something simpler we could do?  Something more elegant?  Is an operational function required to make the website function work? The exercise may be extended with pictures of legacy applications and data elements, again, stripping them back to the bare necessities for that first release.

That didn’t take long did it, and it looks like an initial release candidate. We’ve defined our scope in a way that we do not believe we can cut any more.  Any less functionality would not be a meaningful release.  Now we can get down to writing the stories, focusing our effort on something we are agreed looks right.  We’ve prioritized pictures, outcomes over words; Picture Driven Design.

The user journey

  • Monday, 9 February, 2009
  • By:

“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.

Design vision

  • Tuesday, 3 February, 2009
  • By:

Don’t be fooled into thinking that you don’t need to do any design when you adopt Agile.  Agile development strives to deliver business value early and often, focusing on getting working software to market as soon as possible rather than dwelling in documentation and ‘analysis paralysis’.  But let’s be clear, “business value” and “working software” are not the same thing.  You can quite easily get something into production that fails to generate revenue, decrease costs or whatever other yardstick you use for ‘value’.  What differentiates the two of them is design.  I don’t mean big up front design that details all the features and provides a concrete spec, I mean a design vision that articulates what the product goals are and a roadmap for getting there.  And what is a design vision?  A short statement of intent is a good place to start, and soon after a user interface mocked up in pen and ink.  It is cheap and easy and helps bridge the path from idea to execution.

Behaviour, intentions, interactions and corner cases

  • Saturday, 3 January, 2009
  • By:

According to an article on eMarketer the method customers book travel depends upon their needs. Nothing revolutionary there; what is interesting is that fewer travelers are booking their trips online overall.

“This is not due to personal financial concerns—online travel bookers are an affluent demographic,” Mr. Grau [senior analyst at eMarketer] said. “Rather, it is caused by frustrations related to the planning and booking capabilities of OTAs (on-line travel agents). This, in turn, is spurring a renewed appreciation for the expertise and personalized services offered by traditional travel agents.”

“Online travel bookers are an affluent demographic” and yet we continue to let them down with poor customer experiences and an inability to let them do what they want to do. As an e-marketeer, your sales numbers may be satisfactory, but how much more traction could you get if your customer interactions were more realistically modeled around their behaviours and their intentions. You may point to your personalization engine, but that is probably doing little more than offering up pages and offers based upon information the customer has told you, or prior pages they have visited. It is not going to be a challenge to “the expertise and personalized services offered by traditional [insert domain here] agents“.

Customer frustrations with the web are more often than not due to usability and restrictive Web 1.0 interaction paradigms. It need not be like this. Interactivity can be more human. Some sites such as Kayak.com are introducing web 2.0 interactivity to introduce more fuzzy searching to find what you want. Forms can be more like their real-world brethren. Rather than the “command and control” approach of imperative programming that drives a sequential, rule driven flow, the declarative approach to programming enables greater flexibility and puts the user in control.

So we can do something about the technology to provide a better customer experience, but that won’t be enough. The perfect customer experience will not fit in business rules your IT analysts have determined. In the real world, corner cases and ‘exceptions to the rule’ are abound. In the real world sales people, customer service reps (or their supervisors) have ‘management discretion’. They can listen to the customer, understand their story, recognise them as a loyal customer who made a mistake, and override the business rules to satisfy/ delight the customer in a way the cold logic of the business rules never considered. True personalization will focus upon the corner-case long-tail.

The next generation of eCommerce will be declarative, forgiving and understanding. Rather than being based upon a paradigm that is the result of the technical constraints of the channels early days, it will be something that more closely mirrors the real world. Getting there however will be difficult. As a first step Marketing departments need to address the shortcomings of their existing digital channel before their IT organisation embarks on new channels such as mobile and TV.

Do Business Analysts Destroy Value?

  • Tuesday, 24 June, 2008
  • By:

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

  • Monday, 19 May, 2008
  • By:

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…

1 of 2
12