Options:

Christoph Wolf

The Business Analysis Center of Excellence

How to build a strong foundation for business analysis and requirements engineering inside a company


Usually, the disciplines of business analysis and requirements engineering start somewhat hidden inside companies: A customer service specialist supports the analysis and design of business processes; a product manager or project manager identifies requirements for a new product; a solutions designer or developer translates product requirements into system requirements. But when the product or software development lifecycle reaches a certain maturity, business analysis needs a more professional approach. This is common practice in other areas in the project-driven environment, like project management, PMO or testing. This article gives hands-on tips for transforming “unstructured” business analysis into a Business Analysis Center of Excellence (BA CoE).

Many companies with a strong IT focus have a test department, a PMO and a project management team. But when it comes to business analysis or requirements engineering, fewer companies have a structured and organized approach. This comes as a surprise – one central step towards creating business value is neglected: translating business ideas into implementable requirements. This article describes how a Center of Excellence for business analysis/requirements engineering can be developed, established and improved.

The content of this article is based on personal experience from building up and managing a team of business analysts and requirements engineers [REConf2010]. Inputs from people in charge of business analysis in various companies complete the picture. It highlights the basics of a BA CoE without considering special topics like, for example, agile or lean approaches.

Business Analysis vs. Requirements Engineering

But first some words on the definition of business analysis and requirements engineering. Some companies see the focus of business analysis in improving business processes based on business goals and the business strategy and in developing business features. The requirements engineer translates business features into system requirements, use cases and models. In other companies, business analysis includes both business process design and requirements engineering. For the findings in this article, the distinction between business analysis and requirements engineering is not so important. For easier reading, the second definition is used here and “business analysis” means business process analysis & design, developing business features, and requirements engineering on both business and system level.

Figure 1: Definition of Business Analysis

Building blocks for a Business Analysis Center of Excellence

A Center of Excellence (CoE) in general represents an approach that provides core services, guidance, good practices, support and training for the focus area. In our case, the BA CoE consists of the following components:

Figure 2: Components of a BA CoE

These components are detailed as follows:

Services

The service catalogue of the BA CoE depends on the positioning in the organization and the distribution of tasks among the different organizational units. Here are some examples for the service offering:

Core services:

Supplementary services

Vision, Goals & Metrics

A vision describes the desired future state of an organization - an ideal image that might not be fully achievable [BMM]. A vision is helpful when determining goals and for communication with other units of the company. While company visions should be concise and memorable, the vision of an organizational unit can be more detailed.  A vision could be: “We support every business unit in defining and implementing the right products and processes for delivering optimal business value and providing high customer satisfaction”.

The next step is to break down the vision into tangible goals. Goals should follow the SMART criteria, meaning they should be specific, measurable, attainable, relevant and time-bound. Some frameworks, for example the Business Motivation Model [BMM], distinguish between high-level “goals” and detailed, SMART “objectives”. Examples of some goals are “by the end of this year, every project should have a BA of our team assigned to support business analysis” or “from the next release on, 95% of the requirements should be successfully verified at the end of the specification phase”.

Many CIOs and other executives love KPIs (Key Performance Indicators). For some areas, KPIs and the underlying metrics make sense – but what about business analysis and requirements engineering? It is really difficult to define sensible metrics. Metrics like “Number of requirements” are often not relevant, because complexity of the product or Use Cases or the detail level of the requirements are difficult to take into account. Many important topics like “reducing the number of change requests during the course of a project” are difficult to measure. Often the historical data for defining the improvements are missing or the projects are simply too different to compare closed projects with new ones. Nevertheless, some KPIs can be defined. “Requirements stability” (number of changed requirements compared to the number of all requirements) is a useful KPI. Or for example, the second goal about successfully verified requirements from the last paragraph could be translated into a KPI “Requirements quality”.

