BA Stories: Mind the Gap – The Capability Gap (BABOK 5.2)

Assess Capability Gaps is one of those tasks that we almost all do, but when we read about it in the BABOK we might wrinkle our brow. It seems so obvious that we may not have been aware of it as a discrete task until we take the time to read the BABOK (or you take the time to work your way through this series). But if you’ve ever been involved in scoping a project, you’ve done this task. You probably just did it so intuitively that you didn’t quite realize the value of what you were doing.

The purpose of Assess Capability Gaps is:

“To identify new capabilities required by the enterprise to meet the business need.”

Simple enough, huh?

This task involves analyzing current capabilities, creating an assessment of new capability requirements (aka business requirements) and documenting assumptions about how these new requirements will help us achieve the business need.

Starting this task with analyzing current capabilities is critical, because oftentimes, organizations have existing capabilities that are not being leveraged and a business need can be met by small change. For example, after understanding the current capabilities of the 5 organizations, we realized that one organization had a means of serving advertisements that could relatively easily be leveraged by all the organizations. Every organization had expressed this business need, and one of our first projects was to scale this capability so it could be leveraged by all.

If existing capabilities are inadequate, a project will be launched to create the capabilities. Change can be created in any of the following areas:

  • Business processes
  • Features of a software application
  • Tasks performed by end users
  • Products that an organization creates
  • Services delivered
  • Etc.

This is our more “typical” world as business analysts – defining the capabilities needed to solve a business problem. Note that this task is part of enterprise analysis and enterprise analysis creates business requirements. So at this point, we’re not talking about the detailed, step-by-step requirements that might go into a functional requirements document or software requirements specification, but the higher-level business requirements you might find in a short version of the Business Requirements Document (I say short version because many BRD templates I’ve seen in practice are actually very detailed, but that’s a topic for another post).

In my experience consolidating those 5 software systems, our capabilities analysis revealed about 30 or so features that needed to be enabled in a centralized way – some of these were common amongst the existing technology systems, some were unique, and some were new. To meet the business need and consolidate the systems, we needed to be able to deliver these 30+ features.

On another more typical project where we were building a new customer-facing web portal for an internal application, the capabilities assessment involved articulating the key features to be enabled for the customers and the new business processes the support staff needed to be capable of to support customer self-service.

Share some examples. When have you conducted a capabilities assessment? Do you have an example of being able to leverage current capabilities to achieve a business need?

This post is an installment in our Journey Through the BABOK with BA Stories series.

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

your details are safe with us

Books and Courses You Might Be Interested In

Comments

  1. Michelle Swoboda says:

    Recently I worked on a project to evaluate iStore to determine if it would meet the business needs. It was an interesting concept – gathering requirements, as is and to be diagrams completed within two weeks. Then on to the CRP (conference room pilot) where the vendor displayed the out of the box functionality of the tool and how it matched to the business requirements. We quickly understood how many gaps there were and what we had to overcome. It was an interesting exercise and one that I will hold in my tool box as a model for new projects.

  2. Another area in which change might be required (that is, a gap can be found) is in the Organizational Structure. I once worked on a project to analyze problems a company was having with on boarding new clients. There were technical issues that needed to be resolved in every new client integration, and these problems were being tossed in to the general IT work stream, alongside everything from new development to system maintenance. It soon became clear that there were three “gaps” that should be addressed: a small portion could be fixed with system changes, some required changes to business processes, but there was still the problem that a position needed to be created, staffed, and tasked with the ongoing responsibility for overseeing this important business function.

Comment

*