“The need to be specific with regard to target actors and corresponding strategies, at the same time as the need to be brief and thus the need to summarise and generalize. Strategies (such as communication ) are very actor-group dependent, and need to be more specific than the space that the OLM allows for.”

When projects are beginning, it may not always be clear who all the groups of actors involved will be, making it difficult to identify what the best strategies are. When starting, it is most definitely acceptable to have a ‘general’ OLM, that can gradually be improved as more is learned about to work with/for. 

As things get more specific, it will become necessary to ‘re-define’. For example, many projects are working in different project sites and, in some cases such as the Andean Basin projects, even many different basins! It may thus become necessary, as they learn more about each area (the institutional make-up of the area, and particularities of actors and local conditions) to re-define the OLMs. In some cases, eventually having spate OLMs per basin may be recommended (kudos for Geman Escobar, Project AN1, for bringing this up and discussing it!) Another way in which this can be addressed is that startegies should not provide spurious detail (such as “X number of posters”): this type of information should instead be detailed in a communications plan/activities plan.

“How to handle OLM outcome lines dealing with intermediate products when research outputs are largely aimed at another project rather than outside next users? In principle, these can be handled within the existing OLM structure, but in practice the logic is weak.”

Discussion: As explained above, OLMs are not the best tool for dealing with research outputs that are produced by one project for the use of another, or for finding the interrelations between projects. Delivery of outputs within BDCs can be established in a timeline, or the Basin Gantt chart. Outputs that will heavily influence an outcome line for another project can be mentioned in the last column (‘linkages’, added specifically for CPWF projects for this purpose) and then described in detail elsewhere. A related thing is when 2 or more projects are working towards a shared result: these can e highlighted in ‘linkages’, and will be of course included in the ‘overall BDC logic’ and OLM.

“If OLMs become overelaborate, the underlying logic they try to capture becomes obscured in detail. People can get caught up in ‘filling the boxes’ and then they lose analytical and reflective powers.”

Discussion: This is true. OLMs, as described above, should be used to make explicit and describe overall ToC of a project. As soon as there is too much detail, the OLM loses its advantages in the presenting of this logic. If your aim is to use the OLM to present your logic to others, detail ‘obscures’. This does not mean, however, that it is still not useful to generate and help guide the discussions on what this logic is. In writing up the OLM, it is good that project teams go into details, and challenge - even minute - assumptions of the logic. The trick here is a well facilitated discussion that can gently lead the discussion from and to detail, to use the OLMs to enhance, rather than stifle, reflective powers.