can you hear me now?

​
​

​I am currently teaching a course in the Mohawk College and CARA Research Administration Certificate program. As part of this, I’ve been writing essays around each week’s discussion topic, in response to the discussions and reflections by the students. The next of these is on the topic of the stakeholder categories, prioritization, communications and understanding requirements and expectations.

---

The issue of the size/complexity of the team is a topic of some challenge for those new to research project management. Certainly, large teams with many layers and streams, dispersed across geography and time zones, are challenging (see also Too Much of a Good Thing). Project teams can plan for communication approaches but these often breakdown over time. An important thing about any of the tools used in large complex teams (or any teams): once they stop working, stop using them. If your quarterly email reminding people to send you their progress reports is not getting any replies, then use a different tool or approach. Even changing the language of the email or the sender can get people’s attention. If you have a persistent bad actor – always late/last/incomplete – call them next time a report is coming up and remind them of the deadline and ask them if there’s anything you can do to make providing the info in a timely manner easier/possible. As a last resort – nothing gets someone’s attention like missing a funding advance: if you can restrict the flow of funds until communication improves, sometimes that’s a lever that you need to push.

 
When the project involves change – such as, “we have a new expense claim process for you to use” – it is critical that the change be clearly and honestly described to the users. These stakeholders are in the impacted category – those who will be affected by the project and its outcome. For many administrative processes, non-administrators will not see the benefit to THEM to change. The new process might be easy, but if it is not easi-ER for them (especially if they used to have to do nothing and they will now have to do something), they will not understand why they should change so that your project can succeed. You can include the “big picture” when working on getting them to adopt the new process, but those who are less motivated by such things will not be sold. The project may be important but until you convince them that it is important to them, some users will remain stuck on the old system. (More on this when we talk about persuasion.)
 
Lastly, beware of using tools that can become static. When communicating information that people need to know, the tool used needs to command the attention of the stakeholder audience, be easy for them to navigate, and be an active communication channel. A common tool used to keep everyone “in the loop” is a newsletter, and this can work well as long as it done consistently (both content and time-wise) and doesn’t get too long such that no one reads it. When the format remains the same for too long, people stop paying attention. Another tool is a website, which works well as a repository of information but can easily become a passive tool for communication. Too many times I’ve learned about a change in a process, and when I asked further was told, “well, we posted the new form on the website…”, as if I should be monitoring that page of the website all the time for changes.
 
A product that the stakeholders don’t like or can’t/won’t use is not successful. We need to know who our project stakeholders are as it is their requirements and expectations that define the project and its product – the “why” of the project is to meet these wants and needs. But that doesn’t stop during project planning. Ongoing dialogue with stakeholders to ensure that the project’s product will meet their expectations – be of sufficient scope, quality, cost and schedule – to be considered successful.

---