What the Heck Is Enterprise Analysis Part 1


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.


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
  • Stakeholder Requirements are statements of the needs of a particular stake­holder 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 busi­ness 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 howsHows 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 in­cluded, 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


Like this article:
  16 members liked this article


Dave Schrenk CBAP posted on Tuesday, October 12, 2010 8:46 AM
Without going on a long-winded rant, I will say that I disagree with some of the items in your article. Specifically, I do not think it is the IIBA's responsibility to write a BOK that documents how things DO work as you suggest (nobody would ever be able to document all of them anyway) ... it is to write how things SHOULD work. The BABOK's take on EA is on the money and is pretty near spot on with how things work in my organization.

There's more but I'll stop before I get carried away.
zarfman posted on Tuesday, October 12, 2010 5:01 PM

Greetings dschrenk:

You wrote: I do not think it is the IIBA's responsibility to write a BOK that documents how things DO work as you suggest (nobody would ever be able to document all of them anyway) ... it is to write how things SHOULD work.

Zarfman writes: My field is finance and accounting. The IRS, SEC, Financial Accounting Standards Board (FASB), etc. Tell us by law how things should work and then these agencies and auditors then check up on us to find out how things do work in actual practice. Accordingly, the IIBA or BOK have no standing legal or otherwise in the field of finance and accounting.


Robin Goldsmith posted on Sunday, October 17, 2010 9:35 AM
Thank you for your comments. The article is not about what the IIBA's responsibility is. Nor is it about finance and accounting, or legal standing.

The article describes how the current IIBA BABOK v2 uses the term 'Enterprise Analysis' (EA) and discusses issues with said usage. I agree the purpose of a BOK is to document how things SHOULD work, which in many instances includes how things DO work that are effective. A big weakness of BOKs in general is that they can impede recognition of superior practices by institutionalizing commonly-used practices which are not necessarily as effective as presumed or desired.

Some organizations do use the practices BABOK v2 describes as EA. Far fewer of the organizations using said practices refer to them as EA. Many organizations use practices different from what BABOK v2 describes for purposes similar to BABOK v2's EA; and many of those organizations do not refer to those practices as EA,

My two-part article says that what BABOK v2 calls EA not only is not EA but also is ill-conceived because it grossly misunderstands the role and nature of REAL business requirements. I'm in accord with dschrenk's concern that a BOK should document how things SHOULD work, not merely how things DO work, even if that happens to be how they currently DO work in one's own organization.
zarfman posted on Monday, October 18, 2010 5:37 PM

Apparently, I don’t understand the comments and posts’ regarding your paper on what the heck is enterprise analysis very well.

As I understand it BABOK is a body of knowledge regarding the practice of business analysis. Correct me if I’ve gone astray here.

Let us consider the Standard Industrial Classification (SIC) and North American Industrial Classification System (NAICS) codes. These codes identify a firm's primary business activity. For example a firm with SIC 571 primarily sells retail furniture. A firm with NAICS 311 is primarily engaged in food manufacturing.

Moreover, NAICS includes 1,170 industries and SIC includes 1,004 industries. There are 358 new industries recognized in NAICS, 250 of which are services producing industries.

I suspect that perhaps some or most of these industries have their own unique body of knowledge. I don’t understand how the IIABA and its BABOK can be relevant to over a thousand different industries.

I am further confounded by the concept that one not skilled in specific science or art can analyze that specific science or art in any meaningful way. I would expect the analyst to have some sort of relevant skill set.

Perhaps things should be flipped around so that one skilled in the art or science is in fact the analyst. Who knows.


Robin Goldsmith posted on Thursday, October 21, 2010 9:44 AM
Hi Zarfman,

Thank you for your comment. I don’t understand your point. My article is neither advocating nor objecting to the rationale for BABOK. BABOK indeed is a body of knowledge regarding the practice of business analysis. Business analysis is an activity that can be and is applied in many different industries. Certain business analysis techniques may be more relevant to particular industries or organizations, but in general business analysis concepts and techniques are determined by business analysis rather than by the particular situation in which it is applied. That’s no different from any other discipline, whether it’s medicine, law, accounting, or whatever. People go to the Modern Analyst website because they understand and identify with business analysis as a discipline that applies to many industries and organizations.
zarfman posted on Thursday, October 21, 2010 10:43 PM

If I understand you correctly you are not for or against the idea of BABOK as a body of knowledge for BA’s. I don’t have any problem with that either, however, you don’t seem very happy with some of assumptions made relative to EA and perhaps BA methodology. I will say that after reading some of your other posts I tend to agree with much of what you have to say.

After two years of reading the modern business analyst I find most of posts promulgate various generalized BA techniques. Unfortunately in my experience, difficulties tend arise when one attempts to apply generalized techniques to specific business problems i.e. the generalized technique breaks down.

