The Evolution of Business Requirements

Current Reality

In the 21st century, businesses depend on information technology more than ever. The good news is that they have a wealth of whiz-bang technologies available from which to choose. The bad news is that they have a wealth of whiz-bang technologies available from which to choose. (This is a prime example of my pet philosophy, to wit: every solution creates its own set of problems.) The basic problem is that in order to select which whiz-bang technology is right for you, you have to first know what you want. The time it takes you to figure out what you want is often deemphasized in an effort to “save time”.  Time and again, the time saved by skipping that activity usually leads to expensive rework - or customer rejection once the system is delivered.

This problem is not new. Presumably, the folks who built the pyramids for the Pharaohs needed to gather the requirements from their bosses before they started construction. They probably faced the same challenges then as the modern business analyst faces today when trying to gather the requirements – their Subject Matter Expert (aka: the Pharaoh) was way too busy planning wars, passing judgments, and amassing slaves to give the aspiring pyramid architect the time of day. OK, maybe your SME is not busy with exactly the same kind of activities, but you get the general picture.
The fundamental problem has not changed. Oh, sure, what we are creating has changed dramatically. We no longer have to carve mega-ton blocks of stone from mountains, transport them miles and miles across desert landscapes, float them down the Nile, and then lug them up the steep slope of the evolving burial shrine. The process of figuring out what we should build: how big, what layout, what features, etc. has, however, not changed since the time of the Pharaohs.

Problems and Solutions

The cause of the problem is simple. There are two groups of people involved:

• Those who need things but do not know exactly what they need – or if they do know what, they don’t know how to ask for it; and
• Those who build or have things – and are busy trying to convince the world that their things are exactly what the other people need;

and these two groups do not speak the same language. (Actually, we could refer you back to the Tower of Babel, which presumably predates the pyramid projects and was a lot bigger. It might even be the root cause of the problem.)
Given that the problem is a language barrier, there are only a couple of possible solutions:

• Enable those who want the technology to express their “needs” in a way that the builders and buyers understand those needs at a level of detail that makes sense to these selfsame builders and buyers.
• Teach the builders and buyers how to instantly learn the myriad of languages spoken by the business community (with all of their adjunct dialects and derivations).
• Teach those who know how to create the technology to build technology that fits everyone’s needs, regardless what those needs might be.
• Find a in a translator who understands each language, can talk to both parties, and facilitate the communication between them.

Problems with Solutions

Unfortunately, each of these “tried and truly not perfect” solutions introduces different challenges (another sterling example of my pet philosophy, quoted above).

Solution 1 requires people who have no interest and possibly little techno-how to start to think in what for them constitute really bizarre ways. If you doubt this, try getting a sales person to review a domain model without selling themselves on the idea that it is too complicated to understand. Good luck.

Solution 2 creates the inverse situation, meaning you are actually trying to teach a geek like me (aka: developer) to think like a business person (“That’s illogical, Captain Kirk!”). We tried that in the 60’s and all it got us was the 70’s. Do not go there again.

Solution 3 actually works well for ubiquitous products such as word processors or spreadsheet programs. It does not work well for products that are unique to the individual, or to an organization. If you are defining requirements for the first scenario, have at it. Otherwise, hands off.

The last presented solution is arguably the favorite of organizations such as the IIBA (International Institute of Business Analysts). Matter of fact, it is their rallying cry. Unfortunately, it means helping subject matter experts focus on describing the outcomes they want without getting hung up on the details of how to get it. It also means teaching those who deliver the technology to understand the needs of the business community (aka: “business requirements”) and to translate business requirements into technology solutions.

The Ultimate Consequence

That means, there is a whole lot of teaching going on. If, however, we attempt to teach both sides the finer art of gathering, defining, analyzing, clarifying, confirming, and completing the business requirements, we are basically forcing them to change their jobs — everyone would have to become a “business analyst”. Many SMEs and developers resist this as they consider their “real job” (Pharaoh, accountant, developer, whatever) to be a full-time activity and something they might even enjoy. A word to the wise: not everyone gets excited about a forced career change. In the end (as it was in the beginning), we still have not cracked the code for getting good requirements without involving those with the “needs”, those with the “knows”, and those with the means to deliver. That means, our success depends on everyone’s willingness to share with us the one ubiquitous commodity that we all have in equal measure –precious time. Without it, we are reduced to guessing, gauging, and groping at straws in the hopes of figuring something that someone might actually use at some time. On the other hand, at least the pyramids are still standing – maybe they solved the problem way back then. At least when they put their solution into production (i.e., entombed the mummified Pharaoh), they did not have to worry about change requests. I wonder what ever happened to that Tower of Babel thing.

Editor's Note: re: The Evolution of Tools

This article was a less-than-serious view of the art and science of business analysis from the time of ancient Egypt to today. In all seriousness, we realize that there are a lot of you folks out there trying your best to get your requirements defined — often without the appropriate tools or training. In the next article, we will take a (at least semi-) serious look at one tool in particular which has impressed us. The name of the tool is Requirements Center and you can read all about it on the Blueprint website. You might also notice in the column on the left of this Noiseletter that we are co-sponsoring a webinar with Blueprint. You can register for this free webcast by clicking on the link provided there. In the interest of full disclosure, we are working closely with Blueprint as a strategic partner to provide training in their tool. We are that impressed with the tool.

Tom Hathaway and Dan Myers
Managing Partners

Future Feature: "The Evolution of Tools for Business Analysts"