What is business analysis?

OK, this site claims to help business analysts so a good place to start would be to explain what business analysis is all about.

In this article, you’ll find the following:

 

  • the analogy of business analyst as interpreter
     
  • bridging the gap between IT and the business
     
  • the importance of timing
     
  • problems with language
     
  • other responsibilities
     
  • other project roles
     
  • other definitions of business analysis

 

This is primarily intended for those who are new to business analysis but I’d welcome feedback and your own take on business analysis from those who are more experienced.

 

Business analyst as interpreter

Whenever I’ve been asked what I do at parties, I usually try to avoid the question, or give some generic answer. However, for those who seem to be interested, I’ll start using the ‘interpreter‘ analogy.

The business analyst’s job is to provide frequent, effective, two-way communication between the IT team and the business.

This relates particularly to what problems the business would like to solve with a shiny new IT system (although a shiny new IT system is not ALWAYS the right answer).

In essence, that’s what the job is about and I try never to lose sight of it, particularly when buried in a mass of project detail.

If you can’t justify what you’re doing as making a valuable contribution to the ‘business to IT or IT to business’ communication then you need to ask what value it provides.

 

Bridging the gap

The business analyst needs to interpret and bridge the gap because:

  • Organizations have jargon needing translation
     
  • IT people have jargon needing translation
     
  • Precise, unambiguous statements are required by IT
     
  • Business don’t, typically, need to be as precise as the IT department Of course, the legal department are masters of precise english ;-)
     
  • Business make assumptions about other’s knowledge of their business The implied, unstated knowledge needs to be ‘drawn out’

 

Timing is critical

Precision is great but there is a risk:

if you demand all of the detail too early, you and the business stakeholders will burn out

The trick here is in timing – when should you talk big picture and when should you explore detail ? This is one of the classic IT development problems which has significant cost and quality implications.

At the outset, the following are important:

 

  1. high level scope
  2. high level requirements
  3. approximate cost
  4. high level business impact

 

As you progress through the project, detailed requirements will become critical but not necessarily all at once.

 

It’s a problem of language

Requirements may be specified as a possible solution (i.e. how rather than what) rather than in terms of the business need.

For example:

to deliver a solution that will present a web page that allows the customer details to be captured, validates the user input and stores the results .

Conversely, a clear requirement would be:

We need to reduce the level of fraud and speed up the interviews with our customers .

Even better – it is defined when the requirement has been successfully met:

We need to reduce our losses due to fraud to below £100,000 per annum and ensure our customer interviews never exceed 30 minutes.

If we never understand the real, underlying requirements because we’ve been given the solution then we’ll have problems:

 

  • the business are supplying the IT solution!
  • IT haven’t proposed and considered alternate solutions
  • we won’t recognise success if we never identify the real business requirements

 

In an ideal world, the business analyst will already be involved in the process of investigating the business processes and identifying problems (business process improvement) which is a better situation as he/she will be conversant in the nature of the business need already.

To summarise, I suggest that business analysis is

1. providing interpretation to support business and IT communication

2. controlling the content of the discussion – know when to discuss the big picture and when to discuss the detail.

3. controlling the content of the discussion – be able to recognise when a solution is being described rather than the problem to be solved

 

What other responsibilities?

The business analyst can have other responsibilities which include the following:

  • benefits analysis – what benefit can be achieved? (also benefits realisation)
     
  • business process reengineering – analyse business processes to identify opportunities for increasing efficiency
     
  • change management – programme of work encompassing all aspects of a business change of which the IT element is only one (optional) part

 

What are the other project roles?

The business analyst works alongside many other professionals who have different roles:

  • project manager – responsible for planning the project and monitoring costs and schedules. Handles all communications with the project sponsor (business) on these subjects. Will also manage all subcontracts necessary for delivery of the project.
     
  • developer/designer – responsible for designing the solution and is conversant in the technologies that are being used and what can be achieved
     
  • tester – responsible for testing the solution to ensure it delivers to the requirements
     
  • stakeholder – there will be one or more of these and you will be talking directly to them as they have an interest in the project whether as actual users of the system, assessing the risks, managing the finances etc. One or more of these will be ‘subject matter experts’ who will provide with you with a lot of the material that requires interpreting.
     
  • project sponsor - this is arguably a type of stakeholder but is very significant as it is the person in the business who is tasked with ensuring the project is successful and, typically, will gain credibility if it succeeds.  He/she is likely to be senior management and is someone whose viewpoint will tend to carry most weight.
     
  • Other possible roles – test manager, user interface designer, architect, trainer, end user

 

Some ‘Agile’ methods have a role which is called ‘Product Manager’ which is very similar to Business Analyst and certainly requires a similar skill set as described above.

 

Useful links

Finally, here are some other definitions of business analyst available on the web that I think are useful – personally, I think the interpreter analogy is better ;-)

 

Definition taken from BCS (British Computer Society) supporting ISEB Business Analysis certification