I would contend that the Achilles heel of BA is elicitation of requirements. If I remember you CV correctly you have a law degree and are licensed to practice law. Even though I’ve had a few courses in business law, I am in no way qualified to act as my own attorney in a law suit. As a CFO I contend that in business there are areas sufficiently complex that most if not all BA’s are not qualified to make an analysis.

I don’t know if this helps of not, if not I’ll try again.


Robin Goldsmith posted on Sunday, October 24, 2010 8:59 AM
Hi Zarfman,

Thank you for your additional comments. I do believe bodies of knowledge in general, and BABOK specifically, along with related certifications provide value and serve useful purposes. That doesn’t mean I blindly accept everything they say. I am a BABOK subject expert and reviewer; and I believe it’s improving with each new version but still has plenty of room for more improvement, especially regarding Enterprise Analysis and the REAL business requirements concepts I describe in my book, other writings, speaking, training, and consulting.

In my experience, relevant generalized techniques very much do apply to specific business problems. Even in specialized areas of law, one applies the fundamental techniques. The Commonwealth of Massachusetts says my general training qualified me to take the bar exam, and with my passing grade thereby qualifies me to represent anyone for anything in its courts. For given situations, other attorneys are better qualified than I. There’s an old saying that an attorney who represents himself has a fool for a client.

When done appropriately, business analysis is mainly about inquiring and analyzing to understand the REAL business problems, their measures, value, and causes in order to identify REAL business requirements deliverable _whats_ that when delivered provide value by contributing to solving the problem. Business analysis doesn't rely on the business analyst initially being the subject expert but rather on developing sufficient knowledge and understanding of the subject. I believe BABOK needs to give greater attention to the business analyst’s active discovery and analysis.

zarfman posted on Sunday, October 24, 2010 8:35 PM

I totally agree with your comment that BABOK needs to give greater attention to the business analyst’s active discovery and analysis.

Perhaps I have a different philosophy regarding BA. One of my requirements before accepting any position as CFO, VP of fiancé and accounting is that IT must report directly to me. Most seemed very happy to agree to this.

I require IT to teach my accountants etc. the basics of screen and report design, how to write a simple program, and what is a data base.

Conversely, I had my accountants teach IT a basic overview of what finance and accounting involve e.g. GL, AP, AR etc.

The same cross pollination concept at times has involved engineering, sales, etc.

This has worked very well in that both groups now have a better appreciation of what the other does, perhaps why and often what seems to be simple request can actually be very complex problem. Moreover, they have a better understanding each others terminology. Consequently, projects move more smoothly and the end product is significantly better.

By the way, does the commonwealth of Massachusetts require that one must graduate from an accredited law school before they can sit for the bar exam?


Robin Goldsmith posted on Monday, October 25, 2010 6:51 AM
Hi Zarfman,

Thank you for your comments. I fully agree on the importance of cross-training but don’t think one can assume it happens in most organizations.

Issues of who reports to whom are more problematic. Historically, IT reported to the CFO, usually because financial applications were the first to be computerized. Certainly the IT industry has pushed for its own CIO seat at the executive table, which reflects not only greater power/pay but also legitimate broader organizational impact and subject area specialization, which are less likely to be satisfied by being subsidiary to the CFO.

Business analysis also historically was within IT, probably called something different, such as systems analysis. Recognizing that the BA skills related more to the business than to IT, many organizations moved BA to the respective business areas. Yours is the first organization I’ve heard of that positions BA for everyone within the CFO’s control; and I’d encourage you to rethink it. Being scattered throughout the organization can diminish focus on BA itself. The growth of BABOK and its CBAP certification in part reflect BAs’ desire for greater recognition, status, and career development.

Yes, I graduated from an accredited law school. I think the Commonwealth no longer recognizes Lincoln-like apprenticeships as also qualifying one to take the bar exam.
zarfman posted on Tuesday, October 26, 2010 9:56 PM


I suspect we have reached the point where we agree to disagree, or not.

Many of my biases (I have several) rise from my educational and work history. My undergraduate majors are physics, mathematics and some additional courses in electrical engineering. In science and engineering the analyst is both the subject matter expert and the analyst. Fortunately, in many cases we can communicate thru a common language, mathematics.

In the fields of science, engineering, medicine and law there are many subspecialties. I don’t see the same thing in business analysis. It may be that subspecialties exist in BA and I don’t recognize them. I don’t feel that agile, scrum, etc. are subspecialties.

I won’t bore you with the details of how I ended up as a CFO. However, I carry forward the bias and expectation that the subject matter expert should conduct the analysis and produce the requirements.

