Tag: Best Practices

Building a Business Analysis Center of Excellence: A Blueprint for Success

Written by Abhi Puri on September 21, 2023. Posted in Articles.

A Business Analysis Center of Excellence (BACoE) is a dynamic and strategic organizational asset that can significantly enhance the effectiveness and efficiency of business analysis processes. Often referred to as a Competency Development Center, a BACoE serves as a hub for collaboration, best practice management, and competency development in a specific functional area. This article explores the key elements of establishing a BACoE and its pivotal role in increasing business success.

Defining a Business Analysis Center of Excellence

A BACoE is more than just a department; it’s an organization that promotes collaboration, manages best practices, and elevates the competency level within a specific domain. Whether established as a virtual entity integrated into the broader organizational structure or a distinct group with a dedicated budget and authority, a BACoE can be staffed with either full-time or part-time members.

Creating a BACoE signifies an organization’s move toward higher organizational maturity, and as maturity increases, the risk of project failures tends to decrease.

Responsibilities of the BACoE

One of the primary responsibilities of a BACoE is to ensure consistent quality in business analysis artifacts throughout the organization. Variations in the quality and format of these artifacts can lead to project risks. The BACoE takes the lead in standardizing the expected quality, format, and presentation of artifacts, initially through training and artifact templates. Additionally, it promotes the use of standardized tools among business analysts and provides support for projects to maintain consistent professionalism.

Functions of a Business Analysis Center of Excellence

A well-established BACoE should provide support and oversight in several critical areas:

Tactical Project Assistance: The BACoE offers assistance to projects through project coaches, mentors, and staff. This includes planning business analysis activities at the project’s initiation phase, ensuring appropriate resources and approaches are in place, and providing resources as needed.

Methodology: The BACoE defines standard approaches for business analysis planning, monitoring, and execution. A methodology aligned with industry best practices, such as the IIBA®’s Business Analysis Body of Knowledge® (BABOK®), serves as a foundation for training and practice within the organization.

Best Practices: The BACoE curates a collection of company and industry-best practices for business analysis and artifact creation. This includes standards for use cases, data models, process models, and other documentation types.

Learning and Professional Development: It manages a competency model, training curricula, certifications, assessments, and practices for knowledge sharing. This includes the maintenance of knowledge repositories, discussion forums, and collaborative tools like “wikis.”

Tool Standards: The BACoE provides guidance on tools essential for preparing high-quality, standardized business analysis artifacts, including requirements management and visual modeling tools. It also maintains a repository of templates and guides for artifact preparation.

Forming a Business Analysis Center of Excellence

The establishment of a BACoE involves a series of steps:

Assessment of Current State: Evaluate the organization’s current business analysis maturity by assessing the skills of business analysts and gathering feedback from project managers.

Determination of Desired Future State: Define the level of maturity needed to support projects effectively.

Analysis of Gaps: Identify gaps between the current and desired states.

Specification of Desired Level of Maturity: Clearly outline the competency model and practices required to bridge the gaps.

Development of Competency Model: Create a competency model that aligns with the organization’s needs and industry best practices.

Dissemination of Improvements: Implement strategies to disseminate competency improvements through training, mentoring, and internal resources.

Maintenance and Continuous Enhancement: Regularly assess and enhance competencies through retrospectives, surveys, and ongoing training.

Best of BATimes: Business Analyst Role in COTS Projects

Written by Maksym Lysikov on September 13, 2023. Posted in Articles.

Many tech companies offer commercial off-the-shelf (COTS) products.

Such products allow to meet their clients’ business needs relatively fast, comparing to the development of the new IT solutions from scratch. However, a COTS product for a complex solution such as ERP, CRM, laboratory or hospital information systems requires considerable time and effort to be invested into the configuration. Hence organizations usually involve a separate implementation team of professionals familiar with the COTS product to adapt it for the company’s needs.

COTS vendors normally provide the implementation service to their clients. This can vary from company to company, but oftentimes it includes discovery phase, configuration or customization of the system according to the business needs, user training and making sure the project goes live.

