May 11, 1999, Volume 2 - Number 7
Dirty Little Secrets
Corporate IT has forgotten how to do business requirements, and this memory loss makes their projects risky business
Every profession has its dirty little secrets — the little truths that the profession’s practitioners really don’t want anyone outside the business to know, even though they’re pretty clear to the practitioners. Doctors don’t want you to know it’s an art, not a science. Four years of college, four years of medical school, six years of internships and residency, and it’s still not a science. We know it too, but we don’t talk about it. There’s no cure for the common cold, let alone cancer. Lawyers don’t want you focusing on the fact that the law isn’t about justice. The law is about doing the best job of arguing through the intricacies of an arcane process. It’s about having a better lawyer (which is usually about who has the most money, although there are exceptions), not about justice.
In corporate IT, our dirty little secret is this: We don’t know how to do business requirements anymore.
This is a real problem. For the doctors and the lawyers, it’s mostly about image. If you’re sick, you go to a doctor. You wish they could be a bit more certain, but hey, their guess is better than yours. With lawyers, it’s pretty much the same thing. Neither medicine nor law is intuitively obvious—that’s why we see the specialists, even if they’re not perfect. Their little secret doesn’t really hurt anything, except pride. For IT professionals, however, business requirements are at the heart of the problem. And we don’t know how to do them.
We used to know how to do them. Back when IT was about automation, we were very good at them. We watched an operation, took careful note of the inputs, outputs, and transformations, wrote them down, and voilá—business requirements. It wasn’t even the hard part.
Analyzing Risk
According to the most recent studies we’ve seen, somewhere around three-fourths of the new corporate software developed in the United States never goes into production. Why are we convinced that we can’t do business requirements anymore—or at least that we aren’t doing them very well? There are two basic reasons, one analytical and one observed. On the analytical front, most modern software development theorists offer four major types of risk in a technology project—technology, skills, political, and requirements risk.
Technology risk is straightforward. At some point in the life of every technology project, someone decides which technology to use, and the risk is that the chosen technology won’t work for the application. This is the most obvious risk to a technology project, and it is the one most organizations address the best — although we’ve seen some exceptions here as well. The best way to address technology risk is to use the same technology that you, your organization, or someone you know has verifiably used to solve a similar problem of the same scale. The second best way is to benchmark the critical components and prototype the infrastructure; this way is much more difficult.
Skills risk is a bit more interesting; it is the risk that your organization does not have the technical, project, and managerial skills to complete the project undertaken. The most obvious skill risk is that the organization doesn’t actually have the necessary skills to deliver the project in the chosen technology. This is a risk that an organization can address in a variety of ways, from the appropriate use of consultants to training and mentoring.
Alternatively, you can react to skill risk in a manner that appears to meet short-term requirements while deferring longer-term issues. In this case, the organization recognizes that it doesn’t have the appropriate skill set in the appropriate technology, so we select an inappropriate, or at least suboptimal, technology instead: for example, “We’re a Cobol shop, so we’ll probably do the application on the mainframe.” There are two problems with this approach. The first difficulty is that this course of action often trades skills risk for technology risk, moving a project from underresourced to impossible. If the appropriate technology for an application is outside an organization’s expertise, the organization must address that inadequacy, not shift it to another form of risk. The more insidious problem is that by delivering a lower-quality solution in the wrong technology we both deny the organization its opportunity to develop the required new skills and increase the hurdle for a subsequent “fix-it” release.
Political risk is exactly what it sounds like. Corporate politics can be overwhelming; they can certainly overwhelm any fledgling software-development effort. Any advice on navigating these waters is beyond the scope of this column, but suffice to say that if you’re not good at politics, get someone on your team who is.
All of this is a lot of risk. But is it enough to cause a 25 percent success rate? (Which is not very good. Doctors are in the 90s, and even lawyers score 50 percent.) We think not. The problem, we believe, is requirements.
Wrong Customer, Wrong System
On the observation front, consider a current counterexample: the Web. Major corporations’ ability to actually get their Web sites up and operating effectively is absolutely amazing. The Web and the multitudes of corporate Web sites have signaled the greatest boom in corporate development since the demise of the punch card. What’s happened? Is it true that, as our favorite systems architect jokes, “The Web means you don’t need requirements anymore?” No. Web sites come online and evolve at substantially better than the 25 percent success rate of their more traditional counterparts because their requirements are simpler and better known, and users are willing to settle for whatever can be done rather than requiring replacement-scale requirements.
So what exactly is requirements risk, what’s happened to increase it, and what can we do about it?
Requirements risk is the risk that you won’t build what the customer wants — that the actual requirements necessary to satisfy a project either won’t surface or won’t surface in time to assure successful delivery. This can sound funny (“Whoops! I guess we built the wrong system!”), but it’s deadly serious. It’s the leading cause of systems project failures. The leading causes of requirements risk are threefold: not finding the right customer, not understanding the actual requirements for success, and not establishing a realistic understanding with the customer of what will actually be accomplished and when.
Not finding the right customer may sound trivial, and it can be anything but. We once led a project to design, build, and implement a groundbreaking direct marketing system at a major financial services firm. The new system was supposed to change the direct marketing process in the company radically and reduce the cycle from four to six weeks to a few days. The user requirements were gathered directly from the marketers — the product managers and customer segment managers. There was little focus on the direct marketing group per se because its job would be largely eliminated. Except, of course, it wasn’t. After the glamour (marketing people are, well, different) of project design and implementation, the product and customer managers decided to let the direct marketing group use the system for them. Unfortunately, the system didn’t support the direct marketing group’s view of how the process should work, and cycle times actually increased. Eventually, we did realize the savings, but not without a reorganization and unnecessary pain.
The more typical example of not having the right customer occurs when the project sponsor doesn’t actually have the authority to implement the finished product. You can usually tell when this is happening during requirements interviews when you can’t seem to find anyone interested in the high ROI opportunities or implementation details associated with the effort. Financial services data warehouses focused on internal reporting rather than revenue enhancement are prime examples of this failing.
What Were Those Requirements Again?
Not understanding the actual requirements for success is usually the result of lack of good prioritization and incompleteness. A good requirements methodology will prioritize requirements from the beginning. “Nice to haves” aren’t “requirements.” Completeness is a little more difficult to address. We’ve found that paper process prototypes and walkthroughs are a good way to address this issue. Getting business sign off on the requirements document is not.
Unrealistic expectations and poor communication are so rampant that they’re funny, albeit a graveside kind of humor. The following conversation actually happened, and we bet you’ve been in one pretty much like it:
Customer: “You understand we need a new (name changed to protect the guilty customer) system.”
Consultants: “So you’ve told us.”
Customer: “Before we start, we’re going to need to know how long it’s going to take you to do it and what it’s going to cost.”
Consultants: “How long it’s going to take and what it’s going to cost to do what?”
Customer: “The project.”
Consultants: “It depends on what exactly you want us to do.”
Customer: “That’s going to depend on how long and how much.”
Both positions are reasonable, taken from each side’s own perspective. But this conversation isn’t going to wind up being a helpful one. To avoid this situation, we must do a significant amount of planning before embarking on a new project or product, and the plan— especially the requirements portion of the plan — must be well communicated at the outset.
Unfortunately, the attempts to rectify this situation often lead to more of the same. Most formal development Methodologies (capital “M” on purpose) insist on plans and scopes in project charters. This is a good idea because it sets direction and limits. But project charters come before detailed requirements gathering, so taking the initial plans and budgets and trying to manage to them is an exercise in futility — one that most of us have a lot of exposure to and experience with.
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