Another possibility for a KPI and for measuring the performance of a business analyst and identifying potential areas for improvement is a customer satisfaction survey. The “customers” of the BA/RE service (e.g. product managers, process specialists, project managers) give feedback on the work of a business analyst using questions like “Were all important stakeholders identified?” or “How was the quality of the documented requirements?”. What is important is that the roles and responsibilities of all involved people are defined and understood by everyone (see Section Organization & Roles). One problem with a survey is that it reflects the subjective opinion of the interviewee. Since the role of the business analyst is also to challenge requests, this can lead to tension, impacting negatively on the result of the survey. But this usually levels out when many customers assess a business analyst.

Team

You can have the best processes and tools in place, but in the end it is all about the people – how they behave, cooperate and communicate. The skills of the team members should provide a good balance between knowledge of methods, business domain knowledge and soft skills. The latter is especially helpful when the BA is performing one of his most important duties: saying “no”. Stakeholders normally have thousands of wishes, many of which cannot be fulfilled because of the usual constraints like budget, resources or time-to-market. Thus the BA is in a constant struggle between accepting and challenging stakeholder requests. Challenging stakeholder requests might be very important to support the overall business success of a product, but can also create tensions - sometimes with a negative impact on a performance survey such as described in the previous section. This is where facilitation skills come into play. 

To develop a team and assign the team members to the right projects a skill matrix is very helpful. Skills and knowledge from the following areas should be taken into account:

The team members can then be rated, e.g. on a scale of 0 to 5, by the team manager. The rating should be transparent and discussed with the respective team member. The skill matrix is the basis for:

Organization & Roles

In many companies, the Business Analysts are either centralized, quite often in IT, or distributed over the business units. In the latter case, it is more difficult to build a CoE. Distributed structures usually tend to evolve in different directions because central leadership is missing. Normally, the best thing that can be done is to establish a Business Analysis Community of Practice – a loose alliance to support each other concerning processes, methods and good practices. But the best basis for a BA CoE is a central organization, which includes all business analysts and standardizes process, tools, and so on. A central organization also fosters cross-unit transfer of know-how and ideas.

Another important topic is the demarcation of the business analysis roles from other roles like product manager, project manager or solution architect/engineer. If the demarcation is not properly defined and communicated, it can lead to conflicts:

To avoid this, a RACI matrix indicating who is responsible, accountable, consulted and informed (sometimes extended with S=supportive) for every task or deliverable, should be established. The tasks included in the matrix should cover the tasks described in the process definition of business analysis (see Section Processes & Methods).

Processes & Methods

Business analysis usually does not follow a strict process. It is highly iterative and sometimes shortcuts make sense. Nevertheless it is good to have a framework describing the high level process steps, tasks, methodology and good practices. This gives guidance and facilitates communication, especially during the planning of business analysis activities. It is not necessary to start from scratch. For example the “Guide to the Business Analysis Body of Knowledge®” [BABOK] (short: “BABOK Guide”) from the International Institute of Business Analysis (IIBA) is very useful. The BABOK Guide describes comprehensively the business analysis process and the tasks including input, output and methods. The tasks can usually not be transferred one-to-one, they have to be tailored to the project and product development processes and the way the different project team members collaborate. Some tasks might even not be necessary. The result could be summarized in a “Business Analysis Handbook” with a short description of the processes, tasks and methods to be used including an overview diagram:

Figure 3: Business analysis processes and tasks

The standard literature for requirements engineering and business analysis offers a wide variety of methods and techniques for enterprise analysis and requirements elicitation, analysis and management. It is important that the business analysts know these methods and apply the best method for a given situation. This knowledge can be obtained with training or coaching (see Section Personal Development) and by trying different methods or techniques in projects. A sound basis is formed by the training from the CPRE syllabi. The foundation level and the advanced levels “Elicitation and Consolidation”, “Requirements Modeling” and “Requirements Management” impart good knowledge for the areas Requirements Elicitation, Requirements Analysis and Requirements Management.

