Project stakeholder management has borrowed many of its concepts from other discipline areas. This cross-usage of wisdom is helpful but its application in projects is still to be proven and bedded-in to the way we do things. After all, it’s only in the last few years that stakeholder management has been recognised in project management bodies of knowledge. In the meantime trial and error application has resulted in a number of myths about its application to projects.Continue reading “The myths of stakeholder management”
When rolling out new IT infrastructure to a large number of client sites, it is tempting to consider it to be the same project over and over again. But while the project may be justified in terms of the standardisation of technologies across the corporation, how those technologies get implemented and exploited by each business area may be substantially different.
Phil and his team recognised that the crucial factor, the thing that would make-or-break this global project was not the technology but the differing business contexts and stakeholders concerns that each roll-out would deliver into. A previous attempt at implementation had been a costly failure – the business knew it and needed other options. Fifty-seven countries impacted; 12,000 applications reduced to just one thousand; the very way that users could access their PCs would change with admin rights removed from all personal computers. These changes were far-reaching, and their instigation by a central controlling group was unlikely to meet with group-wide excitement and positive emotions!
The business agreed a new approach was necessary. The first actions taken by the project manager, Phil Urwin, was to send members of his team to visit the twenty hub-countries and establish the stakeholder success criteria. What would make it good for them at their site… in their words? Phil’s aim was to convert the technology implementation into a stakeholder-led programme. Each site visit resulted in a 2-page summary of what mattered to the local stakeholders, and each site was different. Some reported non-technical users who would need hand-holding – others reported good technical skills. Implementation no-go times, PC wants and needs- all captured succinctly in the 2-page mandate for the site implementation.
The rollout project was a large initiative for the company. At the Head Offices in the UK, the normal governance structures existed – “these role-based stakeholder engagements were engaged through formal structures, but often there was little interest from them beyond getting a view about the status of the project. It was with the agenda-based stakeholders that we needed to focus our attention.” The project established open channels of communication with these groups using webex or whatever medium best suited the participants. Before and during the implementation this was crucial and resulted in at least weekly meetings. While the project team took responsibility for the initiation of the meetings, the agenda was driven by the stakeholders – it was definitely their meeting.
With fifty percent of the programme rolled out and four of the largest implementations completed the signs are good. Customer satisfaction ratings were previously 2-3 and during and post the implementation moved from 4.1 to 4.6. When asked about the lesson learned from the project, Phil describes two critical areas:
- A stakeholder-led project. Right from the start, the project outcomes were aligned to the needs and agendas of stakeholders in their own business context. Phil does not talk about the technology or what it could or could not do – his total focus is on addressing these concerns.
- Stakeholder-focused, “like-minded team.” It’s not enough for the project and project manager to be stakeholder-focused this attitude and approach must be propagated throughout the whole team. Following the process is not good enough (although the process matters) the understanding and buy-in from every team member is crucial to translating good ideas into a reality on the client site.
Phil Urwin is currently a programme manager with The Grangeside Group. In September he will be presenting at the New Zealand Project Management Conference in Christchurch on how to recruit the right project manager, develop and keep them. http://www.projectmanagementconference.org.nz/
My thanks to Phil for taking part in the Success Stories Shared initiative.
Success Stories Shared is a South African initiative to encourage sharing across the project community. Driven by Louise Worsley & Linky van der Merwe, you can find these stories online on this blog site or at http://www.virtualprojectconsulting.com/success-stories-shared/
If you have a story to share, please do contact us:
- Louise Worsley: firstname.lastname@example.org
The ‘six-whys’ of communication is discussed in a series of blogs. In this one, the focus is on communication as information-seeking.
Communication as information-seeking
In information-seeking, the ‘who,’ ‘what,’ and ‘how’ questions are critical. Who should we be speaking to about what, and most importantly, who has the authority and expertise to answer the questions. This demands an excellent understanding of the stakeholders’ sources of power and careful thought on how to categorize and group stakeholders for the consultation process.
The PMI process assumes that the primary purpose of communications is to ensure the project provides relevant, accurate, timely, and consistent project information to all the appropriate project stakeholders. This is a good starting point, but there are other reasons for communicating with our stakeholders. For communication to become purposeful, it is important that these are understood if we are to have any chance of formulating the right communications strategy. Aside from the four communication questions—what, when, who, and how—to truly understand the purpose of communication, we must, of course, ask one further overarching question: Why?