Three things I learned from playing board games

The holiday season usually involves family get togethers, and one of our traditions for such events is to play one or two new board games. While playing the games is a lot of fun it is also a source of some useful lessons in project management.

Have the right number of players

Most board games will provide details on the minimum number of players required and some will also indicate the maximum. Whether or not this information is provided, nearly every board game has an optimal number of players. If you have too few, the game might not be as interesting, some players will have to play multiple roles, or you might need to reduce the scope of the game. Have too many and it will increase the amount of time required for everyone to become proficient in playing the game, the game will take longer, and everyone might not be as involved in the play given the longer time they have to wait for their turn.

With projects, while you might be able to deliver the scope with less than the optimal number of team members, it can increase individual work loads, might unnecessarily prolong the project’s time frame and you may not be able to complete the project if you are lacking some critical competencies within the team. With too many team members, it will be much harder to keep everyone aligned and some team members might not be as engaged.

Know the rules, but…

Every game has a basic set of rules. Without these, it will be almost impossible to get consistent actions from the different players and the game might never end. However, the board games which provide some play options or, even better, don’t provide all the answers can be a lot more fun as the players will get a chance to customize the game to fit their preferences.

Projects are the same. There need to be a basic set of guardrails in place to help align the team members and to keep them and the company safe, but beyond those, the team should be given the autonomy to determine and evolve their way of working.

Don’t lose sight of the goal

We’ve all had bad board game experiences. Some times a particular player is overly competitive resorting to cheating, getting frustrated with other’s play or refusing to concede. Other times a player will become too obsessed with the rules insisting that everyone is following them word-for-word. In both cases, the real purpose of playing the board game gets lost.

With projects, whether it is process fanatics, stakeholders with hidden agendas, or leaders who insist on following a plan past its “best before” date, we might not achieve the expected outcomes. A good project manager never forgets what those are and will steer the project as needed to achieve those.

It is the holiday season, so enjoy those get togethers with your families, play some games, and most important, have fun!

(If you liked this article, why not pick up my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores)

How are learnings shared between project teams?

Projects provide a great opportunity for teams to develop new skills and to learn what works and what doesn’t in a given context. But to truly institutionalize the knowledge gained by a given team, it needs to be communicated to others so that they might also benefit.

I’ve written a number of articles in the past about the challenges which delivery organizations face with learning lessons from past projects, and how these lessons are disseminated can make a big difference in value realization.

Four of the common approaches for doing this are:

• Capturing learnings within an individual information repository (e.g. wiki, standalone document) for each team
• Capturing learnings within a single, centralized information repository (e.g. knowledge base, database, wiki) for all teams
• Communicating learnings of interest to a specific skill set via Community of Practice meetings
• Embed learnings by updating or creating templates, checklists, standards or policies

The first approach is by far the simplest to implement and is highly effective for the team itself. However, it is usually useless for other teams as they will either lack the awareness or the motivation to locate and review multiple repositories in the hopes of locating a valuable learning. Additionally, when team-specific repositories are used, context regarding lessons might not be captured which will make it quite difficult for other teams to know whether a given lessons might apply to them or not.

The second approach requires more effort on the part of each team to adhere to a common learning format including the context surrounding each learning, and if the updates to the repository go through a quality review process by a different team such as a PMO, this administrative overhead might discourage teams from contributing many lessons. Assuming the centralized repository has good search capabilities and teams are able to subscribe to receive new lessons matching criteria they’ve provided, it can be useful. However, just because you build (and populate) it doesn’t mean, they will come and use it.

The third approach works well for both tacit and implicit knowledge and the live format enables the participants from other teams to ask questions to understand whether a given lesson is applicable or not. However, unless there is some attempt to capture the discussions and make them easily available for practitioners who were unable to attend the session, the knowledge will only be gained by those present.

Finally, embedding learnings has the benefit of eliminating any effort on the part of other teams as they will benefit merely by using the updated versions of the organization assets. However, it may require significant effort on the part of the contributing team and whatever standards governance groups exist within the organization.

As usual, I wanted to understand which approaches were most commonly used in practice. I ran a one week poll in PMI’s LinkedIn Project, Program and Portfolio Management discussion group as well as in the ProjectManagement.com community. Out of the 38 responses received, 45% used Community of Practice meetings as their primary approach, 26% used a separate information repository per team, 16% had a single, centralized repository and only 13% updated organization assets based on team learnings.

I also requested respondents to leave a comment if they used a different approach. While none of those who commented provided a completely new method of sharing learnings, a few indicated that they used a combination of methods. While this does take more effort, it is a highly effective strategy as it allows the optimal approach to be used for the type of lesson and it can mitigate the downsides of picking a single strategy.

When it comes to increasing organizational delivery capability, sharing lessons is truly caring!

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).

Why hold retrospectives if ideas don’t get implemented?

I’ve written and spoken frequently about the many issues with holding infrequent lessons learned sessions. The good news is that many practitioners now recognize that it is much better to discuss and implement improvement ideas frequently over the life of their projects than just at the end of a phase or the project as a whole. This applies both to projects which follow a predictive life cycle as those following an adaptive one, with the main difference being the frequency at which such reviews occur.

Retrospectives are an integral part of the Scrum framework but conducting such reviews regularly is core to most flavors of agile.

However, that doesn’t mean they are well performed.

To understand why, let’s draw a parallel to project risk management.

Teams might do a reasonable job at identifying risks, assessing them and coming up with risk response recommendations for the higher priority ones. Unfortunately, often times those risk responses never get implemented. This might be the result of response owners not understanding how important it is to implement the responses in a timely manner, a lack of quality in the risk or risk response descriptions, a high tolerance for accepting risks, or just a generally low level of organizational project risk management maturity.

The same appears to be the case with retrospectives.

I ran a one week poll in PMI’s Project, Program and Portfolio Management discussion group on LinkedIn soliciting feedback from the group members on what percentage of improvement ideas had actually been implemented from the last retrospective which had been held within their teams.

Of the 42 members who answered my poll, just under two thirds of them indicated that fewer than 25% of the improvement ideas were implemented. Not a single member indicated that over 75% of the ideas had been implemented.

There are many possible causes for this including:

• The team comes up with too many ideas and is unable to prioritize which should be implemented
• The team identifies issues but no ideas to address those issues
• The team lacks the psychological safety to run experiments to test the top ideas
• The system surrounding the team impedes their ability to implement ideas
• Most of the ideas fall outside the control of the team and they are unable to convince stakeholders to implement those ideas

Regardless of the cause, given how frequently retrospectives are conducted, if so few ideas are implemented, this is a significant waste of people’s time.

Perhaps teams should being to apply the old agile cliché of “Stop starting, start finishing” to the improvement ideas…

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).