- 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.