Negative Stakeholders on Large-scale Public Systems
04 May 2009
Recently, I've been working on large-scale systems that interact with the general public. In doing so, I've identified an interesting group of stakeholders, based around the concept of negative stakeholders. Negative stakeholders are parties who want to damage the system - usually thought of in terms of saboteurs, hackers or terrorists, whose actions would have a high impact on the system, but with a low probability. Requirements are written based on negative stakeholders' potential actions in order to build a system that negates their activities.
However, large-scale public-facing systems may have a sizable minority of negative stakeholders who interact directly and regularly with the system who deliberately try to subvert it – with a high probability of an encounter, albeit with generally low impact. I refer to this group as "Resisters".
What's the best way to handle resisters, who clearly won't have been consulted on system development? First, you need to differentiate between a system that a large minority of stakeholders is trying to deliberately misuse and one that is just plain difficult to use. The difference may be subtle but knowing it will influence the future direction of system development.
Prior to deployment, domain experts can give advice based on observed behaviour on similar systems, and test cases can involve team members playing the roles of resisters. In addition, it's important to plan what statistics to capture to help analyse and categorise behaviour. After initial deployment, you are able to observe behaviour directly and analyse the captured statistics, giving a steer on future development priorities.
In either case, make certain that the business process surrounding the encounter with the system is as simple and efficient as possible. This may make any shortcomings in system design more palatable.