Applying the Logical Framework Approach to Organizational Planning

I got an email asking how one would apply the LogFrame approach for organizations (as opposed to projects) in order to help establish organization-wide goals and indicators of impact. I have been thinking about the problem.

The Logical Framework was pioneered in 1970 for U.S. AID and other foreign assistance projects. It is now one of the chief tools used by the international development community to help design projects so as to achieve measurable results. The LogFrame utilizes a hierarchy: goals, objectives, outputs and inputs. It also utilizes for each level in the hierarchy, to supplement the narrative summary, a set of verifiable indicators, a specification of the sources of data for those indicators, and an explicit statement of key objectives.

Certainly one could simply define the overall goal of an organization (its mission statement), then make a project towards achieving that goal. Define the inputs that are to be available. Then make a plan that would allocate the inputs to achieve specific outputs that would fulfill specified objectives.

The benefit of the LogFrame approach, in my mind, is the discipline it imposes on the planning process. Its emphasis on verifiable indicators makes monitoring progress a natural outgrowth of the planning process, and part of implementation. While many have emphasized quantitative indicators, qualitative indicators are possible and indeed may be quite useful. The requirement that key assumptions be specified should lead to detailed consideration of the assumptions, including an assessment of their importance to the effort and the likelihood that they are valid.

One problem of applying the LogFrame to an organization is that its implicit project nature may not be well suited to the ongoing nature of an organization. Thus an organization may have specific objectives such as a level of activity or impact by a given date, but it also has objectives related to internal capacity building and positioning itself for future impact. Of course, it is possible to specify multiple objectives, as is often done for projects, but that might not be enough to get away from the bias.

Another frequently cited problem is that the use of the LogFrame has been associated in practice with overly costly preliminary planning, and on the other hand, with inadequate implementation management, monitoring and mid-course corrections. Dangerous territory for organizations.

One application of the LogFrame to organizations does seem obvious, and that is to projectize the reengineering or reorganization of the entity. In this case, the process should be time limited, and should have clear goals, objectives, inputs and outputs.

It also occurs to me that there is a potentially interesting extension of the LogFrame approach to organizations. Formal organizations have organizational diagrams, which disaggregate them into hierarchies of organizational units. One could facilitate a reengineering process by creating a LogFrame for each unit within the organization, using hierarchical processes (both top-down and bottoms-up) to define unit objectives, outputs and inputs, as well as their verifiable indicators and assumptions. The process might be very useful as a planning approach, facilitating communication across and throughout the organization about expectations as well priorities in the allocation of resources. The process might also provide management with tools for monitoring progress in the reengineering process.