Skip to main content

Author: Robin Goldsmith

Differentiating Differences that Make a Difference

Perhaps you’ve noticed that a lot of people write, speak, train, and consult about Business Analysis (BA).

The number involved grows quickly when we also include those dealing with systems analysis (SA), requirements analysis (RA), requirements engineering (RE), requirements management (RM), and whatever related two-letter acronyms you no doubt could add.

For the most part, each of these probably represents different names for the same thing. Yet, presumably those claiming one term versus another think theirs is somehow different from the others—in some important way that truly makes a difference. Ironically, if indeed there are differences among these terms, they are hard to tell because there are no agreed-upon definitions that actually differentiate among them.

In fact, it gets worse. Thus, one partisan is convinced their term represents a particular characteristic; whereas someone else feels equally strongly that that characteristic represents their different term; and each is unaware of the other’s perception. Stepping back a bit should make evident how silly it all is; but of course, nobody sees folly in something dear to him/herself. It’s not limited to BA, nor is it new. Centuries ago, satirist Jonathan Swift made light of similar silliness in the classic Gulliver’s Travels.

Yet, such perceived differences actually are of great consequence to lots of people. Whether real or imagined, material or superficial, presumed differentiations often are taken very seriously and can have enormous economic and professional impacts. Consider, for example, how picking just the right terms for ads, titles, and web sites affects sales of books, training, and consulting.

Po-tay-to, Po-tah-to

Now that we say it out loud, it’s fairly easy to recognize some of the significant consequences when similar things are called by different names and when different things are called by the same names. Yet, few are aware that in the U.S. and Canada, the International Institute of Business Analysis (IIBA) and its various certifications predominate, whereas in Europe, the International Requirements Engineering Board (IREB) holds similar status. Each is convinced of their unique niche, but darned if I can see the difference. And, yes, a couple of other contenders further muddy the waters.

Where It Really Matters

In the final analysis, whether you call it RE, BA, or BS is superficial form and matters mainly to the handful of brand promoters like IREB and IIBA. However, difficulties differentiating content substance can have a much less evident, but unfortunately far greater and more insidious direct and indirect impacts.

We’re familiar with the physical science concept of inertia, wherein a body in motion tends to stay in motion and a body at rest tends to stay at rest. However, inertia also pertains to thinking. It’s very hard to overcome entrenched ideas, and institutions often create obstacles to further impede challenges to their vested ways of thinking. Establishing and defending a brand takes advantage of such inertia.

We still regularly see news reports of those in power, or seeking power, torturing and murdering people whose ideas are deemed to threaten the establishment/brand—just as they’ve done for dozens of centuries. Yet, once-heretical ideas can become mainstream, often though only after extended sacrifice by initial adopters.

While not happening to the same draconian extent in the BA community, nonetheless both conscious and unconscious forces continually curtail ideas that are counter to brands’ favored conventional BA wisdom. BA has become big business, relying largely on brands to sell products and services. Though probably not apparent to consumers, promoters quite consciously guard BA brands behind the scenes through economic, social, and legal pressures against their few generally easily-identified competitors.

[widget id=”custom_html-68″]

Unconscious Content Confusion

In contrast, content confusion directly affects a somewhat larger but still small group of BA authors and trainers like me. More importantly, though, content confusion can indirectly affect the full BA community by suppressing innovation and awareness of different and potentially better ideas. Content confusion is especially prevalent because it’s seldom recognized or conscious.

Stories of intrigue often advise “following the money.” In BA, money mainly comes from training, consulting, and publishing. Overwhelmingly, buyers choose which BA products and services to buy based on brief titles and descriptions. Not surprisingly, most BA courses and books have similar names. A search for a particular BA topic keyword on Google or even a training vendor’s website implies all displayed courses/books have comparable content.

Indeed, many BA products’ content essentially is interchangeable. Sometimes that’s intended, such as for courses/books to prepare one to pass a particular certification exam. More often it’s unintended, typically occurring because most authors/trainers simply repeat what they’ve learned from other authors/trainers. That’s not my content.

Better-known authors join to institutionalize their repeated content in various BA brands’ bodies of knowledge. Consequently, I find competing brands’ content virtually indistinguishable except for stylistic variations and a few consciously coined signature terms. Most brands avoid confronting competing brands directly, I’d say somewhat cynically because they can’t convincingly describe let alone set apart their differences.

Different authors/trainers do vary in how they present their common content, which presumably makes one product more interesting or informative than others. Over time, popularity and search engine rank should reflect superior products. However, inertia and promotion also affect product perceptions. Since few buyers look past the first page or even first item of a search, prominent item position is mainly what’s reinforced.

