Intimate Domains – navigating areas of expertise

People who elicit and manage requirements – product managers, business analysts, program managers, and others – also orchestrate and communicate with their clients. In an enterprise software project, the requirements manager (RM from here on out) has to communicate with people across the client organization. To pass along information, gain support, and gather understanding. Plus all of the consulting tasks of resolving conflicts, setting expectations, and managing change.

One of the key factors of effective communication is having an understanding of your audience. One thing you need to understand about your audience is their background. Not only will people have varying degrees of understanding of your project, but they will approach it from very different perspectives – colored with prejudices, assumptions, and histories.

Trying to group people’s backgrounds will help ease some of the context-handling elements of communication, and let you focus more effort on the message. I use the following Venn diagram as a tool to help me, and often to help them (in consensus building, for example).

Most people tend to fall pretty squarely into one of the three archetypes in the diagram.

The business

This is where the stakeholders, users, and people responsible for positioning of a company’s products live. They will be motivated by ROI, adoption rates, use cases, “snazzy interfaces” (yes, groan away fellow HCI folks), and product roadmaps. All decisions seem to be evaluated against this framework. “You can’t show these products in Japan” and “if I can’t do every part of my job in the tool, I won’t do any of it” and “how much money will we save” are often heard in the business circle. Note that other archetypes refer to business people amorphously as “the business.”

The experts

These are the subject matter experts. Folks who have an analytical precision evident in how they approach what you’re doing. They are often extremely rooted in their domain, and will often myopically evaluate the software. They make statements like “You must show FCF with EBITDA, for the data to be credible” or “the only thing that matters is that you include disclaimers about QoS.”

The techies

The developers, testers, system Admins, project managers. All the people who make the system come to life. These folks care about timelines, uptime, server loads, algorithm optimizations, project staffing, and how best to deploy the system. Commonly heard are “we can build anything, it’s all ones and zeroes” or “you can’t constrain time, scope, cost and quality – pick one.”

You don’t have to look any further than some of the bit-players in the Dilbert strip to see some of the stereotypes. But it does help to understand why someone asks for a perpetual motion device, or demands that an NP-complete problem be solved in the software, or why someone doesn’t understand that if it doesn’t work correctly, that’s even worse than being delayed (or vice versa). Most people tend to color their analysis with a single perspective.

Switch-hitters

These are the cross-functional folks who you desperately want involved in the project. Switch-hitters are people who live in two domains – usually having experience in both, or an education in one and a role in the other. The next diagram shows the areas of overlap from the Venn diagram above.

1. The business-savvy expert.

These are the folks who “graduated” from product design to product sales, the hands-on CFO who does all of his relative’s taxes for fun, and other combinations. These are people who have deep domain expertise, and are also aware of the business drivers of projects. They build bridges. They help engineers understand why the company won’t sell a particular product even though it works better than what they are selling.

2. The domain-expert developer.

These are most often IT folks who came from the product/accounting group, and can apply deep domain expertise to software decisions. They are the folks most likely to catch problems with the specs, or the resulting designs. In another post, I’ll talk about mavens and ignoramuses.

3. The tech-savvy stakeholder.

These are the people who bring rationality to projects. They do a great job of balancing practical delivery constraints with business objectives. They can be business-centric IT folks, or execution-focused business people.

Where does the RM fit in?

Ideally, your RM is the star of the project (double entendre intended). This person will understand the business well enough to make good prioritization decisions. This person will understand the “devil in the details” pieces of the domain well enough to communicate effectively with everyone, and be able to know when the requirements are wrong. This person will also be able to negotiate away the impossible, and leverage the capabilities of the delivery teams to achieve the unthinkable.

When you can find one person to live in the center, you win. When you can’t, then bring the switch-hitters together to help everyone work together.