But where to start? A good starting point is Stakeholder Analysis. There are many complaints that Requirements Elicitation performs below expectation because requirements are not discovered at the start of the project and pop up later as more expensive change requests. But the root cause of the problems is that not all stakeholders were identified and properly involved. Thus proper Stakeholder Analysis and Management should be highlighted in the process.

Another important starting point for Business Analysis is the goals of the project and the product. They should be described in the project charter, which is often not done thoroughly enough. When the goals are not documented, the BA should ask the most important stakeholders and then consolidate them. Later it is possible to link requirements to goals and any requirement that does not support a goal should be challenged.

Furthermore, defining the business analysis management processes is vital. Take for example resource management: According to which criteria are business analysts assigned to different projects? The skill matrix mentioned before is helpful. How is mid-term resource planning done? For this a close cooperation with portfolio management is necessary. And what is the long-term planning, e.g. should the team size increase? This could be derived from the company's strategy or a business plan.

Tools & Templates

Templates, supporting documents and tools should be available for various deliverables.
The first deliverable when starting business analysis for a new project could be a business analysis management plan (template). This document should contain an initial stakeholder list, task list, timeline and milestones, a list of issues and assumptions and deviations from the standard process (see “Processes and Methods”). Some of this content might be redundant with respect to other project management deliverables like the project plan or the project issue list. But sometimes, a proper project structure is not in place when starting with business analysis and having all this information in one document is quite helpful for business analysis.

The next step, as already mentioned in the last section, is stakeholder analysis. The starting point for finding the stakeholders could be the project charter, input from other project members, previous projects or a Generic List of Stakeholder Groups. Such a list, containing standard stakeholder groups, should be available to all BAs. It is especially helpful as a reminder of stakeholders like legal, infrastructure or security experts. The result of the stakeholder analysis should be documented in a stakeholder list (based on a template) and/or stakeholder map indicating the influence on, the importance for and the attitude towards the project or the product.

When starting requirements elicitation, a list of possible areas, in which requirements could be found, is quite helpful. For example, the area “Sales Channels” could have the sub-areas “Contact center inbound”, “Contact center outbound”, “Own shops”, “Retail shops”, “eShop”. With this list you can go to a product manager and ask, over which of these channels the product should be sold. In a later stage, you can dig into details about the sales process in each channel to get requirements for the corresponding sales applications.

Concerning documenting and managing requirements it is or course advisable to use a requirements management system. Nevertheless it is possible to start with Word or Excel. Especially when the number of requirements in a project is small and no budget or time is available for implementing a proper requirements management system, Excel is a valid alternative. The drawback of Excel is that features such as traceability, versioning and baselining are not possible or only achievable with significant extra effort.

Introducing a requirements management tool should be treated as a project. Thus the standard process, including stakeholder analysis, requirements engineering, implementation/integration, testing, training, documentation and rollout should be followed. Do not underestimate the complexity in thinking this is only an internal tool.

Development & Career

Personal training and career planning is comparable to other disciplines. One part of personal development can be achieved by professional training. The training courses from the CPRE syllabi [CPRE] form, as mentioned above, a sound basis for business analysts. This can be extended for example by business process design & management as covered in OCEB training courses. In addition, personal training with a focus on communication and leadership are helpful. The identification of potential areas for improvement could be based, in addition to a regular development talk, on a customer survey (see Section Vision, Goals & KPIs).

A clear career path is essential to keep the motivation for developing and improving professional and personal skills. For each career level (for example junior, intermediate, senior, principal), a clear definition of entry criteria (experience, training, certifications) and tasks should be defined. A special task for a senior or principal business analyst could be, for example, coaching the junior business analysts.

External Presentation

Visibility is paramount. The goal is that management perceives business analysis as an important part of the value chain. Otherwise, business analysis will deteriorate and in the worst case, disappear in the future. But what is the best means of communication to achieve adequate visibility?

