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

Save for later


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.

Andrew Gray

Posted by Andrew Gray on 9th Sep 2014

About the Author

Andrew is an experienced project and programme manager with a blend of practical and theoretical knowledge of the management of engineering activities across the product development cycle. From an engineering background in the aerospace sector spanning 20 years he has led teams in multi-discipline, multi-site and multi-cultural environments. Andrew now works for BMT Hi-Q Sigma where he advises clients in all aspects of complex change management. Andrew is a UK and European Chartered Engineer, and a member of the APM, the Royal Aeronautical Society (RAeS) and a past member of the International Council for Systems Engineering (INCOSE).

Andrew is a past committee member of the APM Programme Management SIG, where he co-authored the recent update to the “Introduction to Programme Management” guide, but he has also been a founding member and the secretary to the Systems Thinking SIG. This new SIG has grown out of a joint working group between APM and INCOSE UK formed in 2013 and is publishing via the APM a range of guidance addressing the integration of P3M and Systems Engineering disciplines.  Past conference publications in this area include a paper at the Annual Systems Engineering Conference in 2015, and a related co-authored paper  presented at the INCOSE International Symposium 2017 in Adelaide.

Comments on this site are moderated. Please allow up to 24 hours for your comment to be published on this site. Thank you for adding your comment.

{{item.AuthorName}} {{item.AuthorName}} says on {{item.DateFormattedString}}:

Join APM

Sign up to the APM Newsletter.