Skip to main content

Author: Phil Vincent

Why are Use Cases So Hard?

Maybe it’s because they are so easy to write. Given a template and a few minutes of guidance, anyone can write a use case description. The problem is that everyone writes them differently, and from different perspectives. One person may describe what they want a solution to do, while another tries to describe the design of a set of screens, and another tries to explain how an existing system works. If they all try to collaborate on the same use case, chaos is likely, personalities will take over, and the result will only satisfy the requirements of some of the stakeholders. Usually the technical solution providers persevere and we lose sight of what the business users wanted. We end up with use cases like “Create”, “View”, “Modify” and “Browse” which represent the developers’ point of view, rather than the business point of view.

For some people the use case description is the only requirements artifact they use. They embed data descriptions, business rules, and even screen navigation, resulting in overly complex, confusing, impossible to keep-up-to-date documents.

Look around at all the online discussions about use cases, read the books, take courses, read the UML specification, ….they’re all different! And they’re all more or less right. It’s like a mob contest, where great ideas are embraced temporarily and then tossed aside in favour of the most stubborn, or the loudest, or the biggest. Or for the most cunning, wealthiest or the most popular proponents.

I think we can fix this.

All we need to do is agree on different kinds of use cases to suit the needs of different kinds of stakeholders at different times in a solution’s lifecycle. Now, before you dismiss this as just another feeble attempt by one guy to impose his view of the world, I realize that this has been tried before, quite a few times. Without success.

But what do you think of this idea? Both the BABOK® Guide and the PMBOK® Guide agree on requirements classifications: business, stakeholder, solution, and transition requirements. Could we in the business analysis profession agree on a corresponding set of use case classifications? (Yes, business and system use cases were introduced back in the 1990’s, but nobody agrees on how to write them, either).

“Use Cases are a means to capture the requirements of systems, i.e., what systems are supposed to do.”

As a business analyst, you know that use cases can be a very effective tool for eliciting and describing what stakeholders would like a system to do. And you also know that developers can write use cases to describe what a system will do for its users. So why not use both perspectives in two separate sets of use cases, linked through requirements traceability?

Stakeholder use cases could describe what the stakeholders need to be able to do with a system, written in the vocabulary of the stakeholders, from the point of view of the stakeholders, without using words like “enter”, “dropdown”, “select”, “page”, “screen”, “submit”, “click”, or any other words that impose a design on the system. Scenarios inside the use cases would be written using business nouns and verbs, avoiding abstract terms like “data”, “information”, and “process”, and instead telling us what that data is about, and using the verbs that the stakeholders use to precisely state their requirements.

In response to the approved set of stakeholder use cases, system use cases could describe a proposed design in the vocabulary of the proposed solution. Then business analysts could trace between what the stakeholders said they needed to what the solution proposes to deliver. In this way, different solution options could be proposed and assessed to see how well they meet the stakeholder needs.

A stakeholder use case model (made up of use case diagrams and the use case scenarios) would describe the scope of a proposed solution in business terms, and so could be used to assess feasibility, identify and evaluate alternate solutions, estimate business value and project costs and identify business risks.

A stakeholder use case model could be the starting point to develop system use cases, and could be used to solicit and evaluate solution proposals from vendors and in-house development teams.

A system use case model based on the stakeholder use case model would be faster and easier to develop because the scenarios and the steps of the stakeholder scenarios are already written.

User test cases to validate that the solution will allow the stakeholders to do their work would be based on the stakeholder use cases. Functional test cases would verify that the solution is built according to the design in the system use cases.

There is also a need for understanding how external customers and partners interact with an organization, but BPMN collaboration diagrams can capture that well. If you are not using BPMN, then perhaps you could use business use cases to show that interaction and to establish the business vocabulary while you are describing the business value that the organization delivers to its customers. You could trace between business use cases and stakeholder use cases to make sure that the stakeholder use cases are providing real business value, and not just some internal improvements.

People who support an existing system in production would benefit from use cases that describe the system “as-built”; these use cases would evolve over a useful life of many years.

