Stakeholder management

I’ve noticed this week some more of the differences between Cisco Australia and Cisco UK. Particularly, the degree of stakeholder management within a project, change initiative or complex deal. I’ve found it missing on a few occasions this week, when I have thought it should not have been.

So, stakeholder management for a sales person. Essentially it is knowing who cares about the deal, or might get in your way, or is required for it to proceed (such as approvers in finance, legal or sales management). Then keeping them up-to-date in advance of them needing to know.

I had plenty of stakeholders in a major negotiation I was leading for Cisco whilst in the UK, as part of BP’s global network sourcing tender was called the GTS RFPs. Then I had to actively and pre-emptively manage stakeholders. I’ll be using this deal as an example often in my blog, within the constraints of having signed a non-disclosure agreement and commercial sensitivity of course.

The GTS RFPs had a core response team in Cisco of 20, who actively worked on our submission the four service providers responding to BP. There was an immediate circle of 30 people who were approvers or had some accountability, such as my boss (Cisco’s European-based Director for Global accounts) and our VP. Then lastly was the group of interested parties, which was quite broad.

I liaised regularly, daily, with the core team and emailed the stakeholders weekly or so. Interested parties perhaps every two or three weeks, if I remember right.

I had everyone’s names documented in a file which was shared in the team’s webex file server, which was accessible to all interested parties by invitation. It listed their role and scope of responsibility (such as global or USA or UK). For people I was not familiar with, I had verified this information was correct; it was not assumed.


When an escalation occurred because one of the service providers did not feel Cisco was helping them adequately or was interfering, all the stakeholders to whom they could escalate already knew the current status of the deal. They knew our negotiation strategy and position. They knew we were treating all SPs equally, carefully, following’s Cisco’s “level playing field” principle.

Thus VPs and other senior folk who got dragged into the escalation had some background already.

Another reason is it minimises noise. Some people think that communicating with stakeholders creates work, because you get people trying to meddle when they should not or have no authority to do so. I have found the reverse, that actively managing stakeholders minimises interference because they are better informed. This counters the issue that people meddle when they do not understand the full richness of a situation.

When to do it?

What degree of stakeholder communication and management is appropriate to a given deal? When should it be performed and then, what kind of comms are appropriate?

I bet that if I were to check the literature, someone will have already codified some sensible rules for this. I might do that one day.

My experience is that you should do it when any of these conditions are true:

  • the deal has more important stakeholders than you can easily speak to in one conference call, due to scheduling difficulties
  • there are various parties whose approval you need and whom will want more than a quick brief the day before they’re asked for approval
  • because the complexity of the deal, or scale, makes it more complex than a simple off-the-shelf transaction
  • when it’s something completely new and innovative for the company, and thus requires many non-standard behaviours from a number of people
  • when there’s a good probability of an escalation to management a few layers above you
  • if there are parts of the organisation who will resist the deal or try to prevent it because of some political vested interest.