Enterprise View of the Business Analyst Role

BAs Tend to Have a Narrow Focus on Project Related Work

All too often, the BA is unable to focus upon the right areas during a project due to a lack of enterprise analysis prior to the project. Because of this lack, the BA is forced to do requirements elicitation at too many levels at once rather than having focused requirements analysis at the business level leading to requirements elicitation and subsequent analysis at the functional level. This leads to several dangers.

Danger #1

The BA is put behind the curve from the beginning of the project.

If there has not been sufficient elicitation and analysis effort at the business level before the project, the BA is trying to define the business level requirements while simultaneously building the functional and system level requirements that will deliver/support those business requirements. Most of us have been in projects like this and we know that the pain level is high. 

Danger #2

The BA is very likely to make discoveries during the project that should radically redefine the project; however, promises have been made and no one wants to explain why this was not anticipated. This leads to projects that deliver what they promised but are perceived as unsuccessful because expectations have changed during the project. One solution is to manage expectations; another is a better use of the change control process.

A Wider and More Appropriate Focus

The Business Analyst’s Body of Knowledge (BABOK) v1.6 has a visual in section 1.6.1 (shown below) that shows the relationship between the knowledge areas. I find the picture is effective in conveying a message that the real role of the business analyst is in project related requirements activities.

One way to look at the BA role is to view Enterprise Analysis as encompassing the other BA activities shown in the BABOK. If you take that view, then the BA has a much clearer set of duties and activities before, during and after any project activity.

Using Enterprise Analysis as the Driver

The following graphic allows us to look at the BA’s role more holistically.

If we look at the role of the business analyst as primarily enterprise focused, we can use distinct phases leading from opportunity identification to solution definition to development to implementation and finally to the analysis of new threats/opportunities surfaced from the solution’s existence. This allows greater clarity in the business analyst’s role and deliverables.

Strategic Phase (the first column in the picture) 

Clearly there is (or should be) a phase where the business analyst  is working with business management to create and maintain the business architecture, identify opportunities to pursue, and develop a portfolio or projects from which business management selects those most beneficial to the long-term goals of the organization. These deliverables are listed in the BABOK as associated with Enterprise Analysis (EA).

The BA is definitely using all the project management fundamentals here, but the objective is not to produce a specific new application or process. The focus here is to act as a consultant/support arm to the business management so that opportunities can be identified, explored and selected or deselected. I find that most of my clients have too many projects going at once. In addition, many of these projects have conflicting goals and measurements. We, the BAs, have an opportunity at this stage to establish our credentials as a business partner by helping the business management define a portfolio in which projects are prioritized and staged to maximize business benefit. This would also have additional benefits to organizations such as HR and IT that are stretched too thin under the current approach. 

This strategic phase is where the BA has the opportunity to elicit and analyze the business requirements so that the portfolio decisions can be made as to which projects are worth pursuing. In addition, the BA has the opportunity to include parties who will be affected by any projects initiated from this phase. This would include, but not be limited to, groups such as project management, quality assurance, and training

The BA at this point should be producing a set of deliverables some of which are listed below.  We use the balance as the symbol in the list to reiterate that each is a narrowing of focus and more detailed analysis of a subset of the deliverable which preceded it.  These deliverables include:

• A set of opportunities from which management decides those to be pursued,
• For those selected opportunities, the BA develops alternative solutions with associated trade-offs. Management decides which alternatives to pursue, if any.
• For selected alternatives, the BA would be doing a detailed analysis that will be the business case for projects to be done. This will include the business level requirements that will be addressed by specific projects.

Project Phase (middle column) 

This phase has received the most attention in the general literature and this is not meant to be a complete coverage of the phase. The intent here is to show how the usage of the strategic and operational phases improves the project phase.

The strategic phase leads to project work. In the project phase, a set of selected business requirements should be used as the base to initiate the requirements effort at the next lower levels.  A key point that I am trying to emphasize in this document, however, is that the likelihood of this phase being successful is substantially improved if the business analyst has had the opportunity to produce those products identified in the strategic phase.

Similar to the strategic phase, the BA’s deliverables during the project tend to build upon each other. These include, but are not limited to:

1. Testing/Acceptance criteria for the business requirements being addressed by this project.
2. Functional and non-functional requirements that need to be accomplished to support the business requirements.
3. Trade-offs between different approaches for project delivery
4. Test strategies that will be used during the project to demonstrate that requirements have been delivered.

Frequently, there has not been sufficient work done in the strategic phase (i.e. the EA work has not been done). If so, the business analyst must retro-fit that work into the project. This puts us right into Dangers 1 & 2, identified earlier. Since we have already launched the project and committed to a delivery/completion date, the business analyst doesn’t have the time needed to produce those work products with enough rigor. Worse yet, the project manager who has been driving the planning and execution efforts based upon the approved project scope will be frustrated when/if the business analyst’s detailed work shows that the project should be redefined.

Operational Phase 

In any case, a solution is eventually delivered. Once any solution is in place, the BA enters a new analytic phase. The solution, by its simple existence, opens up new ideas. Once people are dealing with the solution, they start thinking about what could be. This will include high level and low level ideas.

High-level

These will be a mixture of threats and opportunities that the BA should identify by working with all levels of the organization. These ideas can be brought to the attention of senior management and becoming input to the strategic phase.

Low-level

No solution is ever complete or perfect. The BA, working with the solution users and customers, can identify a set of improvements, fixes and general changes that will allow the next version of the solution.

Closing the Loop

The BA needs to be looking at a lifecycle which starts before and lives after the project. We can better acknowledge this by adding the strategic and operational phases to the view of our work. It also institutes a feedback loop to that life cycle which will allow us to establish and build upon the role of BA as a consultant/business partner.

---

John Slack is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. John has over 30 years of experience in business development, project management, business analysis, and professional development. For the past decade he has focused his time on a mixture of active project management and analysis of business operations as well as the development of training for project management and business analysis. His projects have ranged from the retail to high tech sectors including the planning and rollout of business strategy for companies such as Digital Equipment Corp and Intel, to the development and rollout of software applications for companies such as DirectTV, Motorola and American Airlines. 02/09