Unalterable deliverables and program inflexibility June 2, 2009
Posted by Paul Duignan in : Accountability, Indicators, Measurement, Outcomes systems architecture, Reporting systems, Using the approach , trackbackBack blogging now after having been on holiday. Recently I ran into the problem of unalterable deliverables in a project I am involved in. This problem was also mentioned in the UN report on its results-based management system that I blogged about a couple of postings ago. The problem arises where a project is set up and deliverables are set, but where ideally there needs to be some flexibility regarding deliverables as the program develops over time. Sometimes the problem is just a result of the difficulty of changing deliverables.
It may just be that it requires significant work to change deliverables and those involved in administering a project don’t have the time to go through the procedure. It is obvious why those administering projects would like deliverables to stay constant. It means that they can track progress over time. If deliverables keep changing then it is hard to work out what progress is being made on a project. We can think of deliverables as being a type of demonstrably attributable indicators. (See here for more information on what demonstrably attributable indicators are).
Of course, like many things in life, those setting up such systems who insist on deliverables staying the same, or who make it really hard to change deliverables, are making a trade-off. They are often unaware that they are making this trade-off. The trade-off is between keeping deliverables constant and allowing for program flexibilty. Is there a way to escape from this trade-off?
Always using a visual results (outcomes) model helps with the problem in several ways. First, if a visual results (outcomes) model is being used and good practice is being followed, the model will be kept up-to-date. At any point in time, the model should represent the most accurate possible picture of the high-level outcomes which are being sought and of the steps which are being taken to achieve them. Using a regularly up-dated outcomes model in this way provides a basis for talking about the program independently of the set of deliverables being used for the program. It is much easier to conceptualize what is happening in a program and how it is changing by using a well-structured visualized results (outcomes) model than by trying to just work off a deliverables list which is not set out in any kind of causal hierarchy.
Working with a visualized results (outcomes) model in this way, stakeholders can agree when the program has changed and this provides a basis for them agreeing that it is reasonable to change deliverables if the program has changed. If there is no visual model against which to test suggested changes in deliverables, then when program staff suggest that there should be a change in one or more deliverable, and when they present a revised list of deliverables, there is no easy way of assessing whether or not to accept such proposed changes. Do they reflect an actual change in the program (which is easily examined and communicated by using a visual results model)? Or is it just a case of the program staff trying to change one or more deliverables to avoid the program being held to account for not doing things that it should have done. The use of a visual outcomes model makes it much easier to assess the difference between these two instances.
Second, initially developing a results model prior to identifying deliverables for accountability purposes, allows careful consideration of the level of generality at which the steps within the outcomes model should be struck. In situations which are likely to change rapidly, steps within a results model may have to be set at a higher level of generality because the specific details of what will be done cannot be specified in advance prior to the program being implemented. This involves decision makers accepting a trade-off. This trade-off involves them accepting that they will not be able to specify in such detail deliverables which can be used for accountability purposes and will function throughout the life-time of the project. If they want such deliverables which they can use for accountability purposes they will have to revisit them in the course of the program developing. The reality of having to accept this trade-off is immediately and directly communicated to stakeholders when working with a visual outcomes model and they can identify those situations in which it is going to need to be made. In contrast, just having a straight list of deliverables for accountability purposes without the step of building a visual results model, will immediately push thinking downward from the more general and flexible to the more specific and lock in place deliverables which will become out of date as the program has to change in response to changing circumstances.
This is adapted from my recent article:
Duignan, P. (2009). United Nations Results-Based Management System – An analysis. Outcomes Theory Knowledge Base Article No. 244. (http://knol.google.com/k/paul-duignan-phd/the-united-nations-results-based/2m7zd68aaz774/81).
Paul Duignan, PhD
Outcomes and Evaluation Blog (OutcomesBlog.org)
Comments»
no comments yet - be the first?