What We Have Here Is a Failure to Communicate

Successful business requirement development hinges on one thing: good communication

In our last two columns (“Dirty Little Secrets,” May 11, and “More Dirty Secrets,” June 1), we wrote about a number of the common threads underlying unsuccessful systems development in general, and unsuccessful business requirements development in particular. Writing about the problems is the easy part; the hard part is trying to prescribe solutions. In this column, we’ll run through our observations on what does work — or at least what we’ve seen work consistently — in the requirements development process.

Business requirement development is a formal, proactive communications process. When we fail to produce adequate business requirements, we are having a communications failure. In our experience, there are three core elements required to accomplish business requirements for a large systems project. The elements of this approach are pretty straightforward, given our definition: You need a workable formalism, you need to be proactive, and you need to assure high-quality communication. Let’s consider these in turn.

Formality

One good way to understand a process is to “black box” it and examine its inputs and outputs. If we apply this technique to business requirements, we note that the inputs are a lot of conversations, and the output is a lot of paper. First, we’ll focus on the paper. Most business requirement methodologies are paper intensive; certainly all the capital “M” Methodologies are. “Passes the weight test” is one of our least favorite comments on a completed set of business requirements. Weight is a formalism, albeit a pretty bad one; at best, it’s the requirements equivalent of lines of code.

The goal of the requirements documentation is, or should be, to produce the minimal set of documents required to completely express the full problem to be solved in a known manner. There are three operative words in this statement — “minimal,” “completely,” and “known.” You must read business requirements, which is hard — a lot harder than writing them. Brevity helps improve readability. In our experience, the audience must be able to read or present a good business requirements document in a single sitting of about four hours; less, for an audience familiar with the subject. Keep in mind that brevity is good, but it isn’t a trade-off for completeness. If the material is more copious than can be handled in one session, and it usually is, you will need to abstract it and break it up in a way that permits a full understanding to be expressed with details deferred. Such a task is a difficult one, but it is required because it shifts the onus of understanding the problem from the reader to the writer. This shift is also an entirely reasonable thing to expect; after all, if you can’t do a good job explaining what you’re going to build, you’re probably not going to do a very good job building it.

The structure must also follow a process that the organization knows will yield successful results, or at least has yielded them in the past. An architect friend of ours once commented that it’s hard enough building complex systems with an approach he knows works, much less proceeding in an unproven manner he was less convinced would work. The requirements form should follow an effective, proof-oriented, decomposition approach. This approach requires a proof of completeness for both the decomposition approach and the detailed requirements. Our favorite of these approaches is a combination of a good, object-oriented methodology with a complementary technique, called “pyramiding,” that Barbara Minto describes in her book, The Pyramid Principal (Minto International Inc., 1987).

Pyramiding is a process of successive decomposition based on a mutually exclusive and collectively exhaustive (MECE) set of plural nouns. This process breaks up a problem space in terms of its nouns (what it is) until a full set of the nouns is described, and then details the verbs (what the nouns do). The object-oriented folks will be comfortable with this approach because it’s another way of describing encapsulation and aggregation, and encapsulation is the key to communicating and verifying business requirements.

This noun-based decomposition has proved substantially more effective than earlier verb-based approaches, largely because it seems more consistent with the way that people think about problems and is thus a lot easier to accomplish. This is especially true in the requirements arena, where the audience is highly unlikely to be comfortable with formalisms and engineering principles. (We once had a work group devolve into giggles at the use of the word “disambiguate.”)

A noun-based approach should not be confused with a data modeling-driven approach. Although data modeling is a formalism, getting the business users into a room and doing a data model is the third-worst approach to business requirements we know, and a surefire guarantee for a failed project. That doesn’t mean we don’t believe in data modeling; but we believe that it is a design construct, not an analysis construct.

A quick disclaimer: Our focus on formalisms has led some people to mistakenly believe that we think business requirements need to be completed up front. We don’t. We believe that you need to complete enough of the business requirements at the outset to accurately understand and communicate what you are going to build, but that a well-done requirements process will be iterative. This is another reason why encapsulation and successive decomposition are so important to the process.

Be Proactive

We once heard business requirements development described as going into a room with a bunch of customers, asking them what they want, and writing down what they say. We can think of situations where this might work, but it’s not reliable; furthermore, it’s probably the root cause of more systems failures than any other single approach. It is, in our experience, the second worst way to do business requirements.

Proactivity requires that the technical team take responsibility for making the communication happen. This means that the team responsible for the ultimate success of the project must be responsible for, and actually do, the business requirements. The role model for this is what Procter & Gamble call the “product manager”: a person responsible for the deliverable but without authority over the resources required for getting the job done. At P&G, the product managers are responsible for products, but they don’t control marketing, sales, manufacturing, or distribution resources. Instead, they must find a way to make those who participate in the product responsible for the resources they need. The software development responsibility is similar to the consumer goods job. By making a product manager responsible for the requirements definition, we eliminate the ambiguity about who’s responsible.

Amateurs Talk, Experts Communicate

Napoleon Bonaparte was, as the story goes, asked how he assigned recruits in his army. He offered that he divided the recruits along two dimensions, intelligence and aggressiveness. “I take the stupid, lazy recruits and make them the foot soldiers. They will do as they are told and no more. The smart, lazy soldiers I make the colonels and generals. They stay in the back of the lines and discuss what the army should do, but stay out of the way. The smart, aggressive soldiers I make the lieutenants and captains. They command the front line troops, make quick decisions, and have the courage to carry them through.”

“And what of the stupid, aggressive soldiers?”

“Ah. I have them shot.”

When you talk to key business users in failed systems efforts, they invariably suggest that the systems people didn’t understand what they were saying, or that the IT people just didn’t understand the business. The two causes for this result are nonproactive behavior and lack of intelligence and expertise in the subject matter. Developing business requirements absolutely requires that the technical team understand the subject matter well. To do this, the product manager or team needs to develop an understanding of the business basics, as well as a conceptual, abstract understanding of the problem to be solved. Communication requires a common language, and that language has to be the language of the business.

Developing the basic business expertise should be straightforward; it requires a thorough understanding of the existing processes, data, and systems functions. The team needs to develop this understanding before undertaking any meaningful conversations on requirements details. It’s a lot of grunt work, but it’s the job. A good project manager should understand the limitations of the current environment before expecting to earn credibility with the key users.

Clearly, business users will understand the details and nuances of the business as it is currently conducted, but more is needed. Let’s face it, if our systems supported doing business the way we wanted, we wouldn’t be building new ones. Business requirements development is as much business process reengineering effort as it is a gathering of current processes and procedures. In fact, it helps if the requirements team understands the subject matter better than the users on an abstract level. Achieving this understanding requires raw intelligence, specialized training, and wide experience. (It’s often a good place for some strategically placed consulting help.)

But there’s a “gotcha” here as well: The members of the technical team may think they understand what the business needs more than the business people do, but if they are right, they are unusual. And if they are wrong, making that mistake is the worst way to do business requirements.

Doing requirements well requires a set of attitudes and work style which often differ from those frequently found in even the best corporate IT groups. But that’s a different topic.

  John Trustman is a principal of Delta Technologies Inc., a consulting firm specializing in corporate software development with a focus on very large systems and Internet delivery. You can reach him at jwt@trustman.com.

Susan Meshako is the CIO of National Grange Mutual, an East Coast P&C Insurance Co. You can reach her at meshakos@ngmmail.msagroup.com