The Whos and Wheres of Stakeholder Requirements

Whoever said "Think globally, act locally" hasn't done a project complicated by geographically dispersed stakeholders. Faced with multiple languages and cultures, you need to think and act globally and locally when you're analyzing and delivering products. Here are some tips.

Stakeholder Requirements: Who x Where = Complexity ²
Recently, I've wrestled with complex stakeholder requirements on several projects. One required two organizations (in different countries) to merge two products into one. Another involved enhancing existing products, and yet another needed to develop training software for technicians across the globe. Complicated enough for you? And--oh yes--some of the project teams had outsourced the software development or business processes to other countries.

Did I mention that each project had thousands of stakeholders from numerous countries? And, of course, they had divergent needs.

Multiplying who (stakeholders) by where (locations) increases the complexity of any project exponentially. But you need to dive right in. Delaying discovery and analysis of the stakeholders' requirements can lead to unanticipated and expensive consequences.

On Your Mark
How do you start? First, clarify what "stakeholder" means on your project. A standard definition is anyone who affects or is affected by the product: sponsors, product champions, users, advisers, and providers (developers, project managers, testers, and sources of packaged solutions who produce or provide the software product based on your requirements). Essentially, you're answering the who question: Who is involved in this effort?

At almost the same time, ask the where question: Where are stakeholders located? If they're spread across multiple locations, especially internationally, it will complicate analysis. Factoring in differences in language, customs, regulations, and time zones requires additional time and expertise.

Analyzing your stakeholders leads you to explore other requirements perspectives, such as how (processes), what (data), and why (rules). Here, I focus on tips for the who and where perspectives based on my recent work.

The Foundation
Without a doubt, the most fundamental requirements tool is a glossary of key business terms, including definitions, synonyms, and acronyms. Concise, clear definitions help diverse stakeholders work with shared meanings. If, as in my projects, your stakeholders have different native tongues, provide definitions in all those languages. Your investment in creating and maintaining a glossary will quickly pay off in quality, consistency, and speed of communication and requirements development.

A Picture Is Worth ...
Whenever possible, use visual models to elicit, organize, and communicate complex requirements. Models can be especially valuable when you're communicating across languages. For example, a hierarchy model visually expresses what might take several pages of text to describe. Here are key techniques and models I use when analyzing stakeholders:

Modeling Users ="ARIAL">
When you're working with product managers, a great model is personas--fictional archetype users that represent a composite of similar users. Personas quickly help you identify and evaluate your product's users. You could start top-down by modeling a "universal" persona and then look for regional-specific variations. Or, model them bottom-up by asking subject matter experts (SMEs) to identify local versions of personas, then work collectively with all the SMEs to identify their common characteristics and create an abstract universal persona.

Alternatively, consider user roles--people or things that interact with the software product to fulfill a task. Be sure to include direct users (who initiate actions) and indirect users (who get or respond to system behavior).

Producing a user role map reveals the visual organization of the various roles. As with personas, noting where these user roles are located can lead to identifying regional differences.

Whether you use personas or user roles, these models provide a valuable basis for eliciting, prioritizing, and validating requirements.

Modeling User Actions