Holders of the ISEB BSD Certificate in Business Analysis Essentials should be able to:

  • Demonstrate an understanding of business strategy and strategic analysis techniques.
  • Act as effective members of a team investigating an organization’s business systems with a view to recommending business improvements.
  • Apply techniques in order to analyse and model business systems.
  • Understand how recommendations for business improvement may be identified.
  • Assist in the production of a rigorous business case covering the development and implementation of business changes.
  • Identify how business requirements may be supported by IT systems.

http://www.bcs.org/server.php?show=nav.7730

Definition taken from Business Analyst Book of Knowledge (BABOK), created by IIBA (International Institute of Business Analysts)

‘A business analyst works as a liaison among stakeholders in order to elicit, analyse, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understand business problems and opportuities in the context of the requirements and recommends solutions that enable the organisation to achieve its goals.’

http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge

 

Definition taken from E-skills website under then Professional Competency Model or PROCOM (government agency trying to suppport growth and upskilling in IT)

This sub-discipline is concerned with the competencies required to assist an organisation in improving its business performance through a set of integrated and systematic activities designed to analyse opportunities for improvement and identify possible options that may be adopted.

Business analysis may be conducted with a view to improving a specific, element of a business’s operation or strategy such as profitability or customer service, or a combination of elements. It may also consider both what an organisation delivers (e.g. its products or service proposition) or how it delivers it (e.g. the efficiency and effectiveness of its processes or its organisational design). Business analysis may result in recommendations for change to what currently occurs, addition of new or enhanced features or the removal of activities which do not add value.

Identified options arising from business analysis are typically evaluated and prioritised prior to recommendations being made to an organisation. These recommended options may impact single, discrete functions or processes, or a wide range of them. At the most strategic level, they may result in major restructuring of what the organisation delivers and/or how it operates. They may also result in the need for the implementation of new or enhanced information technology systems, driving the need for systems analysis activities to underpin a technology decision and/or process (re)design and/or re-engineering.

The recommendations arising from business analysis, once accepted for adoption, are usually implemented via a project or programme and are often governed by business change management principles.

http://www.e-skills.com/cgi-bin/orad.pl/500/PROCOM_Business_Process_and_Change_Mgt_discipline_TV_060608.pdf

(You’ll need to register as a user to see the source document)

Wikipedia

http://en.wikipedia.org/wiki/Business_analyst

No related posts.

About Alex Papworth

11 Responses to “What is business analysis?”

Read below or add a comment...

  1. IT Contractor says:

    Your role needs an analogy, enuff said! ;)

  2. alexpapworth says:

    Apologies to those who laboured through the first version, I’ve just redrafted this in response to usability feedback. I hope it’s easier to read now

    Alex

  3. I believe that most systems are now packages and that selecting an appropriate package and knowing how to customise it is vital. The salesman will say ‘yes we can customise it’ but some is easy and some will cost, a lot. Not to mention additional work when they release the next version.

    So far I’ve only found one book on this subject.

  4. alexpapworth says:

    Hi Mike
    you’ve correctly picked up that most of my experience is in bespoke projects. I didn’t think I’d described a process, I was just trying to draw an analogy. To continue the analogy, isn’t this all about controlling the content of the conversation as the first task is to frame the high level reqts to enable package selection?
    As you say, subsequently, detailed reqts are determined but mindful of the third party package.
    I think a ‘package-driven’ approach would merit a whole different series of articles.

    Thanks for the comment

  5. Mike Willcox says:

    Might be an idea to point out that the process you’ve described is appropriate if a bespoke system is envisaged.
    Often, a package of some sort will be selected and the BA work is rather different in that case.
    For example, in the field of document, record, content management, there would be a high level BA task to shortlist and then select the application package.
    After this, more detailed analysis is required to establish how the business processes can be adapted to suit the package or how the package might be customised to suit the users or, probably, a bit of both.

  6. alexpapworth says:

    Absolutely with you on that one Robert. I went to an IIBA meeting last night where that subject and more was discussed. The problem is that IT is now seen as a supplier separate to the business. However, the skills within IT would prove very valuable within the business

  7. Robert Sprigge says:

    Challence for BAs

    The big challenge for BAs is to break out of taking small Work packages from Project Managers and, instead, lead from the front. The BA should be the one who understands the Business and what needs to be done to improve it.

Trackbacks

  1. [...] Use cases are not suited for describing the requirements for all types of IT systems.  In order to be of value there must be a high degree of user interaction. If this is not the case, other approaches should be adopted. Interestingly, an IT solution in its entirety may be suited to use case modelling but, in a system of reasonable complexity, there will be elements of it which are not suited to use case modelling. If this is the case, there is no reason why use case modelling can’t be mixed with other approaches. As always, the measure of success should be: If  you can’t justify what you’re doing as making a valuable contribution to the ‘business to IT or IT to business’ communication then you need to seriously consider what value it is providing. (see What is business analysis?) [...]

  2. [...] to this and are thinking of taking up a career, I’d highly recommend you read this article – What is business analysis?. This is where I present a simple analogy of the analyst as interpreter between the business and IT [...]

  3. [...] This is also an area where the business analyst’s role as an interpreter (described in What is a business analyst?) is [...]



Leave A Comment...

*