Logical Framework Approach in Project Planning

A study in 1969 revealed three underlying problems for a certain U.S. Agency’s project management system the planning was too vague, management responsibility was unclear, and project evaluation were an adversary process. The Logical Framework Approach (LFA) became a response to these problems. As it is with all methodologies, the LFA does have downsides, and it is therefore natural, that this article will in addition to be describing the use of the LFA and LogFrame, suggest various possible improvements and implementation advices.

Big Idea

The LogFrame is a tool for summarizing a projects design in terms of its core elements, and it is built on the foundations of process of management of objective. One of its main strengths is its ability to deliver the full overview of the project design and progression in a very compressed format, which thereby makes it a great tool for communicating with stakeholders, even when a face to face conversation is not a possibility. To understand how to use the LogFrame, one must understand the context of its use, i.e. the LFA. As mentioned it is the product of a U.S. Agency for International Development initiative, which aimed at analyzing and diagnosing their project evaluation system. The study revealed three underlying problems the planning was too vague, management responsibility was unclear, and project evaluation were an adversary process. The LFA is essentially a set of tools and an analytical process, which supports objective-oriented project planning and management. It allows the user to structure the project design and handle decision making rationally on the basis of a clear understanding of objectives, and the means by which they are to be achieved. In the LFA the project development process is viewed as hierarchy of events and assumptions related to those events. The overall goal is reached, if the projects purpose is achieved, which is achieved, if the output is produced, which is then again produced, if the activities take place. This goal oriented planning forces the project members to think through the project's logic, and what might influence its performance. It is exactly this structured approach, which is key to the strength of the LFA.

Stages of the LFA

The approach is a two-staged process where the project team would first work on a situational analysis (analysis stage), where the focus is on understanding the context of project and develop a logical explanation of the objective, that are to be pursued. The LFA is outlined in the figure below, where the two stages have been illustrated with two rectangles with rounded corners.

One should be aware that the illustration above does not capture the high iterative nature internally in the two stages. Especially the analysis stage is characterized by this, and an example could be the way, that problem analysis might provide new insight about stakeholders and their behavior, while new problems might also surface as more knowledge about stakeholders is discovered. More detailed information about the two phases and their output is shown in the table below.

	Analysis Stage	Planning Stage
Purpose	Increase the understanding of the project's stakeholders, key problems, objectives and strategy. This stage should be treated as a iterative learning process.	Translates,the analysis results into an implementation ready operational plan, where the technical project design is devised, i.e. the activities in the project are specified and coordinated in a manner, where they best achieve the desired results.
Activities	Stakeholder Analysis, Problem Analysis, Objective Analysis and Strategy Analysis	Developing Logical Framework Matrix, Activity Scheduling and Resource Scheduling
Output	From Stakeholder Analysis the most common is a Stakeholder Analysis Matrix and SWOT Matrix. Problem Tree illustrating the relationship (cause and effect) between identified problems. Objective Tree which is a ‘positive version’ of the problem tree, where the problems are converted into their solutions. The tree describes the causal between project activities, results, purpose and overall objective. Strategy of Intervention can be delivered as a reduced objective tree. The important part is where the amount of intervention alternatives has been reduced to those, which are achievable, not pursued by other projects, feasible and not conflicting with other objectives in program and portfolio.	LogFrame Matrix which defines the key events of the,project on the four levels below (highest to lowest) Overall objective or goal Project purpose Concrete visible results Activities required to achieve results It describes the intervention logic, performance indicators, monitoring,mechanism and assumption on all event levels.

Application

In the rest of this article we will focus on the application of the LFA in the planning stage, that is the usage of specifically the Log Frame Matrix or LogFrame.

Log Frame Matrix Format and Principles

Essentially the matrix is a summary of the work undertaken during the analysis stage, and describes the project in short from the overall objective to the individual activities and external factors. The matrix consists of four columns and four, or more, rows not counting headers. The columns one, two, three and four describes for each event the intervention logic (event relationships), performance indicators (for verification), monitoring mechanisms (sources of verification), and assumptions about external environment. The format of the LogFrame is shown in the figure to the right.

Process of Completion

Although the title may indicate something else the work with the LogFrame should be treated as an iterative one, but in this section we will discuss it as a linear process.

The Intervention Logic

This part of the LogFrame contains what the intention of the project is, and how the events herein are causally related. To state this in the matrix one should follow the five steps presented below.

1. Define the objective

1. Define project purpose

1. Define results

1. State activities to be undertaken

1. Verify the Intervention Logic

Assumptions About External Factors

The assumptions are external factors, over which the management have no control. Furthermore, these factor’s states are critical for the success of the project. The assumptions will along with the objective hierarchy represents the vertical logic in the LogFrame, and the relationship between these two can be illustrated with the [reference to logic gate figure].

Identifying Assumptions For each level in the objective hierarchy determine whether this objective is sufficient for this level to result in the level above it to be achieved, if it does not, an assumption will have to be added to the matrix for the causal relationship to be true. For the assumption to be the most useful they must be described in such detail and concreteness, that one would be able to monitor them during the course of the project.

Some example of assumptions could be the ones below.

• Fuel price fluctuations can be absorbed with current budgeting.
• Partnering organization stays supportive of project.
• Local authorities provide protection for deployed volunteers.

It might seem like one should come up with all assumption at once, which could decrease the exhaustiveness these, but most assumptions should already have surfaced during the analysis stage during discussion at the stakeholder analysis, problem analysis and so forth. Significance and Probability Check Of course not all assumptions are equally important for the project’s success, some might be minor influencers, while other can, if violated, be so called killing factors. Therefore, the next step is to analyze and determine the significance and probability of a violated assumption, in order to determine the course of action. For each assumption one should decide on the course of action by following the decision process outlined in the figure below.

