Concept: Balance competing priorities to maximize stakeholder value. |
Develop a solution that maximizes stakeholder benefits and is compliant with constraints placed on the project.
Main Description
### Balance competing priorities to maximize stakeholder value There is no fair wind for one who knows not wither he is bound. Lucius Annceus Seneca, philosopher, 3-65 AD. Rarely can a system be all things to all people and often attempts to do so are wasteful and result in bloated systems. Therefore stakeholders and developers must clearly understand and agree upon: the problem to be solved, the constraints placed on the development team (cost, schedule, resources), and the constraints placed on the solution. The developers and stakeholders must collaborate to develop a solution that maximizes stakeholder benefits and is compliant with constraints placed on the project. Achieving balance is a dynamic process since priorities and constraints change as the stakeholders and developers learn more about the system. #### Discussion Collectively, these three topics, problem to be solved, resource constraints, solution constraints are the Requirements for the development of the system. The challenge for all project participants is creating a solution that maximizes value, subject to the constraints. This is often referred to as cost/benefit analysis, or value engineering. We simply call this “Balance”, the principle that guides the development of successful systems. Balance is the basis for making the critical design decisions that define the Architecture of the system. Discovering the balancing point is challenging and elusive because the balance point is dynamic. Stakeholder needs change, new opportunities appear, risks are resolved, new risks appear and the development team discovers new realities about the system. Change happens throughout the development cycle and therefore stakeholders and developers must be prepared to re-evaluate commitments, reset expectations, and adjust plans accordingly as the system evolves. This is typically referred to as Managing Scope. There are a number of key practices that support the principle of Balance. These are conveniently organized into practices that focus on the problem domain (Discipline: Requirements), those that focus on the solution domain (Discipline: Analysis & Design), those that focus on ensuring quality (Discipline: Test), and those that focus on managing scope and risk (Discipline: Project Management). Although risk is a fundamental consideration in achieving balance, it is covered in detail in the Evolve principle. ### Practices #### Separate the problem from the solution Too often we run head-long into a solution without understanding the problem. After all, we are taught how to solve problems, not how to define problems, so it's easier. However, this limits our understanding of the problem, imposes artificial constraints and makes it difficult to balance trade-offs, or to even know what the trade-offs are. Therefore, understand the problem before defining the solution. By clearly separating the problem space (what the customer needs) from the solution space (what the system must do) it is easier to maintain the proper focus and easier to accomodate alternate ways of solving the problem. The main artifacts of the problem domain are the Vision, Use Cases and Supporting Requirements for the system to be, whereas the main artifacts for the solution domain are the evolving Architecture and Build of the system to be. #### Know your audience You cannot know how to make effective trade-offs if you do not know who the stakeholders are and what they really want. Therefore, know your stakeholders. Start by identifying all Stakeholders and maintain open and frequent communications between stakeholders and the development team. Refer to Role: Stakeholder and Artifact: Actor for more details on knowing your audience. #### Create a shared understanding of the domain Domain experts often have limited technical expertise; developers, architects and testers often have limited domain expertise; and reviewers and other stakeholders often have limited time to commit to the project and learning about the problem domain. These people often have an inconsistent or poor understanding of the problem domain which causes communication problems and increases the likelihood of building the wrong application. Therefore, enhance and share all parties understanding of the domain. A concise and shared understanding of the problem domain enhances communication and project effectiveness. Start by defining the problem in the Vision document. As your understanding increases, capture key domain concepts and terminology in the Glossary to ensure a consistent shared use of the language of the domain. This practice is a specialization of Maintain a Common Understanding collaborative practice. #### Use scenarios and use cases to capture requirements Many companies still document requirements as a list of declarative statements, often referred to as “shall statements”. Such a list is often difficult for stakeholders to understand, since it requires the end user to read through and mentally translate the list into a visualization of how they could interact with and use the system to do the work they need to do. Therefore, capture requirements in a form that stakeholders understand. Use scenarios and use cases to capture functional requirements in a form that makes it easy for stakeholders to understand. Nonfunctional requirements, such as performance, stability or usability requirements are still important, and can be captured in the Artifact: Supporting Requirements using traditional techniques. Refer to Concept: Requirements, Artifact: Use Case, Artifact: Actor, Artifact: Glossary and Artifact: Supporting Requirements for more information on capturing requirements. #### Establish and maintain agreement on priorities Poor choices as what to develop next can result in delivering capabilities that aren’t used, or identifying problems late in the project that result in delays and even project failure. Therefore, prioritize requirements for implementation by regularly working with the stakeholders during product evolution to make choices that deliver value and drive down risks, while building a system that can evolve. Refer to Concept: Requirement Attributes, Artifact: Work Items List and Artifact: Iteration Plan fore more information on prioritization. #### Make the trades to maximize value Cost benefit trade-offs cannot be realistically made independent of the Architecture. Requirements establish the benefits of the system to the stakeholder while Architecture establishes the cost. The cost of a benefit may influence the stakeholder's perceived value for the benefit. Therefore, work with the stakeholders and developers prioritizing requirements and developing candidate architectures to implement those solutions. Use the candidate architectures to evaluate the cost of the benefits. Candidate solutions are considered at a high level during Capability Pattern: Determine Architectural Feasibility to determine a design which maximizes value while minimizing cost. Each candidate architecture is considered from the point of view of satisfaction of key requirements, or measures of effectiveness. The candidate architecture which provides the most coverage at the lowest cost is selected for further development (see practice "Separate the solution from the problem" above). Refer to Artifact: Architecture and Artifact: Architectural Proof-of-Concept for more details on making trades. #### Manage Scope Change is inevitable and while change presents opportunities to enhance stakeholder value, unconstrained change may result in a deficient system and unmet stakeholder needs. Therefore, manage change while maintaining the agreements with the stakeholders. Modern processes always manage change; adapting to changes in the environment and stakeholder needs, assessing the impact of changes, making trade-offs, and re-prioritizing work. Stakeholder and developer expectations must be realistic and aligned throughout the development lifecycle. Refer to Artifact: Project Plan for more information on managing scope. #### Know when to stop Over engineering a system not only wastes resources but also leads to an overly complex system. Thereofore, stop developing the system when the desired quality is achieved. In the words of Philip Crosby, “Quality is conformance to the requirements” [CRO79]. Thus, this practice is in a sense the “closure” to the first practice "Separate the problem from the solution", ensuring that the “solution” does indeed solve the “problem”. Once the critical requirements are implemented and validated, acceptance of the system is enabled. Ensure requirements test coverage. Don’t gold plate. Refer to Artifact: Test Log, Concept: Traceability and Artifact: Status Assessment for more details.
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright