blue sky thinking

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.

Blue sky apple pie

I’m in Hong Kong in a workshop and we are asking the group to think beyond what they do today. To come up with a “blue sky” vision of what they want from an application.

“Urrrr, excuse me” says one of the team, “what is a blue sky?”

Earlier on, one of the team had talked about “motherhood and apple pie”. Urrrrr. What is that?

Another workshop, “We are interested in how you do things, soup to nuts”. Uurrrr, nuts? Who ends their meal with nuts. If that is what you are trying to say…

On agile projects we talk to customers and soon start talking about “stories”. Urrrr, aren’t stories something I read my daughter at bedtime
We assume that people will understand what “stories” are. They nod their heads in agreement, but do they really understand what we are talking about.?They’re requirements right? If calling them requirements makes communicating with your customers easier, then isn’t it better to use the words they are comfortable with?

When you do a retrospective (urrrr, what’s that? you mean review of how we got on?) how about spending a couple of minutes reviewing the language you have talked to your customers in. Have you spoken their language, or talked at them in your own? Have you communicated in plain English or have you been wallowing in bullshit bingo land.

Oh, and if I’m on a language theme, when you go into Starbucks it is “can I please have a cup of coffee”, not “Can I get a coffee”… 🙂