Business Analyst Study Notes: Commonly Used Tools And Techniques

Commonly Used Tools And Techniques
The top five most frequently used business analysis techniques are:
- requirements workshops;
- interviewing;
- MoSCoW (must have, should have, could have, won’t have this time)prioritisation;
- use-case modelling;
- user stories.

These were narrowly followed by mock-ups (a form of prototyping). We might draw the conclusion from this list that the most common techniques refer to the elicitation, analysis and definition of requirements of various kinds – whether high-level business requirements or detailed solution requirements.

Tool or Technique - Description
Acceptance and evaluation criteria: A form of quantification or scale of measure for a requirement, which will allow test cases to be developed so that a solution can be objectively tested to see whether the requirement has been met.
Backlog management: The continual management and prioritisation of a backlog of work or requirements, in collaboration with other business stakeholders, typically (but not exclusively)in an adaptive or agile environment.
Balanced scorecard: A technique that facilitates the elicitation and definition of critical success factors and key performance indicators at various levels – e.g. organisational, departmental and project – typically using standard categories such as customer, financial, internal, and learning and growth. See Kaplan and Norton (1996)for further information.
Brainstorming: The use of divergent thinking techniques that allow the generation of ideas. Typically used to generate potential requirements, solutions, risks and so forth.
Business cases: A business case should provide a compelling case for change, considering the overall desirability and feasibility of various options. A BA should not own the business case, nor would they be the ultimate decision maker, but a great deal of analysis is required to put the case together. Therefore, BAs are often involved in the creation and presentation of business cases.
Business perspective analysis: The use of techniques to understand the perspectives of a stakeholder in terms of what a business system ought to do and the stakeholder’s perspectives on why that system exists. Possible techniques include CATWOE (customer, actor, transformation, Weltanschauung or worldview, owner, environment), PARADE (perspective or point of view, activity, recipient, actor, decision maker, environment)and root definitions. (CATWOE and ‘root definitions’ originate from Checkland’s Soft Systems Methodology; readers interested in these topics may wish to consult Checkland 1999. PARADE was derived from Checkland by Paul Turner in Cadle, Paul and Turner 2014.)
Business rules analysis: The understanding and documentation of the definitional and behavioural rules that exist within the business. These rules often constrain or shape the way that work is undertaken.
Conceptual modelling: The use of techniques such as business activity modelling to create a view of a set of business activities from a stakeholder’s idealised perspective. This is usually used to find accommodation or (if possible)consensus between conflicting stakeholder views within a situation of interest.
Context diagrams: High-level diagrams which abstract away details of how a system performs its underlying transformation but that consider the types of interaction that external actors (such as users or external systems)have with the system under consideration.
Data dictionary: A compilation of definitions of common business meanings of data elements captured by information processing systems (automated or manual).
Data modelling: Definition of a model showing the different types of data that are important in a particular business situation and the relationships and rules that exist (these include class diagrams and entity relationship diagrams).
Document analysis: Elicitation of information about a business situation by examining documentation that is used within the business.
Financial analysis and investment appraisal: Financial analysis is typically carried out as part of a business case, usually with the support of a predefined template, and often by a suitably experienced member of the project management office (or a project accountant). It involves assessing projects using a variety of appraisal metrics. Includes payback period, net present value and internal rate of return.
Focus groups: Groups in which customers (or other stakeholders)are assembled to discuss a particular issue or problem, in order to elicit ideas or feedback. Can also be used to gauge responses to a potential solution or prototype.
Glossary: A shared set of definitions of key business terminology. A good glossary helps to ensure that communication is more succinct and more precise amongst stakeholders.
Interviews: Typically, one-on-one meetings with stakeholders to elicit information through structured (or semi-structured)questioning.
Mind mapping: A technique for documenting a rich, ‘messy’ situation in a semi-structured way.
Non-functional requirements analysis The analysis of non-functional elements of a solution, such as performance, security, scalability and so forth.
Observation: Observing (viewing or watching)a stakeholder or team, undertaken to understand more about how work is carried out.
Prioritisation: Assessment of the relative priority of requirements against each other, taking into consideration the overall objectives and value that the requirements will help to achieve. This often involves negotiating and managing conflicting views amongst stakeholders.
Process analysis and modelling: Definition of a model showing how a repeatable set of activities happen within a business. Can include process modelling at various levels of abstraction, including process flows, swim-lane diagrams, task descriptions or procedure manuals, and so forth.
Prototyping: The creation of a mock-up of some element of the proposed solution. For an IT solution, this could include screen mock-ups, report mock-ups and so forth. For other types of initiative, BAs may work with other specialists to produce prototypes (e.g. a warehouse move may require consideration of where and how stock will be laid out – this could potentially be prototyped and modelled to varying levels of precision using specialist software).
Rich pictures: A technique for documenting a rich, ‘messy’ situation in a pictorial format, showing ‘softer’ aspects such as culture and conflict (as well as more tangible aspects such as structure).
Root cause analysis: A family of techniques, including 5 Whys, fishbone diagrams, multiple cause diagrams and so forth, that allow a BA to uncover and understand the reasons why a problem has occurred or is occurring.
Stakeholder analysis: A family of techniques used to identify, categorise and engage stakeholders within (and, where necessary, outside)an organisation.
Surveys and questionnaires: Mechanism for eliciting information from a large and typically distributed stakeholder community.
SWOT analysis: An acronym that refers to assessing the strengths, weaknesses, opportunities and threats in a business situation. Often used in combination with other external and internal environmental analysis techniques.
Use-case models including scenarios: System use-case models show interactions between an actor and a system. This may include interactions between a user and a system, and may also represent other actors (e.g. systems). Use-case models often include related scenarios. Scenarios show, step by step, what happens when a particular interaction between an actor and a system takes place. Exceptions and alternative paths are also documented.
User stories: Short, succinct placeholders for requirements. Often articulated in a standard format, such as: ‘As a… I want… so that…’. Acceptance criteria are added to a user story to ensure that it is precise and testable.
Vendor assessment: The assessment of varying potential (external)solution options, typically through an RFI and RFP process, or an ITT process.
Workshops: Facilitated meetings, typically with a range of representative stakeholders present, with a specific defined focus. Often used for eliciting or reviewing requirements.
 

