6 STANDARDISING THE BA SERVICE

INTRODUCTION

The role of the business analyst has been the subject of much discussion in this book. Clarification of the role is supported by adopting a service viewpoint, and this is enhanced by introducing standards and templates that provide a basis for consistency and efficiency. Consistency is important, as it helps to remove role ambiguity and ensures effective communication with stakeholders and colleagues. Efficiency is equally relevant given the time pressures upon business analysts (and many other roles) when working on business change and IT projects; business analysts are expected to be able to be productive immediately so ‘reinventing the wheel’ for each project is not acceptable. Therefore, the introduction and adoption of standards and templates is often one of the driving forces during the introduction of a BA Service, as shown in Figure 6.1.

Figure 6.1 The role of standards in driving the creation of a BA Service

This chapter covers a range of topics related to consistency and standardisation including:

• re-use;

• selecting standards;

• modelling standards;

• creation and maintenance of templates;

• adoption of standards.

The BA Service must provide a framework of standards and templates to support the delivery of business analysis, as some business analysts don’t know where to start and others don’t know when to stop.

THE ROLE OF STANDARDS AND TEMPLATES

Standards refer to the rules, guidance and characteristics used during business analysis activities. They determine the methods, languages, techniques and life cycles that are applied and provide a basis for deciding upon the deliverables that are produced. Standard approaches to business analysis work typically offer clarity about the deliverables, enabling the identification of the required techniques and the development of templates. Examples of standards used by business analysts are as follows:

• methods/languages: UML, Dynamic Systems Development Method (DSDM), BPMN and Soft Systems Methodology (SSM);

• techniques: diagrams, business process models, data models, stakeholder perspective analysis (CATWOE) and RACI charts;

• life cycles: Iterative (Agile), Linear (Waterfall), Incremental.

Templates are re-usable business analysis deliverables that provide a starting point when performing a particular task or developing a particular document or model, so they can save time and effort. Templates provide the opportunity for re-use and avoid the need to develop a new format or structure each time a technique is used.

Templates should conform to the relevant standards, including formatting, branding, agreed content and notation. The alignment of templates with agreed standards helps business analysts to embed consistency and efficiency across business analysis work.

The nature of re-use

There are two main types of re-use: the re-use of format, which concerns the application of standards, and the re-use of content, which provides the opportunity to ensure consistency and avoids re-interpretation of the same information in different ways.

Examples of templates that may be re-used during business analysis work are:

• format/structure templates: document content headings; column headings, BA support tool configuration;

• content templates: introductory information; glossary entries; compliance statements; standard requirements such as those at business level or non-functional requirements that apply to different systems.

Specific examples of format, and the corresponding content, templates are provided in Table 6.1.

Knowledge may also be re-used through sharing information, insights and lessons learned (see Chapter 9).

Benefits of standards and templates

The BA Service should provide a consistent and efficient approach when working with customers if role clarity is to prevail. This is a key differentiator between a BA Service organisation and the use of a business analysis resource pool, where typically there is only limited consistency in the business analysis work. The BA Service will offer a suite of services, enacted through a range of repeatable processes, where the activities and outputs are similar regardless of who has undertaken them.

Table 6.1 Examples of re-use templates and content

Re-use of format	Re-use of content
Document templates	A bank of business level and non-functional requirements Legislative or regulatory requirements such as data protection compliance requirements are a good example of template business level requirements; usability requirements are a good example of template non-functional requirements
Skeleton processes	Common functional use cases or user stories (such as ‘system log-in’ or ‘re-set password’)
Generic screen prototype	Standard screen formats based on organisational style guide and preferred user interface (UI) elements
Analysis elements	Lists of typical stakeholders/actors, logical data entities, attribute definitions, domain definitions, terminology

The importance of standards is more likely to be recognised within a BA Service. The use of standards and templates offer organisations significant benefits including:

• Reduced elapsed time/effort: activities and templates for approaching the business analysis work and for developing deliverables are known at the outset.

• Improved quality: quality controls and best practice can be applied proactively from the outset.

• Consistency of content and presentation: customers and stakeholders know which tasks and behaviours to expect and how to use the deliverables provided.

• Strengthened organisational identity: the use of elements such as logos, branding, colour and tone of written ‘voice’ reflect a consistent organisational approach.