Four different types of use cases are identified, created at different times and for different audiences, with traceability between them. Business use cases describe how the organization provides value to its customers; stakeholder use cases describe what stakeholders need to be able to do using a system to deliver that value; system use cases describe the design of the system, and as-built use cases describe the system as it really exists in production. Both the stakeholder and as-built use cases would be the basis for ongoing support and continuous improvement.

Don’t forget to leave your comments below.

A Review of the PMI’s New Business Analysis for Practitioners: A Practice Guide

The PMI recently published its new Business Analysis for Practitioners: A Practice Guide and is making it freely available (at least for a limited time) to anyone who wants to download a copy. If you are planning to write the PMI-PBASM certification exam you may find this useful because it interprets the PMBOK® Guide concepts of scope, requirements, acceptance criteria and stakeholders from a business analysis perspective.

The Practice Guide is aimed at project BA’s who may be involved at any point “ from identifying business needs to solution implementation.” It is intended to address project-related issues about requirements and business analysis. So for all of you who spend most of your time supporting an existing system, or working in continuous process improvement, or if you are involved with strategic business analysis, this publication is probably not for you. However, if you are involved as a BA working on projects, and especially IT system projects, then you will likely find this Practice Guide to be relevant.

With the upcoming BABOK® Guide v3 moving away from the project focus, it makes sense that the PMI would want to fill in the details about project-based requirements management because that is still such a significant problem for most projects.

A Practice Guide; Not a Standard

The stated purpose of the Guide is to “define what business analysis is, and to demonstrate the practical application of the discipline”. It is only a guide, not a standard or a body of knowledge like the BABOK® Guide or PMBOK® Guide. Think of it as a 200 page text book written by a group of folks who really know their stuff, but was not subjected to a thorough review, nor a consensus-based review and revision.

In some ways, this is simpler to read than the BABOK® Guide or the PMBOK® Guide because the various business analysis techniques are described within the context of when they could be applied. With a few exceptions, the Practice Guide just describes the techniques, but doesn’t tell you how to apply them.

Unlike the BABOK® Guide or the PMBOK® Guide, this Practice Guide should be read from front to back. The Practice Guide sees business analysis as inherently being a process, starting with the definition of the business need, and working through the requirements to solution evaluation. The story builds as you work your way through it. When a technique is only mentioned but not described in one of the chapters, it is assumed that you are familiar with it because it was described previously in the book. In some cases, it’s not obvious that the process is not sequential, and less-experienced business analysts may not recognize that the order in which techniques are introduced in the Practice Guide is not always necessarily the order in which they should be applied.

The PM-BA Relationship

One of the features of the Practice Guide is that it clearly spells out how the PMI expects business analysts and project managers and other project participants to work together. Sprinkled throughout the text are Collaboration Points which detail how the two roles should work together. It often assumes that a business analyst reports to a project manager, or is more concerned with lower level details than the project manager, or lacks the experience, expertise or insight of the project manager. It doesn’t really address the dilemma of the person in the role of both the business analyst and project manager.


The PMI Practice Guide does not discuss the similarities between needs and solutions, requirements and designs. That’s really too bad because users often come to a business analyst with what they think are requirements but which are really solutions. PMI assumes that we are only dealing with requirements. But some of the examples, such as the use case example, feature model and the report layout example, do not demonstrate requirements, but rather specify the design of a solution.


The PMI has always been concerned with documentation and it is no different here. One of the major problems introduced by a requirements document of any sort is that once the project is over, no one seems to keep the requirements documents up-to-date, and so the support teams quickly lose sight of why the solution is the way it is. PMI could have helped to shift the mindset away from text-based documentation of requirements, and moved toward model-based requirements. Instead, they chose to differentiate between models and requirements. This approach could continue to impede the ability of BA’s who support solutions to get access to the requirements that were incorporated into the solution.

Organization and Content

The PMI has defined business analysis in terms of 5 domains:

  • Needs Assessment
  • Business Analysis Planning
  • Requirements Elicitation and Analysis
  • Traceability and Monitoring
  • Solution Evaluation

The Practice Guide explains the major tasks of each domain and the approximate order in which those tasks should be performed, and describes the techniques that could be applied within that domain.

Needs Assessment

