The Project Wall Blog

(This post is the third in a series of five)

In the first two posts of this series (here and here), we discussed that the first order of business when dealing with a social project management software vendor is to determine first, if they are selling social software at all, and second,  if they are selling project management software. In this post we discuss something that most vendors claim to provide – support for social enabled teamwork and collaboration.

The third question that you should ask any social project management software vendor is: “Do you provide what my team needs to collaborate fully on the project while minimizing the impact of project management tasks on project completion.” In order to deliver on this question, a project management software system must (1) help the team to connect together to collaborate, (2) allow as much project information as possible to be shared widely and openly, and (3) provide capabilities for project team members to perform their “project management” tasks easily, and preferably, transparently.

Team Transparency and Interconnectedness

Too often, projects are plagued by a lack of transparency and connectedness, both between the project team members, and between the team and the project manager. This is even more true when teams are geographically distributed. Transparency and connectedness is typically highest in teams that are collocated in the same room. This is due to the ambient awareness that emerges within a group of people who have few barriers to their ability to “catch” portions of conversations, body language, and other non-verbal communication cues. As barriers to the development of ambient awareness, via walls, miles, or organizational barriers, transparency and connectedness become more difficult to maintain. This is one place where social software has a potential transformative application.

Most software applications that claim to be “social” apps utilize the concept of an activity stream, or a “wall” that shows a continual stream of updates. This concept is, of course, most famously implemented in the Facebook wall (now News Feed), and is becoming nearly ubiquitous in the “social” software implementation. What makes this activity stream so important is that, when well used, it is nearest approximation that we have yet devised to the stream of “ambient” information available in the environment when we are near other people. In fact, there is emerging research that illustrates that people are better able to “make sense” of a number of small chunks of information than of a large, detailed document.

Further, as the nature of the information within the activity stream becomes more diverse (as when multiple apps are integrated into an enterprise social system), the activity stream becomes even more like a real project team environment, where multiple tasks and execution contexts are simultaneously occurring .

Finally, to be clear, an activity stream is NOT a discussion forum. Although it exhibits characteristics of a forum, an activity stream’s value and power come from the fact that the information in the stream can be posted by people intentionally, people unintentionally, and by the system itself. Intentional posts are the “status updates”, questions, and other pieces of information that people add to the stream. On Facebook, this might be the cute photo of your kid, or your post about the fact that you were stuck in traffic for an hour.  Unintentional posts are the “by-products” of action within a system. On Facebook, this might be a notice that you’ve “leveled-up” on Mafia Wars, or that you’re listening to Billy Joel on Spotify. In a social project management system, an unintentional post might tell the team that you’ve just finished a task, that you’ve added a document to the document library, or that you’ve just opened an issue that affects the team. Finally, system posts are those posts that humans are not directly involved with. On Facebook, it might be a “friend suggestion”. In a social project management system, it might be a notification to the team that the project has crossed an action threshold, or has missed a deadline.

In short, the integrated and diverse nature of the information on an activity stream helps increased transparency and interconnectedness on your project team.

Access to Project Information

However, far more information is generated and consumed on a project team than what is represented on the activity stream. Project schedules, documents, issues, changes, reports – the list goes on and on. Unfortunately, in most projects these documents are restricted in their distribution and are, in some cases, limited in the access that project team members have to them.

Here is one area where social project management is most closely related to Project Management 2.0. Social project management systems embrace the PM 2.0 concept of the democratization of data access, even while at the same time ensuring proper control over data modification. By this, we argue that Project Management 2.0 had it right when it argued that all of the project information should be available to and accessible by the project team, no matter where they are. However, we also hold strongly to the perspective that most projects still need to be managed, and that certain documents such as the project schedule, still need to be controlled by the project manager. The project plan (and, depending on your project other documents as well) should be always available online to the entire team, but must be able to be controlled.

So, a social project management system is differentiated from a Project Management 2.0 system in the capability to control project information granularly, while ensuring the constant and broad access to the same information.

Project Management Task Execution

Finally, a social project management system isn’t very useful without assisting in the maintenance and completion of project tasks. A social project management system differentiates itself from a social task management system in that the tasks represented in a social project management system are tied back to the real project plan that is the heart of the project (the differences between these systems will be expanded upon in a later post). Rather than a simple to do list, in a social project management system the project tasks assigned to each team member in the project plan are surfaced to each team member. More importantly, when a project team member updates their task list, by marking a task partially complete, or fully complete, or by adding a comment to the task, or attaching a document to the task, this information is reflected in the system wherever it is relevant. Task status updates appear on the wall, the Gantt chart is automatically updated, project and portfolio reports reflect the change, and other people assigned to the task can see the document and comments.

In short, a social project management system should strive to minimize the “work about work”, and let reporting and (appropriate) communication be a by-product of action. Gone should be the days when a project manager chases down the team for task status updates. A team member should never have to wonder if a team member finished a blocking task. This information, and much more, should be represented in the system with as few manual steps as possible.

In summary, a social project management system should (1) help a team to be integrated and connected by simulating as closely as possible the interactions that are only really possible when collocated, should (2) democratize the data of a project, without eliminating necessary controls, and should (3) streamline and eliminate as much “work about work” as possible.

Stay tuned for question #4. Please comment below.