(A version of this article
appeared as the 'Point' in a Point-CounterPoint piece,
together with a matching piece by Kent Beck and then a brief response by each of
us)
Point Counter Point, IEEE Software, March/April 2007, pages 62-65
(opposite Kent Beck's "Don't Just DWWTY" [Do What They Tell You])
In a way, the claim can hardly be gainsaid: nobody wants to build what the stakeholders do not desire. But as usual “the devil is in the detail”.
I will contrast two examples to illustrate what it can mean to build what stakeholders desire:
The product manager on Project A is in no doubt that the key to success is building what the teenage consumers want – excitement, speed, a feeling of mastery, and so on. (It is noticeable that these required emotions are very far from traditional requirements, as David Callele argued in a paper at RE’06). What players want, however, is hard to pin down: the market changes fast, and at any moment a competitor (a powerful negative stakeholder) may produce a game that transforms expectations for all future products. A crucial stakeholder is clearly the player/consumer, but other stakeholders including the regulator (deciding on behalf of the public whether this game is excessively violent or sexual, for instance) are also important and could be show-stopping. The regulator in turn is influenced by politicians, who respond to the mood of the public. Clearly, balancing the desires of the regulator and the player is essential; but so is defeating the competition: building what those stakeholders absolutely do not desire. Finally, Project A is a commercial success if it makes money, ie it does what its financial beneficiaries (directors and shareholders) desire.
The onion model in the figure illustrates the competing stakeholder pressures and that it is eventually the Product Manager who has to mediate them.
The project manager and lead engineer on Project B know that the key to success is building a railway that works safely, safely, safely. The safety regulator’s approval is mandatory, but first the project has to integrate all its components to make a system that actually works. So, the interfaces specified in the system’s architecture are crucial. In theory, interfaces can be worked out in advance and imposed on subcontractors: eg the signalling system exactly fits the train. But if the train has already been designed, the task is much more difficult. The train manufacturer is a powerful stakeholder, and the project can only make progress by negotiation. Preferably, the desires of the less powerful stakeholders are not trampled underfoot. Readers may like to sketch the onion model for this case: it is very different.
I hope it is clear from these examples that phrases like “what the stakeholders desire” conceal a multitude of sins. Dealing with those desires means trading-off large opposing forces, varying widely between projects. That means first finding out who the stakeholders are.
Stakeholders include not only beneficiaries but negative stakeholders – whose desires should not be met. So, should we give stakeholders what they desire? The answer is both yes and no. No – because it’s impossible to please everybody. Yes – because overall satisfaction of the key stakeholders’ desires is crucial for the success of a product.
More Papers, Consultancy and Training on
Ian Alexander's Home Page