• Improved compliance: there is likely to be a common understanding of the requirements of legislative or regulatory compliance.

• Improved risk management: consistency of approach prevents information and processes from being missed or only included to a limited extent.

• Increased learning: the use of standards within an adaptive continual improvement culture with an outcome focus enables the development of a learning organisation.

These benefits, and the path towards their realisation, collectively support the establishment of a highly professional BA Service, whose members apply best practice approaches in an informed manner. The removal of the ‘follow the book’ approach to business analysis will require business analysts to learn, apply and adapt the standards, thus ensuring continual improvement.

The introduction of standards does not necessarily result in the realisation of the benefits listed above. There are several elements that will impact how much benefit can be gained from re-use:

• The culture of the organisation and within the BA Service. Are the business analysts willing to share information and enable re-use of their work?

• The prevailing governance approach. Are there mechanisms and the capacity to audit and mandate re-use?

• The body of work available. Are there sufficient templates and completed deliverables available?

• The delivery mechanisms. Are the tools in place that make information readily available and facilitate re-use?

All four elements need to be considered, and the required actions taken, if the benefits from re-use are to be achieved. It is often the case that a significant investment of time and money is made to consider, design and implement the support tools and technology. However, it is also often the case that insufficient effort is invested to establish the culture necessary to support and encourage re-use. Accordingly, the debate about re-use is often centred on selecting and procuring a relevant support tool with insufficient emphasis given to the management of the benefits and the environment required to realise them.

SELECTING THE STANDARDS

There are numerous standards available and they cover a wide range of categories. For example:

• Methods and life cycles: there are many methods and life cycles available to business analysts. Examples are Scrum or DSDM (Agile methods) and Waterfall/Linear, Incremental or Iterative (life cycles).

• Modelling standards: these offer rules and notation sets for the development of models to represent specific views of the system under consideration. For example, data or process models.

• Narrative standards: these are documentation templates and may be for externally used reports produced by business analysts, such as a business requirements document or business case, or for internally used documents such as project initiation documents or meeting agendas. Often, templates developed by individual business analysts may be adapted for use across the BA Service. This is discussed below.

Standards may be applied on a project-by-project basis or across the organisation. For example, some projects may benefit from the use of an Agile method, while others may require a more linear approach resulting in the development of a detailed requirements definition.

There are a number of factors that will influence and constrain the standards and templates adopted by the BA Service. These factors are, to a greater or lesser extent, outside the control of the BA leaders who have to appreciate that any standards selected need to be adapted to take the different factors into account. The constraining factors are the methods used, the procurement processes, the outsourcing requirements, and the opportunities afforded and limitations imposed by the use of support tools.

Development methods and life cycles

Different methods may influence the types of business analysis deliverables required by the project team. A good example concerns the use of a requirements catalogue versus a solution or product backlog. Many organisations have different project life cycles and development methods in use simultaneously. This may be for a variety of reasons such as the existence of legacy systems, the nature of supplier contracts, the suitability of one method over another for a given situation, and the skills and knowledge of the business analysts and the stakeholders. Therefore, it is likely that the BA Service will need to adopt and maintain standards and templates that align to several different development methods and that the project team will need to select the standards that are appropriate to meet the needs of the project.

Procurement

Where there is limited competitive advantage to be gained, many organisations choose to buy rather than build information systems. Organisational and legal constraints surrounding procurement processes may place specific demands on the business analysis deliverables and may restrict engagement with potential suppliers. It is worth investigating how business analysis activities and deliverables need to comply with or conform to the procurement process when defining the standards and templates.

Outsourcing

Whether software is developed in-house or is outsourced to an external supplier may influence the use of analysis standards and templates. There may be agreements between the customer and supplier organisations on specific standards to be used. For example, the supplier may have specified that certain templates must be used, or new templates and approaches may have been created jointly.

It is a useful investment of time to talk about the format and content of expected deliverables with suppliers, and to determine who will use them and how. However, it can be very easy to sink a great deal of time ‘up front’ in negotiating the details of standards and templates to the detriment of delivering usable outputs.

Support tools

