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.