This article describes the BA role in the implementation of the COTS projects and cooperation between a COTS product team and BA from an implementation team.

BA in Implementation Project

One might say that COTS projects do not require business analysis since there seem to be no significant development activities. However, COTS projects could vary from completely out-of-the-box to complex solutions with lots of configuration and additional customization (codding) involved. In the latter case we can and shall involve the standard business analysis activities:

Plan your business analysis work. Ask yourself what is your business analysis approach (adaptive vs predictive)? Who are your stakeholders? Do you have a requirements governance process in place?
Requirements elicitation and analysis. This covers discovering the current and desirable states, conducting workshops and interviews, document analysis, etc. Don’t forget to elicit and document any gaps if a COTS solution is not capable to meet some of the business needs.
Requirements modeling. COTS projects normally do not require the complete functional specification since the solution is predefined already. However, there are many other requirement views which can be useful for the configuration project. We will discuss that in the section that follows.
Solution evaluation. Define your KPI and measure if they improved compared to the legacy solution.
Configuration. System configuration is normally out of business analysis scope, but some companies tend to involve business analysts in such activities. In any case, the BA should know how the system works and understand the solution limitations.

Requirements Modeling

As mentioned before, it might not be required to document all the functional requirements for the already predefined solution like COTS product. However, not documenting requirements at all could result in certain drawbacks:

Apparently, external stakeholders, like end users, and internal stakeholders, like testing or support teams, will need at least some documentation that describes how the system behaves.
Without modeled requirements, there is no way to validate the requirements before they are actually implemented and the system is demoed for users. What if you only validate your assumptions by demoing already configured piece of functionality? That is right, you will most likely need to reconfigure the system again once you receive the feedback, and then again and again. Nevertheless, you still can present out-of-the-box functionality which doesn’t require any configuration efforts and use it as a starting point to collect the initial feedback from your users.
The change management process can suffer. Imagine that you documented the requirements for the billing module in the bunch of meeting notes, and now 4 weeks after the requirements were implemented the clients insists that some of the billing transactions are not calculated correctly. Would it be easier to refer to the SRS part where all business rules are documented, or try to find the relevant emails?

To address the above issues, the BA can use a variety of the business analysis techniques which will be applicable for the project and audience. For example:

Roles and Permission Matrix: most of the COTS solutions allow roles configuration and assigning permissions. Start with defining and documenting user roles and their permissions. The organization chart can come in handy to define the roles.
Process Modeling: you can elicit and model the current processes using either the standard notations such as BPMN, UML or come up with a simple drawing which doesn’t follow any notation standard but clear for the audience. The next step will be to review the models with stakeholders, define if anything should be changed in the process and update the model. Once done, you can supplement the model with the additional requirements view, e.g. use cases.
Gap Analysis: as the BA on the implementation project you need to identify the areas in your client’s business which are not covered by the COTS package and address it to the product team. Bear in mind that it is always a good idea to think about the potential workarounds you can offer to the client, before escalating the gap to the product team. That way the client can access the desired functionality earlier, the product backlog will not be overloaded and there will be no need to overengineer the product with the functionality potentially used by only 1 client. So at first always assess if it is possible to configure the system in an alternative way or if the client can agree to do certain steps manually.
User Stories: this is a simple and popular way of specifying the requirements, especially if you follow the agile approach and need to deploy the COTS solution incrementally. It is also quite convenient to prioritize the requirements using the user story form.
Use Case and Scenarios: you can document each separate business flow in the use case. Use cases can easily be converted into the test scripts and serve for validation purposes.
Business Rules Analysis: it is always a good idea to elicit and document business rules. Make sure you have a process in place to update business rules due to external or internal changes.
Interface Analysis: your COTS product will most likely not be used as a standalone solution and will communicate with other components. Define and document interfaces specific to your client.
Data requirements: usually a COTS solution replaces an outdated legacy solution and you need to take care of the historical data. And it is better to define data requirements upfront before you realize you cannot import 256 characters long text into the address column for one of the top customer’s client. Ask yourself the following questions: do you need to import the historical data into your brand new COTS solution? will the legacy data fit the new system? how will you handle the cases when the data doesn’t fit the new COTS product?

