It used to be said that 'The man who pays the piper calls the tune'. In those happy, far-off days, a client contacted an engineering firm, stated his requirements, and paid for the resulting system. Or at least, that was the theory. But was it ever so simple?

Requirements are human things, and people are vague about what they want. What's more, they change their minds, and in an age of rapid technological change, they change their minds more rapidly than they used to.

More problematic still, there isn't one person who you can unequivocally call 'the client'. Engineering projects like the West Coast Main Line upgrade nowadays run into billions of pounds, take many years to complete, and involve many people who could be considered to be 'clients', 'users', or 'customers'. In fact, since public money is involved, aren't we all customers in some sense?

The question is, therefore, who can legitimately claim to hold a stake in a project's territory; or, to put it the other way round, who should engineers seeking to define the requirements for a project consult about their viewpoints?

The usual but woolly-sounding term for people whose viewpoint is relevant to a project is the rather Blairite 'Stakeholders'. Some older words have already been mentioned above – client, customer, user. Unfortunately, all of these have rather different meanings, so we are probably stuck with Stakeholders.

This article discusses why the problem – who is this project for? – is important; and presents a simple practical method for organising the analysis of stakeholders and their viewpoints on a project.

The Problem: Why Stakeholders Matter

There are several reasons why getting a proper handle on who the stakeholders are in your project is important.

• Firstly, projects are much larger, take longer, cost more, and involve much greater technological risk – and so, much more risk to budgets and schedules – than ever before.
  
  For example, well, think of any large project that has been in the news recently for overrunning and overspending – it is an easy game to play. The army's Bowman (secure mobile radio) project has notably been stopped and put out to tender twice; over ten years and more than £400M have been wasted.

These are perhaps sufficient justification to consider how to get a grip on the Stakeholder problem.

A Simple Approach to Stakeholder Analysis

Since things seem to be going very wrong, often, it follows that even quite simple actions might save very large amounts of money. The ideal time for such action is at the start of a project, as many decisions are taken then that are very difficult to reverse later. In other words, even if we do not have a perfect theory of how to analyse stakeholders, what little we can do in practice may provide a disproportionately large payoff.

One way to start is to consider the system under development itself. A system is "a complex set of interacting elements (including human beings) which when working together correctly satisfy a need or objective". So the first group we ought to consider are the people who actually form part of the system, namely the operators. I find military examples are often helpful in understanding system concepts – perhaps this is because they are sharply focused on a single purpose.

Consider a fighter squadron. Which sorts of people are part of the squadron? Plainly the pilots operate the aircraft themselves, and indeed receive long training to function effectively. But they cannot operate alone; the planes demand intensive maintenance, refuelling and resupply. Therefore 'operators' include not just normal operators but also maintainers (Figure 1). I suggest that these are fundamental roles, slots that you should expect to fill with specific names and faces if your project is to succeed.

Figure 1: System Operators (standard roles in parentheses)

Figure 1 is already an improvement on the naïve view that 'the system' is a synonym for 'the kit'. Very few if any systems really involve no people; even deep-space probes are ultimately controlled from Earth.

But pilots and fitters are not operating aircraft on their own behalf. Who is supposed to benefit from their work? This is a simple question, and like many innocent-sounding questions it has a complex answer. Firstly, they serve a military commander who wields the squadron as a weapon; he decides what it is to do, and it functions at his command. Let's call this role the functional beneficiary; you can find out who fulfils this role by asking 'who is this immediately for?'; 'who benefits from the working of this system?'. This gives us a larger context for our system, shown in Figure 2.

Figure 2: System in its immediate context (standard roles in parentheses)

Is the commander the Client, then? Well, perhaps. But if an aircraft takes 15 years to develop, it's actually quite likely the future commander hasn't joined the Air Force yet, so he isn't going to be easy to consult; and current commanders neither know about future warfare, nor have responsibility for procuring aircraft for it.

Therefore, large organisations typically have a Procurement department that anticipates future needs and spends money on long-term projects to satisfy them. Purchasers (and with them, analysts and modellers) must join operational commanders in the zone around the system. In some sense the commanders depend on Procurement (arrows on Figure 3) but this is a very long-term relationship.

Figure 3: The Place of Procurement (standard roles in parentheses)

