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:
- high level scope
- high level requirements
- approximate cost
- 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.
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.
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.
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.’
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.
(You’ll need to register as a user to see the source document)
No related posts.