Newsletters with success stories are an easy means of communication - they can be compiled quickly and sent out by email to have a large possible audience. The drawback is that most people do not read them, especially management. Thus it is OK to send regular newsletters but do not expect too much.

A “roadshow” is a good way of explaining the business analysis work to other departments like product development and management, marketing, process management, software development or testing. The presentation can include the vision of the business analysis team, the team members, the high-level processes, expected deliverables, the way of collaboration and, last but not least, the added value of business analysis. This is also a good way of managing expectations by showing what the other teams can expect from business analysis and vice versa.

Presentation on internal events like IT staff meetings or management meetings might also be a good idea. This way decision-makers can be directly addressed. But the positive effect is only temporary so this has to be repeated regularly.

Another way for presenting business analysis are Web pages or Wiki pages on the intranet. Put all information there, which could be helpful for others, and point people to these pages. But do not forget to keep the information up-to-date, because outdated information is quite upsetting.

Improvement

Continuous improvement should be applied in all areas of work. One possibility is a semi-annual SWOT analysis with the team. The basis for this analysis could be the customer satisfaction surveys (see Section Vision, Goals & KPIs), other personal feedback from the (internal) customers, feedback from management and experience of the business analysts. After having the strengths, weaknesses, opportunities and threats listed, the main areas for improvements concerning processes, methods, tools, templates, development and communications are identified and the appropriate measures defined. Each measure should be assigned to a team member with a defined end date and progress should be reviewed regularly.

Another great opportunity for getting ideas for improvement is discussing with other people in similar positions, for example on conferences. Or conducting an assessment with help of an external company specialized in business analysis and requirements engineering.

How to start a BA CoE

The previous nine sections described the building blocks of a BA CoE. But where should the transformation of “unstructured” business analysis into a Business Analysis Center of Excellence (BA CoE) start?

The starting point is the service catalogue as described in the Section “Services”. Everything depends on the services to be offered. Secondly, the initial team should be built with members who can deliver the offered services. The team should also be included in the definition of the vision and the goals, because these form the foundation for future collaboration inside the team. A first assessment of the team members resulting in a skill matrix is helpful at this point in time to optimize the assignment to projects and to later plan the personal development. In addition, the roles and responsibilities and especially the demarcation from other roles in the organization should be defined during this early phase.

As the next step, the processes and methods should be developed. The initial focus should be quick wins like templates and checklists to support the day-to-day work of the BA, since the overall development of the processes and methods will take a considerable amount of time. In parallel, external presentation should be started to create visibility in the organization and create demand for the offered services. The roles and responsibilities of every stakeholder should be made transparent. Development plans for all team members including training based on the skill matrix, on the offered services and on the demand of the organization should be created. As mentioned above, using Word and Excel is a valid choice at the beginning. But in the long run, a requirements management tool should be considered. Introducing a Requirements Management tool is a big project and should be treated as such – including the full scope of requirements engineering and only once the underlying processes are established.

In subsequent steps, the clear career path should be developed and metrics and KPIs should be introduced based on the defined processes and the goals. And last but not least, a continuous improvement process as described in the previous section should be introduced and applied to increase the maturity of the BA CoA.

Outlook

The role of a business analyst and the demands are changing. The tasks in a classical project environment are different compared to agile projects.  But since requirements engineering is already quite an iterative process, it can be adapted to an agile environment.  When testing or development is outsourced, communication is more difficult. But the basis of the business analysis processes stays the same.

Thus the processes and methods need to be adapted to the working environment. However most of the points described here can be applied in other environments, such as agile or lean organizations, outsourced development or outsourced testing. They build a sound foundation for providing best business value by supporting the creation of successful products and efficient processes.

References and Literature

Supplementary Literature


Christoph Wolf

Christoph Wolf works for more than 15 years as Requirements Engineer, Business Analyst, Project Manager and Quality Assurance Manager. He has built up a Business Analysis team and led it for several years. Since last year, he is consultant at SwissQ and supports clients in requirements engineering and quality assurance with focus on delivering business value.