| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

COMMON PROBLEMS

Page history last edited by Cristina Lamb Guevara 6 years, 8 months ago

 

The need to be specific with regards 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 from the outset 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 who to work with, and for.  As things get more specific, however, it will become necessary to re-define the OLMs.

 

It is important to note that strategies 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.”

 

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 can be established in a timeline, or in a Gantt chart. Outputs that will heavily influence an outcome line for another project can be mentioned in a ‘linkages’ column, and then described in detail elsewhere. A related thing is when two or more projects are working towards a shared result: these can be highlighted in ‘linkages’, and will of course be included in the overall logic and OLM.

 

 

 

“If OLMs become over elaborate, 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.”

 

This is true. OLMs 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 tends to ‘obscure’.

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.

 

 

 

Next page: V.     Examples of OLMs

Comments (0)

You don't have permission to comment on this page.