Monthly Archives: April 2011

ProjExec 5.0 reviewed on the AppGap Blog

Please see the review of ProjExec 5.0 on Bill Ives’ TheAppGap Blog.

Bill focuses on the integration of ProjExec with the IBM collaboration stack. This is a key concept of social project management and social business software in general. Technology-enabled business contexts must stop being islands. With social business platforms and open standards for activity stream syndication, we are reaching a turning point in online collaboration.

Whether or not a company is an IBM or other vendor customer, whether or not a company uses ProjExec, AtTask, or Wrike, companies need to start reclaiming the social capital of the organization, not merely the immediate business team. This is not possible when the social business application is not integrated into the social business fabric of the organization.

Advertisements

Peer-to-Project Communication: What if the Project Itself was a Member of the project?

Social Project Management introduces the concept of “peer-to-project” communication, which we explored in a previous post. Peer-to-project communication starts with the idea that the project is an entity that can be communicated with, and an entity that can communicate back. With Social Project Management, this is the reality.

For example, let’s look at Facebook. When a person interacts with Facebook, his or her activity stream (wall) is the communications channel. Friends’ have walls and, more importantly, things like businesses, causes, animals, etc. also have walls. These activity streams that are for “non-humans” behave (in general) the same way as people’s activity streams. Users of Facebook “subscribe” to information by liking things and “friending” people. Once that connection is made, the activity streams of people and things are linked, and can communicate bi-directionally. Importantly the distinction between people pages and “thing” pages dissolves.

Where social project management builds significantly more value than other web-based collaboration tools is with the richness of the project entity. Rather than being simply a container through which teams can collaborate, a social project management system build collaboration around the typical tools of the project manager, including a work breakdown structure and project schedule.

In a social project management setting, when a user is added to a project, they subscribe not just to the collaboration framework for the project, but also to all that the work breakdown structure and schedule provide. First, a project user receive access to post things to the wall, and they receive status updates when others post there. Importantly, the project itself can also post there.

So, second, when a person finishes a task, it is published to the project wall by the project, eliminating the need for the person to complete a separate reporting task. Third, when a task is in danger of being late, the project can communicate via the wall and make the risk known to everyone. Fourth, when a task is completed, the project can communicate to the team and let them know which other tasks can now begin.

While this scenario focuses on the communications benefits of social project management, we will discuss the power of social project management for risk management, resource management and management reporting in a future post.

In a real sense, the large portion of a person’s project communication can be re-focused to the project as peer-to-project communication, rather than as direct peer-to-peer communication. While we would never argue that limiting peer-to-peer communication is a positive thing, with distributed teams, the more that peer-to-project communication is adopted, the more ambient awareness can be generated, and the more a non-collocated project team can “feel” like a collocated team.

Peer-to-project communication via the activity stream helps team members and others understand what is going on, even if they are not directly involved with every task. Making the project itself a communicating member of the team is a great step to building awareness, especially as the size of the team grows, and the geography of the team widens.

And now, a word from our sponsors…

As we mentioned in our first post, the project wall blog is sponsored by Trilog Group.

For those of you who are IBM customers, running Domino, Quickr (Domino or J), Websphere, or Lotus Connections, Trilog Group’s ProjExec 5.0 is the Social Project Management platform that is designed to work seamlessly with whichever part of the IBM collaboration stack you’re running.

Rather than a standalone project management system like MS Project, or any of the many, many web project management platforms that are out there, ProjExec 5.0 is designed to be an integrated component of your social collaboration context, rather than an island.

Check it out at ProjExec 5, Social Project Management for IBM Customers.

Now, back to our attempt at unbiased discussions of social project management :).

Developing Peer-to-Project Communication with Social Project Management

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:

Communication Paths Increase as Staff Number increases

The concept of communications path complexity (peer-to-peer communication)

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:

Peer to Project Communication

Communication Paths in Social Project Management (peer-to-project)

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,