Communications planning on projects takes up a major part of the PMBOK. Because traditional project management is based upon a philosophy of control, project managers are advised to develop and maintain a detailed project communications plan, with important formal communications defined and agreed to by project stakeholders.
Having been involved in scores of projects as a project manager, we have prepared literally thousands of informal and formal communications for stakeholders. However, how many times when we were writing those communications did we think that the stakeholders really valued that information, and that they would really take (have) the time to understand the communications. Rather, we knew that when something was really important (an exception), we would have to call it out with a special communication, that probably was not defined on the project communications plan.
The theory driving the establishment of formal communications planning is network complexity. Who has not seen the image of what happens to communication paths when people are added to projects? Everyone has seen it, but I’ll still link to an image here:
Basically, as Fred Brooks pointed out in The Mythical Man Month, adding people to a project creates more theoretical communications paths, and therefore more potential communications complexity. Because teams are large and, because the communications challenges within distributed and cross-cultural teams are real, communications control led to the partitioning of communications, with the project manager or several project managers becoming communications hubs, responsible for the filtering and distribution of information in order to limit the complexity of communications across the team, and to attempt to reduce information overload see this article.
However, with the emergence of social project management, and the application of the activity streams paradigm, a new possibility for the management of communications emerges. With the project activity stream, or “project wall”, comes the concept that the project itself is a “member of the project”, with whom other project members can communicate, and who can communicate with other project members. This leads to a new paradigm of project communications, shown in this diagram:
Rather than viewing the project as a set of communications paths between individuals (“peer-to-peer” communications), social project management creates the concept of communicating between individuals and the project (we call this “peer-to-project” communication). While project team members will, of course, communicate one on one as necessary, applying the “Facebook” or “Tweet” paradigm to a project, creates a steady stream of information to the project, and from the project to the individuals.
In the diagram above note two specific things. First, ties to projects can be any strength. If a person is dedicated to one project, their ties to that project will be strong. If a person is assigned to multiple projects, their ties may be stronger to some and weaker to others. (An executive’s ties to projects will generally be weaker than the average project member on any project.)
Rather than having to maintain one communications path with every member of a project team, each member only has to maintain one communications path with each project, and then specific communications paths as necessary. However, if the peer-to-peer communications paths happen outside the project, the rest of the project team is unaware of the communications. Whereas in a collocated team environment, much of this informal human-to-human interaction is processed by individuals as part of the environment, in distributed teams this communication must be made visible through the collaboration system. As much as possible, social project management encourages the use of the system for peer-to-peer AND peer-to-project communications, creating the maximum ambient awareness for the team.
Conceptualizing the addition of a new project member as a new set of communications paths between each member of the project, we can conceptualize the addition of a new project manager as a simply a new peer-to-project path. This new path does not change the other peer-to-project communications, it simply adds another potential source to the communications paths.
Additionally, notice from the diagram that social project management, because it is embedded into the collaboration network of the organization, enables the seamless integration of external network contacts via the social networks of project members.
In a sense, peer-to-project communication with social project management is a publish-subscribe model for project communications. While this concept is somewhat silly when describing collocated teams, it is very applicable to technology-enabled teams. This publish-subscribe + tweet paradigm, where the external social network can be seamlessly integrated into the management of exceptions makes project management social.
Obviously, we believe that the social project phenomenon is significant in its impact on project teams. Whereas Web2.0 enabled the easy establishment of online collaboration spaces,