One of the most annoying challenges to manage as a project manager is the flow and volume of email communication. The equation to calculate the number of communication channels between individuals on a team is n*(n-1)/2.
Therefore, if you have a medium-size project with around 20 stakeholders, there are 190 possible communication channels.
By replacing all emails that require distribution list with RSS feeds, a PM can eliminate three problem scenarios that are exacerbated by the growth in communications channels as project teams grow:
1) Receiving far too many low priority emails via distribution list
2) Not being removed from email distributions that are no longer relevant
3) Accidentally excluding key people from important email distributions
Too Many Low Priority Emails
Receiving too many low priority emails via a distribution list is a productivity issue that can have a significant impact on morale. There is nothing worse than accessing your email first thing in the morning and having 100 or more new messages every day.
Then, the first two or more hours of each day becomes an exercise of weeding through all of those messages to find what’s important.
This problem gets significantly more difficult to manage over time, as most busy people will never plow through every email every day, and will end up with thousands of unread messages as the project progresses.
Receiving emails from past projects or teams that are no longer relevant is not only annoying to the receiver, but possibly a security problem for the sender.
This is a particular issue in a consulting company where consultants travel from project to project often. I have personally experienced this in my time as a consultant, in one particular case I was not removed from a distribution list and continued to receive emails from my past project who was a competitor of the company sponsoring my current project.
To make matters worse, in many instances it is common to ask repeatedly to be removed from the distribution list, only to be ignored.
Opps! You Didn’t Get That Email???
Accidentally excluding key people from important email distributions is the reverse of problem scenario two, and can create a perception problem especially if done too often.
It can be quite uncomfortable if an important stakeholder feels that you are repeatedly excluding them from certain communications on purpose.
As a PM responsible for constantly communicating with stakeholders who have diverse communication needs, the task of managing multiple email distributions is a responsibility PMs should automate as much as possible.
RSS Instead of Email
These three problem scenarios are good reasons why RSS feeds should replace email for project communications that require email distributions.
There are obviously several ways one could setup a communication system like this depending on project type. Nevertheless, I will share my high-level process for setting it up on a software development project.
Implement a content management system (CMS) that has a blogging system such as SharePoint for your project. The blogging system (or something similar) will become the foundation of the project’s communications platform. This blogging system must have the following four basic capabilities:
1) The ability to create categorized content
2) The ability to support multiple-users, and user groups with role based access restrictions to create, read, modify content per category
3) The ability for authorized users to comment on content (replacing the infamous reply-all button)
4) The ability to generate secure RSS feeds with role based access restrictions for each category of communication
Create the communication categories starting with at least one category for each functional team, i.e. project management, business analyst, architecture, development, testing, deployment, and training.
Create user groups and access restrictions for content (create, read, modify) per category as well as for accessing a categories RSS feed for each group
Add each stakeholder to one or more groups
Assign a moderator for each category to periodically review content and comments for appropriateness
Assign a moderator for each user group to make decision on who should be a member, who should be removed when job status changes, and what access rights each member should have
Create a task-force responsible for the change management aspects such as:
a. Educating all stakeholders on the need for this new framework, the security rules, and business processes
b. Hold a series of training sessions on how to use the system as well to reiterate the security rules
c. Develop a user guide
d. Provide an openly available list of the stakeholders that are part of each group within the system and who has access to specific RSS feeds
Create a page that anyone within the intranet can access to request access to one or more groups and/or RSS feeds.
Implement the system and eliminate all distribution emails
I am sure the ten high-level steps outlined above sound simple enough. However, there is always the risk that your stakeholders are either slow to adapt or possibly refuse to change completely. The best way to mitigate that risk is to make sure a highly skilled change management team executes step seven.
If you have experienced these problem scenarios, ever worked on a project team that has implemented a communication framework similar to this, or have any comments on how to improve this framework, please share in the comment section below.