John Donne, a 17th century poet, once said, “No man is an Island, entire of itself.” Unfortunately, that hasn’t held true in many of the projects I’ve seen throughout my career. In large companies, projects are often removed from day-to-day operations and function as self-contained, independent units. In cases where the project team has been moved off-site, projects can become isolated islands in the company ocean.

This isolation certainly diminishes both the company and the project team, but there’s a simple solution to the problem: The project manager (PM) should also assemble a peer support group when assembling a team. A group of three to five people the PM can call on as a sounding board for project problems works well, as long as the group includes at least one person the PM can persuade to conduct an alligator review (a risk-centered peer review) of the project. Most good PMs do this routinely, never realizing that what they’re really doing is establishing a small community of practice (CoP).

Communities of practice are nothing new—they’ve existed in one form or another since the craft halls of the Middle Ages. They can be defined as any group of people who have chosen to come together to further their involvement and their knowledge in the day-to-day work of their profession.

The four levels of CoPs
In my experience, there are various “levels of organization” that a community of practice tends to evolve through:

  • Incipient
  • Networked
  • Established
  • Generative

The Incipient CoP is nothing more than the three to five people in the PM’s support group. Another example of an Incipient CoP would be a group of people who come together to jointly study for the PMP exam. This type of CoP tends to be oriented around an immediate need or problem, and it tends to dissolve and re-form as circumstances require.

The nimble PM views this level of CoP as the trial-balloon stage of development. Any CoP needs a core group to get it off the ground. The trick at this first level is to keep re-forming the group until the group members begin networking among themselves for their own projects and begin bringing in some of their own support group members.

Making the transition from the Incipient CoP to a Networked CoP takes patience and faith on the part of the nimble PM. Complex adaptive systems theory refers to this transition as “self-organizing behavior.” The nimble PM knows that the group simply has to jell to move to the next stage, but the payoff in terms of information sharing is definitely worth the wait for everyone involved.

A Networked CoP is one in which the links between the members have been formed and are overtly acknowledged. The members of the community routinely share knowledge and problems and are comfortable that they can contact individuals in the community for support, both collectively and individually.

At some point, a member of the Networked CoP will say something like, “This is how we handle risk (or scope or schedule).” This marks the next level of development, the Established CoP. In an Established CoP, the participants begin to define some level of consistent practice, and the concept of shared standards begins to emerge. This is the point at which the group develops “knowledge assets.”

Most of the current literature on CoPs focuses on communities at the Established level. This is where the company begins to regard the CoP as part of its own management structure and to expect that new hires will be accepted into the community for enculturation and mentoring.

Once a CoP becomes established and begins to promulgate its own best practices, there’s normally a strong desire to go to the next step of development, the Generative CoP. A Generative CoP actually produces a tangible product, be it a method or a training product. Within a company setting, CoPs at this level usually receive direct or indirect funding in order to support the creation of the product.

The four skills needed to run a CoP
Every PM has the basic skills and abilities to initiate and maintain a CoP. By our very nature, we’re organizers who can draw people together for a common purpose without needing to have position power. From the perspective of the nimble PM, building and supporting a CoP (at least through the first three levels) only requires a combination of the following tools from the PM toolbox. They are:

  • Visioning—Why do you want to come together? Someone needs to have an idea of why the CoP is necessary. This vision will be unique to every CoP. The only requirement behind an initiating vision is that it be universal enough for others to share it, and flexible enough to change with the needs of the community over time.
  • Gathering—This is the knack for drawing people together to participate in a shared vision. A nimble PM knows that the trick is to draw people based on the vision rather than on their own personality. Strong, charismatic leaders will often fail dismally at this step. A CoP is a community of peers—any hint that it’s one person’s private fiefdom will doom the entire undertaking.
  • Holding center—This seems to be the element most of the CoP literature misses. Someone—or a series of someones—must provide the organizational infrastructure that lets the group continue to function. Ninety-nine percent of the time, this person will be the keeper of the mailing list. The PM who chooses the role of holding center might not be the same person as the original vision holder, but the group will dissolve if the current “center” doesn’t carry the vision as strongly as the initiator.
  • Facilitation—CoPs, once they’ve gotten off the ground, are self-organizing entities. They will end up being something unique to the current members. Unfortunately, that doesn’t mean they’re completely self-managing. Someone who is an acknowledged “vision holder” must still be in a position to say, “No, this is not what we’re here for,” or, “No, this is contrary to what we believe.” I’ve found that facilitation is often a shared function among a number of long-term members.

In my experience, the nimble PM must have the vision of why the group is a good thing and be able to sell that vision to the group. Beyond that, it helps if the nimble PM excels in at least one of the other factors and is backed up by other community members who can pick up the other functions.

Having reviewed the four stages of a CoP and the four skills nimble PMs need in their toolbox in order to initiate and run a CoP, I need to reiterate why a PM would want to take the time and trouble to create a CoP in the first place.

The simple answer is, in order to be a better PM. No one knows everything. We all learn something every day, and we’re all capable of learning almost as much from the experiences of others as we are from our own. The more complex answer is that everyone benefits from the existence of a CoP. The company benefits because tacit knowledge is more freely shared between project managers. The PM benefits because increased knowledge and support effectively lowers project risk and increases the probability of delivering the right product, at the right time, for the right price.

In the final analysis, communities of practice aren’t the solution to every problem in project management, but based on my own experience of running a worldwide CoP for the past five years, they can be challenging, enlightening, and, for the nimble project manager, a rewarding place to invest one’s time and energy.