The layers of a stakeholder relationship
I hope you can now see how stakeholder management skills are built and layered on top of each other, like building blocks. The further you want to build your relationship, the more blocks you will need to advance, and the tighter the blocks need to be. Quite simply, you can't build a relationship with your stakeholder if you're not somehow communicating with them.
Moreover, this communication should be two-way, even if the relationship is between an author and their readers, which may seem like a one-way relationship. There is still dialog and interaction through reviews, comments, and social media, where the author will get feedback and can respond to it.
Remember that stakeholder management is essentially about building and maintaining relationships and setting and meeting expectations. Your communication plan can be as simple or complicated as you wish. The critical success factor is whether or not it ensures that recipients receive and understand the message you are trying to communicate to them. In other words, does your communication plan create relationships and manage expectations?
In a project scenario, the most typical communication methods include the following:
- Regular status update emails or newsletters
- Requirements and design workshops
- Focus groups for feedback
- Steering groups with budget holders
- Project Management Office (PMO) updates, publications, approvals, and announcements
Within these communications, the basic information of target dates and deadlines, milestones, budgets, commentary on progress, and risks and issues should be included for the appropriate audience. The emphasis is on tailoring your method, as well as content for the target audience, while maintaining a consistent approach and regular cadence, which both help to set expectations. A "weekly project update" should be issued weekly, without fail!
Especially in non-waterfall projects, and for typically more web-based products, I have also seen highly effective examples of more new-age communication methods, including the following:
- Blog posts
- Webcasts
- Show and tells
- Early product demos
- Even hackathons to engage both users and developers
While these may not seem like a logical part of a communication plan, they are all options that you can, and should, think about incorporating. They are not just a novelty, because they can help to make your project stand out, and they really do work.
The goal of your communication plan is to engage and influence stakeholders. This is also the key to setting and meeting your stakeholders' expectations and making sure they know that their expectations have been met!
While your plan, like all plans, will have a start, middle, and end, meaningful engagement and influence are very much a process. You earn your stakeholders' trust and build up your relationship, step by step, little by little. The end goal is to set, and then meet or even exceed, their expectations.
To fulfill their requirements, satisfy their needs, or attain your mutual goals, APM lists 10 key principles in stakeholder engagement:
- Communicate
- Consult, both early and often
- Remember, they're only human
- Plan it
- Understand that relationships are key
- Be simple, but not easy
- Just be part of managing risk
- Compromise
- Understand what success is
- Take responsibility
I've picked out three of these as the quintessential points and central themes to our context of key manager skills in software development, although, they all do play an important part.
As we know, the technology behind our solutions and products are, relatively speaking, simpler than the people involved, which includes ourselves. In other words, it's the people who make developing software complicated. That's not a disparaging comment in any way. It's a pragmatic acknowledgment that stakeholder engagement is absolutely necessary because developing software is a collaborative endeavor.
We have already covered the importance and key requirements for effective communication and how it enables engagement.
The APM has a case study on the ground-breaking National Health Service (NHS) IT program, which was established in 2002. Despite the difficulties and ultimate cancellation of a huge project, there are a number of extremely valuable lessons for all IT projects, especially large-scale programs such as the NHS National Program for IT.
I worked on this program for two years and witnessed some of the very real challenges that the IT and non-IT stakeholders both faced. Most of these were, in fact, different sides of the same trials and tribulations. Some were avoidable, and some were inevitable in such an ambitious program of work to revolutionize the biggest public healthcare system in the world and the world's fifth largest employer. All of these challenges had something to do with engagement and collaboration between people and stakeholders.