Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

March 20, 2003

Across the Chasm

This lesson from an outside discipline may prevent miscommunication that can kill your strategic IT project

by Con Kenney & Phil Leggiere

To the deep frustration of business users and developers alike, most strategic IT projects, despite the best of intentions, fail badly to meet user requirements. As developers tell it, business users don't know what they want until they see it. Business users see developers as hopelessly stubborn, sticking to their shopworn tactical formulas despite decades of failure, oblivious to their clients' real needs, delivering solutions too late, buggy, bloated, and expensive to do anyone much good.

There's no use looking for villains. The real problem is that business users and developers define the purpose of the IT application in very different ways. The words may sound the same, but they don't mean the same thing. This confusion accounts for most application failures: According to the Standish Group's infamous 1994 report CHAOS: A Recipe for Success, only about 25 percent of all IT projects succeed, and most of the failures can be traced to missing or misunderstood requirements. (Standish defines a successful project as one completed on time and budget and delivering all originally specified functions and features.) In his book Competitive Engineering (Addison-Wesley, 2003), software engineering management expert Tom Gilb demonstrates that about 40 percent of the average project is spent on rework, and long-established industry estimates say each error costs 10 times as much to fix at each subsequent stage of a development project.

Why IT and Management Can't Communicate

The root cause of these breakdowns lies deep within the way developers are trained, the incentives employed to reward them, and the methodologies and tools they use to create applications. Computer science and software engineering borrow heavily from mathematics to teach developers how to solve programming problems. From a developer's point of view, getting a clean compile and the expected results are what matter. Inside many IT organizations, cowboy programmers and "code slingers" are lionized as role models; the relationship with businesspeople is something begrudgingly to be managed, an inconvenience at best, a necessary evil at worst. IT teams want to get to code as soon as possible, and business requirements are just an obstacle to that goal.

Over the years, experts in application development, recognizing this problem, have advocated more effort for requirements. At the same time, there have been countless attempts to coax businesspeople into using IT approaches for conveying requirements. Both attempts to change behavior have failed. Why? Developers want concrete, unambiguous requirements, businesspeople want firm estimates of cost and time, and both groups want a prediction of an unknowable future. Approaches based on the quest for absolute certainty are almost doomed to fail.

The need for a new strategy is clear. Instead of seeking certainty, developers and their business colleagues need to find enough agreement so they can proceed to the next small step. Fortunately, new research in the seemingly academic realms of anthropology and cognitive science provides practical insight into how such an agreement can be forged by changing the perceptions and behavior of developers and business managers alike.

Anthropology studies human behavior using the tools of ethnography, or "writing about people." A technique called ethnographic conversation allows theories and concepts to emerge, instead of testing them, and focuses on uncovering the reasons for what people do. Market researchers and consumer product developers employ ethnography to study the "fuzzy front end" before moving to traditional, quantitative methods of analysis. Conceptual blending, a methodology developed by cognitive scientists Mark Turner and Gilles Fauconnier, comprises a new set of ideas about how we think that enables us to take complex stories apart and put them back together. In combination, ethnographic conversation and conceptual blending help developers and businesspeople find common ground, so they can take the next step in the project with confidence.

Ethnographic conversation and conceptual blending are simple, powerful strategic tools for developers to increase their understanding of the business context, goals, processes, and measures of success. These tools demand a willingness to enter a different kind of conversation and challenge assumptions.

The key to the ethnographic conversation is getting people to open up and tell stories. A good story can explain a complex situation far more succinctly and memorably than an analytic presentation. And, unpacking a story can help developers understand characters, motivations, relationships, and rules when they're analyzing trade-offs or making decisions.

Asking the Right Questions

An effective, open-ended question will encourage people to talk about themselves and to tell stories. If possible, developers and their business partners should collaborate on forming the question, committing about a half day to roughing out the most evocative question possible.

The group can start by brainstorming about the context of the application, asking out loud such seemingly obvious but too often ignored questions as: What are the real the business opportunities and potential problems? Who are the stakeholders? What are the appropriate benefits, risks, and measures of success? Then the group can cast candidate questions that get at the heart of the application's purpose and allow additional prompts for more detail. For an ERP project, some examples of potentially pertinent candidate questions might be: Whose work will change the most with a successful implementation? In business terms, why is this process so important to you? Is this project like another project you know about?

When the team has chosen what it feels is the best question, respondents should be chosen from a diverse, representative cross-section of the stakeholders in the application. For a year-long $1 million project, 12 to 15 interviews should suffice. In the final step of the preparation, the group should break into pairs so each person can practice interviewing each other. Some teams may decide to tape interviews, but regardless, careful note-taking is essential. For this reason, many teams send two interviewers, one to ask questions and the other to take notes.

Questions should be easily understandable and focus on feelings, impressions, experiences, and theories. Neither the respondent nor the interviewers should know what they'll say beforehand. The objective is to encourage spontaneity, getting the respondent to talk comfortably for about an hour, plus or minus 15 minutes. Many teams develop a canned introduction describing the purpose and nature of the interview to ease getting started and begin with a simple, open-ended question anyone could answer comfortably. While interviewers can probe for more factual content occasionally, maintaining the flow of the conversation is essential. Developers can always follow up with fact-gathering interviews when the context of the application is established. Above all, interviewers must avoid taking a stance or voicing an opinion on what the respondent says. The interviewers' reactions are important data, but the interview is the wrong time to explore those reactions.

Interviewing teams should debrief immediately after their interviews to discuss the major themes that came up in the conversation. Assuming that the interviews occur over several weeks, weekly team meetings to discuss what people are hearing are important venues for team members to learn from each other. Circulating notes and audiotapes can also help team members gain a sense of what happened in other interviews. Initially, the mass of data may be very confusing, but the team will begin making sense of it through conversation. People will develop little theories that they can test in subsequent interviews. In an ethnographic approach, the sensibilities of the interviewers are the most important instrument.