Avoid being an outcomes model ‘Go-Between’ September 26, 2007
Posted by Paul Duignan in : Doing evaluation more efficiently, DoView, Outcomes models, Standards, Using the approach , trackback
A while ago a colleague recounted to me how they’d ended up pulling out their hair because they found themselves in a ‘Go-Between’ role when drawing an outcomes model (also called program logics, results chains, strategy maps, ends-means diagrams). You need to try to avoid this at all costs, although when dealing with high level stakeholders it’s often not easy to do so. I found myself in this role on a major project a while ago and I certainly didn’t enjoy it.
What usually happens is this: there’s a draft outcomes model of some sort which is floating around that has been modeled in DoView or in some other software. For a range of reasons, the decision-making on amending the model has gone off-line. This may be because the group which earlier drew the model has been disbanded, is in recess, or is too busy to be brought back together within the time-frame in which you need to make the amendments and get a consensus model off to one or more important stakeholders. Alternatively, you may have put the model together from one or more sources yourself and now it feels like every man and his dog (or person and their pet) feels that it’s open season on your model and that it’s their mission in life to have a go at it. Of course, looking at it objectively, it’s great that busy people are sufficiently interested in the model to want to amend it because they realise that what goes into the outcomes model is going to be important for them.
However, no matter how well-intentioned everyone is, the end result is that you’re now bombarded with emails, scrawled faxes and incoherent phone messages as powerful stakeholders or their staff try to tell you how they want the model amended. Some of the suggestions are great and you can implement them immediately, but at least some of the suggestions are mutually incompatible and you have no way of resolving such incompatibility. To make it worse, the people offering the suggestions all have different ideas about what should and what should not go into an outcomes model and they’ve no idea of the set of guidelines for drawing outcomes models that you’re trying to work from. Or, if they know about the guidelines, they’ve not had time to read them and to really understand how they’re practically applied when building a model.
Many of us may have been in this situation, what we need to know is how to damage control it, and how to avoid it as much as possible in the future.
First, damage control. Here’s some suggestions for dealing with the immediate situation.
- Try to get decision making about the model back into a group setting of some sort. You may not be able to get all the high-level stakeholders into that group, but at least it will not just be you arguing on your own against a proposed change that is really just not a good idea.
- Involve the highest-level stakeholder you can in that group (even if they can’t be in attendance through all of its meetings). Their status can help you defend the decisions of the group.
- If possible, get the message out that you’re drawing the model according to a set of guidelines and if some of the suggestions clearly violate some of the guidelines you might be able to use this to reject their inclusion.
- Attempt wherever possible to work with an electronic version of the model when talking to stakeholders rather than just working off a static paper version, it’s usually easier that way. I use a third-party subscription internet service called Glance which lets up to 17 people view my screen in real-time while I work with a DoView model during a teleconference. Sometimes you can get a virtual group going this way via electronic conferencing. When I built a model for the IMF a while ago I built it using normal videoconferencing, it’s a bit exhausting and there were problems due to the low screen resolution you get with videoconferencing. This was with Inspiration, the software I was using prior to DoView being available, it presumably would still be a problem with DoView or any other software. You are better to somehow (e.g. through Glance) get the better resolution available over the internet rather using traditional videoconferencing approaches. However, if you can do it via electronic conferencing, regardless of the type, it means that you get to work with a group and they carry the decisions that are made. This is always better than you having to try to mediate irreconcilable suggestions from different stakeholders – particularly when they are high-status stakeholders and you are at a lower level within the organizational hierarchy.
Drawing an outcomes model is very much a matter of making trade-offs and just getting to something that works for most people most of the time. Working with a group tends to encourage people to compromise their idiosyncratic tastes about exact wording etc. There’s also an element of ‘agreement by exhaustion’ – when people have been through the process of trying to come up with ideal agreed wording and arrangement of steps and outcomes within a model they tend people be more relaxed about the exact details of a model. They accept the 80-20 rule and just want to make sure that the general thrust of the model is appropriate. They tend to be happy to live with the fact that there are serveral good ways of drawing a model all of which will work.
As for avoiding the ‘Go-Between’ problem in the future. The best way to set up a group for drawing an outcomes model is as follows:
- Get the highest level stakeholder you can find to be part of the group
- Get a mandate for the process you’re going to use. For instance, I sometimes hold a larger meeting of interested stakeholders, explain the process (e.g. if I’m using the Easy Outcomes approach I’ll show them one of the Powerpoint presentations from the Easy Outcomes resources page). Explain the process to them, how its important that a small group be set up (I’ll do a blog posting sometime on who should be in such a group); and if necessary, that you’ll not be playing a ‘Go-Between’ in drawing the model.
- Ideally draw the outcomes model before there’s immediate pressure to use it. So, for instance, if an executive team is keen to do some strategic planning in the near future, they’re unlikely to want to spend four half day sessions just drawing an outcomes model before they start talking about strategic priorities. A good way to get models built is to draw them in the context of monitoring and evaluation planning – there’s usually a longer lead time on this type of work. Then, when it comes around to strategic planning time with its more immediate pressures, the model has been built and is ready for the team to just use it to determine strategic priorities.
- Make sure everyone knows about, and is happy with, the guidelines you’re using to draw the model. I obviously use the Easy Outcomes guidelines and run people through the Powerpoint presentation available on the Easy Outcomes resources page before we start drawing the model.
- Allow enough sessions for drawing the model. I find that a lot of progress can be made on an average-sized project in four half day workshops, but that it usually takes something like this time to get the model up and running.
- If you originally convened a larger group of stakeholders, or if it makes sense to convene one at this time, report the model back to them. Make sure that at this meeting you’re not on your own defending the model and that you have some of the members of the small group. In my experience they always do a great job of making sure that only essential changes are made to the model at this time rather than cosmetic fiddling with it.
I hope this helps anyone who’s been in the outcomes model ‘Go-Between’ role to handle it and to avoid it in the future wherever possible.
Paul Duignan (outcomesblog.org)
Comments»
no comments yet - be the first?