Automated tools may be used to support just requirements engineering activities or even the full software development life cycle (SDLC). The tool configuration may include ‘templates’ that determine the standards to be used. Sometimes, the templates may be configured to reflect the approach agreed upon by the project team and the stakeholders. This may determine the information that must be recorded and the format in which it is presented, so may impose customisation of the templates. For example, if a template had existed as a spreadsheet, business analysts may have been free to customise headings and add columns to meet specific needs. When using a tool, there may be constraints on how the templates are tailored, so it may not be possible to meet the required information needs.

MODELLING STANDARDS

The purpose of most business analysis outputs is to aid communication and enable the audience to come to a shared understanding. With this in mind, it seems appropriate to adopt standards and notation that will be familiar to the highest number of people and to remove ambiguity as far as possible, which will simplify rather than add complexity.

Business analysts may need to produce models at different levels of abstraction including:

• conceptual: may be either high level or a partial representation of a situation;

• logical: a representation that is independent of any specific implementation environment;

• physical: a representation that is specific to a particular implementation environment;

• reality: a representation of the physical world.

BA Service standards need to take into account the variety of situations that will require analysis – and the needs of different stakeholders – and agree standards relevant for different scenarios and audiences.

An obvious contender for standardisation within a BA Service, and one that causes much debate, is the area of modelling and notation. The decision between using UML or BPMN is only a relevant question for the area of modelling processes, and there may be a reasonable argument to use both in certain circumstances. For example, business process modelling (at a specified level of detail) may need to conform to BPMN, but where a use case description is articulated as a process, a UML activity diagram may be used. These approaches are described in further detail below.

Unified Modelling Language (UML)

UML is maintained by the Object Management Group® (OMG®), an international, not-for-profit technology standards consortium, founded in 1989. OMG® standards are driven by vendors, end users, academic institutions and government agencies, and membership is open to all. UML aims to support consistency in systems modelling as defined in the UML standard:

UML² provides a suite of modelling techniques that may be used during the business modelling, analysis, design and specification of business and IT systems. It provides a robust and precise set of standards that define for each technique the modelling notation, terminology, rules and syntax. Key modelling techniques provided by UML are described in Table 6.2.

Table 6.2 Key UML models

Model name	Purpose
Activity diagram	Sometimes known as the UML flowchart. It provides a diagrammatic representation of business processes, use cases, tasks, system processes and test scenarios. It supports elicitation and analysis of scenarios and business rules This is a straightforward notation set, so it is accessible to business staff. It is an excellent technique for use when eliciting and recording both tacit and explicit information during interviews, meetings and workshops
Use case diagram	This provides a diagrammatic overview of a system, whether a business system or IT system. It shows the scope of a system, the functionality within the system boundary and the actors who interact with the system It has a straightforward notation set, so is accessible to business staff. This is a useful technique to facilitate discussion, particularly during meetings and workshops. Provides a basis for the functional design of the software
Class diagram	This provides a diagrammatic representation of the data recorded within an IT system. It shows the classes of data and their attributes, the operations enacted within each class and the nature of the relationships between the classes It has a straightforward notation set but some concepts are complex, so requires the analyst to support business staff in understanding the diagram. It can be useful to elicit information during meetings about data and the business rules applied to the data. It provides a basis for database design
State machine diagram	This provides a representation of a particular class and the events to which objects within that class may be subjected. It shows the sequence of the possible events. It supports the definition of test scenarios It has a simple notation set that is very similar to the activity diagram notation. It models concepts that can appear complex without sufficient explanation, so requires care when using with business staff
Sequence diagram	Provides a representation of a use case realisation, including the classes that collaborate to enact the use case, the operations performed as part of this realisation and the communications between the classes It has a higher level of complexity than the other key models, so is less accessible to business staff. However, the concepts included may be described to business staff in order to validate the processing components required to realise a use case

Business Process Model and Notation (BPMN)

The OMG^® has also developed a standard for business process modelling known as Business Process Model and Notation (BPMN³). This international standard represents the combination of best practices within the business modelling community to provide a standard approach to business process models and notation. It provides a consistent approach to communicating process information between all those interested in business process implementation, improvement and automation.

The BPMN notation set is significantly more complex than the UML activity diagram technique, which is also used for modelling processing. However, the extent of the BPMN provides a basis for modelling processing where the rules to be applied are represented in a rigorous and specific way. This can provide a basis for automatic generation of software to deploy the process; for example, within workflow software.