Provide Feedback to your Product Team

A good way to improve the product is to listen to your user’s feedback. And when it comes to COTS project who is the best candidate to elicit, analyze and document all the client’s concerns and frustrations? Yes, you’ve got it right! It is the implementation BA or anyone else who fulfills this role in an organization. And thus the BA is the one who should establish a process to communicate all business concerns and client gaps to COTS product team.

For example, the BA can create a separate Wiki page per a client where they can list all gaps discovered during the project and communicate them to the product team. The product team can then collect the feedback from all clients, prioritize the gaps for the future releases and share the roadmap with the implementation team.

Conclusion

COTS implementation projects can be a challenge for the BA as they differ from the traditional IT development projects. However, with the right attitude and a bit of creative thinking, we can adopt the BA techniques and establish the process which will bring value to the implementation projects and help improve the COTS product.

Published: 2019/08/08

Best of BATimes: 5 Characteristics of Effective Business Analysts

Written by Giorgos Sioutzos on September 6, 2023. Posted in Articles.

“Business Analyst” is not just a title. Is not a job. It is a mindset, a concept and a structured process executed by people in different positions inside an organization. It’s more like, an approach of making the things happen from the realization of business need towards the final implementation.

It’s easy to call yourself business analyst but difficult to be a good and effective business analyst. The field can be great fun, and very rewarding, but you need to be prepared. People who take on business analysis roles typically believe they need three things: skills and experience, a bit of marketing, and an interest in working in a variety of environments. However successful business analysts know they need much more than a technical expertise and specific skills. They need a mindset and a specific attitude in order to serve with the best possible and feasibly way their clients business needs.

What is expected from business analysts can vary widely. And what they actually need you to do can be completely different from what they expect. Business analysis is an exciting, dynamic form of work. You can have a positive impact on your clients and be well paid for your effort. But you have to be appropriately equipped.

To be an effective and successful business analysis you need to continuously develop some specific characteristics.

The first is technical depth. It’s critical that you have the technical background to satisfy your clients’ needs. This means you have experience in a variety of environments. The more breadth of experience you have in your technical area, the easier it will be to apply your skill as a business analyst.

Second, effective business analysts need to understand quickly and accurately what’s happening in their client’s environment. Your power of observation needs to be well tuned. Being able to listen carefully and patiently, observe the behavior of your clients, and make sense of what is happening is very important.

Third, effective business analyst care about the welfare of their client’s business and the clients themselves. You need to be able to put yourself in your client’s shoes and appreciate the difficulties they may be facing or have faced. While what you do may seem routine to you, it probably isn’t routine for your client. You need to appreciate that fact and behave accordingly.

Another important characteristic is emotional intelligence. Often clients will engage you because they’ve had substantial difficulties. They may have a skill shortage, or they may not be sure how to manage what you’ve been asked to deliver. All these conditions create stress. On top of that, you’ll be striving to learn as much as you can as quickly as you can, so you’ll be under stress as well. Dealing with all that requires personal emotional maturity and the ability to assess and deal with the emotional state of your client.

Also, you have to develop the observation and effective listening as a personal characteristic, make recommendations based on sound business judgment, and be patient. As trust builds, the direction your client provides will likely become more reasonable. Work out your contract. Understand your client’s needs and desires, and establish a good relationship with your contract manager, and you could put on your superhero costume to celebrate your success. Observation helps towards a really robust problem definition statement. So as you look at your problem-solving, and you’re getting ready to start pursuing that initial set of ideas, you need to go through that prioritization and pick the highest value one that’s going to have the biggest impact on your overall solution.

