Content deleted Content added
→Handbooks: spam link removed Tags: Mobile edit Mobile app edit Android app edit |
m Open access bot: url-access updated in citation with #oabot. |
||
| (9 intermediate revisions by 6 users not shown) | |||
Line 3:
==Background==
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>[https://web.archive.org/web/20131004220343/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>[https://web.archive.org/web/20140714121413/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 24:
These are viewed as a hierarchy of hypotheses, with the project or program manager sharing responsibility with higher management for the validity of hypotheses beyond the output level. Thus, Rosenberg brought the essence of scientific method to non-scientific endeavors.
The "Assumptions" column is important in clarifying the extent to which the project or program objectives depend on external factors, and greatly clarify "[[force majeure]]" which are out of control of the project delivery partners — an area that was of particular interest when the [[Canadian International Development Agency]] (CIDA) at least briefly used the LFA as the essence of contracts.
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 {{
==Handbooks==
The Logical Framework Approach, Handbook for objectives-oriented planning, Fourth edition, [[Norwegian Agency for Development Cooperation|NORAD]], 1999, {{ISBN|82-7548-160-0}}.
Strategic Project Management Made Simple:
==References==
Line 43:
* [https://web.archive.org/web/20041215130331/http://ciaris.ilo.org/english/tos/actcycle/planific/methodes/fiche_7.htm Centre for Informatic Apprenticeship and Resources in Social Inclusion] Short description.
* [https://web.archive.org/web/20120824053010/http://www.ausaid.gov.au/ausguide/Documents/ausguideline3.3.pdf AusGuideline 3.3 The Logical Framework Approach]
* [
* [https://web.archive.org/web/20130424232428/http://www2.lse.ac.uk/researchAndExpertise/units/CARR/pdf/R%26R-24-Winter-2012.pdf Fernando, Renuka. "Getting on With It: Monitoring and Evaluation in the Third Sector" Risk and Regulation. London School of Economics. Winter 2012.]
* [http://lgausa.com/logframe_approach.htm Example of the LFA as a design methodology]
| |||