Decision Model and Notation (DMN™)

This standard, published by the OMG^®, has been developed to support the specification of business decisions and business rules, separately from the processes that use the decisions. Attempting to model business decisions as part of a process can lead to large and complex process models that are difficult for stakeholders to engage with and for business analysts to maintain. For complicated business logic, it may be preferable to model the decision independently of the process, showing only the decision outcomes on the corresponding process diagram.

Other modelling standards

Other options exist that provide notation sets for use during business analysis. There are a range of ‘structured’ approaches – which essentially means that they are not part of the object-oriented set. These approaches may be found in methods such as Structured Systems Analysis and Design Methodology (SSADM) and Information Engineering. Typical modelling techniques within such approaches are shown in Table 6.3.

Table 6.3 Alternative models available to business analysts

Model name	Purpose
Entity relationship diagram (ERD)	Provides a diagrammatic representation of the data recorded within an IT system. Shows the data groups (entities) and the nature of the relationships between them. The notation set is relatively straightforward to understand at an overview level but some concepts, such as optionality and recursion, are often found to be more difficult. This technique can be used to elicit information about data and the business rules applied to the data during meetings with business staff, but the business analysts will need to support them in understanding the diagram. A completed ERD provides a basis for database design
Data flow diagram (DFD)	Provides a diagrammatic representation of the processing conducted within a current or required information system. A DFD also shows the external entities (the actors or roles) that interact with the system and the data that is received, stored and output by the system. A hierarchy of DFDs tends to be built at increasing levels of granularity. The notation set looks off-putting to business staff so requires explanation. It is a useful technique to facilitate discussion, particularly during meetings and workshops. It provides a basis for the process design of the software
State chart/state transition diagram	These are alternative names given to the state machine diagram from UML. They use a very similar notation set and purpose
Create, Read, Update, Delete (CRUD) chart	A matrix that provides a means for modelling the effect of an event on the entities from the data model. The resultant matrix may be read in two ways: each row shows the impact of an event occurring, i.e. all of the entities and the effects on each of them; each column shows each entity and the effects on it that result from certain events occurring. This technique may also be used to map use cases against classes or events against classes. It is extremely useful for more granular analysis and often exposes gaps in the analysis work. It is not part of UML but is often used in conjunction with UML models, as it supports the creation of the state machines and sequence diagrams

When a standard notation has been adopted, it is often necessary to adapt its notation set and application. This may be due to the particular constraints or factors present within the organisation or project environment.

Many business analysts feel comfortable with modelling processes but are less confident in the analysis and modelling of data. However, analysing and modelling data are as integral as process modelling to the success of business improvement initiatives. The drive towards a more digital mindset necessitates an understanding of data amongst the business analyst community.

Business analysts may also need awareness of notation and standards used by other related professionals, not necessarily to create but to review and consume these artefacts. Relevant standards will differ across organisations, but examples could include Gantt charts, created to visualise planning and scheduling, capability maps to represent the business capabilities, TOGAF® and ArchiMate® standards developed by The Open Group⁶ to underpin architecture definition, and XML for storing and sharing data.

BA leaders need to consider the techniques and types of models that may be helpful when working on business change and IT projects within their organisation. The appropriate set of models for an individual organisation will depend on a number of factors, including:

• the BA Service offering;

• the nature of projects and problems requiring analysis attention;

• the experience, skills and preferences of customers and stakeholders.

BA leaders should also ensure that business analysts have the skills and confidence to apply the selected techniques effectively. This is likely to require development activities to be introduced, as described in Chapter 4.

CREATION AND MAINTENANCE OF TEMPLATES

Most business analysts have a collection of templates that they may use for a range of deliverables. However, these may or may not adhere to the business analysis standards in place within the organisation. This can cause many versions of similar products to be in use simultaneously within an organisation and contrasts with the need for consistency and efficiency.

Template gap analysis

It is helpful to apply the gap analysis technique when creating a set of standard templates that will support the BA Service Framework. This is reflected in Figure 6.2.

The gap analysis approach is applied to template creation as follows:

1. Look at what exists. Hold a ‘template amnesty’ to uncover all business analysis deliverables and guidance documentation in use. For a single product this may generate examples in different formats (e.g. spreadsheet, document, presentation, specific tool).