This first section provides an explanation of how to understand problems and opportunities, and provides a pretty down-to-earth explanation of how to conduct a situation analysis, SWOT analysis and root cause analysis. Some of the examples are pretty good, and the supporting diagrams are easily understandable . This is a useful step-by-step guide about conducting a needs assessment, with more focus on understanding the problem or opportunity than on recommending a solution.

Business Analysis Planning

The discussion on stakeholder identification and analysis is pretty thorough and serves as a good guide or checklist.

The Practice Guide uses the term “business analysis plan” to refer to all information that is documented regarding business analysis planning decisions, and explains that the business analysis plan works in conjunction with the requirements management plan. The business analysis plan is a part of the overall project work plan, and so must be developed in collaboration with the project manager.

A possible point of confusion for people studying for the PMI-PBASM certification is that the PMBOK only mentions the requirements management plan, not the business analysis plan. The Practice Guide relegates the requirements management plan to a more narrowly focused role which may not be consistent with exam questions. Even the Guide is not 100% clear, since the glossary definition of the requirements management plan doesn’t exactly match what is described on page 46.

The suggestions about what to consider when developing the business analysis plan are pretty extensive, but there is no real help about how to develop the plan. Many business analysts are uncomfortable with such comprehensive planning; the description here could be overwhelming. There is an opportunity to provide some guidance and examples here, I think.

Requirements Elicitation and Analysis

The Practice Guide only describes how to elicit by asking questions, and doesn’t talk about the need to use research or experimentation as primary elicitation techniques, or to corroborate information provided by stakeholders. It pretty well assumes that you can get most requirements by asking the right questions of your stakeholders, even if they don’t know all of their requirements, or may have difficulty articulating them.

The discussion on analysis suggests using a combination of models to understand the requirements, and to identify gaps, and that’s a good thing. It’s too bad that the Practice Guide doesn’t suggest ways that business analysts can collaborate with stakeholders to develop models concurrently with elicitation, since that approach can be pretty efficient, speeds up validation and consensus, and encourages early buy-in from stakeholders.

A useful table is provided on page 90 to categorize the different types of models and the purposes for which you would use them.

There are simple examples of how to use most of the models, and the diagrams are clear and easy to follow. In almost all cases, precise notation is ignored in favour of a clear explanation, and I think that’s a workable approach.

Overall, the discussion of the analysis models seems more appropriate for a systems analyst than for a business analyst. All of the diagrams drift into the solution design, and miss the solution requirements.

The discussion of requirements documentation seems to lose sight of the models, and is biased towards extensive text-based documentation.

The description about writing requirements is pretty thorough.

The suggested techniques for resolving requirements conflicts are a worthwhile read.

Traceability and Monitoring

The PMBOK® Guide exerts a substantial influence on this chapter. The heart of the described approach to traceability is the Requirements Traceability Matrix (RTM), a concept right out of the 1980’s. Yes, it is worthwhile to take a disciplined approach to traceability, but a matrix is a very cumbersome tool for managing many-to-many relationships between requirements, and between requirements and designs, solution components and test cases. A lot of potential overhead is introduced in the discussion about requirements attributes; you don’t always have to use all of these attributes; in most cases, a few key attributes will be all you can handle.

The discussion on managing changes to requirements is also a little outdated because it promotes the idea of doing an impact assessment on every change request before the request can be considered for approval. The trouble with this approach is that at the project planning stage, nobody ever plans enough time to do all of these impact assessments. If there are many change requests, the project team can burn up a lot of project time assessing potential impacts of changes that will go nowhere. What the Practice Guide could suggest is to obtain a preliminary approval before doing the impact assessment to prevent the project from wasting time on change requests that will never be approved.

The focus on the project perspective of change requests misses out on the business analysis perspective of assessing change requests in terms of the impact to solution value after the project is completed.

Solution Evaluation

This section deals with validating the solution, and then evaluating the solution after it is in operation.

Solution validation and acceptance is discussed in-depth, and includes a good discussion of planning considerations to test and validate the solution. Transition planning to support the solution implementation is also covered in some detail.
The discussion about ongoing solution evaluation is limited to the planning that might occur as part of the project work.

About the Team of Authors

