By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.
The discipline of business analysis (and therefore the role of the BA)is very broad and varied. It can involve up-front strategic analysis, pre-project problem analysis, requirements work, and can continue until after a change has been implemented and benefits have been realised. This variety means that practitioners often get exposure to a wide range of projects, tasks and stakeholders. It is becoming increasingly common for the BA role to be considered ‘T-shaped’; in that it is necessary for a practitioner to have deep analysis and general business knowledge, but also a broad understanding of other disciplines. BAs also need to gain an understanding of different approaches to delivery, and to understand the part analysis plays within those approaches.
A useful starting point is to consider the breadth of business analysis within the lifecycle for business change.
First, is the BA role right for you? - Do you enjoy analysing complex ideas and situations? Business analysis involves contextualising and analysing complex situations. Successful BAs enjoy working within this complexity, having the ability to delve into complicated detail where needed. - Do you find yourself curious about situations, always wanting to ask questions? Good BAs show genuine curiosity about the situations they work within. This curiosity drives them to ask questions and investigate angles that others might overlook. - Do you find yourself looking at the big picture? When conducting analysis, it is crucial to examine the situation holistically, considering people, processes, organisational issues and information & technology (e.g. POPIT™ model). This is a skill that can be developed over time, but those who have the ability to think at a broad, macro level (as well as a micro level)may find business analysis an easier career transition than those who tend to think only at the micro level. - To what extent do you enjoy working with others? BA work often involves a mixture of working with others and working alone. There can be intense peaks of interaction with others – perhaps a major workshop – followed by periods of writing up. A BA therefore needs to be comfortable with both. This does not mean that you need to be an extravert, though shyness could prove to be a barrier. - Are you comfortable with ambiguity? More senior BAs often need to deal with significant levels of ambiguity. They may be examining situations where there is a general feeling that there ‘is a problem’, but the scope and scale might initially be undefined. It is important not to immediately jump to the detail or a solution but to examine the richness of the situation first. The level of ambiguity that a BA needs to deal with often increases with experience – more junior BAs may work within more bounded arenas, but it is nevertheless important for all BAs to be comfortable with embracing some level of ambiguity. - To what extent are you comfortable negotiating through, and generally managing, conflict? It is highly likely that BAs of all levels will have exposure to conflict. Whether it is a granular issue (such as stakeholders vehemently disagreeing over the priority of a particular requirement)or whether it is a macro-level issue (such as a disagreement over strategic direction), a BA needs to be comfortable acknowledging and addressing the conflict. Individuals who are uncomfortable with conflict may find business analysis a challenging career choice. - Are you a clear written and verbal communicator? Communication is key to business analysis – both verbally and in written form. Being able to communicate precisely and concisely is a significant advantage, and BAs who do not possess this skill will need to acquire it extremely quickly. - Do you prefer a routine or varied schedule? Most BA roles involve a very varied schedule. One week might involve long days running (and writing up outputs from)workshops and interviews. Another might involve desk-based work putting together draft models or specifications, while liaising with stakeholders one on one. There will be peaks and troughs, and it is important to be ready to accommodate this. - Are you confident liaising with (and, where necessary, challenging)very senior stakeholders? BAs need to liaise with senior people in organisations, and this requires confidence. New BAs might initially be shielded from more senior stakeholders, but as their career progresses it will become increasingly important to liaise with heads of department, directors, and even chief executive officers, chief operating officers and chief information officers. This is likely, on occasion, to include challenging a stakeholder’s perspective. For example, a stakeholder might have a preconceived idea about what a solution should be, and a suitably experienced BA may offer instead to carry out a more thorough analysis to see whether there are other (potentially more suitable)options available. Being able to challenge with rapport (and with the organisation’s best interests at heart) is an important skill – particularly for more senior BAs. - Are you a lifelong learner? Analysis is a continually evolving discipline, and good BAs accept the need to continue to learn and develop. This may be undertaken outside the core role, in the evenings and at weekends, but it is part of what enables a practitioner to stay current. Additionally, newer BAs should consider gaining a relevant business analysis certification – for example, the BCS Foundation Certificate in Business Analysis or the BCS International Diploma in Business Analysis, or IIBA®’s Entry Certificate in Business Analysis™ or Certification of Capability in Business Analysis®. More experienced BAs may aim for the BCS Advanced Diploma in Business Analysis or IIBA®’s Certified Business Analysis Professional®. - To what extent are you (or could you become)resilient? Business analysis invariably involves challenging stakeholders, who might not want to listen. It also involves being embroiled in conflict – which often has a political undertone. It is easy to get stuck in the middle, and sometimes BAs have to make themselves unpopular in the short term for the overall good of the organisation and the project. This requires resilience and the ability to abstract oneself away from the conflict situation. If you are someone who finds that they cannot do this, or if you find it impossible to switch off after a difficult day at work, then business analysis might be challenging for you. - Are you a fast learner? Many BAs work across different business areas, which requires them to come up to speed with new domains quickly. To take an example, if you were put on a project in the finance team to replace a major financial system, would you feel comfortable that you would be able to independently and quickly ascertain the key concepts and areas of terminology that you would need to work with the finance stakeholders? - Are you able to influence without authority? There is an element of leadership in just about every BA role. Even the most junior of BAs is likely to need to influence those around them, whereas senior BAs may be responsible for influencing a whole range of stakeholders inside and outside their organisation. This may involve, for example, helping to foster agreement amongst a group of stakeholders who initially disagree. It may also involve explaining the benefits of a project and persuading stakeholders to make more of their time available during the project.
Business Analysis And The Business Change Lifecycle
Alignment During the alignment phase, the focus of the analysis will include understanding the external business environment and assessing relevant opportunities and threats. This is an area where more experienced BAs may be directly involved, helping sponsors and stakeholders as follows: - Assessing and understanding the internal and external environmental factors, using techniques such as SWOT (strengths, weaknesses, opportunities, threats), STEEPLE (social or socio-cultural, technological, economic, environmental, political, legal, ethical)or PESTLE (political, economic, social or socio-cultural, technological, legal, environmental), Porter’s five forces, resource audit, VMOST (vision, mission, objectives, strategy, tactics)and others. - Identifying potential changes that may be necessary to leverage opportunities and protect against threats. These changes may involve the development of new organisational capabilities, including changes to organisational structures, people or roles, processes, and information and technology. There is a natural intersection with the discipline of business and enterprise architecture here, with larger organisations typically having delineation between these roles. In these cases, a BA may work alongside other roles to undertake or support these types of activity. - Understanding the organisation’s existing enterprise architecture. Assessing its strengths and weaknesses, and identifying areas in which it may need to change. - Ensuring that potential changes are aligned to strategy – and raising concerns where initiatives are suggested that are out of kilter with the organisation’s stated strategy. - Ensuring that potential changes are aligned to the organisation’s architectural roadmap. This may include considering the IT roadmap, the systems that are deemed to be ‘strategic’ and the systems that are due for decommissioning. It may also include considering the proposed change in the context of the process architecture, determining opportunities for reuse of technology or processes, and so forth. - Highlighting where stated strategy may need to be revisited or redefined in light of external or internal environmental changes. - Contributing to, or working on, an initial outline or strategic business case. - Analysing and presenting various options for achieving the requirement outcomes.
Definition Change or project definition involves the definition and prioritisation of competing initiatives, taking into account more detailed estimates of the likely costs and benefits than have been created previously, and establishing – at a high level – how the underlying business and stakeholder needs might be met.
More experienced BAs may be involved, undertaking activities such as: - elicitation, analysis, documentation, validation and management of requirements; - production of detailed documentation to support the selection of a vendor or solution, including supporting request for information (RFI), request for proposal (RFP)and invitation to tender (ITT)processes where relevant; - revisiting and contributing to the business case; - analysis and presentation of various more detailed options for achieving the required outcomes.
Design This phase of the business change lifecycle includes the detailed design of the change that will deliver benefits to the organisation. This may involve the design of IT systems, processes, organisational structures, job or role profiles, and so forth. A key enabler for design is a clear and shared understanding of the requirements, as these requirements elaborate and articulate the underlying needs of the business. Business analysis helps to ensure that this common understanding is maintained throughout the design stage.
Definition And Design In case of business analysis, ‘definition’ and ‘design’ have unclear edges. For example, a low-fidelity ‘throw-away’ prototype, such as a quick sketch of a screen, might be used to elicit basic information about the data that needs to be captured. This would be classed as ‘definition’. Yet, if the prototype were collaboratively refined so that it showed the broad layout that was required, it would start to shift towards ‘design’. The same can be true of processes too. Specifying a detailed set of ‘to be’ processes, which include detailed task descriptions, that lay out precisely how the work should be undertaken includes a strong element of design. A key point to take away from this is that the business change lifecycle provides an overall framework but does not prescribe or restrict how the techniques can be used. It is for us, as skilled practitioners, to choose the right tool for the job. The BA will also ensure that a holistic view is taken. For example, a change to a process may have a knock-on impact on the organisational structure and may require new technology to enable it. Equally, implementing a new IT system may mean that some processes need to be redefined, people need to be engaged and trained, and new support roles need to be created. It is also important to keep in mind the organisation’s architectural roadmap, to ensure that the relevant design fits well (or, if it departs from the roadmap, that this is a conscious and agreed decision). The design stage of the business change lifecycle also includes the development and testing of any change. BAs will be on hand to support test specialists or other practitioners who are undertaking any testing effort, with acceptance criteria being a crucial link between the requirements and testing activities. As with every stage, the business case will be revisited, and the BA will work continually with the project and business stakeholders to ensure that scope is tightly managed. The business and project objectives that are articulated in the business case will act as a guiding beacon, and the BA (along with the project manager (PM) and other key roles)will act as a guardian of the scope. The BA will also highlight to the sponsor and PM when situations change and the scope may need to be revisited.
Implementation Implementation involves the physical roll-out and bedding in of a business change. It would be naive to think that a change will stick simply as a result of being delivered. Stakeholder engagement and management are crucial throughout the business change lifecycle, but they are a core focus during the implementation stage. People may suddenly see the change as very ‘real’ (whereas in the past it was ‘abstract’, discussed only in meetings, roadshows and newsletters). This can, quite understandably, cause shock and fear. It is important that we are empathetic to the situation – often we are ultimately changing the way that people work, and this can be very disconcerting. Things sometimes get worse before they get better. Or, to be more precise, productivity may well dip whilst people are getting used to a change. If you were to switch to a Dvorak keyboard, you would almost certainly slow down for a few days (or more likely weeks)whilst you got used to the new layout. However, once you had learned the new layout, the benefits would start to accumulate. It is important that expectations are managed; there are very few (if any)silver bullets that lead to instant improvement. Often there is a period of discomfort at first, and it is important that people are aware of (and supported through)this discomfort. BAs rely on their interpersonal skills, and the relationships that they have built throughout a project, to engage with stakeholders and their situation, and to help to successfully embed the change.
Realisation Benefits realisation involves assessing the benefits that a change initiative actually achieved and comparing them against what was forecast. During a project, there is often a focus on delivering ‘on time’ and ‘on budget’. These two factors are of little value if you do not also deliver ‘on scope’, ‘on quality’, ‘on strategy’ and crucially ‘on benefit’! Throughout the business change lifecycle, BAs, along with other project professionals, ensure that there is a clear articulation of the anticipated benefits. BAs may also conduct analysis for a benefit owner to determine whether a solution has met the benefits that were forecast. The sponsor is ultimately accountable for the benefits and is likely the ‘owner’ of the business case, but BAs can help in assessing whether the benefits have been realised. It is crucial that as BAs we act ethically and genuinely report the situation that we find. In fact, if the benefits have not been fully realised, this might be an opportunity for another incremental change. Perhaps only 80% of the anticipated benefits have been realised but a small (cheap)incremental change will release the remaining 20%. It may be that this improvement can only be identified if we revisit the original change once it has bedded in. It is clear from the discussion above that business analysis (as a discipline)exists both inside and outside projects. Of course, as practitioners, a significant proportion of our work may be project related, but we can equally add value before a project is initiated and after it has been delivered. Some engagements might not be project related at all.
The T-Shaped Business Analyst Since BAs are involved in such a wide range of activities, they need both a depth of knowledge and experience in business analysis and business practices, and a broad and shallow understanding of other complementary disciplines. It is increasingly being recognised that BAs need to be ‘T-shaped’ professionals. Michigan State University’s T-Summit provides the following useful definition, which compares I-shaped and T-shaped individuals.
T-shaped professionals are characterised by their deep disciplinary knowledge in at least one area, an understanding of [holistic] systems, and their ability to function as ‘adaptive innovators’ and cross the boundaries between disciplines. In comparison with the ‘T’ shaped individual, the ‘I’ shaped individual is focused largely on their particular knowledge and skill-set, views the workplace as a competitive environment, and works within disciplinary silos.
Vertical: Depth of knowledge and experience It is important that a BA has expertise in relevant business analysis knowledge areas, frameworks, tools and techniques. It is also important that we retain a healthy level of curiosity and connect with practitioners in other domains (and other parts of the world)who may be using or developing different techniques.
As well as deep business analysis skills, we also require sufficient business knowledge. This includes having enough specialist domain knowledge to be able to hold a meaningful conversation with stakeholders. We certainly do not usually need to be subject matter experts (SMEs)or domain experts, but we do need to have enough knowledge to meaningfully converse with such experts. This knowledge and expertise can come from a number of sources: some BAs make the transition from domain expert or SME to business analysis, and when they do so they bring with them a wealth of domain information.
For BAs who have entered the discipline from other routes outside the business, it is often necessary to consciously develop sufficient domain knowledge. Often, this is a natural part of undertaking project work. When a BA is ‘parachuted’ into a project, they will need to conduct fact finding, which may well involve researching and understanding the domain. This might involve reading relevant reports and white papers, drawing on professional networks for advice, and examining other artefacts that give details about how the specific organisation is structured. For example, organisational structure charts and process models tell us a lot about how a business operates and give us clues regarding the types of terminology, acronyms and jargon that are used. It is also important that we have sufficient knowledge of how businesses operate generally, having an appreciation for common business practices, processes and trends, and that we stay actively aware of emerging and changing trends.
There may be other areas of specialist knowledge and skill that are required, depending on the specific environment or initiative. For example, BAs working in an adaptive agile environment may well require detailed knowledge of the particular approach which has been adopted as well as a thorough understanding of the underlying principles of agile, whilst also maintaining a more general knowledge of other agile approaches.
Horizontal: Depth of knowledge and experience There are two broad horizontal areas of knowledge and experience. These are areas that help us to collaborate well with other disciplines: - Broad (shallow) appreciation and understanding of other disciplines: As a BA’s career progresses, it is likely that their exposure to complementary disciplines will broaden due to the projects that they work on – indeed, experienced BAs may seek specific projects in order to gain broader experience. This could include an understanding of disciplines such as user experience, customer experience, project and programme management, software architecture, testing, service design and many other topics. It is important to note that I am not suggesting that all BAs must become experts in these topics (although of course an individual practitioner may choose to specialise in a certain area). However, developing an understanding of multiple disciplines helps us to work more effectively with our colleagues and also collaboratively see the bigger picture with regard to how business change is progressed. - Boundary-crossing competencies: There are also other competencies that, although often considered to be rather generalist in nature, are crucial for effectively practising business analysis. These include interpersonal skills, leadership, critical thinking, influencing without authority and so on. The fact that these are shown in the horizontal part of the T does not suggest that they are any less important. They are important enablers that allow BAs to liaise and work with others.
Career trajectories of BAs While the BA discipline is broad, individual BA roles may be narrower than the broad possibilities. Additionally, many organisations have a range of BA roles, at varying levels of seniority, typically with less experienced BAs initially requiring less depth and breadth. It is quite possible to transition towards a BA role from other roles.
Naturally, over time, an individual practitioner’s breadth and depth of experience will increase. However, it is crucial that we (as individual practitioners)take ownership of our development. It is important that we do not stagnate and that we actively keep up to speed with developments in business analysis and our industries. Where possible, we should also seek engagements that stretch us and provide us with opportunities to expand our exposure and experience.
Approaches To Delivery Of Change The types of techniques that we use and the skills we deploy are affected by the nature of the engagement we are working on and the delivery approach that is being pursued. There are a wide variety of types of approach that can be used to deliver change and it is important that we know about these and tailor our BA approach to fit the context. Two approaches are outlined below.
1. Predictive approaches Some predictive approaches focus on reducing uncertainty by formalising scope early. These approaches typically segment a project into phases and are executed in a fairly linear fashion. It is normally assumed that a stage must be completely finished before the next commences, and each stage typically produces a range of documents and other deliverables.
Although predictive approaches are typically shown in a linear fashion, there will undoubtedly be some recursion back to earlier phases when necessary changes are identified.
Business analysis involvement can start prior to a formal feasibility study and will typically involve understanding the core problem or opportunity, understanding the internal and external context and constraints, and helping to define the required outcomes. A BA may lead or contribute towards the business case and will help to evaluate various options for potential solutions. If the business case is approved, then more BA effort will be required in the analysis phase – this is typically where the existing situation is examined in greater detail and detailed solution requirements are defined. For large projects in large enterprises, this can span several months. A typical detailed analysis deliverable is a requirement specification, which typically consists of a range of artefacts, including models and textual representations of requirements.
2. Adaptive approaches Iterative and agile approaches favour an evolutionary approach to requirements discovery, with a focus on collaboration. The project is typically divided into fixed ‘timeboxes’, during which increments of working software are designed, developed and tested in order to deliver elements of valuable change to the organisation sooner.
‘Does there need to be a BA in agile projects?’ After all, with smaller iterations, it is tempting to think that the role can be subsumed by a developer who speaks directly to the business stakeholders. You may also have observed that some agile approaches do not mention a BA at all.
The agile principles […] include a principle that identifies the importance of a face-to-face conversation between a developer and a business user when uncovering requirements. Highlighting the importance of a conversation to clarify requirements means that business analysis is needed, even if the work is done by someone with a different job title.
Working as a BA in an agile environment can be quite different from working in a waterfall environment. Firstly, the demand for BA resource in agile environments tends to be more level, whereas in waterfall environments there are typically significant peaks (relating to feasibility and requirements)as well as troughs where less BA resource is required. In agile, a BA may also find that the artefacts they produce are lower fidelity – perhaps a quick snapshot of a prototype on a whiteboard (alongside relevant conversations and clarifications)is considered good enough to guide the next iteration of development, although this will of course vary depending on the context. This is in contrast to waterfall, where a BA is much more likely to produce more formal sets of documents.
Subject Matter Expertise Another area of perennial debate in the BA community is how much domain knowledge a BA must possess. Does a BA have to be a domain expert or SME? The amount will depend on their situation, context, seniority and so forth.
Business Analyst Roles And Responsibilities The specific areas of responsibility and accountability that a business analysis practitioner has on a particular assignment are likely to depend on a range of factors, including the particular context within which they are operating, the type of project, and their level of experience or seniority. They will also depend on the relative maturity of the business analysis function or practice within the organisation, and how well it is perceived by stakeholders. Organisations with a mature BA capability often find that analysts are engaged in pre-project problem analysis work; others may still be aiming to gain exposure to this type of work. BAs can work both inside and outside projects. Some of the common key areas of responsibility include the following: - stakeholder identification, engagement and management; - planning and estimating the business analysis work; - elicitation; - strategic analysis, problem finding and contributing to the business case; - requirements analysis, documentation and validation; - requirements management; - solution evaluation and benefits realisation; - leadership; - staying current; - understanding other disciplines.
Stakeholder Identification, Engagement And Management Business analysis is a very people-centric profession. Organisations are, ultimately, ways of orchestrating and co-ordinating action, and it is the people within them that make this action happen (or not). Therefore, BAs of all levels find themselves spending a lot of time working with stakeholders. Often, when starting a project or change initiative, the stakeholder landscape will not be known. It is necessary for the BA to work alongside other project members to scope out the stakeholder landscape and to identify those stakeholders who will be relevant. Often the project sponsor can give an indication of the organisational areas, functions or teams that are likely to be impacted by a project, and this will provide a useful starting point. Yet, depending on the nature of the project or change, other stakeholders are also likely to be relevant, including external stakeholders such as regulators, customers or partners. Stakeholder management is, of course, a shared responsibility. The BA is likely to work closely with other colleagues, such as the project manager. Yet analysts often have a unique perspective – able to pre-empt and hopefully prevent issues occurring by identifying the areas that may be impacted or affected by a proposed change. It is also likely that the BA will closely liaise with stakeholders of all types during the project, and will therefore be able to pick up on subtle changes in attitude that may otherwise go unnoticed. It is quite possible that an individual who was once an advocate of a change may ‘go cold’ if they feel they are not being properly consulted. Regular engagement will help to pick up on this change early, so that relevant action can be taken.
This highlights a crucial skill that good BAs possess – the ability to engage, relate to and empathise with people throughout an organisation. BAs starting their career may be able to rely on more experienced colleagues for help when liaising with very senior executives, yet as more experience is gained it is crucial that a BA is able to communicate and work with stakeholders of all levels. It is often necessary to gain an understanding of a stakeholder’s perspective relatively quickly whilst meeting them, so rapport-building skills are crucial. It is also quite possible that some stakeholders may be sceptical of or even resistant to change, so the ability to empathise with different perspectives (whilst remaining as impartial as possible)is important.
Planning And Estimating The Business Analysis Work BAs may be involved early in the business change lifecycle, long before a project has been defined or a PM has been assigned. This means that it is necessary for BAs – particularly more senior BAs – to put together plans for the proposed analysis work. Indeed, this is true throughout the business change lifecycle. Once a project has been defined and a PM has been assigned, it is likely that the BA will need to provide a plan of the analysis work for the PM to feed into their overall project plan. Analysts also need to monitor against, and report on, the progress made against the plan. This reporting may be directly to a sponsor or to a project or programme manager. Where multiple BAs are working together, a more experienced senior or lead BA may report on the group’s progress. The lead BA will also be responsible for co-ordinating the work of the other team members, ensuring that key deadlines are met and ensuring that all of the necessary analysis work is conducted to the desired standard.
Elicitation Another key responsibility that analysts of all levels take on is that of elicitation. This is an area that BAs may be responsible for at different levels throughout the project lifecycle. Elicitation can be described as a proactive approach to uncovering the requirements. It involves drawing out information from the [stakeholders], helping them to visualise the possibilities and articulate their requirements.
Elicitation, therefore, involves drawing out information from the business situation – for example, by speaking with stakeholders, observing them, and analysing documentation and so forth. This responsibility starts very early in the business change lifecycle. A BA may elicit perspectives on a problem situation and investigate possible causes. This may lead to the definition and documentation of high-level business requirements. Assuming the project proceeds, further elicitation will be required to refine those business requirements into more granular solution requirements.
Strategic Analysis, Problem Finding And Contributing To The Business Case It is crucial for BAs to be aware of the strategic context within which their organisation operates. Mid-level and more senior BAs are also likely to be responsible for strategic analysis. This may involve assessing the strategic landscape, understanding external factors that may affect their organisation, assessing internal strengths and weaknesses, and making recommendations. This work is likely to start before a formal ‘project’ is initiated and is likely to involve helping the sponsor to understand – at a high level – the problem or opportunity that they are looking to address. A sponsor may initially have a gut feeling with regard to the nature of the problem, but further investigation will be required to determine whether this gut feeling is in fact accurate. The BA will be responsible for planning and undertaking this investigative work, and reporting back to the sponsor or their nominated deputy. As well as helping to define the opportunity or problem that the sponsor is looking to address, BAs will typically be responsible for helping to evaluate potential options. There are often a whole plethora of options available, which may involve IT change, process change, in-sourcing, outsourcing, organisational structure changes, training of staff and much, much more. Sometimes, stakeholders will have an early assumption on what the ‘best’ option would be, and the BA may need to encourage divergent thinking so that other options can be considered and evaluated. This will ensure that the sponsor – as the ultimate decision maker – can make a decision based on information and analysis. A crucial document that enables this informed decision making is the business case. The business case is ultimately owned by the sponsor (who is accountable for the realisation of the benefits that are outlined within it), but the BA is an important contributor – often writing some (or most)of the document. Normally business case work is undertaken by mid-level and more senior BAs, and specialist members of the programme or project office may provide templates and input. This will particularly be the case where specific investment appraisal techniques are used – a BA may provide the input, with the calculations being undertaken or validated by a specialist.
Requirements Analysis, Documentation And Validation Elicitation of requirements – whether high-level business requirements or more granular solution requirements – will likely result in multiple and contradictory views emerging. It is likely that different, often conflicting, requirements will be raised by different members of the stakeholder community. Perhaps the marketing team wants a website that is ‘easy to use’ and so wants to reduce the number of clicks required to navigate through an online order form. Yet the legal and compliance team states a need to include a full, lengthy set of terms and conditions with a number of ‘opt-in’ check boxes. It may be difficult to balance these two requirements, and therefore negotiation will be required. Requirements analysis involves synthesising a range of perspectives, filtering the requirements, and ensuring that the resultant requirements form a consistent set and are of good quality. It involves working with stakeholders to resolve conflict and to prioritise the requirements, so that those that are most crucial (and that deliver most value to the business or customer)are delivered first. This is easier said than done! As this takes place, whatever requirements artefacts are being produced will become more structured. This might mean, for example, that the results of initial conversations are drawn up as a set of user stories (with associated acceptance criteria, and perhaps even with quick sketches that serve as prototypes). Or, it might mean that a requirements catalogue is produced. The formality and format of the documentation will depend very much on the approach, with adaptive approaches such as agile typically preferring less formality when compared with predictive approaches such as waterfall. Certainly, BAs must shape and challenge the documentation that is requested or produced. The art is to produce just enough to communicate unambiguously – being precise yet concise is crucial. It can also be beneficial to create one or a range of models to add clarity and precision to the requirements. BAs use a range of models, including context diagrams, use-case models (and scenarios), prototypes, data and information models, process models, state transition diagrams, sequence diagrams and many more. Experienced BAs should be familiar with a whole range of diagramming conventions, with newer BAs perhaps being familiar with just a few. Of course, even in the most linear of approaches, requirements are likely to emerge in a somewhat iterative fashion. That is to say, stakeholders’ ideas may evolve and be refined as the requirements are discussed and documented. There is always a danger that the requirements that have been documented will not match the actual needs and expectations of the business; therefore, it is important to undertake requirements validation. This helps to ensure that the requirements are in scope and aligned with the business’ needs, and this process typically culminates in some sort of approval. The formality of this approval may vary depending on the type of project and the context – if the solution is being designed and delivered by a third party (external)vendor, it may involve physical sign-off. Where projects are smaller or being conducted using a more adaptive approach, a softer approach to sign-off may be acceptable.
Requirements Management Requirements of all types must be managed – whether they are high-level business requirements or detailed solution requirements. A BA is typically responsible for ensuring that the requirements are managed and remain traceable throughout the business change lifecycle. This involves ensuring it is possible to determine where a requirement came from (e.g. whether from a stakeholder, a document such as a piece of legislation or elsewhere), who owns it and what the status of the requirement is (e.g. whether it is delivered or whether it has been agreed that it will no longer fall within the scope of this particular project). This traceability – from source to resolution – is known as ‘horizontal traceability’. It is also key to be able to trace requirements to the overriding business requirement and business objective, and down through different levels of abstraction – this is known as ‘vertical traceability’. Maintaining traceability involves managing a requirements architecture that enables different requirement and design artefacts to be associated with each other. For example, a use case in a use-case model may be associated with a scenario; that scenario may mention that it is necessary to capture ‘Customer’s Name’; and this in turn may relate to an attribute of an information or data model. A set of non-functional requirements may sit across all of the use cases, providing (for example)requirements on security and accessibility. Maintaining traceability is a crucial responsibility. On larger projects, more experienced and senior BAs may be involved with defining the requirements architecture – this includes deciding on the models that are appropriate to use for a given situation. This is particularly crucial when more than one BA is involved, as it is important to ensure that the various requirement artefacts link together. Junior BAs may well make this decision too, for smaller projects, but are likely to follow the guidance of more experienced colleagues on medium and larger projects. Requirements management also involves the management of change. When using a predictive model of change (e.g. linear waterfall), this will typically involve liaising with stakeholders and ensuring a formal ‘change request’ is raised. This change request will then typically be impact assessed, based on its costs, benefits, risks and impacts. In some adaptive models of change (e.g. agile approaches), there is a focus on welcoming, prioritising and absorbing valuable change whenever it occurs – the BA will typically work alongside the relevant business and project stakeholders to assess the impact of the change and prioritise it against other requirement areas. This is typically orchestrated through some form of prioritised requirement list or ‘backlog’.
Solution Evaluation And Benefits Realisation During a project, the focus is often on delivering a solution. Yet, ultimately, a ‘solution’ is only a means to an end – it is a way of realising some form of benefit. Usually this will ultimately translate to some form of financial benefit, such as increased profits (by increasing revenue or reducing costs, or both). It may equally be some other form of outcome which does not directly translate to a financial benefit (e.g. migrating away from an old unsupported IT system to reduce operational risk). Assessing a solution’s effectiveness is key. Mid-level and more senior BAs may have some level of responsibility for this task, although the benefits themselves should be owned by the sponsor or a relevant benefit owner. There are several situations in which a BA may become involved in this type of work: - Benefits not realised: Where there is a feeling that benefits haven’t been realised, a BA may be tasked with investigating, benchmarking and so forth. This may lead to further investigative work and eventually a recommendation for further change. - Systems or processes not working: Where a project has been implemented but there is a feeling that the systems and processes haven’t bedded in, a BA may carry out investigation. They may find, for example, that the communication and engagement during the transition did not work as well as expected, and therefore that front-line workers did not receive the training required (resulting in them adapting the process informally). Again, this may result in recommendations for further changes or enhancements. - Assessment of benefits: BAs may be involved with the assessment of benefits. As an objective party, a BA can help to ensure that the figures are not manipulated and that there is no evidence of ‘creative accounting’. Often a BA will work alongside other stakeholders to collate the relevant data and compare it against the latest version of the business case, reporting back to the sponsor or benefit owner.
Leadership BAs of all levels of seniority are responsible – to some extent – for leading. More senior analysts may have formal responsibility for leading a team of analysts on project work, but even analysts with limited experience need to lead – often without authority. In Business Analysis and Leadership: Influencing Change (Pullan and Archer 2013), a range of authors and thought leaders from the world of business analysis discuss leadership at four levels (see Figure 3.1 for a pictorial representation): - Leading oneself: Every practitioner has the responsibility to lead themselves. As individuals, we should develop self-awareness, be aware of our own strengths and weaknesses, and own our professional development. It is important that we have the audacity to ask difficult questions for the good of the organisation and project. - Leadership of a project or programme: On projects, BAs typically lead stakeholders in a subtle but crucial way. We influence without authority, building relationships and doing everything we can to keep the project on track. We escalate concerns and work alongside project and programme management colleagues. More senior or lead BAs may, of course, be responsible for co-ordinating large pieces of work and leading other BAs. - Leadership within the organisation: To make change stick, we need a clear understanding of the organisation in which we work. We may lead early pre-project strategic work that helps to form a clear understanding of the real problem. We may exercise informal leadership by considering situations holistically, looking beyond silos, and ensuring that projects and other initiatives are working in the best interests of the organisation. This may involve proactively navigating culture, politics, and thinking holistically and systemically. It may also involve proactively promoting business analysis to teams that do not (yet)see the benefit of the change, and acting as a strategic partner to the business. It can involve perceiving problems that the business stakeholders themselves haven’t yet seen, and pre-empting change that may be beneficial in the future. - Leadership within the wider world: BAs may exhibit leadership outside their organisations too, whether this involves volunteering for professional associations such as BCS or IIBA®, or sharing ideas and experiences with other practitioner communities. This might involve writing, blogging, speaking, attending knowledge-sharing meet-ups and much, much more. Extremely experienced BAs may become known as thought leaders through their contributions to the community.
A tricky question emerges when leadership is discussed in the context of business analysis. Should a senior BA be responsible purely for leading others on an initiative, providing guidance for that initiative? Or should senior BAs also be line managers? Different organisations tackle this question differently. Often, where there is a large team of BAs, there will be a capability lead who has overall responsibility for leading the team but who delegates the day-to-day line management to a handful of career managers, or lead or principal BAs. However, when considering one’s own career plan, two considerations should be kept in mind: - To manage or not to manage? Some BAs are excellent people managers and relish the opportunity to take on line management. Others are quite comfortable with managing others on a project but do not enjoy the nuances of line management (e.g. absence management, mid-term and annual reviews, and pay reviews). Therefore, some organisations provide the ability for BAs to progress with or without line management responsibility. - Project managers and line management – a word of warning: It is normal for BAs to provide regular updates to PMs; however, it can be tricky if a PM is a BA’s line manager. Imagine, for example, that a project is running late and a BA has a three-day training course coming up (which has been in the diary for 18 months and won’t run for another six months). A good line manager would probably take the view that, if a training course has been in the diary 18 months, it should take priority over the project (after all, if absence cannot be planned with 18 months’ notice, then something is seriously wrong!). Yet a PM may face a dilemma; if they are seen to let the BA go on a training course, this might be perceived badly by the sponsor. They may, therefore, be inclined or feel pressured to suggest that the BA cancels. This can lead to situations where there is a tension between the best interests of the member of staff (who in this case just happens to be a BA)and the project. It should be said of course that there are many good PMs out there who wouldn’t bow to such pressure – but it is a consideration that should be kept in mind.
Staying Current We live in a fast-moving and ever-developing world. There is an implicit responsibility for BAs to stay up to date with trends in a number of areas, including our industry sector, technology and of course, crucially, analysis generally.
Industry We should maintain a ‘watching brief’ on our industry sector, ensuring that we maintain sufficient knowledge of the context in which our organisation (or our client’s organisation)works. This does not imply that we need to be SMEs. Yet, in order to have meaningful conversations with our stakeholders, we should know enough about the domain and any changes or disruptions that are occurring. We ought to have a broad knowledge of any key pieces of regulation or legislation that affect us, the services that the organisation offers, and its customer base – but, again, this does not imply that we need to be experts. Taking just one example, if we were working with a sales team, it would be crucial that we had an awareness of any data protection legislation that was in force or might change (as it would be vital that the relevant legislation were adhered to when recording details of customers).
Technology The extent to which a BA needs to be familiar with technology depends on the nature of the organisation and the context in which the practitioner is operating. A BA working in a retail and warehouse operation might need to be familiar with technologies such as barcoding and what is known as ‘voice picking’. A BA in an insurance company might need to be familiar with industry-standard underwriting systems and business rules management systems. More senior BAs may need to have an appreciation of the underlying technical architecture too. Again, a BA does not need to be an expert in the technology. It is useful, however, for them to have sufficient background to hold a meaningful conversation with business stakeholders, technical stakeholders and other project stakeholders such as testers. If an organisation makes heavy use of CRM systems, for example, it is important to stay informed in the types of development that are emerging in this field, as well as the terminology and lingo that are used. If a BA working within this context does not have this knowledge, it is important that they carry out some initial research to ensure that they are speaking a common language with their stakeholders. Otherwise, certain nuances might be lost in communication when our colleagues use specific terms which we understand in a different way. For example, to a member of the sales team, ‘opportunity’ might mean ‘a qualified lead for which we are pitching’; however, to a BA, it might mean ‘a factor external to the organisation that we can seize’. Ensuring we have enough knowledge of the landscape and any key terms will help us to avoid this kind of communication clash. This type of knowledge can be gained by reading industry publications and white papers, attending vendor webinars, attending conferences and so forth. It can also be useful to monitor general technical journals and to follow relevant groups and experts on social media.
Analysis Whilst the core purpose of analysis is unlikely to change any time soon, new techniques and established practices do emerge. It may be that existing techniques are adapted or clarified to fit particular circumstances) or new techniques emerge which are considered particularly relevant for particular contexts (e.g. user stories along with associated acceptance criteria in agile). It is crucial that we stay informed about developments, so that we can draw on relevant techniques when the specific circumstances call for it. What we are really talking about here is the continual adaptation and evolution of our BA toolkit. With a global community of business analysis practitioners using techniques and learning from these experiences, we have a vast well of knowledge on which we can draw. Many individual practitioners share their experiences in online forums, with others contributing and adding details of what worked (and did not work)for them in specific contexts. This can be a great way of learning and a great way of contributing one’s own experience. Of course, as with any online source, one should treat any assertions made with a certain element of caution, ensuring that assertions have been on the basis of evidence! Yet practitioners will often share case studies, ideas, patterns, flexible templates and so forth, which can be useful. Additionally, there are publications and journals that discuss and evaluate different techniques, and professional associations such as BCS and IIBA® provide platforms for practitioners to meet and exchange ideas. There are also a whole range of larger conferences (such as the Business Analysis Conference Europe and the Building Business Capability conference in the USA)where practitioners meet and share their experiences. All of these are ways of staying up to date with established and emerging trends. Plus, those of us who work within an internal BA team or practice should not forget our own colleagues. There can be great opportunities to learn from each other, either informally (such as through ‘lunch and learn’ sessions)or more formally (through forms of knowledge transfer such as training, or knowledge capture and management strategies).
Understanding Other Disciplines Business analysis has natural intersections with other disciplines, and an experienced T-shaped BA will have some knowledge of some of these disciplines – along with boundary-crossing skills which enable them to build rapport and exchange knowledge with others. BAs liaise closely with colleagues who work in these disciplines, and it is therefore helpful for an experienced BA to have a basic knowledge of the core concepts within these disciplines. This may be achieved via structured learning or self-directed study, but equally may be picked up on the job. It is often the case that projects provide us with exposure to different disciplines, different ideas and perfect opportunities to expand our knowledge and develop broad as well as deep expertise.
User experience consultant or professional User experience (UX)is a broad topic which considers how users interact with systems. It is a rigorous discipline which enables data and insights to be gained from studies of real users (or potential users). It also enables deliberate design (or redesign)in order to improve the experience, prototyping, and testing (amongst other activities). User experience is the totality of the effect or effects felt by a user as a result of interaction with, and the usage context of, a system, device, or product, including the influence of usability, usefulness, and emotional impact during interaction, and savoring the memory after interaction. BAs and UX professionals need to work closely together to ensure that work is not duplicated. For example, a BA might define the broad scope of an engagement (‘We want to launch new features on our online web-based banking platform’), which is then followed up with detailed user research (‘Our customers are telling us that they would value an easier way of tracking interest rates’), which then leads to low-fidelity sketches and prototypes (‘Let’s test this idea’) and then potentially high-fidelity realistic prototypes. It is likely that the UX consultant would lead the detailed customer research and that the BA and UX consultants would collaborate on the initial prototyping, with the UX consultant handling the high-fidelity prototyping. Alongside this, the BA would be considering aspects such as data (‘What is the impact, if any, of these changes on our data model?’)as well as process and broader aspects such as how the change would be rolled out and communicated to the relevant users and stakeholders.
Project manager A PM is responsible for establishing the objectives of a project, initiating the project, assembling the resources, and monitoring and reporting on the progress that has been made. The PM reports to the project sponsor and will often work closely alongside the BA. It is useful for a BA to have a basic grounding in project management techniques, approaches and terminology, and it is equally useful for a PM to have a grounding in basic business analysis techniques and terminology, to ensure clear communication. Additionally, early in the business change lifecycle, there may be no PM assigned. It is often the BA who carries out the initial pre-project problem analysis, to gain an understanding of where the problem areas are and to gain a view on possible options that might improve the situation. The BA may contribute towards, or lead the development of, the initial business case, and (once a PM is assigned)will feed the analysis activities into the overall project schedule. The BA will also escalate risks to a PM and report on the progress of the analysis activity. It is therefore crucial that the BA and PM have a strong and solid working relationship.
Business architect Business architecture represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders. A key role of a business architect, as defined by BIZBOK®, is to provide an ‘abstract representation of an enterprise’, allowing architecture models to be created that facilitate communication and analysis. These models and other artefacts are often closely associated with (although may not have a one-to-one mapping with)the artefacts that a BA creates. For example, a capability model (showing what a business does and the capabilities it needs to support its value proposition)may have an association with multiple process models (showing how the work is undertaken). Yet the relationship can be many to many – a single process might relate to multiple capabilities, and each capability may relate to multiple processes. It is clearly important, then, that BAs and business architects work together to ensure that the artefacts that they create are compatible and that any relevant links between them are maintained. It is also beneficial when shared, compatible notations or models can be agreed upon. In many organisations, more experienced BAs are assigned business architecture tasks. In fact, the BCS Advanced International Diploma in Business Analysis3 includes a Business Architecture module, which highlights the collaborative nature of the relationship between the two disciplines.
Solution architect A solution architect is typically responsible for defining and maintaining the blueprints of architectural changes required for a solution. If the solution involves IT, this will involve understanding the business and solution requirements, and working with the project team to establish how the various components of the IT architecture (e.g. infrastructure, applications and data)will work together to fulfil the requirements. They may liaise with other specialist architects and are likely to liaise closely with the BA. In particular, it is crucial to remember that the solution architect is one of the many key ‘consumers’ of the requirements artefacts that BAs create and manage, so ensuring that they are provided with sufficient clarity is important.
IT systems analyst or developer An IT systems analyst, often working with a solution architect, will assess how requirements can be met by a specific IT system. This may involve, for example, the mapping of data requirements to the standard (physical)data model offered by a commercial off-the-shelf package, or the assessment of which modules of code need to be changed in order to update an existing in-house bespoke system. Developers are typically responsible for the detailed implementation and coding; however, in some situations, a single individual may undertake the systems analysis and development, or even the business and systems analysis. A BA may liaise with these types of experts to understand the capabilities or constraints of a current IT system or to discuss how requirements will be met by a new (or newly adapted)IT system.
Subject matter expert A subject matter expert (also known as a domain expert) is an individual who has specialist knowledge regarding the specific domain in which a change is occurring. If, for example, a change is being implemented within an insurance underwriting team, the subject matter expert needs to have broad experience and knowledge of what types of underwriting practice typically happen across the industry, as well as the types of system and process that are normally involved. It is important to distinguish this role from a senior user. A senior user often has very detailed knowledge of particular processes but may not have the same specialist breadth of knowledge. They may not, for example, have knowledge of best practice outside the organisation. A subject matter expert, therefore, brings a wider view of the situation. Typically, BAs rely heavily on the information provided to them by subject matter experts, and over time BAs can start to ‘inherit’ areas of domain expertise themselves. There is nothing inherently wrong with this, but it is important that BAs defer to the relevant subject matter experts rather than making assumptions.
Tester Other key roles are those of the test manager and tester. Responsible for ensuring that the final product meets the defined acceptance criteria, testers have a huge stake in the business analysis activity. It is often useful to engage testers early, not least to provide them with information on what will (soon)be heading their way, but also because testers often have very useful ‘war stories’ of how things have gone wrong in the past. Additionally, I have found that testers are particularly good peer reviewers of requirements – they are often able to spot inadvertent omissions that the requirements author has missed. Some BAs may also be required to carry out testing – indeed, there is an argument that says that BAs often know the requirements very well and so they can establish whether a requirement has been properly met. However, it should also be noted that test execution (and test planning in particular)requires a specific set of skills, and testing is a recognised discipline on its own. Therefore, as mentioned earlier, when a BA undertakes testing, they are (metaphorically speaking)taking off their BA hat and putting on a tester’s hat, and they need to be able to shift priorities and perspectives accordingly. It is also sometimes said that having a separation of duties – particularly on larger projects – is healthy, or else there can be a risk that a BA is ‘marking their own homework’.
The Many Kinds Of Business Analysis It is also important to note that, whilst many BAs work on assessing, specifying and implementing change in a project environment, there are many other environments where business analysis skills are used. BABOK® lists five perspectives but highlights that this is not a definitive list, and many other perspectives may exist depending on the organisational context: - agile; - business intelligence; - information technology; - business architecture; - business process management.
Some BAs specialise in particular perspectives, which may lead them to focus and refine their skills in the use of particular techniques. For example, some BAs may work in continuous improvement teams using approaches such as Lean or Six Sigma. This focuses on specific elements of a business process management perspective. As well as having a good understanding of general BA techniques, they will need detailed knowledge of the approaches relevant to that perspective. They may require additional skills too, beyond those of a typical BA. For example, some continuous improvement approaches require a detailed application of statistical techniques of a kind that would not be required in many other BA roles. Whilst all BAs will have core skills, they must adapt to the context they find themselves working within, drawing on the most appropriate skills and techniques. The breadth of the discipline means that there are many flavours of BA role, with BAs existing both inside and outside projects.
The Future: Following are some roles that an experienced BA might consider: - specialist process change roles; - specialist business change/business readiness roles; - business architect; - programme manager; - head of business analysis; - business analysis consultant/contractor; - product owner; - product manager; - director of change; - entrepreneur working with (or in)start-up organisations or small businesses; - and many, many more.
Join 4M+ learners. Unlock unlimited quizzes, wrong-answer tracking, flashcards + reminders, study guides, and 1-on-1 challenges.