All assumptions, which are still contained in the LogFrame at this point, will be monitored during the project and are valuable for development of more extensive risk management plans. At this point each level in the LogFrame should contain both the events in the objective hierarchy including the causal relationships between these, and the assumptions necessary for the higher levels.

Objectively Verifiable Indicators and Sources of Verification

In order to manage the events in the objective hierarchy, one have to be able to monitor and determine the progress and completion of these. This is done through what is known as Objectively Verifiable Indicators (OVI), and these describes the objectives in such detail, that they are measurable and specify the required performance level to be met in order to achieve the overall objective, purpose or result. This importance of performance visibility and awareness is widely articulated as a precondition for project success, as I. Mackenzie and A. Davis also identified as a headline driver of the 2012 Olympics success. “It was, thus, essential that there was... a high level of visibility of performance throughout construction (to expose problems and issues at the earliest point). To determine the OVIs a top-down approach is taken, where that for the overall objective is determined first, which at the planning phase should be clear to the project members. Thereafter, the OVIs can be determined by breaking it down all the way to the individual activities. Many different indicators can be used such as quantities, timing, target groups, locations etc. It is suggested that in order to develop a good indicator one must follow a four step process.

1. Identify Indicator
2. Set Quantity
3. Set Quality
4. Specify Time

To see an example of the use of the above see the section titled Example of Application. OVIs should always be as insensitive to subjective opinion of individuals, and ideally different people should arrive at the same OVIs value, if data is collected simultaneously. Sources of Verification Sources of verification or means of verification are used interchangeably about the source from where the necessary data to generate the indicator values originates. Each SOV should specify that below.

1. What data is to be made available? (medical records, interviews, surveys etc.)
2. Who collects and provides the data?
3. What form is the data in? (statistical database, financial statements etc.)
4. How regularly is the data provided? (continuously, monthly etc.)

In case an indicator does not have a suitable SOV, i.e. it is infeasible to collect data from this source, it should either be modified or replaced by a verifiable indicator.

Example of Application

A soft drinks company want to lower the costs of producing their popular energy drink. The project team have completed the analysis stage of the LFA and have determined the strategy of intervention, which is presented as the reduced objective tree seen in figure [reference to figure].

Intervention Logic

This intervention strategy is to be included in the LogFrame’s first column, where the overall objective is positioned in the top of the objective tree. By inserting the objectives in the LogFrame the result shown in [reference to figure] is obtained. In this case the number of activities are limited, but in a real project the activities will be many and their interdependencies complex, which is why, it is common practice to include the activities in a separate page or for more complex projects network diagrams [reference to network diagram] or Gantt charts [reference to Gantt Chart page]. The activities are here presented in same page as the remaining objectives.

Assumptions about External Factors

At this point the assumptions for each level, besides the overall objective, are identified. These can either be related to one specific assumption, several or all on that level as also seen figure [reference to figure with assumptions].

The LogFrame shows that in order to achieve the result “1.1.2 Administrative expenses are lowered” the activity “1.1.2.1 Reduce insurance premiums” need to be obtained without reducing the insurance coverage, as this otherwise would simply increase the cost of an accident.

Objectively Verifiable Indicators and Sources of Verification

At this stage the vertical logic has been made clear, and the horizontal logic should be assessed, that is the performance indicators and the data sources are to be determined. Using the four step process described in [reference to Objectively Verifiable Indicators and Sources of Verification], one could establish the following indicator or OVI for Purpose 1.2. Step 1: Identify Indicator Lowered variable cost per liter energy drink Step 2: Set Quantity Lowered variable cost per liter energy drink by 5% Step 3: Set Quality Lowered variable cost per liter energy drink by 5%, without realizing a, to the consumer, quality loss. Step 4: Specify Time Variable costs per liter drink produced lowered by 5% by 2019 Q3 without realizing a, to the consumer, quality loss. Now the source of verification is to be determined. In this case the amount of produced energy drink would have to be collected from production reports or similar, while variable costs are found in internal financial reports. OVIs and SOVs for the overall objective and purpose level have been determined, while the remaining ones have been left out for simplicity’s sake. The final LogFrame is found in the figure below.

Finallogframe.PNG

With the filled in LogFrame the project management can effectively communicate the project design to stakeholders and modify “on the go” if needed. As the LogFrame presents in short the desired state of the project at completion and is therefore very useful for project monitoring and evaluation, since all indicators are linked to an activity schedule and the underlying assumptions. Limitations and Suggestions The limitations referred to in the application section are described here, and although some of them can stand alone without references to literature, the majority will be those mentioned in previous literature. 1. If over-emphasizing the objectives and external factors set up during the initial phases, the project administration can become immensely rigid, as it will not allow for the changing variables of the environment to have an impact on the scope and objectives of the project. A response to this would be to arrange regular review meetings, where the project's elements are adjusted if needed. 2. The approach for the significance and probability check [reference to section] does indeed assess and mitigate the risks implied by the assumptions, but the way of treating significance as a binary variable is highly unrealistic, and could even have an impact on the risk inherent in the project. By assuming binary behavior, the probability of including an assumption, which does have a significant impact on the project if violated, is higher, than if the significance were scored on for example a scale from one to five. Regarding limitation two above, it is suggested, by the author of the article, that the decision to redesign the project, just include the assumption or discard the assumption should be made based on a risk score computed from a significance score and probability score.

Annotated Bibliography

Each of the 3-10 references and further readings are summarized with 100 words. Citation style will follow the Harvard format (see [1]).