Figure 6.2 Template creation using gap analysis

2. Decide what is needed. The BASF in Chapter 2 sets out the portfolio of services to be offered by the BA Service, the activities to be conducted and the techniques that may be used; this provides a basis for identifying where templates may be of use. Business analysts are usually able to quickly describe what ‘good’ looks like for a given situation. Techniques such as mind mapping or a product breakdown structure could be used to structure the conversation. It may be appropriate to include customers and other stakeholders in these conversations to prevent the BA Service from being too inward looking.

3. Prioritise. Consider what is most likely to be needed in the near future and what offers most value to the BA Service and its customers.

4. Agree approach. To generate a consistent set of products, some ground rules must be established, such as file formats, use of branding, naming conventions.

5. Assign. The largest possible number of business analysts should be engaged in the creation of the standards and templates, as this helps to promote the sense of ownership and community responsibility. Where possible, template creation should be developed when creating a specific deliverable for a project or piece of work, rather than a theoretical prediction of what might be needed in future.

It is helpful to create a repository of templates, guidance materials and worked examples that business analysts may access as and when required. The ongoing maintenance of the standards and templates must be undertaken by the business analysis community. If a business analyst needs to augment or amend a template for a particular purpose, there may be a gap that could be reflected in a new version of a template or a new template.

The analysis deliverables that are most likely to be of use within the BA Service should be prioritised when creating standards, templates, guidance and worked examples. Building these standards as a group enables the BA leaders to share ownership, the agreement of priorities and the commitment to the agreed priorities. The action priority matrix shown in Figure 6.3 reflects a means of prioritising this work.

When establishing a BA Service, this model helps to identify where to prioritise the initial efforts (the ‘quick wins’) and where longer-term, more complex activities may be needed (the ‘major projects’).

• Quick wins: can be accomplished rapidly and will be used regularly. These are often not as quick or simple to achieve as it first appears, so it is important to be realistic and not put too many items into this category. Business analysts often find it possible to fit these in around project commitments.

Figure 6.3 Action priority matrix

• Major projects: may require dedicated BA resource, or the coordinated effort of several business analysts over a long period. The benefits of the major projects to the BA Service and customers should be well understood, and these projects should appear on the BA Service Road Map or Service Improvement Plan (see Chapter 12).

• Fill-ins: may be considered as ‘nice-to-have’ and present a good opportunity for less experienced business analysts to contribute to the ongoing improvement of the BA Service.

• Hard slogs: the BA Service should be vigilant about undertaking any ‘hard slogs’. These may present as ‘pet projects’ by a business analyst or to address the wants (rather than needs) of an individual customer or project. A ‘major project’ can turn into a ‘hard slog’ if it takes significantly longer than imagined, or the potential impact of delivering is reduced for some reason.

This model also shows that the full set of standards desired for use by the business analysts may take a considerable amount of time and effort to produce and that prioritisation can help to make this work achievable.

Linking standards and templates to services

Different standards and templates apply to the different services provided. It is useful to describe the typical deliverables produced for each service, as this enables customers to understand what will be produced and why. Table 6.4 shows the relationship between the business analysis services, the standards that support them and the templates that may be used. This links to the discussion in Chapter 2 of the techniques which are applicable to each service.

Table 6.4 Business analysis service portfolio with relevant standards and templates

ADOPTION OF STANDARDS

The creation and initial adoption of a set of appropriate standards and templates is the first step on an ongoing journey of making additions and improvements and ensuring compliance. BA leaders must ensure that all business analysts:

• are aware of the standards;

• know how to use and apply them;

• understand when standards can be tailored and adapted.

The BA Service will require a governance mechanism to review and improve the set of standards. A number of BA Service processes will need to be aligned to the standards and templates including new business analyst induction (see Chapter 3), peer review (see Chapter 12) and BA planning (see Chapter 9).

Communication of standards

With a wide range of applicable standards to choose from, it is necessary for each organisation to determine and then communicate exactly which business analysis standards will be applied.

Documentation and communication of the selected standards does not have to be onerous; it could be as simple as a list on a poster or whiteboard, a presentation, a set of documents or web pages. Considerations for the communication of standards include:

• Are they available to those who need to access them?

• Are they understandable to those that need to apply them?

• Are they maintainable as the standards evolve over time?

