The first meeting for a project is a tense affair. There can be a lot of new things coming at you all at once. New co-workers. New technology. New processes. And, perhaps most problematic, new business partners.
These meetings tend to follow predictable patterns. You, the technical person, want to stick to a process, gathering basic requirements that can be put into a document. So you ask some questions about what’s going on with the business and what problems need to be solved.
The business person talks rather vaguely about what she wants to accomplish. She seems excited about something, but you don’t know exactly what. So you ask more questions to try to understand.
Before long, frustration creeps in. She can’t comprehend why you don’t “get it.” And you still have no idea what she’s talking about.
This disconnect occurs because you both think about work differently. We in IT see work as the act of solving problems. Business people see it as the act of achieving a vision.
A nontechnical colleague and I have been exploring this difference.
Problems have a very specific structure that we bring from the world of math into our work lives. They include problem statements, assumptions, rules, constraints and solutions. These conceptual tools are powerful because they let us focus on what we’re trying to accomplish and formulate detailed approaches to implementing solutions.
Visions don’t have as rigid a structure. They are imagined futures — they’re visceral, not analytical. Business people imagine the experience of using the product, its feelings and its effects.
These opposing conceptualizations of work interfere with our ability to collaborate in two key ways.
First, we have trouble planning together because we orient ourselves toward the same work from completely different perspectives.
Problems are rooted in the present. They start with the current reality. To solve the problem, we work forward, plotting a course from the problem statement to the solution, and navigating the assumptions, rules and constraints.
Visions are rooted in the future. Achieving a vision requires working backward from the imagined future and figuring out what is needed to make that future real. As a vision transforms from vague to vivid, a detailed path to creating it emerges.
When this disconnect occurs, we have serious problems planning together because we approach the exercise from opposite ends of the project.
Second, we have emotional reactions to each other’s approach. For us in IT, problems are wonderful. Solving them is our life’s work. They are invitations to think, build and create. And to us, visions are annoyingly vague ideas requiring clarification to become actionable.
For business people, problems should be avoided at all costs. When we turn their beautiful visions into problems, they feel like we are dragging their ideas through the mud. And when we ask questions, we interrupt their flow, preventing them from clarifying their visions.
To make sure early project meetings go well, don’t try to force those visions into a problem structure too soon. Give the business people time to envision the work completely, and support the process by talking through dependencies. At the end of the session, synthesize what you’ve heard as a problem statement. It is possible that both parties just might get what they want.
Copyright 2011 by Computerworld Inc., One Speen Street, Framingham, MA, 01701. Reprinted by permission of Computerworld. All Rights Reserved.
For more information about how you can leverage geeks to get the technology you want, contact firstname.lastname@example.org or call 310-694-0450.