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

I was recently working with a telco who were running a campaign for a single application that sits on a Symbian phone and gives the user access to all their mobile services (rather than having to access them individually via the mobile web). This is not unusual, organisations marketing the technology rather than the benefit or the experience. The technology should be incidental to what you are selling.

It is hard to put it better than what Duncan Cragg writes

“What most people want on their mobiles is not the applications, but the stuff they animate.

People only accept the concept of applications (whether a native app or a Web app) because that’s all they’ve been offered, and it’s largely good enough. But no-one actually wants to download and launch and register and log in to a local find-your-friends application – they just want to find their friends in the area – now! And they shouldn’t then have to flip between the find-your-friends map owned by that application and the restaurant review map owned by another.

They don’t want Facebook videos and YouTube videos and phone videos. They just want to share videos. They shouldn’t have to think about whether to send a picture by MMS or to use an upload app, after remembering the login. They don’t want multiple ways of sending messages: IM, SMS, Twitter, Facebook, etc. They shouldn’t have to think about how to tell their friends about some news item – whether to post a TinyURL link on Twitter or copy the text manually into Facebook.

They only want one shared calendar, not the phone calendar and a Google calendar and events on Upcoming.org, that need two more logins. They shouldn’t have to think about how to synchronise music or contacts lists on the phone, the iPod, the PC, some memory card and online. “

He goes on to introduce the ‘U-Web’ Mobile 2.0 platform. This is exciting stuff and well worth a read. The challenge is not just about the IT industry getting excited about U-Web, the drive needs to also come from marketeers focussing upon “what” experience they want the customer to enjoy rather than “how” it will be delivered. They shouldn’t be distracted by the application that the experience will be delivered through, they should focus on delighting the customer and driving value to the organisation.

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.

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…

Typically the process will be for these requirements to be captured by the Business Analyst who acts as the conduit to the development team. Nowhere is the user interface explicitly referenced – it will almost certainly be articulated in the reality of the current systems; what the BA knows and understands. Despite the iterface being delivered through a browser, the developers are not web developers. Inevitably the finished product will be functionally correct, it meets the requirements, but it will be clunky: select parameters > search > results… because it reflects the requirements as the trader put them “I want to do this and this and this, press a button and get a list back“.

So what are the chances of an internally developed investment bank application looking like Google finance’s Stock Screener? And what would your trader rather have?

Sadly, focusing upon the how rather than the what is a driving factor behind so much of the mediocrity in enterprise software. Rather than stating “what” (they want) in terms of their dreams and aspirations, the business express their requirements in terms of what they perceive IT can deliver. “What” could never be the design quality of Apple (visionary) because they believe the “how” (their IT team) is not Apple (mediocre). But wouldn’t your average developer rather be building something visionary than something mediocre?