Figure 3 answers the question who pays the piper, and it is not in general the people who either operate or functionally benefit form the system. It is fair to call Procurement the 'customer', if you are a Developer, but that is not the same thing as the 'client', who presumably must have at least some knowledge of the operational side of things. However, Procurement does typically act as if it represented Operations, and when the Operators are still in short trousers today, this is an essential piece of surrogacy.

Actually, it is possible for these roles to be combined in the person of a single stakeholder; if I buy myself a pocket calculator, or a car, or a mobile phone, I am both the operator and the functional beneficiary, as well as the purchaser (and if I change the batteries or top up the oil, I am arguably the maintainer also). Incidentally, the popular term 'user' seems to apply to just such a hybrid role – the mass-market purchaser / operator / beneficiary of a consumer product. But 'user' is not a good synonym for stakeholder, with the range of possible roles that it implies.

Who else ought to be involved? Clearly the chain of command does not stop with the military; ultimately, the forces are at the disposal of a government, and they are the political beneficiaries of the system. Political benefit need not be literal; it can be internal to an organisation. For instance, it applies to the managers of the department that carries out the operations involving the system under development: they will benefit if they are seen to be running an effective show. Since their career advancement may hinder other managers, it is only too possible that there will be political opposition within the organisation – there may be negative stakeholders much closer to home than environmental campaigners and English Heritage. We have already mentioned Developers; they are in a sense right outside the system context, but this is quite a risky situation – if a developer is not concerned about the results of a development (the quality of the product) then he may attempt to make a quick profit at the customer's expense. A better approach may be to find a way of giving the developer a continuing stake in the product, e.g. through a maintenance contract. Then if the product is unreliable it is to some extent his problem – though the risk to the customer organisation cannot be conjured into non-existence by any magic spells or Public-Private Partnership contracts, no matter how ingenious. Other indirect stakeholders include financial beneficiaries, if any (Figure 4).

Figure 4: A Wider Circle of 'Indirect' Stakeholders (standard roles in parentheses)

Is that everybody now? Well, no. The Public have a crucial stake in most large projects, most often negative – they protest rightly and vigorously when their legitimate interests are threatened.

On some issues, the Public are very well-organized, and pressure groups like Greenpeace, Friends of the Earth, and the various Wildlife societies campaign effectively on causes in which the Public believe strongly. For example, if the UK Government attempts to build a new airport at Cliffe Marshes on the Thames estuary in Kent, destroying Sites of Special Scientific Interest (SSSI), a Nature Reserve and an internationally acknowledged (Ramsar listed) wetland habitat, it is already clear that there will be massive and arguably quite justifiable environmental opposition – an airport project is not only a matter of engineering.

On many other issues, the public do not have a well-developed voice of their own; instead, various pseudo-governmental organisations speak on the public's behalf, in a wide range of surrogate roles. Among the most important of such roles are government-appointed Regulators, who ensure things like Health and Safety, and fair use of the Radio Spectrum (Figure 5).

Figure 5: A Typical Set of Stakeholders

We now have a full range of types of stakeholder from direct operators through to the general public and the government. This is a broad span for an engineering project to consider, but the fact is that a project which ignores stakeholders does so at its own risk.

Many detailed variations on these themes are possible, but this simple model can act as a template in a wide range of projects. It is not guaranteed to solve all problems of conflicting viewpoints or misunderstood stakeholders, but it does offer a practical basis for asking questions, such as:

• Who needs to be consulted on the scope of this project?
• Who has an input to the budget of this project?
• Who can support or harm this project politically?
• Who can provide guidance on the usability, functionality, and required qualities (reliability, safety, lifetime, maintainability, …) of the system under development?

Conversely, if you have a slot that is filled by two or more roles with differing viewpoints – e.g. if your budget depends on two departments with different ideas as to what the system should consist of – you must urgently reconcile the conflicting viewpoints of the stakeholders concerned. This kind of trouble does not go away and it does not diminish with time; rather, as development proceeds and money is spent at a higher rate, it gets more acute.

Conclusion

Stakeholder analysis is not a science, and does not involve excitingly challenging branches of control theory. Yet the issues that it addresses have to be faced by every project, and on current evidence, it would be a good thing if it were taken far more seriously by many engineering projects. In a nutshell, people matter; and people play many different roles, all crucial to project success. Projects need to know the roles involved, and the viewpoints of the stakeholders playing those roles.

© Ian Alexander 2003