User, customer or beneficiary? - the sometimes confusing world of stakeholders

Causing confusion over customers
There is much written about the importance of stakeholder engagement and management, and in most cases it is right failure to engage with just one key stakeholder can undermine even the most well-defined and organised programme.

However I have found that even a good programme team can become confused at times about the roles and influences of stakeholders, especially when focusing on satisfying your customer. But who exactly is your customer? The definition is basically the person or organisation paying for the goods or services. But in labyrinthine worlds of major infrastructure programmes, acquisition organisations, government / public finance purchases (and so on) it is easy to lose sight of your actual customer.

Take a local focus or a global view?
We strive to maintain a solid vision through all levels of the programme, and satisfying the customer will probably be a key part of that vision. But if a programme manager provides a budget to a project manager, should the programme manager not be seen as the projects customer? Where then should the project focus be? An excellent example of this sort of question was posed on the APM Forum by Martin Dunn last year on external or internal sponsorship (also see Martin Samphires response).

And what of the times when the user (of a capability you are delivering) is not the customer? The end user can be more important (ie. has more influence) than the person paying the bill. It is the Senior User that sits on the Project Board; it is the Business Change Manager who sits on the Programme Board . The voice of the customer is left to the SRO or Project Executive according to theory. This is when it pays dividends in having sponsor or customer representation on the board - as a specific identified role.

Remove confusion through good governance
When they are different, it is very easy to confuse customer with user so take steps to remove that confusion from within your team. Any such action should be part of a robust stakeholder engagement plan, but these are only really effective when married up with your governance arrangements - and your benefit management plans and the management of your user requirements. Does your test & acceptance plan dovetail into the benefits realisation plan? Does your User Requirements Document explicitly state who the users and customers are?

Remember that cui bono is not the same as qui emit
The importance of the alignment and integration of these key plans can be overlooked, but they can address another dimension of any confusion within your team those who benefit. Customers and users are usually beneficiaries of some kind, but other beneficiaries can be perceived as customers in the minds of your team, potentially giving them false levels or proximity of influence. Dont let the multiplicity of stakeholders sow discord and confusion within your team. Use the Benefits Management tools (identification, profiles, realisation planning) to help provide clarity.

Be proactive in your stakeholder engagement
Stakeholder influence analysis within a programme is multi-faceted it can depend on the point of perception (e.g. inside/outside, programme/project). Very often actual stakeholder engagement plans can be lip service to theory, but for programme success they need to be live, responsive, focused and proactive (see Donnie MacNicols recent blog on the art of successful stakeholder engagement). But they also need to be integrated with the rest of the programme management system (as pointed out in the Body of Knowledge).

Speaking from current experience, its easy to say all this and difficult to get right - but oh so important that you do.