The aim of communicating the agreed standards is to have mutual understanding, both within the BA Service and by its customers, about the analysis approach that will be taken and what the outputs will be measured against.

The BA Service also has a responsibility to support others in the organisation who are outside the service and who may need to utilise or apply business analysis techniques. For example, process modelling, or SWOT analysis are often in widespread use within an organisation, so the BA Service has three options:

1. attempt to discourage or limit the application of business analysis techniques by those outside the BA Service;

2. try to deploy business analysts to meet all possible demand and thereby maintain full control of the use of the business analysis techniques;

3. enable and support others to use the tools and techniques accurately, successfully and consistently.

Option 3 is the one realistic and sustainable approach, though business analysts and BA leaders may only come to this conclusion after attempting the first two. There are often situations where business analysis approaches and techniques will be very useful to the business, but this does not necessarily mean that a business analyst must be involved. For example, stakeholder analysis and management techniques used by business analysts may be equally useful to other internal services such as finance, marketing and HR for them to better understand their stakeholders.

Applying the standards

Converting to or complying with standards should not be done by the business analyst in isolation once the analysis process has been completed. Successful business analysis involves co-creating analysis deliverables that have a clear purpose and audience and ensuring that all customers understand how to utilise them.

For example, one approach to data analysis may involve the business analyst holding interviews, analysing forms, systems and spreadsheets, and building a fully formed data model that is then shared with stakeholders. However, this approach is likely to generate confusion and a reluctance amongst the stakeholders to engage with or validate the model.

A more successful approach is to generate models collaboratively, developing them alongside stakeholders and using simple notation that conforms to standards and business language that is accessible by stakeholders. The resultant models can then be cross-checked against other sources of information and, potentially, discussed with the wider stakeholder community.

Business analysts need to appreciate the rationale for applying standards and the benefits that the use of standards can deliver so that they can communicate this to colleagues and customers. This will enable the widest application of standards and will support improvements in business analysis practice.

Adapting the standards

Some business analysts (and those performing other IS professional roles on projects) are reluctant to adopt standards, as they are seen to constrain and restrict their work. Therefore, it is important to adopt an approach that is tailorable, scalable and embraces continual improvement in the development and maintenance of standards and templates.

Business analysis projects are varied, as illustrated in the BA Service Framework in Chapter 2. Business analysts may be required to work to establish a change project, to support the development of the change solution or to enable the successful acceptance and deployment of business changes. Part of the skill of the business analyst concerns the ability to apply relevant approaches as appropriate, and to adapt them as necessary to the needs of the particular situation. Tailorable standards offer a basis for this adaptation and ensure that the business analyst does not expend valuable time working on irrelevant and unhelpful deliverables.

Less experienced business analysts may need support and guidance when working with standards, as there can be a tendency to ‘follow the method’ or ‘fill in the form’. A ‘one-size-fits-all’ approach to analysis that fails to recognise that projects have particular differences and concerns is rarely successful, so standards should be applied in an informed manner and with an outcome focus. Business analysts have to ensure that the work they do, and the standards they apply, contribute to achieving the desired outcomes. Where this is not the case, they need to question the relevance of all or part of a particular standard and adapt it accordingly.

Ensuring that business analysts and stakeholders are aware that standards and templates can be tailored, and communicating the benefits of adaptation, can help to overcome initial resistance to standards. Claims such as ‘this project is different’, ‘that won't work here’ and ‘we don’t need these deliverables’ can be overcome through the use of an adaptive approach. Both standards and templates should be ‘shrink-to-fit', and the relevance of any activities, diagrams, information items or documents that do not support the achievement of the required outcome should be questioned. This may result in the reduction, replacement or removal of all or part of the standards, which should ensure that they are applied effectively within a particular context. Templates can be designed to explore of a wide range of areas to guide the analysis and prompt discussion. Anything that is not relevant or not needed for the given situation can be removed or revisited later.

The adoption of a tailorable approach to the use of standards contributes to the continual development and improvement of the BA Service and individual business analysts. It encourages everyone to apply standards in an informed way and to think about how they might be improved so that they better support the business analysis work. This approach also helps to develop professionalism amongst business analysts. Rather than accepting a standard as a ‘rule’, business analysts are encouraged to consider whether the standard will benefit the project and whether there is a better alternative. This extends their understanding of the standards and improves their analytical thinking skills.

