Collaborating and Learning Across Organizations in the Context of Joint Projects

Learning in the context of collaborative efforts and/or complex organizational structures can be a challenge. Most of the literature, including what has been written by KM practitioners, focuses on the organization as the main unit of analysis. On the other hand, the Learning and Development (L&D) practitioners are primarily focused on individuals and sometimes teams. There is also a significant amount of work written about learning across teams, which addresses transferring knowledge from one team or one project to another. In fact, the theme of knowledge transfer comes up regularly. The focus below will be different.

Increasingly, individuals within organizations find themselves working in teams, projects or work groups that are made up of staff who belong not just to different divisions within the organization but to different organizations altogether. As collaborations, partnerships and contracting arrangements evolve to meet the needs of a constantly changing environment, individuals must learn to work effectively within these teams, which includes learning to learn collaboratively. This type of joint learning or co-learning is relevant in the two fields I am most familiar with, international development and aerospace. In both fields, the Government entities (USAID & NASA) do not deliver their mandate on their own. They work with and through myriads of partnerships, contractual arrangements as well as formal and informal collaboration agreements each of which comes with a specific set of constraints and opportunities. For each of these ways of working together, co-learning opportunities need to be identified and their potential value assessed upfront. Co-learning isn’t for everyone and every situation.

Co-learning across multiple organizations can be challenging. It’s one thing to conduct a lessons learned conversation within a team whose members all belong to the same organization. It’s another to conduct the same lessons learned conversation when members of the team belong to different organizations. The likelihood that walls (defensive mechanisms) will come up is increased.

For example:

• The organizational cultures may be different. While one organization may be accustomed to open and honest conversations about what isn’t working, others may shy away from such transparency. 
• Organizational processes may be different. One organization may have a very rigorous and structured process for documenting lessons while another doesn’t have a process at all. This may lead to many unspoken and unwritten assumptions. 

As with all aspects of collaboration (not just the joint learning aspect discussed here), one of the drivers of success is a thorough discussion of all assumptions about not just what will be done, but how it will be done. For example, if two organizations are going to implement a project together with specific roles and responsibilities clearly assigned and a component of that project is to discuss and document lessons to make regular adjustments in the project’s path forward, it will be important to address all relevant assumptions upfront and clarify as much as possible, including the following:

• Clarify the overall goals and objectives of the joint learning activities. There should be a clear understanding of why the learning activities are being undertaken jointly as opposed to each organization involved in a collaboration conducting its own independent lessons learned. This can happen even within the same organization and is typically a sign of dysfunction. There are many circumstances where an internal lessons learned session is also needed, which might focus on questions such as “What did we (as organization x) learn from our collaboration with organization Y? Joint lessons learned sessions should never be used to try to place blame on any member of the collaboration or to tell other members of the collaboration what they should have done differently. If a serious problem occurred (a partner isn’t performing as expected for example), there are avenues to address these problems other than a lessons learned session. The joint learning session helps identify what every party involved could have done different from the start, not who is to blame for failures.
• Clarify who will lead the joint learning effort. Perhaps not just which of the two organizations, but which staff position. This may be important in providing clues regarding how the activity is perceived by both organizations and whether there is a disconnect that needs to be addressed. Does the position/person have the right level of seniority, appropriate level of expertise, etc.? If it is important for all parties to be represented fairly and equally in the discussion, it may be a good idea to get the support of a third party facilitator to ensure neutrality in the conduct of the session.
• Clarify the schedule of learning activities. Avoid using ambiguous wording. Phrasing such as “Lessons learned will be documented on a regular basis” can be interpreted in many different ways and could lead to disconnects between the collaborating partners.
• Stipulate the methods to be used: A wide-open lessons learned conversation with 20-30 participants is very different from a series of one-on-one interviews, yet both could conceivably be used to elicit and document project lessons. In fact, a broad discussion of methods and their use in the specific context of the project would be valuable. Don’t assume that the way you’ve been doing it on other projects is necessarily the right approach in this context.
• Be clear about outputs and utilization: Discuss how lessons identified will be utilized to make adjustments to the path forward in terms of work plans and specific activities. For example, my preferred format for documenting lessons learned discussions is an insight map. However, I would never assume that it’s always the best format or that it works for everyone. Beyond concerns about formats which can be trivial, it’s important to talk upfront about whether the session is meant to identify specific recommendations and actions or not. In some cases, the parties to the discussion have a wide open conversation, go back to their respective offices and independently decide on specific actions they will take to address issues raised during the lessons learned meeting and perhaps report on actions taken at a later date. In other cases, a second joint meeting may be held to focus on specific recommendations and actions. In these different variations of the process, it’s also important to discuss the issue of decision making and validation. Who will have the final say in terms of the final version of the lessons and/or recommendations? What kind of follow up or accountability process is in place to ensure that lessons are indeed embedded into future activities (within the ongoing project, not just in a potential future collaboration)?
• Be ready for disconnects: Since it is not possible to anticipate every inaccurate assumption or disconnect that might derail the collaboration, there should be a clear mechanism for quickly addressing disconnects when they arise. 

And a final point, don’t assume that prior collaboration experience between two organizations means you can skip all these steps about clarifying assumptions. For all you know, one of the two organizations may have held an internal lessons learned process at the end of the last collaboration and decided that it didn’t work well for them and they would recommend a completely different approach. Or, you might just be dealing with very different team, different leadership, making it a completely different collaborative environment. It never hurts to check that you are all on the same page.