Moreover, titles and keywords that buyers think to look for are unlikely to reveal products that have different or innovative ideas content. Even the brief descriptions of similar-sounding products often cannot convey meaningful content differences.

Buyers sometimes rely on sales representatives to explain respective products’ pros and cons. With perhaps 1000+ titles for sale in their catalog, sales reps cannot actually be familiar with more than a few, and may not truly understand them, let alone how their content differs or why it matters. Not surprisingly, sales reps usually stick with pushing the same popular products, sometimes at the expense of possibly preferable ones.

Confusion’s Catch 22

Indeed, parts of my courses and writing are like what others also say. It would be foolish not to gain guidance from colleagues and other experts. However, mostly what’s the same is general concepts and techniques. On the other hand, my work is differentiated by key central models and methods which I developed personally over many years performing real projects of business significance for leading organizations.

Certainly, many people have project experience and maybe even have innovated; but I’ve seen few who critically understand what they’ve done and even fewer who can extend it to benefit others. Besides having a propensity for trying to figure out how and why things work, I’ve been fortunate to build perspective from encountering similar situations several times and having the occasion of creating courses to analyze and translate them into meaningful models and methods others can use to advantage.

For example, my BA work focuses on discovering what I call REAL business requirements, which are very different in ways that make important differences from the “requirements” most authors, trainers, and brands focus on.

Yet, few buyers, sales representatives, or even other BA authors/trainers recognize that my courses/writings (including also Proactive Testing™, REAL ROI™, and Beyond the Textbook™ acquisition) differ from most others, let alone understand the differences or appreciate why my materials are so much more valuable. Differences in titles and descriptions just don’t register with someone until after they’ve learned about my approaches; and they won’t learn about my approaches because the differences don’t register with them. Explanations like this are so important for building awareness.

REAL Business Requirements

Other authors, trainers, and bodies of knowledge do use the term “business requirements,” almost always to mean objectives and purposes/desired value. In contrast, REAL Business Requirements are business deliverable whats that when satisfied achieve objectives and thereby provide value. That’s a real difference.

REAL Business Requirements deliverable whats are satisfied by some product/system/software, whose product requirements/features are ways how presumably to satisfy the whats. Other authors, trainers, and bodies of knowledge focus almost entirely on product/system/software requirements hows, which do not themselves provide value.

Creep, changes to requirements after they supposedly have been settled, is a major cause of project overruns. Conventional wisdom is that creep is caused by requirements, meaning product requirements, which are not sufficiently clear or testable. Testability is largely a function of clarity.

While clarity and testability are important, much of creep occurs because the product requirements, regardless how clear and testable they are, fail to satisfy the REAL business requirements, mainly because the REAL business requirements have not been defined adequately, in turn because conventional wisdom mistakenly thinks that product requirements are THE requirements.

Thus, the key to reducing creep is first to discover the REAL business requirements deliverable whats that provide value when satisfied. Then, define the requirements/features of a product/system/software way how to satisfy the whats.

Traditional BA courses and writings don’t teach this because their authors don’t know it. When I present these ideas to a group of practicing business analysts, about half seem to have aha moments and make comments like, “Now I understand why I’ve been having requirements problems all these years.”

Ironically, many BA guru authors/trainers don’t seem able to understand the differences. Some folks would say it’s because they have a vested financial interest in the traditional model focused on product requirements that they sell. I think it’s more likely their mindsets are so firmly established that they cannot mentally accept something fundamentally different. I think that’s their loss, and more importantly also the BA community’s loss.

In addition to explanations like this to create awareness my courses do differ, I’ll more consistently include hopefully differentiating terms in course titles, such as REAL business requirements, and explain their important differences in course descriptions.

Problem Pyramid™ Prevents Prevalent Problem Statement Problems

Problem statements are a widely-used and well-regarded technique. Yet, I find many fail to achieve the benefits attributed to them.

The powerful Problem Pyramid™ overcomes problem statement shortcomings to provide expected value to projects.

Many projects use problem statements and often include them within a project charter. Defining the problem before undertaking its often-costly presumed solution is sound conventional wisdom—in theory. After all, no less a theoretician than Albert Einstein is often attributed saying to the effect that if he had only one hour to save the world, he would spend fifty-five minutes defining the problem, and only five minutes finding the solution.

