First published by the British Computer Society
Are you considering a move into Business Analysis? Has the glamourous lifestyle of the BA caught your eye? In this age of digital disruption and digitisation, the Business Analysis role is more relevant than ever and can offer a varied and rewarding career path, but knowing where to get started to move into the profession can be difficult.
The Business Analyst role is multi-faceted and it is rare to find two BAs with the same set of experiences, skills and knowledge. It is common for Business Analysts to have experience of a range of industries, to have worked on projects ranging from the highly technical to the strategic and to be experienced with both waterfall and agile methodologies. Similarly, there are BAs who have chosen to specialise in one industry or discipline. As such, it is difficult to describe a ‘typical’ BA, however there are a number of key skills and techniques which are core to the BA role and regardless of industry, project or methodology, are essential additions to any BA’s toolkit.
#1 Stakeholder Engagement
A Business Analyst is often one of the first points of contact for business stakeholders when a business change or systems development project arises. Whilst in some organisations stakeholders may have discussed the business requirement, opportunity or problem with a Business Partner, in others the BA will undertake initial engagement activities.
Stakeholder engagement encompasses stakeholder identification, analysis and management, but in its simplest form it is how a BA works with their stakeholders (loosely termed as any users, customers, sponsors and other individuals or groups impacted by a change).
There are some excellent models and techniques for identifying, analysing and managing stakeholders. A basic stakeholder matrix for example is extremely useful for mapping stakeholders by their power (influence) and interest and can assist in deciding the strategy for working with different individuals and groups impacted by a project.
Tools such as this can be extremely valuable and it is useful to learn how to use them. An aspiring BA could do much worse than procuring a copy of Cadle, Paul & Turner’s ‘Business Analysis Techniques‘ and reading the section on ‘Working with Stakeholders’.
Perhaps however the most powerful thing to remember when dealing with stakeholders is that they are human. They are people with wants, needs, aspirations and concerns. As such, great stakeholder engagement is as much, if not more, about communication, negotiation, relationship building and empathy as it is about knowing specific techniques and tools.
#2 Requirements Elicitation
Requirements gathering is often the activity most non-BAs associate with the role of the Business Analyst and is essentially the process of discovering the functional and non-functional requirements (the wants and needs) of stakeholders for a system. Whilst these will usually be the requirements of an IT-related solution, the term ‘system’ is holistic and it is often necessary to also consider and capture process, organisational and ‘people’ requirements.
There are a number of excellent elicitation techniques, all of which have their strengths and limitations. Often the best approach is to use a combination of two or more techniques to balance out these pros and cons and provide a more thorough and rounded view of the requirements. As an aspiring BA it is well worth gaining some hands-on experience of the following:
- Observation
- Workshops
- Interviews
- Document Analysis
- Brainstorming
- Surveys and questionnaires
- Prototyping
#3 Requirements Prioritisation
A thorough requirements gathering exercise can generate hundreds of requirements, some of which will be vital to the success of the project whilst others may be more aspirational or ‘wish list’ items. Time and budgetary constraints will usually dictate that a choice needs to be made on which of these requirements will make the final cut and go forward into development.
This can be quite a daunting part of the BA role, as it often means challenging stakeholders to truly consider their priorities and to frame their requirements with their end goal in mind. Where there are conflicting priorities between different stakeholders, the BA can often find themselves mediating discussions and managing conflict.
A much-used approach is MOSCOW prioritisation, where stakeholders are asked to categorise requirements as follows:
Must Have – requirements which must be delivered when the project goes live. The project cannot go live and the solution will not work without all of these.
Should Have – requirements that are needed, but can be rolled out later. They’re important, but the solution will work without them for the interim
Could Have – requirements that are useful, but not essential. They may be rolled out if there’s time or pushed to a later release
Would Like – it is valuable that these requirements have been captured, but they won’t be included in this development
#4 Requirements Documentation
Once a BA has gathered the requirements, they need to document the information in a format that can be used by developers and testers. This requirements documentation may be used to create a functional specification, technical specification, to create a product backlog or may be used directly for development. As such, one of the challenges for the BA is capturing the requirements in language which is both understandable to the business (who need to sign them off) and useful to a solutions architect and the development team.
Often the approach to documentation will vary depending on the organisation. Some will require a requirements catalogue, combined with a detailed requirements document whereas others will use User Stories for agile development. Detailed data requirements may be documented using Entity-Relationship Diagrams or Class Diagrams, whilst business-level requirements may call for process mapping. Software used for requirements documentation may range from Microsoft Excel, Visio and Word through to more sophisticated requirements management tools such as JIRA or HP Quality Centre.
With this variety in mind, here are some key tools and techniques to investigate further:
- Requirements catalogues
- Use Cases (UML)
- User Stories
- Process Modelling (including BPMN, UML, Flowcharts and Data Flow Diagrams)
- Data Modelling (Class Diagrams (UML), Entity-Relationship Diagrams)
- It is also a very good idea to get familiar with MS Visio!
#5 Communication
Linking back to #1, communication is essential to building strong stakeholder relationships. Throughout a project, stakeholders need timely communications, using the channels they prefer, containing a message that is relevant to them. As communication is a two-way street, it is also essential that stakeholders feel they have a voice and that their BA is approachable, open to discourse and is empathetic to their situation.
In technical projects, a Business Analyst is often described as a translator between the stakeholders (who have the requirements) and the technical IT teams (who will be designing and building the solution). It is the responsibility of the BA to understand the business’ requirements and communicate them to technical teams, whilst also being able to understand the technical abilities and constraints and feed these back to the business in a way that makes sense in the business context.
The BA also needs to operate at a strategic level however, understanding the strategic context of a project, the cultural impacts it may have and the longer term organisational goals that it relates to. As such a BA may also find themselves needing to be a sales person, a visionary or a trainer, all of which require strong communication and presentation skills.
But lest we forget the importance of communication and engagement within the project team. Whilst we often focus on stakeholder communication, it’s important for a BA to ensure they keep open, clear and honest communications with the Project Manager or Scrum Master and other members of the project team. Lack of communication is often cited as one of the main reasons for project failure and as such at a good communication in all areas is key to success.
Rachel Drinkwater 