I have been working with a voluntary sector client who is required to use the Logical Framework (Logframe) structure to submit proposals to potential donors and then use that tool to report progress. Broadly, Logframes require you to identify Objectives, Purposes, Outputs and Activities and demonstrate how an intervention will result in an overall improvement.
I will write separately with my thoughts on the Logframe structure (which has something in common with OpenStrategies’ PRUB-thinking), but here I want to discuss “Assumptions” which also have to be captured when preparing a Logframe.
When I work through the principles of project initiation with clients I usually encourage them to avoid listing too many Assumptions. Generally, I would rather see them identifying potential Risks. The rationale is usually that, if you state Risks, it more logically leads to the identification of mitigating actions (be they preventive, or contingency). My worry about Assumptions has always been that they can be “left hanging”, with no clear course of action to test them, or to amend plans where necessary.
The Logframe approach focuses on Assumptions when proposing a project, which seems to be a very positive way of thinking, rather than immediately looking for potential sources of failure (Risks).
Once a project has been approved, based on a well thought-through Logframe, a more detailed Risk Analysis can be carried out in order to identify mitigating actions.
Overall, that seems to be quite a constructive way of pitching for funding for a project; focusing on the positives of what it will achieve and the assumptions that underpin it (“glass half-full”). The task for the Project Manager and team is then to mitigate the risks (“glass half-empty”).
Of course, the way that Assumptions are written will be very important, otherwise it will be difficult to assess their validity. When writing Risk statements, they are usually expressed in the form “there is a risk that abc happens or doesn’t happen; which would result in xyz consequence for the project”. Risks can then be assessed to identify their Likelihood and Severity using agreed rating scales which enables an overall Risk level to be established.
Assessment of Assumptions requires a slightly different approach and, generally, Logframe guidance suggests “Assumptions are external factors that have the potential to influence (or even determine) the success of a project, but lie outside the direct control of project managers.” They…
- can be derived from the objectives tree for the project
- are worded as positive conditions
- are linked to the different levels in the logframe matrix
- are weighted according to importance and probability
So, I guess my conclusions would be, Assumptions aren’t such a bad thing if you are trying to persuade someone that a project is worthwhile, but you pretty quickly need to get into thinking about Risk and mitigating actions as soon as a project is approved.
More on Project Initiation.