Your working group project has just finished. The deliverable is signed off, the steering board has thanked everyone, and the working group's online space should, by every normal rule of project management, go quiet.

Except it hasn't. People are still posting in it. Someone's asked a question that has nothing to do with the original brief, and three people have answered it within the hour. Somebody else has suggested "we should keep this going somehow." That instinct, the working group refusing to die on schedule, is usually the first real evidence that you have something worth turning into a community of practice. It is not, on its own, a reason to do it. Let's go through the actual trade-offs.

Why should you turn your working group into a Community of Practice? 

You're not starting from zero. This is the single biggest advantage, and it's a genuine one. Most communities of practice fizzle out in their first six months because nobody trusts anybody yet, nobody knows who actually has the answers, and the founding members are still working out what's appropriate to ask. Your working group has already solved that. People know each other, know who's good at what, and have already built a shared vocabulary from solving a real problem together. 

The knowledge has somewhere to go. Working groups generate an enormous amount of tacit knowledge that never makes it into the final report.  The dead ends that didn't work, the workaround nobody documented, the "ask so and so, they’ve dealt with this before" knowledge that lives in people's heads. A community of practice gives that knowledge a permanent home and an ongoing reason to surface, rather than letting it evaporate the moment the project team is reassigned.

It builds organisational resilience. If your working group solved a one-off problem that will recur, and most public-sector problems do recur, in slightly different forms, for years, a CoP means the next person who hits that problem doesn't start from scratch. They ask the community.

The case against 

Not every working group should become one. This is the uncomfortable bit nobody wants to say out loud at the closing meeting, where everyone is feeling warm and fuzzy and "let's keep in touch" feels like the obviously right thing to suggest. Politeness in a closing meeting is not the same as a genuine ongoing appetite. If you skip the readiness check and launch a Community of Practice that nobody actually wanted, you end up with an embarrassing, visibly dying space that's worse for morale than no space at all.

Loss of momentum due to no deadlines. This is the number one reason post-project CoPs fail. In a working group, the impending deadline forces engagement. People have to log in, reply, and collaborate. In a CoP, participation is voluntary. Without a looming deliverable, members will deprioritise the community in favour of their new, urgent daily tasks. The community can quickly become a ghost town.

Who should facilitate a Community of Practice? Communities that are assumed to self-organise rarely do. Someone has to prompt discussion, welcome newcomers, chase down answers to unanswered questions, and quietly keep the thing breathing. If that person or persons were the working group's project manager or leads and they've now been reassigned to something else, the community has no oxygen left. Decide who does this before you launch, not after engagement drops off a cliff after a few months. 

Energy doesn't transfer automatically. Working groups run on deadline urgency. Communities of practice run on intrinsic motivation and reciprocity. People show up because they get something out of it, not because a milestone is due. That's a completely different kind of energy, and it has to be deliberately designed for. Simply renaming the group and hoping the same energy carries over is the most common and most predictable way these transitions quietly fail.

How to make it work

Redefine the "Why" Together. Before the working group ends, host a transition meeting. Do not simply dictate that a community is being formed. Ask the working group: “What did we enjoy most about working together? What topics do we want to continue exploring?” Formulate a new "Community Charter" that outlines the shared domain of interest. The members must feel a sense of ownership over the community’s purpose.

Match the Functions to the Purpose. The tools you used to manage your project may still be the right tools, but they will need to be used in a different way to manage a community. Identify the types of discussions, activities, content, and communication that will be needed for a community approach and how they differ from a working group.

Shift Your Leadership Style (From Project Manager to Community Manager). You must stop acting like an enforcer of the working group and start acting like a host of a Community of Practice. 

• Project Managers ask: "Is this task done?"
• Community Managers ask: "What do you think about this?"

Establish Community Rituals. Without a project timeline, you need to manufacture a "rhythm" to bring people back. Create predictable rituals:

• Themed discussion: Discussions on hot topics or requests for help.
• Key documents: Capturing the key documents, guide and information about the knowledge domain.
• Monthly Events: Bring in a guest speaker or team member for an exclusive Q&A.

These rituals create habits, and habits sustain communities.

Start Small and Protect the Core. Don't announce your new CoP to the whole world on day one. Start with the core members of the original working group. Let them establish the culture, set the tone of the discussions, and populate the forums with high-quality insights. Only when the community is humming with activity, then look to open the doors to a wider audience.

Measure value, not activity.  Post counts and login numbers tell you almost nothing useful. Ask members directly whether the community has actually helped them answer a real question, saved them from reinventing something, or changed how they think about a problem. That's a much better test of whether this was worth doing.

What this looks like in practice

Option 1: The project manager sends a final email  "great work everyone, I've converted this group into a community space, feel free to keep chatting!" and then walks away. Three weeks later, two people have posted, nobody's answered either of them, and the group quietly becomes the digital equivalent of a noticeboard nobody reads. Nobody decided to kill the Community of Practice; it just wasn't given the specific facilitation it needed to survive. 

Option 2: Someone takes an afternoon to write a one-page “Community Charter”, names themselves and/or willing colleagues as group facilitators, seeds genuinely useful posts before telling anyone it's "open," and checks in every day to keep things moving. Six months later, it has a rhythm: a monthly call, a handful of regulars, and a slowly growing archive of solved problems. The difference between those two outcomes isn't luck or how much everyone liked each other on the original project. It's whether anyone did the unglamorous design and facilitation work in between.

If your working group has a genuine appetite to keep going, a knowledge domain that's bigger than the project that just finished, and at least three people willing to facilitate the group, make the move. The trust and shared practice you've already built is a head start most communities never get.
If any of those three things are missing, don't force it. The closing of the working group with good memories is a far better outcome than a community of practice limping along with hardly any new content and nobody quite willing to admit it isn't working.