Content deleted Content added
tag with {{Bare URL PDF}} |
|||
Line 5:
The Logical Framework Approach was developed in 1969 for the [[U.S. Agency for International Development]] (USAID). It is based on a worldwide study by Leon J. Rosenberg, a principal of Fry Consultants Inc.<ref>[http://pdf.usaid.gov/pdf_docs/PNADW881.pdf Final Report, Contract csd-2510, July 24, 1970]</ref> In 1970 and 1971, USAID implemented the method in 30 country assistance programs under the guidance of Practical Concepts Incorporated, founded by Rosenberg.<ref>[http://pdf.usaid.gov/pdf_docs/pnaec576.pdf Practical Concepts Incorporated, "Guidelines for Teaching Logical Framework Concepts"]</ref>
It has been widely used by multilateral donor organizations, such as [[Agencia Española de Cooperación Internacional para el Desarrollo|AECID]], [[Deutsche Gesellschaft für Technische Zusammenarbeit|GIZ]], [[Swedish International Development Cooperation Agency|SIDA]], [[Norwegian Agency for Development Cooperation|NORAD]], [[DFID]], [[Swiss Agency for Development and Cooperation|SDC]], [[UNDP]], [[European Commission|EC]] and the [[Inter-American Development Bank]]. Some [[
==Description==
The Logical Framework Approach takes the form of a four-by-four project table, often referred to as a "Logframe".
The rows represent types of events that take place as a project is implemented: ''Activities'', ''Outputs'', ''Purpose'' and ''Goal'' (from bottom to top on the left hand side — see EC web site under external links).
The columns represent types of information about the events: a ''Narrative'' description, ''Objectively Verifiable Indicators'' (OVIs) of these events taking place, ''Means of Verification'' (MoV) where information will be available on the OVIs, and ''Assumptions''. Assumptions are external factors that could have an influence, whether positive or negative, on the events described in the narrative column.
The list of assumptions should include the factors that may impact the project's success but cannot be directly controlled by the project or program managers. In some cases, these include what could be ''killer assumptions'', which if invalid 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.
Line 28:
The LFA is also used in other contexts, both personal and corporate. When developed within an organization, it can articulate a common interpretation of the objectives of a project and how they will be achieved. The indicators and means of verification force clarifications as one would for a scientific endeavor, as in "you haven't defined it until you say how you will measure it." Tracking progress against carefully defined output indicators provides a clear basis for monitoring progress; verifying purpose and goal level progress then simplifies evaluation. Given a well constructed logical framework, an informed skeptic and a project advocate should be able to agree on exactly what the project attempts to accomplish, and how likely it is to succeed—in terms of programmatic (goal-level) as well as project (purpose-level) objective.
One of its purposes in its early uses was to identify the span of control of 'project management'. In some countries with less than perfect governance and managerial systems, it became an excuse for failure. Externally sourced technical assistance managers were able to say that all activities foreseen have been implemented and all required outputs produced, but because of the sub-optimal systems in the country, which are beyond the control of the project's management, the purpose(s) have not been achieved and so the goal has not been attained.<ref>http://pdf2.hegoa.efaber.net/entry/content/927/The_Logical_Framework_Making_CIDA.pdf {{Bare URL PDF|date=March 2022}}</ref>
==Handbooks==
| |||