Content deleted Content added
No edit summary |
The explanation of the difference between the terms Logical Framework Approach (LFA) and Logical Framework (LF or Logframe) added. |
||
Line 1:
The '''Logical Framework Approach''' (LFA) is a management tool mainly used in the design, monitoring and evaluation of development projects. The LFA method was developed by Leon J. Rosenberg, under contract to USAID in 1969. Practical Concepts Incorporated, a firm founded by Rosenberg, then extended use of LFA to 35 countries. LFA is widely used by bilateral and multilateral donor organizations like [[Gesellschaft Fuer Technische Zusammenarbeit|GTZ]], [[Swedish International Development Cooperation Agency|SIDA]], [[Norwegian Agency for Development Cooperation|NORAD]], [[DFID]], [[UNDP]] and [[European Commission|EC]]. It has also been widely adopted by NGOs, though not without reservations and concerns by some. In the 1990's it was often mandatory for aid organisations to use the LFA in their project proposals but its use in recent years has become more optional.
It is useful to distinguish between the two terms: the Logical Framework Approach (LFA) and Logical Framework (LF or Logframe). They are sometimes confused. The Logical Framework Approach is a project design methodology, the LogFrame is a document.
The text below describes the document, not the global methodology of project design. For the brief description of the LFA as a design methodology, see for example the page *[http://lgausa.com/logframe_approach.htm], for the thorough description see for example "AusAid guideline for LFA" cited in "External links" section.
The Logical Framework takes the form of a four x four project table. The four rows are used to describe four different types of events that take place as a project is implemented: the project ''Activities'', ''Outputs'', ''Purpose'' and ''Goal'' (from bottom to top on the left hand site - see EC web site as under external links). The four columns provide different types of information about the events in each row. The first column is used to provide a ''Narrative'' description of the event. The second column lists one or more ''Objectively Verifiable Indicators'' (OVIs)of these events taking place. The third column describes the ''Means of Verification'' (MoV)where information will be available on the OVIs, and the fourth column lists the ''Assumptions''. Assumptions are external factors that it is believed could influence (positively or negatively) the events described in the narrative column. The list of assumptions should include those factors that potentially impact on the success of the project, but which cannot be directly controlled by the project or program managers. In some cases these may include what could be ''killer assumptions'', which if proved wrong will have major negative consequences for the project. A good project design should be able to substantiate its assumptions, especially those with a high potential to have a negative impact.
| |||