Context is king
While a BA must maintain an awareness and working knowledge of a wide range of techniques, it is unlikely that an individual practitioner will need to be fully versed in every single technique. Particularly when a BA is beginning their career, it is likely that other more experienced analysts will be available to provide guidance on which techniques are most suitable for a given situation whilst also providing practical help on how to apply the techniques.

1. Choosing an appropriate tool for the job: Senior BAs will be involved with understanding the business situation and selecting the analysis tools and techniques that are most relevant to the context. If a practitioner is not aware of a technique, then they will be unable to choose it (the technique may be completely outside their awareness, an ‘unknown unknown’). Left unchecked, this may result in other, less appropriate and less effective techniques being used.
2. Adapting to a context: As alluded to earlier in this chapter, no two projects are identical, and contexts can vary dramatically. One project may require precision, accuracy and flawless quality. Another may need to get something out quickly, with the acceptance that it may not be perfect (and may be polished and refined after release). The context may drive the analysis approach taken, the types (and number)of resources engaged, and the tools and techniques that are used. This in turn may have a knock-on impact on other project resource and scheduling requirements. We may need significant chunks of stakeholder time for elicitation activities, or we may require collocated office space for collaborative working.
3. Providing guidance to other less experienced practitioners: As a BA’s career progresses, it is likely that – either implicitly or explicitly – there will be an expectation that they will provide guidance or even mentoring to other less experienced members of the team. It is therefore essential that they maintain an up-to-date view on the breadth of tools and techniques available.
4. Variety of initiatives: As a practitioner becomes more experienced, it is likely they will have exposure to a wider range of initiatives – including IT change, people change, organisational change, culture change, location change and many other aspects too. Some of the types of technique that are most relevant in, say, a small project to update the branding on an existing website will differ from those required to assess the impact of a major merger between two companies. Therefore, continually enhancing and expanding one’s toolkit is crucial.

However, it is very rare that a practitioner needs to be an expert on all conceivable analysis techniques. It is usual for experienced practitioners to become very familiar with the most commonly used techniques whilst maintaining a working knowledge of others, so that those other techniques can be deployed when required. Equally, it is perfectly normal for practitioners to look up information as and when they need it – this can be particularly useful to refresh one’s memory. If a practitioner has not drawn a use-case diagram for some time, and cannot remember the precise notation for some of the more advanced concepts, they may well refer to a trusted resource or ask a colleague for clarification.

Remaining curious about the business situation and our stakeholders and being prepared to challenge and question are absolutely crucial. 

Related Notes: Business Analyst Study Notes: Frameworks, Tools And Techniques