I was a little surprised that the PMI chose to have many of the same people who were extensively involved with the development of BABOK® Guide to lead, contribute or review content for this PMI Practice Guide. You would think that such a large organization as PMI with such a global reach would have found a different group of expert contributors. Are these really the only business analysis experts in the world, such that both the PMI and the IIBA must rely on them so heavily? The good news, of course, is that those experts have been doing a lot of deep thinking, sometimes together, about business analysis for several years, and so the resulting product is pretty solid.

Given that the same people were involved in the creation and review of both publications, it should come as no surprise that much of the content is similar between the PMI’s Practice Guide and the upcoming BABOK® Guide v3. Parts of the discussion on Solution Evaluation are strikingly similar in both publications.

One disappointment is that some of the techniques that are described in the Practice Guide are not generally applied business analysis techniques. When I did an Internet search on some of the terms and techniques with which I wasn’t familiar, I was disappointed to discover that the top ranked hits are associated with some of the Practice Guide’s authors’ companies.


The PMI’s Business Analysis for Practitioners: A Practice Guide is a useful addition to your business analysis toolkit if you work on IT projects that follow a sequential lifecycle. Every now and then there is some acknowledgement of adaptive (it really means Agile) projects. It is a first step at extending the requirements process and requirements management practices that are identified in the PMBOK® Guide.

It will likely be most useful to people who are new to business analysis, although even experienced BA’s are likely to get some tips. It is focused on business analysis within the context of software projects, and for BA’s who report to a project manager. Professionals who already have one of the PM certifications may find this to be a useful resource as they try to earn a second certification.

The PMI has indicated that it is planning to produce a consensus-based Requirements Management Practice Standard in the future. This Business Analysis for Practitioners: A Practice Guide, is a good start.

Don’t forget to leave your comments below.

What Elicitation Really Means

Bondale FeatureArticle Nov28

In the old days, business analysts used to gather or collect or capture requirements, but all that changed in 2009 with the second edition of the BABOK® Guide. Now we elicit requirements and other business analysis information, and the term elicit was defined in the BABOK® Guide as meaning “to call forth, or draw out”.

It seems that the good folks at the IIBA didn’t tell us the whole story. However they were on to something when they said the term means trying to uncover unstated and implied needs, not just what the subject matter experts (SME’s) tell you they want. This proves that you can’t just accept what your SME’s tell you, you have to work at it to discover what they aren’t telling you.

The Oxford English dictionary tells us that the term elicit is derived from Latin and originally meant to to call forth or draw out by trickery or magic. Take for example a 2013 FBI press release with the title Massachusetts Man Charged with Making Hoax Emergency Calls to Elicit SWAT Team Response. Not exactly what us business analysts usually think of when we use the term.

Spies and Counter-Spies

But the FBI does use the term in other ways that are very relevant to business analysts, and in fact it provides a free brochure called Elicitation Techniques in which it describes how spies and counter-spies discretely gather information from a variety of sources and then piece the information together into something useful. The FBI defines elicitation as the strategic use of conversation to extract information from people without giving them the feeling they are being interrogated. They provide the example of trying to plan a surprise party for someone, where you need to know his schedule, his friends’ contact information, and his food and drink preferences, but you can’t ask him directly.

The FBI provides a long list of elicitation strategies including being a good listener, starting a conversation at a high level and gradually leading it to be more specific, word repetition, mutual interest, flattery, stating assumptions that invite correction, questionnaires and surveys to get people to agree to talk with you, and so on.

The spies have long known that just asking one person a direct question may not always give you the whole truth; the real value is having multiple sources that either confirm each other, or to identify discrepancies which merit further analysis.

And the spies also know that it is essential that you ask the right people. Different people have different expertise; its not always the most senior or most experienced person who provides insight.

Sometimes, a Conversation Just isn’t Enough

Sometimes, SME’s don’t agree, and the BA encounters what are sometimes called conflicting requirements. Just asking more questions may not shed any more light on the conflict.

The very first thing to do is to verify that they are expressing a requirement that represents a need and not a solution; then be clear whether they are describing the current state or the future state. Believe it or not, sometimes when you ask a SME about their requirement, they could tell you what the current system does, or how the new process could or should be organized, and think that they are providing you with the answer you need. It can sometimes be difficult to tell the difference.

