It’s Stakeholder, not Steakholder

January 19, 2013 | Author: PM Hut | Filed under: Project Management Best Practices, Project Stakeholder Management

It’s Stakeholder, not Steakholder
By Robin Johnston

In the 1988 movie ‘Working Girl’, Alec Baldwin delivers an ultimatum to Melanie Griffith, to which he receives the response “I am not steak – you can’t just order me.”

I’m sure the line was never meant to be relevant to corporate communications, but I’ve never found one that better sums up the manner in which some communications strategies rely on beating their audience into submission.

In the past (and I mean the long distant past), leadership styles were significantly more authoritarian than they are today. Raising issues with management direction could have been a career decision. And in some companies this can still be the case, although thankfully it is now the exception rather than the rule.

Today’s Management Boards have recognized that simply mandating a change does not ensure its successful delivery. While everyone may pay lip-service to the objective the fact remains that people are, in general, very resistant to change.

When proposing a program of strategic change, one of the first things that needs to be appreciated is the fact that dragging people towards an objective is not nearly as effective as having them gravitate towards it.

One of my favorite bloggers, Daniel Burrus, wrote an interesting piece a few weeks ago that clearly articulated the difference between collaboration and cooperation, and pointed out that people confuse the two. The key distinction he makes is worth repeating here:

“Cooperation is based on a scarcity mindset; it’s about protecting and defending your piece of the pie. Collaboration is based on an abundance mindset, working together to create a bigger pie for all”.

Seems obvious, doesn’t it? But where Change Management activities are concerned, it’s one of those key distinctions that tend to fall by the wayside in the headlong rush to build consensus and move forward. The problem of course is that if you settle merely for stakeholder cooperation, everything you build thereafter will be less stable and the consensus is liable to develop cracks. If you want to build on a solid foundation, you need your stakeholders to want what you want. In order to do this they have to share your vision, not just execute it.

And that, when all is said and done, is the tough bit. How do you get a group of stakeholders not just to move in the same direction, but to want to move in the same direction and to encourage others to come with them?

Your new strategic direction may promise inescapable benefits for the organization, but it may also have a dramatic impact of a vast number of careers. It may require employees to learn new skills, or new ways of working. It may require changes in their reporting lines or the manner in which they are remunerated. Suppliers or customers may be required to work with you in new ways (which can be tricky to enforce with suppliers, and next to impossible with customers). It may also mean that some existing roles become redundant, in which case having your stakeholders believe that as one door closes several others will open is of critical importance.

There will undoubtedly be personal issues that shape the opinions of stakeholders both inside and outside your organization, and you will need to understand them (something I’ll come back to in a future post), but your first priority should be to understand where everyone fits, both in terms of how they can impact the project and how they are impacted by it. This is the essence of Stakeholder Segmentation.

A large group of stakeholders can be segmented in a number of ways, but the key requirements are to understand where they fit in terms of reporting and role, to understand their level of seniority or influence, and to understand the likely impact of the project on their day job or, for external stakeholders, their business.

Getting the names of all these stakeholders, their responsibilities and other key information is not a difficult task, but it is time consuming and unfortunately there is no way around it.

Existing org charts will take you some of the way there, as will mailing lists, but the remainder will largely be grunt work – talking to colleagues, making phone calls, sharing iterations of the list and seeking feedback until such time as you can be sure it is broadly complete. There will always be one or two that you miss, but they will become apparent as soon as the comms flow starts.

With the list in place, you can start to determine what kind of communications detail will be required for each audience. Your IT stakeholders will likely require very different information that that required by your marketers, or by HR, or your suppliers, and while you may be able to use some of the communications materials across all stakeholder groups, each group should feel that the materials you develop have something in it for them. Remember, the more information that does not apply specifically to a particular stakeholder, the less likely that stakeholder is to read it. Management may have mandated the change, but getting the stakeholders to pay attention, understand and actively engage will be on you.

If you need to go to the length of producing modular communications material, which is entirely possible, you will need to start building relationships with the experts in your project team and project board.

The Project Manager is always a good place to start, and he/she will be able to describe the skill sets available to help you develop the detail that the communication may require. In addition, your project’s Senior User or Senior Supplier will be able to help you be aware of some of the key challenges that exist, both in terms of the benefits that are expected and the challenges of implementation. I should probably point out here that I am using Prince2 project management structure, since that is what I was trained in, but other Project Management methodologies encompass similar roles.

This will be the point at which some sensitivities exist, as you will also have to segment your stakeholders based on perceived level of support and influence. Those who support the activity may be able to become active in influencing others, but you will need their support to be on message because not only do you want them to communicate correctly and not start any unnecessary rumors in motion, but also you want them to bring you feedback so that any level of resistance apparent in initial discussions can be addressed while it is still just a risk, rather than waiting until it becomes an issue.

There will invariably be certain key stakeholders who are skeptical or hostile. It is particularly important to highlight who they are at an early stage, particularly if they have a level of seniority that could delay or undermine the project, or if they have expertise that is held in high regard by other stakeholders. A bit of extra time or effort spent on syndicating objectives with this group of individuals, and sounding them out for objections or concerns will pay dividends in the long term.

In order to be certain of their views and to encourage their positive engagement, you may need to use “man defense” rather than relying on “zone defense”, meaning they will need to be approached on an individual basis, ideally by someone within or close to the project, and with whom they have a good relationship.

This ‘relationship owner’ takes responsibility for representing the details correctly, engaging frequently to secure feedback, and reporting the substance of any resistance back to the center.

This is unfortunately quite a labor intensive way of engaging (to ensure just one individual is in possession of all the facts, and that his or her opinions are accurately recorded), but in a small number of cases you may find there is no substitute for it, and even that it can be more efficient.

Finally, while it is important to know what your stakeholders think, it is just as important that they know you know and that they have confidence that their concerns are being taken seriously.

There is only one thing worse than being confronted with a change you don’t agree with, or not knowing who to talk to and how to raise concerns, and that is to talk to someone and raise concerns and never hear anything about it again. If this happens, you’ve taken a key step towards getting your stakeholders engaged and then dropped the ball by not letting them know that you’ve heard their concerns, that you’ve shared them with the relevant people and that an answer is being developed. In short, you’ve given the impression that their views are irrelevant.

If you don’t have an answer, don’t bullshit them. They will almost certainly find out and when they do you will have gone 90% of the way towards losing their trust forever. Tell them you don’t know, then go and find out what the answer is. Unless you’re dealing with a stakeholder who has a particularly poisonous agenda (and they do exist), you will gain points for honesty and collaboration far more often than you will lose them for being “unprepared”.

Is this all there is to stakeholder management? Of course not but this is a blog not a book, and following these basic steps will at very least move you in the right direction.

Robin Johnston is a Client Service Director at Inkblot. Inkblot is a virtual agency, sourcing the best available talent for each project, from brand identity development to fully integrated marketing campaigns, across traditional above and below the line, as well as digital media. You can read more from Robin on his blog.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories