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.
(1 votes, average: 5 out of 5)
Loading ...
Add Tyner Blain to Google Toolbar
January 4th, 2006 at 1:01 am
[...] Maintain use of language that is clear to the customer [...]
January 4th, 2006 at 1:26 am
[...] Kevin talks in particular about how to communicate with different team members as part of incorporating UI designs into the finished product - by understanding that you need to communicate with people in the language to which they are accustomed. I just wrote about this same topic at a general level in my recent post, Intimate domains. Kevin provides great specific suggestions along the same vein. [...]
January 4th, 2006 at 1:28 am
#
Scott Sehlhorst said,
December 28, 2005 at 10:59 pm · Edit
Marcus has posted a complimentary article on his site at http://rationalizedthoughts.blogspot.com/2005/12/why-of-business-analysis.html
It’s worth a read
January 4th, 2006 at 1:40 am
[...] One of the key points that enables James’ approach is “tight collaboration” between the program manager and the developers. He talks about the “miracles” that can happen when you have this, as conversations can cause time to miraculously appear in the schedule. And his use of the toaster analogy is spot on. The key takeaway is that you must have a program manager who can interact with, and understand developers well enough to ask questions like “why is X so expensive?”. This is just one manifestation of the switch hitter archetype, the tech-savvy stakeholder, doing his job. In an awkward (non-agile) development process, your switch hitter may have to rely on reviews of design documents and documented assumptions to identify when money is being spent that shouldn’t. [...]
January 4th, 2006 at 1:52 am
[...] OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat – the consumers of the requirement need to know UML. This is usually not a problem for development teams, however stakeholders are also consumers of requirements – they have to validate that what you’ve documented expresses what they require. Without a tech-savvy stakeholder, this approach is unlikely to provide unambiguous documentation. [...]
January 4th, 2006 at 2:02 am
[...] I’m having a little trouble reading the spec - I left my secret decoder ring at home! Ever hear that before? A set of requirements that makes perfect sense to one team member can be completely unintelligible to others. Requirements written in business-speak, or full of accounting jargon may be unintelligible to the development team. Unless you’ve staffed the dev team with switch-hitters, you have to provide supporting documents that explain this domain-specific information. [...]
January 4th, 2006 at 2:42 am
[...] The goal of writing a requirement is not pedantic accuracy, it’s effective communication. In addition to crossing domain-boundaries with the different audiences that consume our requirements, we often are crossing language barriers and varying educational levels. It’s hard enough conveying concepts that presume contextual knowledge, our readers shouldn’t have to parse the text repeatedly. [...]
January 11th, 2006 at 8:45 am
[...] These techniques, while effective, are not sufficient. Making sure the writing is targeted at the audience, and reviewing the spec for changes (because from change you infer engagement) is certainly important. Getting stakeholders to put some skin in the game is also a great idea. But these are still primarily passive activities - worth doing, but there is more you can do. [...]
January 20th, 2006 at 10:45 pm
[...] I do disagree with Cote’ that some of these layers of documents exist to enable people who aren’t “technical enough” to participate. Different people play different roles, and care about different information. Communicating with these people, in their language, is critical. [...]
January 22nd, 2006 at 3:19 pm
[...] E3 - Misinterpreting the requirements. The developers can implement something that doesn’t match the requirements. This can happen in either be a faulty design or a faulty implementation. It may be that the developers didn’t understand the requirements (perhaps they were too vague or ambiguous), or it could be that they were incomplete and didn’t account for all of the possibilities. Validation of the requirements with the developers is critical to making sure that your spec is unambiguous and complete. Developers bring a level of rigor and analysis that can help you make a spec bullet-proof. Use their skills to fix a bad spec before it’s been signed off as “correct”. Even after you do all that, the implementation may not match the spec. That’s one reason why we test. E4 - Testing for the wrong implementation. Developers will create tests of their implementation. Unit tests are the most common example. A developer could incorrectly test their implementation (incomplete coverage, incorrect analysis). However, even good implementation tests can only make sure that what was intended (by the developer) was achieved. If the developer misunderstood the requirements, the test won’t assure that the desired outcomes are achieved. [...]
January 25th, 2006 at 7:01 am
[...] The project was one that was designed to improve both management accounting and sales decision support processes for this large company. Understanding the objectives required relatively deep business domain expertise. Our development team did not have that expertise, and our business consultants were already overloaded with rainmaking and pathfinding activities. [...]
January 31st, 2006 at 11:37 pm
[...] OK - now I’m getting concerned. Why is it a good idea to have non-experts specify the branding, layout, interaction design, and usability of a web-based application? Assuming that an expert business process modeler is at the helm, we can expect that high-level workflow is well designed. But the user experience? Show me a business expert who’s competent at designing interfaces and I’ll show you a switch-hitter currently occupying the chair of a business expert. [...]