Asking the SME’s “why does it have to be that way?”, or “why is it that way?” can often differentiate between a requirement and a design; and their perspective of the current or future state.

Once you have confirmed that there really is a conflict about the requirement, consider using other elicitation techniques to provide independent corroboration, such as research (web searches, reports from expert consultants, current process documentation, statistical reports of transactions), benchmarking to learn what other organizations do, and surveys.

When Experts are the Only Source

Scientists and engineers suggest that elicitation is the process of extracting expert knowledge about some unknown quantity or quantities, and specifically use elicitation to help achieve a consensus among a group of SME’s when no one SME definitively knows the answer. Psychologists have taken it a step further and attempt to determine a probability distribution to assess the quality of the expert knowledge.

The basic idea is to replace conversation and debate (or argument) with task performance. This can reduce the influence of SME’s who tend to dominate discussions, the unwillingness to abandon publically expressed opinions, and avoid false consensus and groupthink. These techniques encourage buy-in and consensus by actively engaging the experts in the performance of the task, identifying discrepancies, and collaborating to understand the inconsistencies.

Rather than just ask questions and record their expert opinions as fact, use a structured process to allow a group of SME’s to independently apply their judgement several times, in a variety of situations, in order to identify patterns and assumptions that the individual SME’s may have difficulty recognizing on their own. For example, ask several SME’s to review case studies or perform tasks from the business domain to provide their expert opinions, and then ask them to explain why their conclusions differ. This helps to uncover tacit knowledge and hidden assumptions behind the conflicting requirements.

Delphi Technique

In the Delphi technique, SME’s individually answer a questionnaire or perform a set of tasks, and provide a justification for their answers. These explanations reveal hidden assumptions held by each expert. The assumptions are then discussed among the SME’s in a facilitated session. Some of the assumptions may be dismissed, but most will reveal characteristics about the requirements that were previously unstated. For example, in a business process, there may be decision points that must be modified to deal with situations that hadn’t been identified before; new steps may be identified which address the data quality or lack of information available to the person performing the task, and some steps or even entire flows may be eliminated. The facilitator, in our case the business analyst, uses the Delphi technique to manage the effects of group behaviour and instead allow the SME’s to collaborate to identify and describe why they do what they do.

Nominal Group Technique

In the Nominal Group Technique, each SME is asked to perform a task or to describe a solution to a problem. Each SME describes their approach to the group. The BA clusters these explanations, so that duplicates are removed. Next, each SME is asked to rank the proposed solutions as best, next best, etc. Often a secret vote is used to minimize the influence that some SME’s may have on others. You could use points to weight each of the votes, such as 5 points for “best”, 4 points for next-best, etc. The BA reveals the total points and then facilitates a discussion among the experts. If there is a clear winner, then little discussion may be required; but if there is no obvious consensus about the “best” approach, then there are likely some underlying assumptions that have not yet been identified and agreed to, and so the process is repeated. This technique often leads to a hybrid “best” approach that can be supported by all of the SME’s.


What if you are trying to discover the requirements for a product or service that has never been done before? You could develop a hypothesis about each of the conflicting requirements which could then be confirmed or rejected through an experiment. The experiment should be designed to test just the hypothesis, while minimizing the cost and risk to the organization, and the people involved in the experiment. Develop a prototype based on one SME’s perspective and test it with independent users; or build a simulation of a process and execute it hundreds of times in simulation. Sometimes a limited pilot of a new solution can identify requirements which no one could have known before it is put into real use by real people in real situations.

Ask your SME’s to observe and interpret the results with you. You might use the Nominal Group Technique to facilitate the discussions.


Okay, so we won’t usually rely on trickery or magic to elicit requirements, but it is worthwhile to recognize that SME’s find it very difficult to give us simple and straight forward answers to our questions about their requirements: their business situations are very complex, and different SME’s legitimately have very different perspectives. Use a combination of techniques to elicit information, use conflicting requirements as an opportunity to discover unstated assumptions, and apply other techniques like expert judgement and experiments to corroborate the information. And every now and then, someone may have to pull a rabbit out of a hat.

Don’t forget to leave your comments below.

5 Classic Mistakes of a Business Analysis Centre of Excellence

