Strategies for social CPD – Creating a PM community

How learning groups spontaneously form and disperse…

Some people sitting at a meeting table watching another person write on a white board. They may well be having a learning session

A while back I attended an APM focus group facilitated by Dr Michael Moynagh of CPD Futures Ltd on developing strategies to improve the way that project professionals approach continuing professional development (CPD). One of the topics that came up was that established approaches to CPD (including the approach promoted by the APM) are somewhat rigid and introspective, and lack a social dimension. The suggestion arose that some sort of group learning approach might be helpful, e.g. creating a PPM Community of Practice.

I have seen this happen with some success (albeit rather briefly!) in the following situation:

  • The organisation had stated its aim of raising the standard of the organisation’s approach to Project Management (and hence the professionalism of the individual PMs)
  • An entire department of PMs had been through some comprehensive PM training (delivered very professionally and capably by Michael Nir of Sapir Consulting)
  • Following the training, all the PMs were given the opportunity to go on and attempt to gain the PMI‘s PMP certification, which a good proportion of them (including me) took up.
  • For those going on to take the certification, there was a fairly hefty exam in prospect, preparation for which involved a fair bit of study and exam practice (I guess this is the CPD / Learning Community equivalent of a “burning platform”).

As a result, a group of us set up “Lunch ‘n’ Learn” sessions every week or so for several months, in which contributors would take it in turns to give a short (20 mins or so) refresher presentation on a topic (say earned value) and then ask some example PMP questions – all over lunch in a spare meeting room.

This worked quite well, but tailed off as the people sat the exams and either passed (in which case they had little interest in attending further) or failed (in which case they generally didn’t attempt a re-sit). It was good while it lasted though, and produced a few learning points for me:

  1. Communities of practice form spontaneously where there are shared interests and objectives.
  2. Participation is maximised when there is an opportunity for (or even an expectation of) contributions from all.
  3. For a community of practice to thrive, contributors must have a genuine interest in the development of both themselves and of others. Don’t be surprised if a significant proportion of potential participants don’t have such an interest. You can lead a horse to water…

Have you seen PM communities of practice? How were they formed (were they organised or spontaneous)? How long did they last? Were they successful? What approaches do you recommend? Let me know in the comments.

Image by WOCinTech Chat,
Licence at

Related articles

How to make sure that Lessons Learned stay that way

I often wonder just how much project management organisations really learn from project successes and mistakes. I think we could all definitely learn better than we currently do.

How to make sure lessons learned stay that way

I will start by saying that we should not wait until the end of the project to learn lessons (both good and bad) – these will be happening all the way throughout the project and should be logged as they happen. Completion of a Stage (including the final one at the end of the project) present a convenient time to review lessons and take action (including communicating the lessons to the wider project community), but waiting until the end of the project to even identify the lessons represents a missed opportunity for continuous improvement. Having said that, the end of the project is where projects usually consider lessons learned (if they do this at all), in the form of a post-implementation review.

In my portfolio management office (PfMO) experience I have seen post-implementation reviews come up with the same lessons again and again (e.g. build contingency into plans; take more time and care to gather requirements; don’t Go Live without full sign off / back-out plans / user training, etc.), but I have seen even more examples where post-implementation reviews weren’t carried out at all because: the project was too small / too simple; the project finished too long ago / hasn’t finished yet; I don’t have the time; the project team is now working on something else / has all left the company; nothing happens with Lessons Learned anyway; I don’t think it’s worth the effort (delete as applicable!).

I think the PMO can help with Lessons Learned, and that the problems lie not only with identifying the lessons, but also with what to do with the lessons that have been identified to embed the learning into the organisation’s experience and memory. Here are some ways that the PMO can help, to make sure the Lessons are not only learned but also acted on:

  1. The PMO can add the lessons to the corporate PM methodology.
    Done well, robust PM processes and methodologies form part of an organisation’s corporate memory, and are built making intelligent use of the lessons the organisation has learned from previous projects. They are aimed at preventing the repetition of past mistakes without unnecessarily impeding delivery. But the more you add to the methodology, the more rigid and prescriptive it becomes, and the more likely it is to either be cheerfully ignored or blindly implemented in full (and you can bet it will be ignored on the big risky projects and implemented in full on the little simple ones!). The PMO should also avoid becoming the methodology police.
  2. The PMO could collect the lessons identified in a Big Database
    …but to be useful this relies on someone (PMs? the PMO?) reviewing new projects against all the lessons in the database, and identifying relevant points to note.
  3. The PMO could add the lessons to a checklist
    …but that relies on people (PMs)using the checklist and giving some serious consideration to what the items on the checklist represent (rather than just paying lip service and ticking the box). And there will always be the temptation for PMs to come up with a good reason why a checklist item doesn’t apply to the current project…
  4. The PMO can run Lessons Learned sessions
    where the PM of a completed project presents their Lessons to the rest of the Project Management community (but this relies on an open and honest communications culture, and/or bribing the attendees with cakes), or…
  5. The PMO could pre-load the Risk Register template
    with the risk of repeating mistakes made on previous projects – the mitigation for which would be to review the Lessons Learned Big Database for things to consider (and the PMO could add value by offering this as a service).

I think the last two approaches are the best, because one encourages the development of a learning community (this is the subject of a separate post) and the other places responsibility for reviewing past lessons (or not) with Project Managers, but supports them with a PMO service.

So that’s my approach to making project lessons “stickier”, learned through experience. What do you think? How do you ensure lessons from past projects are not just identified and logged, but learned and applied to new projects? Let me know in the comments.

If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you on your next big project or programme?