Examples of effective adaption of standards are as follows:

• Selecting relevant techniques to analyse and represent conceptual aspects of business situations. Possibilities include capability maps, value streams and business use case diagrams. Business analysts are required to understand the different techniques and have the ability to evaluate and apply them.

• Identifying where a central repository of information that supplements other requirements artefacts would improve communication and understanding. Possibilities include creating a scoping model, such as a use case diagram; developing a glossary of terms that incorporates definitions, synonyms and antonyms; building a central repository of business rules.

A standards-based approach, combined with the ability to adapt where relevant, balances the need for flexibility on projects with the drive for re-use and the benefits this offers. This balancing act is reflected in Figure 6.4.

Providing examples

To aid the adoption of templates and the compliance with standards amongst business analysts, it is incredibly helpful to provide completed examples. Examples provide business analysts with good insight into the appropriate level of detail. Initially, it may be necessary to apply new standards retrospectively to some existing business analysis deliverables, but over time all business analysts should be encouraged to share examples to show how the standards can be adapted to meet different business needs and analysis goals.

The emphasis is on these being ‘previous examples’ rather than ‘best practice’, as this reduces the pressure on the creator, lessens the tendency of business analysts towards perfectionism and re-enforces the message that business analysis deliverables may be tailored to meet the situation. Ensuring that examples are shared within the BA Service fosters both efficiency of approach and potential for collaboration.

Figure 6.4 Balancing the need for standardisation

Governance

Governance of standards is needed to ensure that there is a mechanism for the standards to evolve in a controlled way. The level of formality of the governance approach will be influenced by a number of factors, including the size and maturity of the BA Service and the prevailing organisational and sector culture.

There are three main governance models for standards (shown in Figure 6.5) and, depending on the needs and approach of the BA Service, there may be multiple governance levels. For example:

• A large BA Service may encourage a community approach where anyone is able to suggest updates to standards and templates. These may be considered periodically and consolidated by a steering committee or change board, and, if sufficient information and justification is provided, these changes may be put forward to be ratified and accepted by the whole community.

• In a small or highly integrated BA Service, individuals may be empowered to make sensible changes that will be immediately accepted by all.

A committee approach can work well if obtaining input from those who use business analysis deliverables is practised. For example, testers, developers and business representatives can suggest improvements and also advise on the potential impact of changes.

A SIPOC analysis (shown in Figure 6.6) may be used to determine an appropriate level of governance and associated processes. If the customers of the standards are many and varied, this may point to a committee-led approach. If suppliers and customers are largely overlapping and confined to a small number of people, a community approach will be suitable.

Figure 6.5 Governance models for business analysis standards

Figure 6.6 SIPOC analysis for business analysis standards and templates

The process used to provide governance of standards requires a careful balancing act for the following reasons:

• Not everyone has the same level of interest in standards.

• People can become frustrated if over- or under-consulted.

• Very detailed debate about topics that affect only a small number of people can alienate members of the community.

• If the process is too laborious or slow, it can stifle innovation and improvement.

• Without governance, the standards and templates may not be fit for purpose for the BA Service.

Reasons standards and templates fail

Despite the benefits that may be achieved from adopting standards, the creation, review maintenance and version control required to ensure that standards are relevant and in use can be seen as an overhead. Even when standards are in use, there are several issues that can arise. Table 6.5 shows a number of typical issues that arise from the use of standards and possible ways to address them when they occur.

Table 6.5 Issues with standards and templates

The specific reasons business analysts suggest for the lack of adoption of standards and templates provides a basis for identifying the root causes of problems and defining the specific actions required to address them. When creating, selecting and adopting standards and templates, it is important to keep in mind the main objective, which is to produce clear, concise and complete analysis deliverables that aid communication and meet the needs and expectations of stakeholders. This goal may have to overrule the need for compliance with the most recent version of a template or slight divergence from standards.

CONCLUSION

The use of standards and templates within the BA Service can be highly beneficial, providing a starting point for the work to deliver each service in the BASF, avoiding the need to ‘reinvent the wheel’ on every project, and removing the temptation for every business analyst to develop and apply their own personal ‘standards’.