Another widely-cited source of insights, Yogi Berra, said, “In theory there is no difference between theory and practice. In practice there is” (
In practice, problem statements tend to be what I call “conventional we’s dumb.” Many if not most actual problem statements not only give merely the illusion of soundness but also often outright mislead. Moreover, too often they become simply templates as substitutes for understanding.

Typical Contents

Sources seem to agree that a problem statement should state what the problem is, how bad the problem is, the value to be obtained from solving it (why), and its general expected solution (how). Frequently the why includes identifying those with the problem who need a solution. Some also emphasize the importance of quantifying the problem and/or its solution’s expected benefits (how much).

Projects often go awry when they focus on solving the wrong problem, or when they take mistaken actions because even the right problem is not adequately understood. Thus, problem statements are intended to increase chances of project success by assuring the project is solving the right, well-understood problem.

Too often, though, execution in practice falls short of those laudable purposes. An inaccurate or misleading problem statement in fact can contribute to exactly the types of project mistakes it was intended to prevent.

Actual Contents Issues

Far more than realized, problem statements describe the wrong—or at least not right—problem. Accurately defining the problem turns out to be much harder than generally assumed. Twelve people describing ostensibly the same situation often state a dozen different problems, and they still all may be wrong. What they call a problem instead could be symptoms, causes, measures, presumed solutions, or something else.

Yet, most conventional problem statements I’ve seen simply take as given whatever someone has declared to be the problem. When that someone is a higher-up, as often happens, their declaration of the problem is even less likely to be questioned.

Many problem statements I’ve seen are mainly venting, frequently piling on about how awful the problem is. Of course, the worse the problem is made to seem, the more likely a project will be initiated to achieve the proponent’s proposed solution and the less likely their proposed solution will be evaluated critically. Not surprisingly, proposed solutions almost always are intended to benefit the proponent most but frequently are ill-conceived and fail to deliver the proponent or the organization expected value.

[widget id=”custom_html-68″]

Problem Pyramid™ Overcomes these Issues

The Problem Pyramid™ is a powerful six-step systematic disciplined tool for getting right the problem, its value measures, causes, REAL business requirements deliverable whats that provide value when satisfied, and a responsive product/system/software way how to satisfy the whats.

goldsmith 052818a

The steps/boxes need to be performed in numbered sequence, for each builds on the prior steps. Moreover, we don’t proceed from one step until it passes serious scrutiny to be sure it is correct. For each step we apply a number of disciplined evaluation guidelines that give far greater confidence it’s right before going to subsequent steps that depend on it.

For instance, with conventional problem statements, the problem seldom is meaningfully evaluated or even questioned; and management oversight, if it exists at all, usually consists of pointlessly asking the problem statement’s author whether they’ve correctly identified the problem—they’ll always answer “yes.”

In contrast, the Problem Pyramid™ confirms Box 1 is a problem, Box 2 current and Box 3 goal measures accurately apply to it, and achieving the Box 3 goal measures in fact indicates the problem has been solved, opportunity has been taken, or challenge has been met, which in turn provides REAL value. When measures are not defined or don’t match the problem, the problem is usually wrong, and the measures often are too.

Box 4 causes are the as is (or current state) process producing the Box 2 current measures that tell us we have a problem. We confirm Box 4 identifies all key causes and that together they reasonably explain why we have the Box 1 problem.

Box 5 describes the should be (or future state) process top-level REAL business requirements. We confirm these are business deliverable whats that when delivered, satisfied, or met reasonably will achieve the Box 3 goal measures and thereby provide value. We also confirm the Box 5 should be whats reduce or eliminate all the key Box 4 causes so the problem won’t persist.

Box 6 describes a product, system, or software way how to satisfy the Box 5 whats. We confirm the Box 6 how in fact will reasonably satisfy the Box 5 whats and thereby provide the Box 3 value. Most projects creep and fail because they start with a presumed Box 6 product how which turns out not to satisfy the Box 5 REAL business requirements whats that provide value when met, usually because the Box 5 whats have not been defined adequately, if at all.

The Problem Pyramid™ guides accurately identifying the REAL problem and providing REAL value by reducing/eliminating its fully-identified key causes. Moreover, the Problem Pyramid™ assures ordinarily-overlooked REAL business requirements deliverable whats that provide value when satisfied in fact are identified adequately and will reasonably be satisfied by a responsive product/system/software how.

Avoid the Top Three REAL Causes of Scope Creep

Scope creep, changes to requirements after they presumably have been settled, is surely the biggest reason projects overrun budgets and schedules, yet still fail to deliver desired results.

This isn’t news. It’s been known for a long time. Lots of explanations and solutions have been offered over the same period, but scope continues to creep.

I find our scope creep dilemma is due largely to what I call “conventional we’s dumb” reflecting widespread but nonetheless mistaken understanding of scope creep’s REAL causes and the ineffective solutions which inevitably result.

For example, perhaps the most typical responses to scope creep are to blame change control procedures for not preventing changes and the project manager for “poorly managing the project.” Adding further procedural overhead mainly creates resistance, and a project manager who has been beaten up may learn how to hide things better but probably continues to have the same kinds of creep. Their supposedly better-managing successors also almost certainly suffer similar or worse creep. The blame game cycle repeats and projects persist in failing. Sound familiar?

Scope Creeps Because …

My analysis indicates that the overwhelming reason the scope creeps is that the scope was not defined correctly in the first place. Thus, the scope is not creeping, or at least not as probably presumed. Rather, what’s changing is awareness of what the scope should have been all along.

The negative impact of incorrectly-defined scope grows geometrically when the organization’s processes and procedures first fail to recognize this fundamental cause of creep, and then especially when they tend to impose all manner of counterproductive reactive behaviors, such as inquisitions to punish project managers and.often-mindless mechanical administrative restrictions on the changes they actually desperately need.

In Turn, Because …

I’ve found three main frequently-interrelated reasons why defined project scope so often is either wrong or at least not right.

1. Defined in Inappropriate Terms

Most projects I encounter have a one- or two-sentence scope statement which generally consists of objectives or desired benefits. Objectives indeed are essential for project success. In fact, success means achieving the objectives. However, scope defined in terms of objectives cannot help but creep because nobody knows what they’ll get. Each person has his idea of what will achieve the objectives, and there’s a good chance their idea doesn’t match someone else’s, but nobody recognizes it.

Alternatively, some project scope is defined in terms of tasks to be performed. Vendors who have succeeded in business use this method. Because the vendor can control the tasks they perform, defining project scope as tasks enables the vendor to be sure they can satisfy contractual commitments—regardless whether the client’s needs have been met. Ironically, if/when the client’s needs are not satisfied, it creates an opportunity for the vendor to propose follow-on work doing additional tasks which presumably will meet the client’s needs. If the vendor does the promised added tasks but still does not meet the client’s needs, round and round it can go again.

2. Defined (Often Dictated) Prematurely

I find that many projects are destined to fail because the scope is set, typically in concrete, prematurely. Scope definition is premature when it’s not based on adequate information. Many projects are initiated by executive pronouncements which too often dictate project triple constraints—scope, budget, and schedule–without sufficient understanding of what’s needed or what it will take to accomplish it. Executives tend to presume mistakenly that their position alone imbues them with the necessary knowledge. It doesn’t.

Some organizations have formal project initiation procedures to assure project decisions, in fact, are based on suitable information and reliable decision making. Such procedures usually are called “feasibility analysis” or something similar and typically include formal cost/benefit Return on Investment (ROI) financial analysis.

While these analyses can be done effectively, too often, they are all-form-and-no-content expensive window dressing that gives only the illusion of well-supported decision making. Cutting through the rigmarole frequently reveals only findings to support the result that the advocating executive wanted to dictate all along.

Organizations that consider themselves Agile may not be defining the scope explicitly at all. They may simply leave it up to the Product Owner to decide what goes into the backlog, which some may consider defining the scope. Also, Agile projects would seem highly unlikely to have formal project initiation procedures. Recognize though that these Agile actions actually may reflect informal, implicit decisions that are equally premature. Thus, the backlog may include only stories that fit the Product Owner’s possibly fuzzy impression of what is in scope; and that impression could constantly change, though perhaps without awareness or thoughtful consideration.

3. Predicated on Presumed Product

Especially, but by no means only, Agile projects generally define their project and thus its scope based on the product/system/software they expect the project to produce. That’s all well and good unless the product is not right—which happens far more frequently and to a far greater degree than ordinarily is recognized.

REAL Business Versus Product Requirements

There’s another even more important but seldom-recognized fundamental problem with focusing first on the product, and this problem is a major reason presumed products turn out to be wrong. Products do not themselves provide value.

A product provides value only to the extent that it satisfies what I call REAL Business Requirements—business deliverable whats that provide value when satisfied by some product/system/software how.

Creep largely occurs when the presumed product feature hows fail to satisfy the REAL Business Requirements whats, usually because the REAL Business Requirements whats have not been defined adequately, in turn typically because “conventional we’s dumb” mistakenly says the product features hows are the requirements.

Scope doesn’t creep nearly so much when the scope is defined as high-level REAL Business Requirements deliverable whats that provide value by achieving objectives when satisfied. Moreover, when the scope is defined in business terms everyone can understand reasonably the same, misunderstandings, miscommunications, and creep drop dramatically.

Recognize, though, following an appropriate model is only the starting point. It takes time for informed, skilled, integrated data discovery and analysis to identify the right REAL Business Requirements right. Often they are not evident or as presumed. As discovery and analysis proceed, the scope can and should adjust as understandings improve; but when done right, such adjustments will be far less and far less disruptive than conventional creep.