I am brushing up on a few concepts and processes that I have used in the past and may very well need to use in the future.  One concept concerned a business philosophy of Results Based Management (RBM) and a tool RBM uses for project design, the Logical Framework (LogFrame).

Building a LogFrame 

LogFrame was developed in the late 1960’s by the American development organization, USAID.  At its heart is a 4 x 4 (16 square) matrix. The individual rows are deductive – working from general principles at the top to more detailed and precise levels of details at the bottom.  Columns support this deductive process through systematically summarizing, measuring, verifying and testing assumptions.  The following two graphics demonstrate these concepts and design principles. 

Paint by (Project) Numbers

In designing or evaluating a project, you start in square 1 (see the graphic above) and work your way down and across based on different steps.  For example, the world bank recommends the following uses [1]: 

• Link with Corporate Goals (1)
• Set project objectives (1-4)
• Define project performance indicators (5-8)
• Distinguish between project impact and deliverables (2 vs 3)
• Define assumptions and risks (13-16)
• Define the project monitoring system (9-12)
• Determine project resources (4 & 8)

Would You Use a LogFrame

Like any project or business technique, the LogFrame has its uses and limitations.  A plus/minus score card is as follows (based on a variety of sources)

Plus / Positive	Minus / Negative
Provides a summary that can be printed on 1-2 pages	Still requires additional project management and delivery work; e.g. is not a project plan.
Provides built in reminders for project design and covers the project triangle of SCOPE / TIME / BUDGET	If updates and changes are not properly managed or governed, rigidity can set in.
Intuitive and relatively straight forward to learn but to also scale (to a point)	Must be developed in a collaborative manner and as a result is dependent upon a high trust environment
Supports most pre-existing project methodologies (e.g. Waterfall, agile, hybrid, etc.).	Another tool to learn and to integrate into pre-existing decision, monitoring and resource allocation processes.
Can be re-purposed and used in whole or in part by a variety of stakeholders.
Supports aggregation of like projects
It is implementation focused but can also be used as the basis for project approval
Project tracking a success monitoring is built in.

All in all, the minuses are considerably fewer than the positives and they also tend to be common to virtually any project management process.  Best of all, I see the LogFrame aligning very closely to an Agile Project methodology.  The bottom rows may need to reflect relevant sprints but the focus on WHY something is being done versus WHAT is being delivered is definitely agile’esque.  

What do you think, would you use the LogFrame for your next IT project?  Does your organization have the trust levels to work their way through the 16 squares?  How about simply using the LogFrame matrix as primary business case for projects?

Let me know your thoughts on this seemingly ‘Logical Framework’!

[1] Team Technologies Inc. “The LogFrame Handbook; A Logical Framework Approach to Project Cycle Management.” The World Bank, January 1, 2005.