Numerous industry standards and templates exist, and these can provide BA leaders with a basis for improving the consistency of the business analysis work. The selection process needs to take into account the availability of standards plus factors such as organisational policies, processes, culture and values.

While a single person can be the driving force behind standardisation, if that individual leaves or moves on, a gap is created. Even if the particular individual remains with the organisation, it can be a lonely place if you are trying to establish standards in the face of apathy or disagreement. Therefore, an individual bearing all of the responsibility can become disillusioned and this can result in the usage of standards coming to a halt and the objectives of consistency and efficiency failing to be met.

A ‘champion’ for the standards approach can be highly beneficial for the organisation and the BA Service, but this is not sufficient to ensure that they are adopted successfully in a sustained way. Instead, the BA leaders need to offer clear support for the initiative and should allocate different areas of responsibility across the members of the BA Service; ownership and responsibility for creation, review and maintenance should be shared by all.

Where the benefits are genuinely understood and appreciated by the whole community, there is a far greater chance that the standards and templates will be adopted. Where there are consequences if standards are not applied, this will also increase the chance of adoption.

CASE STUDY 4: PROVIDING CONSISTENT BUSINESS ANALYSIS

Matt Eastwood, Care Quality Commission (CQC)

Like many organisations, the Care Quality Commission has recognised the need for a consistent and repeatable approach for delivering projects for many years. There was a PMO (Project Management Office) in place, with a remit to establish and maintain standards, create templates, embed project management good practice, and offer advice and mentoring. CQC identified the value that coordinated business analysis could have and created a new Lead BA role who would define and lead the BA team. As a Lead BA, Matt was contributing to projects at the same time as developing the BA Service.

‘One of the first things we did was create a BA Service Catalogue; this defined the services we offered to our internal customers. The main aim was to help other people in our organisation understand what we do and how we do it.’ By using language that customers could understand, the BAs were able to engage and guide stakeholders to consider how business analysis could be used to best effect on their project.

Matt wanted to introduce standardisation in two main areas, (1) competency of BAs and (2) business analysis outputs. To address the first area, he researched professional standards for business analysis and was inspired to create a four-level capability framework specific to CQC. The model made it really clear to BAs what was expected of them, and they were supported to address any gaps.

To ensure consistency of the outputs produced by BAs they created a set of standards, templates, definitions and completed examples. They believed it was really important to have examples of ‘what good looks like’ to help BAs achieve the required levels of detail and quality. They already had a number of strong examples produced by the team, but these were updated to align to the new agreed standards. ‘I was trying to ensure a good level of quality across the whole team, so no matter who was allocated, standard outputs would be delivered.’

CQC has been using BPMN for many years, and had a lot of good examples, not just of stand-alone models, but models of different levels and how they interrelate. There is consistent application of the notation across different BAs, underpinned by the use of templates in MS Visio.

On the whole, both BAs and their customers were very happy with the move towards standardisation. One slight pocket of resistance was from individual contract BAs, who had been brought in for their expertise, were used to a high level of freedom and had their own ways of working. Matt was able to ensure that their concerns and experience from elsewhere were taken into account and reflected within the organisational standards.

Considering the benefits of standardisation, Matt said: ‘It improves and standardises quality and provides assurance to projects that the right things are being produced in the right ways. For BAs it helped remove ambiguity and they had access to good examples to work towards. In terms of personal objectives and performance management conversations, they can provide evidence of work that they have done that meets the quality standards.’

Following an internal re-structure, Matt has progressed to BA Practice Manager, and is leading a single BA practice that now provides BA support across the whole change framework to transformational programmes, business change projects, digital projects and improvement initiatives, so the benefits of standardisation have the potential to be even wider. Matt knows that the new remit of the team brings a new dimension to standards: ‘As the range of work is so varied, standardisation must not be overly prescriptive. I want to ensure that our new BA function has the flexibility to use the right tool for the job.’

1 UML Standard Version 2.5.1. Available from: www.omg.org/spec/UML/About-UML

2 See www.omg.org/spec/UML/About-UML

3 See www.omg.org/spec/BPMN/2.0

4 BPMN Standard Version 2.0.2. Available from: www.omg.org/spec/BPMN/2.0

5 DMN™ Standard Version 1.2. Available from: www.omg.org/spec/DMN/About-DMN

6 See www.opengroup.org/togaf