Business analysis is performed on a variety of initiatives within an enterprise. Initiatives may be strategic, tactical, or operational. Business analysis may be performed within the boundaries of a project or throughout enterprise evolution and continuous improvement. No matter their job title or organizational role business analysts are responsible for discovering, synthesizing, and analyzing information in order the best solutions to be derived and the clients’ needs to be accommodated in the best possible way.

Published on: Dec 2, 2021

Best of BATimes: What Problem Are You Trying To Solve?

Written by Larry Blankenship on August 24, 2023. Posted in Articles.

One of the most important lessons I’ve learned to ask during my BA career is “What problem are you trying to solve?” It’s not as straightforward as it might appear.

Often, business partners come with all sorts of preconceptions, which they present as the actual problem. Sometimes they try to be helpful. It’s the BAs job to ask more questions to determine if that’s the real problem.

For example, I had a business partner who told me that the data in an email we were sending to one of our customers was “encrypted”. It would have been easy to waste hours trying to chase that down. I started down that road, until I caught myself and asked “What’s the problem I’m trying to solve?” I asked the business partner to see a copy of the email. It was then that I realized that what she was referring to as being encrypted was actually just raw XML being presented straight to the page. The problem wasn’t that the email was encrypted, it was that it wasn’t easily readable by a human. One parameter change later, and the problem was fixed.

Donald Gause and Gerald Weinberg wrote a seminal work on discovering the real problem called “Are Your Lights On?” I reread it at least once a year, to remind myself how to ask the questions needed to determine the real problem, because sometimes what appears to be the problem at first glance isn’t the real cause.

A recent real-life example was encountered by the Dutch bike manufacturer Van Moof, who found that over 25% of their bicycles were being damaged en route to the customer, especially when being shipped to the US. The company could have invested money in improving their packaging or looking for a new shipping company. Instead, they spent time identifying what the real problem was: the people doing the shipping weren’t being careful with the product, perhaps because they perceived a bicycle as being sturdy enough to withstand rough handling. Or perhaps they didn’t perceive bicycles as being as valuable, so they didn’t feel the need to take extra care when handling them. What was the solution?

In the end, the bicycle company put a picture of a large screen TV behind the picture of the bike. They didn’t indicate that there was a TV in the box. The shippers, who apparently don’t have time to read carefully, treated the updated boxes like there was an actual big screen TV inside them. As a result, damages in transit dropped by 80%.

1. Asking the business or customer what the problem is that they are trying to solve isn’t the end of the process, it’s only the beginning. Here are some ways you can get to the real problem:
Ask what things would look like if the problem was solved. Often, this will let you identify the real problem based on what the business sees as the desirable result. An example given in the book was a building whose tenants complained about the elevator being too slow. The desired solution wasn’t that the elevators be made faster, it was that the tenant’s stopped complaining. In the end, a mirror placed on each side of the elevator offered enough distraction that the perception of the elevator’s speed was no longer an issue.

2. Don’t accept a solution as the problem. Often in my career, the customer brings a solution that they want rather than a problem to be solved. Asking what the problem is that’s trying to be solved often allows for simpler resolutions. For example, one department is complaining that another department’s data entry isn’t accurate. The solution they presented was to add a high number of edits and validity check to the system where the data was entered. This would have required a large quantity of analysis and development time to ensure that the validations were correct and didn’t create additional follow on effects. Instead, time was spent bringing the two departments together to discuss the issues and looking for ways to improve accuracy at the front end. In the end, development wasn’t required, and the problem was solved via process improvement.

3. Spend time on root cause analysis. Sometimes the perceived problem is a symptom, not the actual malady. When I wrote software, a bug would frequently be caused by a change to a variable much removed in the stack from the code I was looking at. Doing root cause analysis will often help you identify what element is actually causing pain. This can also be a matter of overlooking something because “We’ve always done it that way.” The root cause may be the result of some process before or after the pain point that is creating the issue.

In the end, finding the real problem that needs to be solved, can be simple, complicated or somewhere in between. Taking the time to do the right level of investigation is an important part of the BA’s value in the development process.