vincent Nov24A Business Analysis Centre of Excellence (CoE) can be an effective means of improving the way business analysis is performed, resulting in better business outcomes from successful projects and operational support initiatives. It often begins with an ambitious training program, followed by a distribution of templates and instilling the best practices. Some CoEs are successful, but all too often the CoE is disbanded after a couple of years of disappointing results. Having been involved with dozens of CoEs with different companies, I’ve observed some of the most common mistakes and how to avoid them.

1. Failure to Engage the Right Stakeholders

Many CoEs successfully inform executives about the CoE’s reason for existence, and they also let the BAs know what is expected of them. However, few BA CoEs meet the needs of the other key stakeholders. These stakeholders have their own priorities and challenges, and may not have time to worry about better business analysis. Take the time to understand their needs, and to help them make the necessary transitions.

  • Solution providers like vendors, developers and testers who use the approved requirements may be expecting specific formats and specific levels of detail in the requirements artifacts, and expect that the artifacts will be produced in a specific timeframe. Internal solution providers may have their own CoE with its own tools and standards that conflict with those of the BA CoE; while external solution providers may be bound by contractual specifications about the requirements. There could also be unspoken cultural expectations about the role of the BA and the types of requirements documents and requirements artifacts.
  • Operational managers and subject matter experts who use BA resources may have business pressures that prevent BAs from spending time implementing good ideas from the CoE.
  • Customers may have certain expectations about dealing with the BAs in your company; they may actually like the current way of working with your BAs and may object if you change things too much.
  • An existing union agreement may describe job functions that need to be considered by the CoE, which may also enhance or restrict the ability of workers to implement new techniques or best practices. Or, responsibilities and job titles could exist that have been endorsed by your human resources department, possibly requiring adjustment.
  • Internal procurement specialists who reach out to suppliers of contract BAs need to be aware of the skills and duties required by the CoE. Existing supply arrangements may need to be revised. If the CoE asks for too much of a change too soon, the organization may find itself unable to find adequate resources that meet the new skillset expectations.
  • Companies supplying the contracted BAs need to understand the BA CoE’s guidelines about required skills and duties. It will take them some time to source the right people with the right skillsets, and the organization could well find itself paying a premium for such resources.

2. Too Much Reliance on Templates

A document template sets expectations about what types of requirements and requirements artifacts are to be produced.

  • The first problem with most templates is either that they are too generic and broad to be of use on a specific initiative, or that they are too narrowly focused and fail to recognize the differences between projects. Many BAs are frustrated by their current templates because they don’t meet the needs of a specific initiative.
  • Many templates are focused on software requirements and ignore all of the other areas where business analysis can really be of use, like changes to business policies and rules, job functions, relationships, capabilities and workflows.
  • Templates establish the focus of the BA work on documentation rather than on discovery, collaboration and analysis. Filling out the template on time becomes the goal, rather than understanding the requirements and recommending solutions.
  • A template-driven requirements document is project-centric, and the usefulness of the document diminishes as soon as the project is completed. But, the reality is that the requirements actually live on with the solution and could be relevant for many years. Since most project documents are seldom referenced after the project, consider changing the focus of the BA work to produce a coherent set of versioned requirements artifacts like process models, a data model, use cases and storyboards that live on their own and can be base-lined and assembled into a document at any time. You will need a requirements management tool to do this well.

3. Trying to Make Too Many Changes at Once

It’s usually easy to spot lots of possible areas of improvement in your business analysis practices. But culture, tradition and ceremony are likely to resist too much change at once. Some of the changes requested by a CoE like enhanced time and status reporting may just be perceived as low-value overhead. Left to its own devices, the organization will revert to its previous status quo (the way we’ve always done things). So if you want to make sustained changes, the only way to do so is to lay a solid foundation, make incremental changes, realize and communicate the benefits and provide ongoing and substantial reinforcement to those changes.

  • Training is the easy part — but sustaining it is difficult. Training can encourage your BAs to consider new ways of working. Applying the theory from training is quite difficult, and almost always requires time to recognize how to apply it in real life, to realize how to apply it effectively and to apply constant reinforcement.
  • Consistency in the way the BAs perform business analysis should be a primary objective, prior to making substantial improvements. Every one of the BAs has a group of stakeholders who must be informed and educated about the new approaches to business analysis. Time must be allotted to allow them to make the changes and achieve buy-in from those stakeholders. Many of those same stakeholders work with other business analysts, not spotting inconsistencies very quickly. Some stakeholders will exploit those inconsistencies because it makes it easier for them to do their own work.
  • Focus on incremental changes; test new techniques and tools on pilot projects and make adjustments so that the project is successful. Communicate the successes broadly and then roll the improvements out to other projects, providing strong support until the BAs using them indicate that support is no longer needed. Be prepared to abandon some changes if you can’t be successful with them.

