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.

5 Comments

  1. Robin Morris · Tuesday, 24 June, 2008

    Agreed some BAs need to be more Blue sky but you contradict yourself….

    (they used the desktop application to mine the data then copied and pasted into excel)

    That sounds like As-Is Analysis to me 🙂

  2. PCallahan · Wednesday, 25 June, 2008

    Do Business Analysts Destroy Value?

    I don’t know where to begin….

    As-Is analysis IS done to understand the business state, business needs and user goals – all with a focus on the “business”, not the technology the business is using.

    Good To-Be analysis MUST involve “blue sky” thinking and not be constrained by technology or even budget. It certainly should not be a detailed and lengthy specification. Its purpose is to open minds to possibilities.

    My feeling is that the real value of Business Analysts is destroyed when As-Is analysis is short changed or eliminated altogether. Haven’t we learned that starting with solutions is bound to fail? Or worse, that users reject solutions that don’t address their needs? Where’s the value in that?

    The commentator really doesn’t understand what As-Is and To-Be analysis is – or, come to think of it, know what a Business Analyst is.

  3. Prashant Gandhi · Friday, 27 June, 2008

    Marc,

    You began on the right premise, but as Robin pointed out you are slightly contradicting yourself. Even if you are starting with the To Be Analysis, you have to have the context of the current world. How else do you challenge the existing assumptions ? The trick of course is to be able to step away from the as-is world and not re-invent the wheel.

    Also, in this example, it seems like a new business model is an accidental discovery . I would argue that there is a disciplined way of getting to the same answers.

    regards,
    Prashant

  4. Chris Leishman · Friday, 4 July, 2008

    I agree whole-heatedly with the notion that we must focus more on ‘what if’ rather than on ‘what is’. BAs should be about helping businesses to find new and innovative solutions to supporting their business processes, not just writing story cards for pre-conceived requirements.

    However, I think it’s foolish to disregard ‘as-is’ analysis entirely. Whilst it is great to think innovatively and plan for a much better business process (and technical system to support it), it must be tempered with some pragmatism. There often is an existing process/system and understanding how to incrementally move from that process/system to something more ‘ideal’ is the other major part of a BAs role.

Leave a Reply