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

Continued from Page 1

Framing the Application

Over the course of the interviews, the team members will find the way they frame the application changing, and they'll mention interviews as evidence for their point of view. Sometimes team members may interpret an interview differently, and it's very important to preserve these differences instead of forcing a common interpretation. In an ERP project several years ago, the IT team members believed that cost minimization was the stakeholders' top goal, while the businesspeople heard that process flexibility to support new products was the priority. The truth is that stakeholders were saying both goals were important without being clear in their own minds about the trade-offs. Forcing the team to choose one goal would have not only misinterpreted the interview data but would also have divided the team. A sure sign you're on the right track is when someone says: "I was assuming that ..." The ethnographic conversation works when people start to see their own assumptions.

The concluding step to this stage is an all-day meeting for the entire team to go through the interviews, compile the major themes, and compose their core story. The core story distills all the stories the team has collected and created into a simple, memorable form. Every member of the team should be able to tell the same story, but individuals will include different elements: The differences are fine as long as the core story is recognizable. At this point team members can easily agree on whether a new element fits within the story or not, and everyone can generate variants of the core story that remain faithful to the original.

Before building on the core story through conceptual blending, the team must test the story with some of the people they interviewed, additional stakeholders, and nonstakeholders. Not only should nonmembers be able to understand the core story, they should also be able to extend the story and create variants. If more than a few of the testers can't play with the core story comfortably, it's probably too complex or abstract. The team should strive for a "human scale" core story that's compressed in time and space and that expresses shared values.

When the core story is stable, conceptual blending can help the team derive new, related substories to tackle various business and technical questions, such as the business case or process flow. Say the core story is about sales managers gaining more information about the sales pipeline and sales activities. Furthermore, to justify the application, the team must prepare a quantitative business case showing the costs and benefits. The core story is one "input frame," and the standard business case is another input frame. The team has already defined the salient elements in the core story, and there are only a few in the business case, such as decreased effort, lower expenses, or higher revenue. Through trial and error, the team then maps the elements of one input space to the other. Pairs of connected elements go into the "blended frame." The blended frame is a new story that combines parts of the core story and parts of the standard business case.

In the blended frame, an element of the new story might be: For every 10 salespeople who use the sales automation features of the CRM package, the field sales organization could eliminate one sales analyst position for an annual savings of $75,000. The team can test this proposition in its core story by evaluating how much overlap exists between the information managed by the salespeople and sales analysts and by testing whether salespeople would be willing to enter customer data into the CRM. The blended frame and the original input frames can change as the team maps elements and connections and composes new blended frames.

Team members can also extend the blended frame in a kind of mental simulation to explore what would happen over time. The team might find that the quantity and quality of information available to sales managers about their sales pipelines could actually decrease because salespeople withhold information. The conceptual blending framework provides a powerful, simple set of tools for producing scenarios based on shared assumptions.

Finding Common Ground

A relaxation of the intensity of interaction among developers and the businesspeople is one of the early signs that the ethnographic conversation is taking hold. You'll notice more open-ended questions and that the pace of the dialog will slow somewhat. Sometimes the group may even be silent while everyone reflects. If you hear someone start a sentence with "I'm assuming ..." or "My assumption is ..." or "Is your assumption that ..." then you'll know the group is on the right track.

As the group prepares for management briefings, developers and businesspeople switch roles and talk about issues that are usually in their counterpart's domain — a powerful indication of an effective ethnographic conversation and conceptual blending. Developers haven't become businesspeople, but they're now more capable of seeing the world from a second perspective, putting themselves in the places of their sponsors and customers. The emergence of this particular conceptual blend augurs well for the project, because developers now have the basis for making decisions aligned with the interests of the businesspeople. Developers can also describe the trade-offs and decisions they're making in the language and logic of the businesspeople.

The immediate benefit of engaging in the ethnographic conversation and unpacking the conceptual blends is that there will be far fewer missing or mistaken requirements.

The other benefit, not so immediate, is that the tenor of the relationships among businesspeople and application developers will shift from blaming and avoiding blame to trying to understand our own assumptions and the assumptions of others.

Anyone capable of developing software is also capable of initiating the ethnographic conversation and unpacking conceptual blends — we all have the brains for it, and little training is needed. Application developers have to gather requirements anyway, and these tools can produce benefits far after the project has ended.

Rate This Article

Comments:

Optional e-mail address:

Con Kenney [cfkenney@comcast.net] has 20 years of consulting and managerial experience in technology and strategy and founded the first client/server architecture consulting practice while at Sybase. Most recently, he served as CTO of Zerotime Labs.

Phil Leggiere [philguy@prodigy.net] is a professional writer specializing in technology. His work has appeared in publications such as Upside, Market Makers, and Wired.