(Note from me: This (rather long) post was inspired by my partner in this exercise who challenged me to try to blog about our own process reflections. It seemed congruent to frame it as a "How To" - so this is my learning about learning!)
In many project documents and programme concept notes you see mention of building on or using learning from best practice. But how exactly do you go about collecting this, and in what form can you use it?
We recently finished a 6-month learning exercise at a large international NGO which explored this issue. It focused on learning from a number of experiences in the last 10 years in a newly developing area of partnership work for the organization - providing independent advice for businesses on biodiversity conservation in their operations. The HQ programme manager saw some patterns developing that she thought would be interesting to capture, organize and make available for other colleagues around the world who were interested in adding this kind of work to their portfolio of projects.
We were also curious to see if there was a way to describe some of the common components of the processes that were being used as models that made them more easily transferable. And we wanted to learn from the Project Managers living and breathing these experiences about what worked and what they might change, if they did this again, in the different stages of their process. These included areas like governance, communication, contracting, etc.
Don't Shelve It! (Why to Collect It in the First Place)
In this case, there were several reasons for collecting best practices:
- To help understand more about staff member's work in this new field and to make it visible;
- To provide Project Managers doing this innovative work with an opportunity to reflect on their process and what they are learning, and to document this;
- To provide interested staff members with some basic "how to'" information, as well as to connect them with a set of experienced colleagues to whom they can go for advice;
- To develop a set of models - in the form of diagrams, generic steps, and actionable insights - that help to lightly organize the experiences (which developed organically in many cases). These model descriptions can help staff and potential partners more strategically choose from amongst them when a collaboration opportunity arises, and also help this new practice be more effectively communicated internally and externally.
Do It in Steps: How We Collected Best Practice
A. What Makes for Best Practice? Identifying the Cases
One of the first steps in the exercise was to identify the cases that would become a part of the learning and analysis. We found that we did not need to worry about how to categorise "best" cases (by anyone's subjective standard) as in every case Project Managers could pick out aspects that were working very well, and could also always pinpoint things that could usefully change or had changed for various reasons. Good practice was a better frame as it exhibited itself in every case we analysed, whether in setting up the project Advisory Board, how stakeholders were integrated, developing strategic reporting time lines, or using formal team building. Each Project Manager had innovated in interesting ways, and also had naturally come up against challenges. In some cases, they had effectively solved them for each other, but prior to this exercise no format existed to capture and exchange on these items.
We started with 10 cases and ended up using 7 of them for various reasons. We tried to get a variety of experiences from different parts of the world that were well established (i.e. had been going for some years, or were nearly completed) and for the most part well-documented. Each however had something in common, they worked with a new business partner with a specific goal of providing independent advice for biodiversity conservation.
B. Creating an Opportunity for Reflection: Gathering Information
For each case, although for most cases there was lots of descriptive documentation on the web, it often did not include process information. It was mostly framed as reporting details and quantitative data. We did use that as background, but our main input was conversation based, using Appreciative Inquiry stems for questions (e.g. focusing on what is working). So Skype or face-to-face interviews with the Project Managers and, in many cases, other delivery team members external to the organization, were built centrally into the process. We focused in the interviews on what people thought worked very well and what could be different to make the experience even more successful. Creating an opportunity for reflection, we asked about learning along the different stages of the process, from preparation/set up through delivery, to reporting. And, because this was a newer area of work for an well-established organization, we explored perceptions of risk. We specifically asked for Tips for future project managers who might be running a similar exercise, and on the qualities that Project Managers needed to have make the project successful.
C. What's Bubbling Up to the Surface? Developing the Model
It was only after all the cases had been written up, that we could step back and try to understand what some of the commonalities might produce in the form of a generic model or structure. In the stories of the Project Managers there were definitely repeating elements, process steps, even challenges. Some features were shared across all the cases, for example, all had some similarities in sequencing of process steps, all had a governance component - an external Panel or Steering Board that helped the advice given be truly independent, all were set up with some form of formal agreement between two organizations even if a larger number were involved. Across these common elements much good practice was exhibited.
Other things in the cases were clearly different, and what became apparent as we looked deeper, was a framework model that included the goal of the process, especially the depth of outcome desired - was the change on which the project focused a remedial action (e.g. trying to fix something in a specific location like a lake, harbour or protected area?) Or was it aimed at much broader social change? This was linked to the level of intervention - a field operation, a company, sector, supply chain or society. Each of these in turn had an optimal level of stakeholder involvement. We plotted the categories of projects and the individual cases along these lines to see what we would get.
What this analysis produced was a useful tool, a diagram, which collected the different kinds of experiences in one place, based on their key features. It effectively organized the diverse experiences in a visually interesting way and could be used as an aid to guide an exploratory discussion with new staff member or with a potential business counterpart.
D. Pulling it All Together: Producing the Best Practices Product
The "How To" Learning document was an exercise in synthesis. Although we had collected a binder full of data, and held hours of interviews, the result had to be a crystallisation of the learning. In the end, the main body of the document was 22 pages of text with diagrams which included an overview of the main categories we identified, each with a set of steps for implementation, tips for setting up and managing the processes, communication lessons, and a discussion of potential risks and management options. It was in the Conclusions section that we introduced the model that situated all the experiences into relationship with one another based on the features mentioned above (depth of outcome desired, stakeholder involvement, and scope of intervention). The case studies and resource documents were alphabetised in the Annex, along with a matrix snapshot of the cases in terms of their exact cost, time frame, managers, and level of public disclosure. The cases studies were also referenced throughout the document in the form of a three letter code, set up as a key at the beginning, so that for any tip or process step, readers could refer back to a real example in one of the case studies.
A Challenge We Faced in Developing Best Practice Advice
Even though the framework model was a key intellectual input into the learning exercise, we chose to put it in the Conclusion. This decision was based on what we found as one of our key challenges in this overall best practices process.
Innovation in organizations can happen in many different ways. A new idea or practice can be developed centrally and then tested in different locations/conditions to see how it works. The lessons can be gathered and analysed. This more top-down process exhibits a certain amount of standardisation at the onset, although different contexts will see practice gradually diverge from the first model. Another way, however, is more bottom-up. Some internal or external opening or trigger (policy change, global change, etc.) sparks new practices start to occur organically in different places and these experiences start cropping up in parallel to one another with very little horizontal interaction. They each understandably develop their own vocabulary, labels, and a proliferation of process peculiarities. If at this point you decide to undertake a learning or best practices process that includes some sort of meta-model development - which need a certain level of harmonisation of labels and a set of common concepts - then you might find this a little more challenging. You can still find incredibly useful best practices, and will get to be creative about the categorization and labelling of these.
In the end, each case we explored was indeed unique, and at the same time, their goals were very compatible, which made for a rich value-adding exercise to look across them and understand what makes for best practices, so that they can be shared, communicated, and used for continual improvement through learning in the future.