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-PBA^SM 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.

Requirements

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.

Documentation

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-PBA^SM 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.

Conclusion

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.