4. Show the Way, Don’t Dictate

The BAs that are being asked to change the way they work must be confident that the people who are asking them to change actually know what they are doing. You can’t fake it; the BAs will know. It’s okay to have a professional manager run the CoE, but skilled BAs are essential to make the changes happen.

  • The individual members of the CoE who tell other BAs about the needed changes must first have real experience in the new business analysis techniques, not just theory. They should also have substantial business domain knowledge so they can provide relevant examples of how to apply the new techniques.
  • The members of the CoE must be excellent coaches and mentors.
    • A coach proactively provides guidance to the BAs that are working on projects and shares responsibility for the BA’s success or failure on those projects. A coach lets the BA do the work, but anticipates real problems and provides proven solutions and alternatives that the BA can execute. The coaching for each individual BA will be different based on the nature of the project, the stakeholders, and the current skills and abilities of the BA.
    • A mentor is someone who an individual BA can ask for specific guidance on a topic. Unlike with a coaching relationship, the interaction is at the discretion of the BA. Mentoring occurs when coaching tapers off, once the coach and the BA agree that the coaching role is no longer needed. The mentoring relationship is based on trust and can only occur if the BA really believes that the mentor is truly proficient at business analysis and understands the business domain.
  • Coaching and mentoring may be impeded if there is a cultural reluctance to “ask for help” or to be perceived as “requiring help.” Just remember that every champion athlete has a coach; no one gets to the Olympics without one.
  • External consultants may be engaged as temporary coaches to get things started and to “coach the coaches.” However, every effort should be made to develop internal coaches and mentors.
  • One effective approach is to rotate some of the roles in the CoE with practicing business analysts. This helps to broaden the experience of individuals and helps to keep the coaching grounded in reality.

5. No Skin in the Game – Misalignment of Goals and Objectives

Most CoEs are established with goals or objectives that align with the organization’s strategic direction. But all too often, the BA CoE’s goals fail to align with those of individual BAs with tactical project objectives like schedule and budget, and with operational objectives such as minimizing customer service delays. This is most evident in a matrix organization where any one person may be trying to meet several disparate sets of goals. The CoE’s goals could actually conflict with the “real work” that is being done.

  • Operational managers and project managers are likely to resist the imposition of BA standards and templates if they perceive them to be in conflict with their own goals, especially if their own goals are tied to annual performance reviews.
  • If an individual BA tries to follow standards set by the CoE and the project fails, what degree of accountability is assumed by the CoE?
  • If a BA is supporting an existing solution and, by applying new BA techniques, fails to implement requested changes as quickly as expected, to what extent is the CoE accountable for the failure?
  • One of the CoE’s objectives must be to make the individual BAs more successful. And that usually means making the BA’s stakeholders more successful. So the BA CoE must be aware of those stakeholder goals and ensure that the CoE helps to support those goals. The best way to make this happen is to hold the CoE accountable for the successful use of the new techniques and tools.


A Business Analysis Centre of Excellence is no small undertaking. There can be a substantial payoff in terms of better business outcomes from successful projects and operational support. But, great care must be taken to ensure the CoE has a positive and sustained influence, and doesn’t turn into an irrelevant Ivory Tower, or worse, a nuisance.

Critical success factors include the following:

  • Extensive stakeholder engagement
  • Incremental improvements built on consistent practices
  • Focus on improved processes and not just templates
  • Ongoing coaching and mentoring by people who truly know business analysis and the business domain
  • Shared accountability for successful business outcomes

Don’t forget to leave your comments below.