 |
Home > Detail: The Whos and Wheres of Stakeholder Requirements
| A StickyMinds.com Original |
|  | |
The Whos and Wheres of Stakeholder Requirements
By Mary Gorman
   
Summary: Whether you're working on a collocated or distributed team, it's important to take stakeholder requirements into account. "Who" are they, and "where" are they located? In this article, Mary Gorman offers some tips to help you narrow the gap between thinking and acting globally and locally. | | |
|
|
 |
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 * Where = Complexity2
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 still 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 a ...
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
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
Scenarios or stories are valuable tools for stakeholder analysis. A story, such as "As a book buyer, I want to return the book I bought so I can get a credit on my credit card," starts with who initiates the interaction. Scenarios, which are broader in scope than stories, also begin with who, such as "customer returns a purchase."
Remember to dig to discover any indirect users that participate in producing the outcome. Your product may interact with another system (in the sample story, the credit card company could be an indirect user) or may send information to another stakeholder. Often, analyzing where the action takes place leads to the discovery of new business rules and data requirements.
Prototyping a product or a user interface gives you a visual way to elicit and confirm a stakeholder’s needs. Ask, Who is allowed to use the interface? What is their authority level? Ask questions about which data and business rules are specific to each who. Learn where they will use the interface by studying their physical environment—a desk, a factory floor, a moving vehicle, outdoors (with weather challenges).
Include culture-specific requirements. For example, on a user interface for Western cultures, you position fields left to right. Rules about data may vary based on location. Leverage international standards wherever possible, such as adopting ISO 8601 for numeric dates and time.
Regulators as Stakeholders
Regulators certainly affect the product! Identify whos such as regulatory bodies and legal authorities, and specify where their jurisdiction applies.
Don't wait. One of my clients documented its software requirements in one language and then later learned it had to translate the requirements into the language specified by a national regulatory commission. Ouch!
And be sure to analyze who must enforce the policies, rules, and regulations. You may uncover new user roles.
Providers as Stakeholders
Providers have a vested interest in the success of the product. On a recent project, the product managers' responsibilities were expanded, and they found that specifying "fast" response time and a "user friendly" interface was not sufficient for providers to deliver the right product. The entire team realized that they needed to set realistic expectations for all parties by defining early on how much detail was needed and clarifying who would uncover and specify these details.
As with many distributed projects, the developers (the providers) were located in different countries from those stating the requirements. The solution was for the product managers to take the first crack at stating specific quality attributes and then to work with developers to finalize the details.
It's all in the numbers
Whether you're working with collocated resources or a distributed team, do the arithmetic. Make sure you factor in the time and talent you need to fully support the who and where requirements.
Have you worked on a dispersed product team? What did you learn? Share the wealth. Email me (mary@ebgconsulting.com) with your experiences, and look for your stories in future columns.
Further Reading
See Ellen Gottesdiener's article related to
stakeholders.
About the Author
Mary Gorman, CBAPTM, Senior Associate at EBG Consulting, assists project teams to explore, analyze, and build robust business and system requirements models. Mary serves on the Business Analysis Body of Knowledge (BABOK®) committee of the International Institute of Business Analysis and is the leader of the Elicitation subcommittee. She can be reached at mary@ebgconsulting.com and http://ebgconsulting.com.
Back to Top
StickyMinds.com Weekly Column From 5/18/2009 
|