Published: 2020/06/04

Avoid The “Saying/Doing” Gap

Written by Adrian Reed on August 10, 2023. Posted in Articles.

Elicitation is a core part of business analysis, and there are a vast array of elicitation techniques at a BA’s disposal. However, if you’re like me (and most BAs) you probably have a few favorite techniques that you gravitate towards. For me, I’ll often start with interviews and workshops, using document analysis to gain context and perhaps some observation to see how things really work.

While it’s completely natural to have frequently-used techniques, it’s important not to forget that other elicitation techniques exist. It is very easy to fall into a rhythm of reverting to a particular set of techniques irrespective of the context, project or situation being examined. This could lead to a situation where other techniques might have proved more efficient or effective. In particular, it’s important to use an appropriately varied set of techniques to avoid the ‘saying/doing’ gap…

People Often Do Things Differently In Reality

As any experienced BA will tell you, asking someone to describe how they do their work will often give you a very different result to going and seeing them do their work. There are often parts of the process that are so obvious to the people undertaking the work that they don’t even think about mentioning them. Imagine if someone asked you to describe the act of driving a car… you might explain the steps of opening the car door, putting the key in the ignition, checking mirrors and accelerating away. You probably wouldn’t mention putting on a seatbelt, or closing the door… but these are things that are very important! If we are wanting to understand an as-is process, we’ll often want to understand those ‘seatbelt’ moments too.

There’s also the tricky subject of exceptions and unofficial workarounds. Sometimes there will be exceptions that the designed process never really catered for, so workarounds have emerged. These workarounds might not be documented anywhere, or if they are documented they might be documented in an informal way. Knowing about these workarounds (and the exceptions that cause them) is important too—any new process really ought to cater for these situations without a workaround being necessary.

All of this points towards the need for a mixture of elicitation techniques.

Use a Mixture of Elicitation Techniques

Interviews and workshops are excellent techniques for understanding stakeholders’ perspectives on a situation and asking probing questions. Yet if we are going to gain a broader understanding of the situation, it’s important to mix and match our techniques. There are also some techniques that might not traditionally be thought of as elicitation techniques that can be brought into the mix too.

Here are just a few examples for consideration:

Analysis of Reports, Data & MI: What does the data show you about the process? When are the peaks? How many queries go unanswered? What are the most common queries from customers? Why are those the most common queries? What are the uncommon situations that might be causing exceptions or problems?
Observation, Sampling & Surveys: Observing colleagues undertaking their work can help us understand how the work really works, but requires a good level of rapport (else people might revert to the ‘official’ process rather than what they actually do). It isn’t always possible to do this, so sampling can be useful. In a call center where calls are recorded, if (with the relevant legal permissions) you can gain access to call recordings, you can potentially sample elements of a process and see how things are done. Or, you might issue a survey to the relevant customers or internal stakeholders. Sometimes giving people some time to reflect (rather than asking for an instant response in a one-on-one interview) can be useful.
Document analysis: A very broad technique, but looking at things like process models, procedures, exception reports and so on can prove useful. Of course, there is often a gap between how a process is written and how it is actually executed, but documentation is a good starting point.
Correspondence or sentiment analysis: This is really a particular type of document analysis, but if you are looking to improve a customer-facing process, why not look at some of the correspondence that customers have written about it? What do they like and dislike? Look at complaint logs, which elements are they complaining about? After all, complaints are a potential source of innovation, when they are filtered and used as input to process improvement. If your company has a social media team, perhaps they are capturing suggestions that have been submitted via these channels also.

Of course there are many other elicitation techniques too, these are just a few examples. But crucially, initiatives usually benefit from a mixture of elicitation techniques, some of which require synchronous stakeholder input, some of which require asynchronous stakeholder input (and therefore gives reflection time), and some of which initially don’t require stakeholder input at all (e.g. document analysis).

With a breadth of elicitation techniques, we gain a broad understanding of the current situation (and future needs). This helps ensure we deliver a valuable solution to our stakeholders.