How can we judge the success of the solution? People often don’t think about how they will determine whether some enterprise has been successful. Contemplating this evaluation early on helps crystallize the stakeholders’ thinking about objectives and steers the project toward a clearly successful outcome. Project success criteria are the subject of Chapter 4 of my book Practical Project Initiation: A Handbook with Tools (Microsoft Press, 2007).
What’s a successful solution worth? Whenever possible, quantify the business outcomes. All projects involve some cost–benefit analysis. Understanding the potential return in meaningful units helps participants make cost-effective decisions.
Who are the individuals or groups that could influence this project or be influenced by it? This question seeks to identify potential stakeholders in the project. The BA might need to consult these stakeholders to understand their interests in the project, their expectations, and the nature of their involvement. Stakeholders could be internal to the project, internal to the organization, or external to the organization. And you can bet that your stakeholders will have conflicting objectives, requirements, and priorities.
Are there any related projects or systems that could influence this one or that this project could affect? Look for dependencies between projects and systems that need to be analyzed and accommodated. Sometimes apparently small changes can have vast ripple effects across multiple interconnected systems.
Which business activities and events should be included in the solution? Which should not? These questions help define the scope boundary. Modifying the established project scope is a business decision that has implications for cost, schedule, resources, quality, and tradeoff decisions.
Can you think of any unexpected or adverse consequences that the new system could cause? Consider whether certain individuals, organizations, customers, or business processes could experience a negative impact from the system or product being developed. For example, a new information system that automates a process that has been performed manually in the past could threaten the job stability of the people who perform that process. Employees might need retraining, or their job descriptions could change, both of which could lead to resistance to the project and unwillingness to cooperate.
As you gain experience with these sorts of dialogues, you'll build a set of your own questions that you find helpful to pull out the key information. You might write those kinds of questions down on index cards. When you find that an elicitation discussion is stalling out or nearing an end, randomly pull out one of those cards and see if the question on it has already been addressed. If not, the question just might help you surface another tidbit of knowledge that will help you plan the project and keep it on track.
Don’t forget to leave your comments below.
Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.
(adapted from More about Software Requirements by Karl Wiegers)