Adopting Web 2.0 PM Tools – A Question of Balance

My last post began to make a case for Web 2.0 tools as something that can give project teams access to collaboration and information sharing capabilities that many organizations have viewed as simply out of reach. One of the risks in embracing a new technology is that it may consume a lot of time and resources doing well, something that wasn’t worth doing at all. After all, Project Managers often struggle with just getting things done, never mind the challenges of learning new software tools. Why is information sharing and social networking software worthy of a Project Manager’s attention?

Implicit in a discussion of project team collaboration and information sharing tools is the idea of a Project Management Information System (PMIS). Functionally, that’s the set of tools (and I use the term in its broadest sense) that project managers use to organize project information. The information can include all of the formal project management documents (e.g., charter, project plan, change requests) as well as emails, schedules, forms status reports, meeting minutes and other documents that chronicle the life of the project. The information tends to exist in a variety of different formats, and individual documents tend to have a short working lifetime. All organizations have some kind of system but there is great variation in terms of how explicitly it is recognized, how much structure it imposes and how consistently it is adopted. The reality is often no formal PMIS that anyone would recognize as such.

In fact, there is a strong temptation to believe that’s good enough.  The usual focus for Project Management software is something to help Project Managers with planning, tracking and reporting on project activity, and desktop PM software does that well. But suppose the project team is charged with the business end of innovation — developing new products and services. Projects like that carry lots of pressure to respond to changing circumstances quickly with informed decisions. And what if the project team members rarely get a chance to meet face-to-face? It doesn’t take too long to make a case that the day-to-day work of project teams can be improved by giving them better access to project information when they need it and wherever they happen to be.

Unfortunately, there is no simple formula for picking the right software or the right implementation path. Much depends on where the individual organization is in their project management maturity journey, which is often not the linear progression we would like to think it is. For many organizations, embracing better project management tools advances more in the fashion of technology adoption in the marketplace. Early adopters who see value in something new and are willing to accept some trial-and-error are likely to blaze the trail, absorbing new tools in the way their teams work long before the tools become mainstream. Likewise, small organization operating at a simple “Do-It” level of maturity can gain almost immediate benefits with little cost by just using good practices that are embedded in freely available, web-based tools. At the other end of the spectrum, organizations that have already reached a high level of standardization can still benefit when project team have access to improved information sharing capabilities.

Adopting the tools becomes a question of balance. Like any knowledge-based capability, organizations improve their collective project management expertise in cycles that balance informal knowledge gained through experience with structured knowledge codified in templates, procedures and processes. Each cycle of the learning process should be adding just enough structure to make a difference at a practical level and to carry the organization’s strategic priorities a step forward.