Web 2.0 for Project Management – Why Email Isn’t Enough

My last post about Web 2.0 tools for project management led to two lines o f conversation with some colleagues. The first was about and how poor communication about requirements can lock in design mistakes early in Design / Build projects and lead to major rework costs later on. The other was about why we need to bother trying to get people to learn how to use a new communication medium. We all use email every day; isn’t that enough?

Three “C” words tie these threads of conversation together: Communication, Coordination and Collaboration. Not a particularly original phrase, I admit — Lotus Notes jumped on it a long time ago to promote its (then new) groupware capabilities. Nevertheless, making it easy for people to work together is one of the cornerstones of project success. Writing in the Project Communications Bible, Bill Dow and Bruce Taylor cite communication deficiencies as the leading root cause of why projects fail. They go on to spend more than 800 pages in a practical exploration of how to apply good project communication practices to all aspects of project management.

Michael Sampson argues that Collaboration in the context of project management just summarizes key ideas conveyed by the other two “C” words. In his view, a good collaboration means that the project participants communicated well, debated openly and worked together to achieve a set of objectives that everyone understood.

Applied to any Design / Build project the most critical collaboration among project stakeholders is arguably requirements definition. We all know (and the PMBOK reminds us) that the ability for stakeholders to influence the final product of a design/build project is highest at the beginning and diminishes exponentially over the life of the project. The mirror-image is the cost of accommodating changes, which increases over the life of the project at a rate similar to the decrease in stakeholder influence. That is as true for putting up a building as for developing a piece of software. Providing a forum that encourages a high level of end user involvement early in the project is a strong measure for preventing a host of problems (not to mention risk of rework) later on. Effectiveness of that involvement can be judged, at least in part, by how well it promotes open debate about requirements.

In an ideal world we would have lots of opportunity to bring key stakeholders together in a series of meetings that would provide the forum for debate about requirements. Design team could go happily on their way, confident that they had an accurate set of requirements to build from. Sadly, we don’t live in an ideal world so we look for technology to help the project communication process. The first place we usually turn is still email because it’s easy to use, it gets the job done and we feel like we have a certain amount of control over it.

The problem with email in projects stems from the way people interact with it. Partly, it’s volume — email contributes a big chunk of the information overload that we all struggle to cope with daily. It’s easy for important project communication to get lost in the flood. (How many messages do you have in your inbox, how many are unread, and how many are messages that you actually wanted to receive?)  The other problem is Information Channeling. Two individuals may start up a private discussion thread over email and actually feel that they are making a positive contribution to the project. However, that discussion may exclude key stakeholders, either consciously or unconsciously. Over time, people may move in and out of the thread through the CC list or the thread may be lost entirely if a key individual leaves the project or the organization. Lars Ploughmann suggests the following scenario for what could easily happen to a message about an important project change that has been approved when it is sent to 10 people via email:

• 9 people read the email
• 8 people file the email (in their private folders, thereby duplicating effort)
• 7 people are interrupted in their work or thoughts when the email arrives
• 6 people will never be able to find the email again
• 5 people didn’t actually need to know about the change
• 4 people joining the project in the next phase wouldn’t have received the email
• 3 people will be able to find the email again, should they need to
• 2 people will check back to the email at a later date when they need the information
• 1 of them will understand the email in context, be able to find it at a later date and action it

Web 2.0 tools offer the promise of better project communication, and more effective collaboration among stakeholders who don’t get to meet face-to-face nearly often enough. The challenge is that adopting the tools has far more to do with human behaviour than technology.  Research evidence and common sense both suggest that if technology doesn’t fit the organization and people don’t understand it they won’t use it. The outcome with social media could be just as ineffective as Lars Ploughman’s scenario, just transferred to a different technology platform.

High quality tools matter but the focus of attention should be what the tools let people do. If the goal is better collaboration then it should be easy to find all of the project information in one place and to engage in discussion through annotations and comments. As well, the pace of change needs to match people’s capacity to absorb it. People who are already accustomed to using sites like Facebook and Twitter know intuitively what to do. Others may need some guidance. All will need some time to judge the quality of the content, how easily they can participate in discussions, and how that affects project outcomes in the long run.