Three Umpires

How do you decide when to call it a requirement?

Three baseball umpires were interviewed about how they decided whether to call pitches balls or strikes. Each talked about his positioning behind the catchers, where he focused, and myriad small technical details. Finally, the interviewer asked each of them how he really decided.

The first umpire said, “When it really comes down to it, I call ’em as I see ’em.” The second umpire said, “Maybe I’m a little less humble, and maybe my eyesight’s just a little better, but I call ’em as they are.” The third umpire smiled. “They ain’t anything till I call ’em.”

What exactly does this have to do with software development? Over the past few months we’ve been doing a lot of talking, listening, thinking, and writing about more effective ways to approach requirements development. But we haven’t addressed what is perhaps the most important facet of the process: how companies structure their requirements development gathering. And the umpires are very important to understanding these issues.

The best documented approach to modern software development is the one popularized by Microsoft’s Office team. Our two favorite books on the subject are Jim McCarthy’s Dynamics of Software Development (Microsoft Press, 1995) and Microsoft Secrets by Michael Cusumano and Richard Selby (Simon & Schuster, 1995). This process describes a group, headed by a general manager, with five subgroups: one each for product management, program management, development, quality assurance, and user education. The overall approach is outside this article’s scope; here we will focus only on certain organizational aspects of the requirements process.

This approach divides requirements development into several pieces. The product management team must figure out what the customers and prospects want the software to do. Program management figures out what implementing the required features means to the full software project, from specifications through schedule. The development team must figure out how to implement the features and what it will actually take to get the software done. QA decides how to test the features, and user education plans and describes the user interface and customer documentation. Release planning in this context boils down to a trade-off among features, resources, and dates. In reality, it’s just a features issue. In Microsoft’s model, the date is fixed (only to slip later) and the size of a development team changes only very slowly. So you have a given date and a given resource level, which means the only real debate is over which features make it into a release.

“Figuring out what the customers want” has a very specific meaning in this context: The metric is the number of additional units to be sold or lost based on each feature’s inclusion. This metric, in combination with the estimated development time and cost as well as the impact on the development schedule, makes prioritization more objective than arguing over what features are important.

This approach to the division of labor certainly doesn’t solve all the problems. Product managers overestimate their favorite features’ effect, and development time estimates are definitely colored by the development team’s eagerness to take on or avoid a particular feature. But the objectivity of the estimation process does resolve the “squishiness” over time: Product management estimates can be loosely compared to sales and more tightly to good market research, and development estimates can be checked against the actual development costs. So much of the ongoing ambiguity surrounding requirements development can be, and typically is, resolved over time. It’s still far from a scientific process, but at least it can be an engineered one.

One of the hallmarks of this approach to requirements development in particular, and to software development in general, is the final release prioritization process. As the team nears a fixed or at least highly targeted ship date, the feature set for the release is frozen and features are removed from the release. As Chris Peters, one of the prime forces behind Windows and the Office products, was fond of reminding his teams, “Shipping is a feature.”

What makes this process work is that the third umpire is in charge. What differentiates spreadsheets and word processors from ERP systems and brokerage systems is that the inclusion of a feature in a spreadsheet defines the spreadsheet, not the other way around. A minimum set of features is necessary, but many are optional. To paraphrase Hebrew National Franks, while Excel may be defined as the set of features in Excel, Schwab’s trading engine “answers to a higher authority.”

For that reason, and for a host of related ones, this approach doesn’t work for corporate development. Of course, the typical corporate development approach, characterized by the first umpire — I call ’em as I see ’em — doesn’t really work much better.

In the more familiar corporate development organization, requirements definition is carried out by a team of business analysts working for a project manager. The project manager is typically responsible for “the IT side” of the project, and the IT team is usually paired with a team responsible for “the business side” of the project. We’ve written before about the difficulties involved in this artificial division and the ways most companies exacerbate an already difficult situation. Here the problem is easier to understand, although the understanding doesn’t really help solve the problem.

The “business people” are responsible for explaining to the “IT people” what the system needs to do, and the IT people are responsible for recording the information and making sure that it is logically complete and consistent. The “making sure” consists of searching for internal gaps in the information they receive and asking the business people to sign off on the requirements. The IT team is acting like the first umpire — taking things at face value — as the members have been told the system works. Unfortunately, the business users typically aren’t trained to read technical documentation, let alone to do engineering-level explication. So basically no one is responsible for making sure that the system actually does anything useful, and in the somewhat rare circumstances where it does, it usually simply faithfully replicates the current environment. At considerable expense.

What’s needed is the middle approach: Call ’em as they are. In the corporate software environment, calling them as they are requires breaking the problem in two: the fundamental, underlying business problem — what we call the “abstract business process” — and the company-specific implementation, which we call the “business process model.”

An abstract business process (ABP), as we define it, is the unambiguously defined fundamental business process definition; the “what” without the “how.” An ABP is common across an industry, and is neither negotiable nor debatable. The model must be a mathematical or engineering representation of the problem and is not usually something derived from conversations with users, but rather is typically documented in something such as a textbook. Fundamentally, the model should be extensible in any manner consistent with the underlying problem. Most important, from a requirements standpoint, the ABP and the software that manifests it can, and should, be implemented without involving the user significantly — except to have the business experts explain difficult or arcane concepts to the development team.

In this way, we build systems with a fundamentally sound understanding of the business process, and we educate the engineering staff in the key underlying constructs of the business. This is how ERP systems are built; the underlying system implements the abstract business process, and the company-specific customizations are then layered on top of it. This model is the second umpire’s “as they are.”

The ABP can be built in a manner similar to the Microsoft model because the required system functionality can be objectively defined. Before interviewing customers about potential sales, the product management team can reverse-engineer the current product portfolio to understand the required feature set to support current operations. This defines the minimum functionality in a first release. Because this functionality is fixed, corporations must work the trade-off between resource levels and timeframes. In our experience, team sizes change slowly over time in this environment as well, so the “flexible” dimension is frequently time in first releases. In subsequent releases, this situation flips; timeframes can be set and feature sets negotiated.

The business process model, which will be implemented as layered on top of the abstract model, describes how the company would like to operate. Developing the business process model is highly dependent on the nontechnical “business user,” as the choices involved in the business process model are, from an engineering standpoint, arbitrary. It is a useful exercise to describe the current business practices as a business process model on top of the abstract business processes to verify that the abstract model does capture sufficient detail to support business operations. Most of the value in implementing a new system comes from defining a reengineered product or workflow in the new software. Creating this definition requires that the user team be skilled in business process reengineering, which is why we refer to this model as a “BPR.”

In our experience, approaching the problem in this way offers the best chance of success because it separates the engineering process from the business design process as long as practical, reduces the scope of early deliverables, and forces the technical team (or at least a good portion of it) to learn the fundamental business.

Back to baseball.