Accordingly, we don’t have any BA’s per se, just subject matter experts who know (thru training) how to generate requirements that IT can understand. The subject matter expert, the project manager and IT all interact/communicate with each other over time. This didn’t happen over night, depending upon the corporate culture it can take one to two years. Moreover, we do have a project prioritizing mechanism which includes a cost analysis.

Looking forward to part 2 of your paper.


Robin Goldsmith posted on Wednesday, October 27, 2010 5:50 AM
Hi Zarfman,

Thank you for your comments. Subject matter expertise is indeed essential, but not sufficient, for discovering requirements. Effective requirements discovery depends upon combining subject matter expertise with the analytic skills and objectivity which subject matter experts are unlikely to have because of their very expertise doing whatever they do however they currently do it. People are not good at seeing themselves and what they are familiar with from other, perhaps more objective perspectives, which is needed to reveal the weaknesses which are an important part of discovering requirements for improvement.

Effective analysts start with discovering REAL, business requirements deliverable _whats_ that provide value when delivered. IT indeed should be able to understand REAL business requirements, but IT doesn’t develop systems and software from them. Rather, IT develops from designs, starting with product/system/software requirements which actually are high-level design of a presumed way to accomplish the REAL business requirements.

Unfortunately, most business analysts and non-analysts fail to recognize this and focus only on defining product requirements. Creep occurs when the product requirements fail to satisfy the REAL business requirements, usually because the REAL business requirements have not been defined adequately, in turn usually because people think the product requirements are _the_ requirements. These inadequacies don’t get overcome merely by assuming subject matter experts will know better.
zarfman posted on Monday, November 1, 2010 6:16 PM

In my mind if a subject matter expert doesn’t have the necessary and sufficient analytical skills to analyse a specific subject matter area, then that person is not subject matter expert. In fact I would contend that the media used the term expert so often that it has almost become almost meaningless.

Objectivity, how does one recognize it when one see’s it and who is the final arbiter?

Value is an interesting concept. I see monetary value and intrinsic value as non intersecting sets. Both of which are vulnerable to lack of objectivity.

Product requirements vis-à-vis _the_ requirements, do they ever interest? If so when?

I don’t expect IT to understand business requirements. All I expect from IT is for them to instruct the computer hardware, operating system and application software to do our bidding and do it correctly.

The term CIO never made sense to me. I would suggest that in many economic entities there exists information that the CIO is never made privy to.

Regarding your comments about BABOK I’m left with the impression that it is a work in progress that is still in its infancy. BABOK seems discuss what to do not very much of how to accomplish the what. It’s like telling a boxer not to get hit so much, easy for his corner to say, hard for the boxer to do.



Dave Schrenk CBAP posted on Tuesday, November 2, 2010 7:35 AM
Yes, the BABOK is in its infancy. But, it does provide methods, techniques, tips, tools, etc. for how to accomplish a task.

I agree with your point that IT should not be expected to understand business requirements. But, a business analyst, whether reporting to the business or IT, should be expected to understand them. When it is determined that a technology solution is needed for the business to build on a strength, reduce the impact of a weakness, take advantage of an opportunity, or mitigate a threat, the user, functional, and non-functional requirements that a BA elicits, documents, analyzes, validates, and manages for the IT project MUST support the REAL business requirements in order to make the effort successful. That is why BAs are often considered the bridge between business and IT.
zarfman posted on Wednesday, November 3, 2010 9:03 PM


Product requirements vis-à-vis _the_ requirements, do they ever interest? If so when?

The above statement should be corrected to read;

Product requirements vis-à-vis _the_ requirements, do they ever intersect? If so when?


Robin Goldsmith posted on Tuesday, November 16, 2010 3:38 PM
Subject matter expertise in no way is equivalent to analytical skills and is likely to be completely counter to objectivity regarding the subject matter which analysis needs. SMEs have gained their expertise through experience and reinforcement with a particular view/skill set. It’s unlikely they will be able to see the issues in what they are so invested in.

All value must be quantified in money. It’s a widely-held but nonetheless deceptive illusion to think ‘intrinsic’ value exists somehow separately from monetary value; and the illusion is perpetrated because it’s easier than quantifying and provides the perfect out to always justify the course of action one prefers. The value of something that seems unquantifiable is what one is willing to pay for it.

REAL, business requirements provide value when met. Everyone in the organization should be able to understand the REAL business requirements when defined; but discovering them is very difficult and not what most developers, business people, or even trained/experienced business analysts know to do or how to do. In my view, discovering the REAL business requirements is the necessary first step of any project or project initiation; and business analysts need to know to do it and how to do it effectively. BABOK v2 misses this entirely.

Product requirements are a response to REAL business requirements and often include considerable copy-and-paste overlap; but the overlap is only appropriate when starting with the REAL business requirements. Skipping them and going directly to the product and its requirements is what causes most creep.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC