< Zurück | Inhalt | Weiter >

11.7.2 Stakeholder Buy-In

Stakeholder buy-in can be another important part of a software project. As we discussed in Section 11.5, stakeholders are any of those people who are touched in some way, direct or indirect, by this software project.

For this simple budgeting program, there will be few stakeholders—it will largely be Ellen and her direct reports. The system will not likely be a large drain on computing resources, so system admins don’t need to be brought in at this point. If and when the project expands to include other users across the network and across the enterprise, then the system administrators should definitely be included. There will be few reports from this first cut of the project, and what few there are will only be read by Ellen and her direct reports, so again, there are few others that need to be consulted as stakeholders.

The idea at this stage is to listen to other points of view—those of your stakeholders—to get a different perspective before charging headlong down one avenue of development.

It’s not that you will be able to satisfy all points of view—it can be a wor- thy goal, but it is often unattainable. Rather, you need to hear from all those involved since your software will affect all those people, and understanding something about how it will fit into their roles and daily tasks will help you make better tradeoffs and design better software. It will likely uncover previous- ly unseen requirements. It also has the political benefit of those people knowing that you cared enough to listen to them before sending them a finished solu- tion. It increases the likelihood that your software will be seen as a help, not hinderance.4


image

4. As engineering types it is difficult for us to understand and appreciate the importance of this, but in many ways these personal, political, and psychological factors are much more im- portant to the success of a project than are technical choices. It has taken us years to appreciate