Chapter 4. Balance Stakeholder Priorities

Benefits	Align applications with business and user needs. Reduce custom development. Optimize business value.
Patterns	Define, understand, and prioritize business and user needs. Prioritize projects and requirements and couple needs with software capabilities. Understand what assets can be leveraged. Balance asset reuse with user needs.
Anti-Patterns	Achieve precise and thorough requirements before any project work begins. Document precise requirements at the outset of the project, driving the project toward a custom solution. Architect a system only to meet the needs of the most vocal stakeholders.

The principle stated in this chapter's title articulates the importance of balancing often conflicting business and stakeholder needs, as well as balancing custom development versus asset reuse in order to meet these needs.

Most stakeholders would prefer having an application that does exactly what they want it to do, while minimizing the application's development cost and schedule time. Yet these priorities are often in conflict. As an example, if you leverage a packaged application to deliver a solution faster and at a lower price, you may have to trade off many requirements. If, however, you elect to build an application from scratch instead, you may be able to address every requirement on its wish list, but the budget and project completion date might both be pushed beyond their feasible limits as a result.

Rather than sending programming teams out to attack each element in a requirements list, you need to understand and prioritize business and stakeholder needs. This means capturing business processes and linking them to projects and software capabilities, so that you can prioritize projects and requirements effectively and then modify these priorities as you learn more about the application and stakeholder needs. It also means involving the customer or customer representative in the project to ensure that you understand what their needs are.

Second, center development activities around stakeholder needs. For example, by leveraging use-case-driven development and user-centered design, your development process can accommodate the evolution of stakeholder needs over the course of the project, as a function of changing business and your improved understanding of the capabilities that are truly important to the business and the end users.

Finally, understand what assets are available and balance asset reuse with stakeholder needs. Examples of assets include business models, legacy applications, services, reusable components, and patterns. Reuse of assets can in many cases lead to reduced project cost, and reusing proven assets often means higher quality in new applications (see Figure 4.1). The drawback is that in many cases you must trade off asset reuse against perfect satisfaction of user needs. Reusing a component may lower development costs for a feature by 80 percent but address only 75 percent of the requirements. Effective reuse thus requires constantly balancing reuse of assets with evolving stakeholder needs. Reusing an asset may also increase risk as a result of creating dependencies on external parties.

Figure 4.1. Balance Asset Reuse with Stakeholder Needs.

Using a component can radically reduce the cost and time to deliver a certain set of functionality. It may in many cases also require you to compromise on some functional or technical requirements, such as platform support, performance, or footprint (size of the application).

The anti-pattern to following this principle would be to document thoroughly the precise requirements at the outset of the project, force stakeholder acceptance of requirements, and then negotiate any changes to the requirements, each of which might increase the cost or duration of the project. By locking down requirements up front, you reduce the ability to leverage existing assets, which in turn drives you toward undertaking primarily custom development. Another anti-pattern would be to architect a system only to meet the needs of the most vocal stakeholders.

Let's have a look at some of the concrete practices that will help you balance the use of existing assets with evolving user needs:

• Practice 8: Understand the Domain shows how you can effectively communicate essential information about the problem domain to your project team.

• Practice 9: Describe Requirements from the User Perspective describes how use cases can help capture requirements so that end users and team members alike easily understand them.

• Practice 10: Prioritize Requirements for Implementation explains how to determine which requirements to address first in order to deliver customer value and mitigate key risks.

• Practice 11: Leverage Legacy Systems outlines how to leverage the many valuable assets you have in your organization.