For many business analysts (BAs), the IIBA Business Analysis Body of Knowledge (BABOK®) Knowledge Area that is the least familiar is Enterprise Analysis (EA). In some ways, this may be a mixed blessing. On the one hand, the BABOK® Version 2 (v2) EA area describes important topics and techniques that BAs should be conversant with: defining business needs, solutions, business cases, and project initiation.
On the other hand, I have issues with the ways BABOK® v2 treats these topics, especially how it portrays business needs and considers defining them as only part of EA. Moreover, I think the BABOK® v2 view of EA depicts things that often aren’t Enterprise Analysis while at the same time failing to address what EA is or should be.
BABOK® v2 EA
Figure 1 is my diagram of BABOK® v2’s requirements-related knowledge areas. In it, EA is a separate, executive/enterprise-level activity that precedes projects and decides in an idealized somewhat grandiose manner which projects to initiate. EA is where business needs are defined and prospective project solutions’ feasibility is analyzed.
As most BAs’ unfamiliarity with these topics attests, BAs can be but often are not involved with defining business needs, defining their solutions, and analyzing feasibility. I agree with BABOK® in suggesting these are appropriate activities for BAs.
According to the BABOK® v2 model, the bulk of BA time would be spent subsequent to EA in the initiated project--eliciting, analyzing, and managing requirements of the product, system, or software that the project is producing. Indeed these are the activities that most BAs currently mainly do and that BABOK® v2 mostly concentrates on.
Issues with BABOK® v2—EA View of Project Initiation
BABOK® v2 essentially assumes that all projects are initiated in EA through a very structured and enlightened explicit project initiation process. In this view of EA, executive senior management makes informed, conscious decisions about whether or not to initiate a proposed project based on enterprise criteria; and often choices are made by choosing the best project for the enterprise from among multiple proposed projects competing for limited resources. Financial business cases may aid the decision.
BABOK® v2 implies senior executives of course always make such project initiation decisions wisely based upon thorough and accurate information about the project’s implications for the enterprise, often including formal financial feasibility analysis.
Some organizations, at least sometimes, in fact do something similar to what BABOK® v2 assumes happens all the time. It’s fairly common for organizations to require typically-larger requested projects above some size criterion to go through a formal approval process. Such processes often involve standardized submission of information about the proposed project, and can include business cases, to guide the decision making.
A formal approval process may be carried out by the full executive group or some sub-group of it charged with approving projects. Executive-level activities usually aren’t very visible to those below, so one can’t really know whether or what deliberations led to their decisions. Nonetheless, it can be easy to presume that project initiation decisions flowing from executive levels indeed resulted from well-reasoned informed analysis about the proposed project’s relative importance to the enterprise.
Many organizations make project initiation decisions one of the responsibilities of a Steering Committee. A Steering Committee typically is a quasi-permanent body that meets regularly to guide some activity affecting several organizational units. The Steering Committee consists of members representing each affected unit. Members may be executives, but often are lower in the hierarchy. Regardless of level, members must have authority to act for their unit on matters before the Steering Committee.
The BABOK® v2 portrayal of EA simply is not accurate. Most projects are not initiated through such an explicit separate pre-project initiation process; and most don’t need an enterprise view to decide to do the project. Even for those that are, there’s no knowing the nature let alone wisdom of the thinking leading to project initiation decisions.
Many executive decisions, even at the highest levels, more often than we’d like to admit are based on something other than solid information, sound reasoning, and sensible (let alone enterprise or enlightened) criteria. Just look at the daily news for examples…
One of the advantages of Steering Committees is that they force stakeholders competing for limited resources to decide who among them gets what they want and who does without. Such enforced ownership makes such decisions workable; but their decisions are more likely based on horse trading and local concerns than on enterprise criteria.
Moreover, many if not most projects are initiated in far different ways than BABOK® v2 presumes. Those organizations with formal project approval processes, and especially financial feasibility analysis business cases, usually limit them to projects which are presumed to be large. Most projects are smaller and thus seldom subject to such scrutiny. Ironically, of course, quality problems and overruns due to inaccurate estimation commonly afflict ill-conceived smaller projects, thereby often turning them after the fact into large projects which probably would have required the formal approval procedures.
Perhaps the most common form of project initiation involves only a manager responsible for the subject area the project addresses. That manager often is below the executive level. Even when an executive is deciding whether to initiate the project, and even if a formal financial feasibility analysis is conducted, decision criteria probably are largely limited to the presumed value of the project itself, rather than within the bigger picture enterprise context. Such limited non-enterprise perspectives can be just as true for enterprise applications, such as corporate financial systems, covering all business units.
(Other Issues Regarding the Feasibility Analysis Phase)
I contend that every project has a Feasibility Analysis Phase, which does not have to include financial feasibility analysis and business cases. Few people recognize this, and it’s not in the manner BABOK® v2 suggests. The basis for my reasoning is shown more clearly in Figure 2, which depicts the relationship between the System Development Life Cycle (SDLC) in the boxes and the Project Management Life Cycle on the left.
The bulk of a system project is spent typically iteratively defining detailed requirements, designing the system, and developing and testing it. The bulk of project management effort in a project is spent directing and controlling the execution of these SDLC phases. Post-implementation, it’s common to review what went well and poorly in the project for lessons learned that can be, but too seldom are, applied on subsequent projects.
The Feasibility Analysis Phase is the SDLC phase where the Project Management Life Cycle’s initiation, planning, and organizing take place. The output of the Feasibility Analysis Phase is the project definition, including its expected deliverables, budget, and schedule. Explicit financial analysis can and should be but often is not performed. In many projects, Feasibility Analysis is simply the first phase of the project, not a separate pre-project initiation activity as BABOK® v2 assumes.
In many projects, the project definition has been completed (“cast in concrete” or “cast in stone,” your organization’s favorite verbiage may differ) before the Project Manager and project team are assigned. Not surprisingly, such dictated budgets and schedules usually are created (by executives or managers) without adequate information, usually because they’ve performed the Feasibility Analysis Phase in essentially zero time, which is why most people don’t recognize that every project has a Feasibility Analysis Phase.
Consequently, many (some would say most) projects’ Feasibility Analysis Phases invariably set budgets and schedules so low that they inevitably destine their projects to fail. The team’s frustrating and unrewarding role is to do their best to deliver the project despite its destined failure and minimize the extent of the failure. Of course, it’s the Project Manager who gets blamed for the project’s being wrong, late, and over budget.
Issues with BABOK® v2—EA View of Business Needs
BABOK® v2 says that EA is where the Business Need is defined:
The business need defines the problem that the business analyst is trying to find a solution for…. It is common for organizations to act to resolve the issue without investigating the underlying business need. The business analyst should question the assumptions and constraints that are generally buried in the statement of the issue to ensure that the correct problem is being solved and the widest possible range of alternative solutions are considered. (Section 5.1.2)
Business Goals and Objectives: Business goals and objectives usually have to be refined in order to define the business need. (Section 5.1.3) Business goals and objectives describe the ends that the organization is seeking to achieve. (Section 5.1.4)
Requirements [Stated]: Elicitation must be performed in order to assist stakehold¬ers in defining their perceived needs. Ensure that they reflect actual business require¬ments, as opposed to describing solutions. (Section 5.1.3)
Not surprisingly, I largely agree with these points, since my input helped shape some of them. However, there still are issues with how BABOK® v2 treats them. Even though BABOK® says its Knowledge Areas are not life cycle phases, they cannot help but be treated that way. Since many if not most projects don’t have explicit BABOK® v2 EA, many BAs aren’t familiar with these topics.
More importantly, such projects therefore apparently also may not have defined Business Needs or Goals. Accurately defined Business Needs and Goals are essential for project success; and few projects actually involve or need an enterprise view. Consequently, I believe it’s essential to make defining Business Needs and Goals an integral part of every project, rather than sticking it in a separate EA which is likely to be skipped.
Furthermore, I think BABOK® v2 understates the difficulty of and appropriate approach for defining Business Needs and Goals. In my experience, much more than ordinarily recognized, many projects go awry from the start because they are solving the wrong problem or not solving the right problem.
Getting the problem right is much harder and requires far more active skilled inquiry and analysis than is implied by, “assist stakehold¬ers in defining their perceived needs” and “question the assumptions and constraints.” To me, BABOK® v2 describes essentially the same largely passive BA role for EA that it depicts for Requirements Elicitation and Analysis. For further discussion, see my article, “Should BABOK Include Shorthand?”
Issues with BABOK® v2—Business Requirements
In the Introduction, BABOK® v2 defines several types of requirements, including:
- Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. They describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success. Business requirements describe needs of the organization as a whole, and not groups or stakeholders within it. They are developed and defined through enterprise analysis. (Section 1.3.3.3.1)
- Stakeholder Requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various classes of solution requirements. They are developed and defined through requirements analysis.
- Solution Requirements describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are developed and defined through requirements analysis. They are frequently divided into sub-categories, particularly when the requirements describe a software solution:
- Functional Requirements describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses.
- Non-functional Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environ¬mental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, secu-rity, availability and the information architecture and presentation of the user interface.
Except for the tie to EA, the BABOK® v2 definition of business requirements reflects widely-held conventional usage. I contend both the BABOK® v2 definition and EA tie are mistaken.
I use the term REAL business requirements to distinguish them from the conventional usage as in BABOK® v2. In my view, the business need is not the business requirements; nor is the goal or objective [to meet the business need] the business requirements. Rather, the REAL business requirements are the business deliverable whats that provide value by achieving the goal or objective of meeting the business need when those REAL business requirements deliverable whats are delivered, satisfied, met, or accomplished by some product, system, or software how.
I think it’s much more appropriate to recognize that stakeholders are the source of all REAL business requirements. “Stakeholder” is an inclusive term. All users are customers, but there can be customers who are not users. All customers are stakeholders, but there can be stakeholders who are not customers. Stakeholders can be internal or external.
I use the terms “Product Requirements,” “System Requirements,” and “Software Requirements” as synonymous ways presumably how to satisfy the REAL business requirements whats that provide value when satisfied. These seem to be what BABOK® v2 calls “solution requirements.” As such, all these terms, including “functional” and “nonfunctional” requirements or specifications, refer to high-level design. What BABOK® v2 calls “stakeholder requirements” actually are a form of “solution requirements” high-level design describing the usage (as opposed to user) requirements for an expected product, system, or software solution.
REAL business requirements are high-level, but they also must be driven down to detail. Contrary to the flawed conventional requirements model embraced by BABOK® v2, the difference between REAL business requirements and product requirements is not just a level of detail or abstraction; and high-level REAL business requirements do not decompose into detailed product requirements. No matter how far down in detail they go, REAL business requirements always are business deliverable whats that when delivered provide value. Whats do not decompose into hows. Hows are responses to whats; and hows can’t help but creep when the whats have not been defined adequately.
Moreover, REAL business requirements are not identified only in EA and do not depend on EA for their identification. Discovering REAL business requirements should be the key business analysis function in any project. As Figure 2 indicates, high-level REAL business requirements need to be discovered as part of the Feasibility Analysis Phase project initiation; and detailed REAL business requirements need to be discovered as part of the Systems Analysis (Requirements) Phase.
These concepts and related techniques are described more fully in my articles, seminars, and book, Discovering REAL Business Requirements for Software Project Success.
Issues with BABOK® v2—EA View of Solutions
BABOK® v2 says, after defining the Business Needs and Goals, EA involves:
Assess the current capabilities of the enterprise and identify the gaps that prevent it from meeting business needs and achieving desired outcomes…. if existing capabilities are inadequate, it will probably be necessary to launch a project to create that capability. (Section 5.2.2)
Enterprise Architecture: The enterprise architecture defines the current capabilities of an organization. (Section 5.2.3)
The solution approach describes the general approach that will be taken to create or acquire the new capabilities required to meet the business need. To determine the solution approach, it is necessary to identify possible approaches, determine the means by which the solution may be delivered (including the methodology and lifecycle to be used) and assess whether the organization is capable of implementing and effectively using a solution of that nature. (Section 5.3.2)
The solution is described in terms of the major features and functions that are to be included, and the interactions that the solution will have with people and systems outside of its scope. State in-scope and out-of-scope components of the solution. Describe the business units that will be involved, business processes to be improved or redesigned, process owners, and IT systems and other technology that will likely be affected. (Section 5.4.4)
These points also represent responses to my input and I believe are marked improvements over prior BABOK® versions, including earlier drafts of v2. Nonetheless, I still have issues with how BABOK® v2 treats them.
At first blush, it could be easy to be misled into thinking what BABOK® v2 calls a “Solution” is the same as my REAL business requirements. It’s not.
Closer reading reveals that BABOK® v2 Solutions actually are describing a combination of implementable products, systems, or software along with project management tasks, resources, and other considerations affecting their implementation.
Such Solutions in fact are high-level design presumed ways how to satisfy the REAL business requirements whats that provide value when met; except BABOK® v2 doesn’t define REAL business requirements. Instead, BABOK® v2 describes a process which jumps prematurely to focusing on a way how to satisfy an undefined what. That’s a major cause of creep and destines too many project initiations to failure!
In Part 2 of this article, Robin suggests some alternatives and resolutions to the BABOK® v2 issues; and he offers more appropriate ideas on What the Heck Enterprise Analysis Is.
Author: Robin F. Goldsmith, JD is President of Needham, MA consultancy Go Pro Management, Inc. He works directly with and trains business and systems professionals in requirements, quality and testing, metrics, ROI, and project and process management. IIBA BABOK® subject expert and reviewer, participant in developing the IIBA Handbook of Enterprise Business Analysis, and TechTarget SearchSoftwareQuality.com testing and requirements subject expert, he is the author of the Proactive Testing™ and REAL RIO™ methodologies and the Artech House book, Discovering REAL Business Requirements for Software Project Success. [email protected] www.gopromanagement.com www.ProveIT.net