Developing A Project

Logic:
A Guide for Project Design
August 2020

Project logic provides the basis for planning and

implementing, monitoring, and evaluating
projects.
INPUTS ACTIVITIES OUTCPUTS OUTCOMES IMPACTS

Disclaimer: This publication was produced with the financial support of the European Union. Its contents are the
sole responsibility of SPREP and do not necessarily reflect the views of the European Union. This document has
been compiled in good faith, exercising all due care and attention. SPREP does not accept responsibility for
inaccurate or incomplete information.

© Secretariat of the Pacific Regional Environment Programme (SPREP), 2020. Reproduction for educational
or other non-commercial purposes is authorised without prior written permission from the copyright holder
provided that the SPREP and the source document are properly acknowledged. Reproduction of this publication
for resale or other commercial purposes is prohibited without prior written consent of the copyright owner.

Acknowledgment: Ms. Joanne Oddie, Director and Monitoring and Evaluation Specialist at Strategy Evaluation &
Engagement for Development (see4d) for providing technical assistance in the development of this guide.

SPREP Library Cataloguing-in-Publication

Developing a project logic: A guide for project
design. Apia, Samoa: SPREP, 2020.
14 p. 29 cm.
ISBN: 978-982-04-0812-8 (e-copy)
1. Project management – Industrial 2. Logic
Designs – Handbooks, manuals, etc. I. Pacific
Regional Environment Programme (SPREP). II. Title.
658.404

Secretariat of the Pacific Regional Environment Programme (SPREP)

PO Box 240 Apia,
Samoa
www.sprep.org
[email protected]

Our vision: A resilient Pacific environment sustaining our livelihoods and natural heritage in harmony with our
cultures.

As part of SPREP's commitment to the environment, this item is printed on paper made from 100% recycled post-
consumer waste.

Developing A Project Logic: A Guide for Project Design 2

Contents

Introduction 4

So, what is Project Logic in practice? 4

An example of ‘Outcomes Hierarchy’ for a PacWastePlus Project 6

- Management of E-waste

Building Project Logic in Participation 7

- Session 1: Defining the Scope

- Session 2: Develop an Outcomes Hierarchy
- Session 3: Articulate and Document Assumptions
- Session 4: Further Critique the Project Logic
- Session 5: Identify the Risks Associated with the Assumptions

Conclusion and Next Steps 12

References 13

Developing A Project Logic: A Guide for Project Design 3

Introduction
For PacWastePlus it is expected that all teams designing activities will have developed some
form of project logic in participation with their implementing partners. This will demonstrate
the logic of your collaborative thinking and design, and clearly articulate the changes to which
you hope to contribute.

Project logic provides the basis for planning and implementing monitoring and evaluation at
project level.

Project logic is defined as a conceptual framework of how a program or project is understood,

or intended, to contribute to its specified outcomes. It focuses on outcomes rather than
process. It demonstrates the causal links between inputs, activities, outputs, and outcomes.
Such models are usually shown diagrammatically but can be reported in narrative form.
Project logic can be developed prospectively for planning new programs and activities, or
retrospectively for existing programs. Project logic can be used in various ways, such as to
guide an evaluation; to provide staff and other stakeholders with a motivating vision; or to
structure a performance story to funders and senior decision makers.
Alternative and similar terms: Logic model, Outcomes map, Theory of change

So, what is Project Logic in practice?

A complete project logic comprises:

First, some definitions of terms used in a project logic, or an ‘outcomes hierarchy’, then an
example is provided:

Developing A Project Logic: A Guide for Project Design 4

 Contributes to
the Project
Outcome
Project
Accountability ----------------------------------------------------------------------------------------------------------------------------
a project logic. The most typical convention for an outcome hierarchy is that the longer-
These elements fit together to form an outcome hierarchy, an essential component of

term outcomes are at the top of the hierarchy, with the activities near the bottom.

Project is mostly accountable or has some significant influence

----------------------------------------------------------------------------------------------------------------------------

Foundation
Sometimes there are other critical foundation steps to consider that could shape outputs and
activities. Rigorous assessments capture all these levels and recognize their nested relationship, which
helps assessments to stakeholder needs and could positively contribute towards producing desired
outcomes.

Developing A Project Logic: A Guide for Project Design 5

An example ‘Outcomes Hierarchy’ for a PacWastePlus Project – Management of E-waste
Assumptions would need to be developed additionally.

Developing A Project Logic: A Guide for Project Design

6
Building Project Logic in Participation
This note describes a process for developing project logic in participation with your
colleagues. It is always better to build project logic in a group with a participatory process.
More and informed perspectives make a stronger logic. You could build a ‘straw man’ (draft)
project logic with your core team and then test it with your partners and stakeholders. Building
project logic is a dynamic thinking process best done over several sessions when minds are
alert and focused, with good breaks between sessions.

Principles for Project Logic

The following principles are useful to consider:

• A clear understanding and agreement are required among participants about what needs
to change, and how the project can best contribute to that change, in the context of the
system in which you will be working.
• Discussion of what is working, and people’s visions and aspirations, are more useful than
statements of problems.
• Explicit immediate and intermediate outcomes pave the way for then designing project
strategies and activities.

A project logic is most complete when:

• Accompanied, or preceded, by an analysis of contextual conditions that are
understood and critical for the project to succeed.
• Areas of uncertainty, or essential conditions for success, are explicitly stated
(Assumptions).
• Intermediate, end-of-project, and longer-term outcomes are clearly described. (What
will change) (See Box 1)
• How change is assumed to occur is described, that is your theory of change. (How
change happens)

Session 1: Defining the Scope

Scoping the boundaries for the project logic is an important discussion to have at the start of
the process either before, or at the commencement of the project logic workshop. Endeavour
to answer the following questions:

1. What is the investment timeframe and what is the amount of funding available for the
investment/project?
2. What is the overall outcome to which you the project will contribute? Then, what is achievable
in the life of the project?
3. What needs to change, and which changes are most urgent? What is the best sequence?
4. What do we know that works to achieve the changes required? (Why does it work and for
whom?) What else could we try? What do we know doesn't work from previous experiences?
(Are we operating in an environment that could allow for testing innovative approaches?)
5. Are there any rules or regulations that will need to be considered in designing the project?
6. Who will use the project logic and how will it be used?
7. Is there potential for partnerships? What other resources are available? Who else could/
should be included in the design process?

Developing A Project Logic: A Guide for Project Design

7
 Session 2: Develop an Outcomes Hierarchy
Project long term outcomes usually involve a wide range of activities conducted in complex
social, cultural, political, economic, technological, and legal circumstances. Investing time in
developing a robust project logic will help you be realistic about what you can achieve in the
funding period of your project.

Apply specific timeframes to each level of the ‘outcomes hierarchy’. End-of-project outcomes
are those you will need to report on during, and maybe after, the project. You will be most
accountable for end-of-project outcomes. Think positively about how the project can
contribute to achieving the changes desired that are under consideration. There will be
ongoing opportunities to challenge, and re-frame, the project logic.

As a group, you will be writing a series of outcome statements – statements describing future
desired conditions, while you then take a ‘looking backwards’ view on what changes will be
needed along the way.

Resources: Ideally, you will map the project logic out on a wall using:
• colored paper (colour coded to the outcome levels),
• good quality thick markers for clear, big writing, that you can read from a distance, and
blu-tack, for sticking the paper on the wall.

Below is a guide to writing outcome statements. Read this before you start writing outcome
statements, which need to be expressed as a statement of desired future condition, or
state, of a subject or object, system, or policy.

Box 1. Guide for writing outcome statements

• State outcomes succinctly (about 10 words or less) indicating clearly what change will look
like -- a statement of a desired future condition. They must say ‘what’ has changed, not
‘how’ the change will be achieved. ‘How’ will come later when you think about activities
and strategies that will contribute to achieving the desired outcomes.
• Include the subject, or object, of change; who or what will experience the change?
• Use simple language – no ambiguity. Define the key terms used if necessary.
• Remove all unnecessary adjectives such as quality, ensured, compliant, affordable, resilient,
reliable etc. that will increase the difficulty of measuring outcomes. It is assumed the
outcome will incorporate good practice; you will not be delivering, by intent, low standard
outcomes.
• Test that outcomes are likely to be achieved in the program timeframe. Draw a line across
the outcomes map – where those outcomes below the line will be achieved in the life of
the program, with those above the line being potentially achieved as a later consequence,
or a subsequent project.

Developing A Project Logic: A Guide for Project Design

8
These are the key steps you can apply with your team to get the ‘outcomes hierarchy’ up onto
the wall:

Step 1: Define and clarify the longer-term outcomes (5-10+years)

Describe the big picture changes the investor and partners are hoping to contribute to
through the project, the desired future conditions for broader society, particular groups, or
relevant institutions.

• Make sure that there is general agreement that these are the intended outcomes.
• They can be reviewed and refined at any stage as the ‘outcomes hierarchy’ is iteratively
described.

Step 2. Describe the end-of-the project outcomes and intermediate outcomes that are
desired/ intended, which will likely lead to the longer-term outcomes.

Endeavour to describe exactly what it is that you want individuals, groups, organisations or
institutions to be doing differently. Look at the types of example changes in the definitions
table in Note 1.
Map out the changes that you intend to achieve over time, with the earlier expected changes
lower down ‘on the wall’.
• Ideally, you will use arrows to demonstrate the cause and effect relationships between
outcome levels (this leads to that, and that leads to something else…)
• This is where you need to be discussing as a group how you believe change will be
achieved or influenced.

Step 3. Describe the inputs, activities/strategies, and outputs that will contribute to
achievement of the expected intermediate and end-of-project and longer-term
outcomes.

• As you describe activities, it is likely that you will review and refine the intermediate
outcomes.
• Sometimes you are already implementing activities (often for political or other reasons)
without having been clear about the outcome to which you have been trying to
contribute. In this case you would start your ‘outcomes hierarchy’ at activity level and
think upwards to describe intermediate outcomes.
• Sometimes you have several ‘strands’ of activities contributing to one intermediate
outcome, or one activity contributing to a number of intermediate outcomes. Make
sure you illustrate this in your ‘outcomes’ hierarchy. Arrows are useful to help illustrate
the connections.
• As you document the activities describe how the activity will lead to your desired
outcome. This is your theory of change.

Step 4. (Optional) Identify foundational activities that help you get ready to commence
the project.

• Sometimes these are critical to commencement e.g. negotiating Memoranda of

Understanding with partners, or negotiating funding arrangements, or it might be
conduct of a particular piece of research, or development of an agreed strategy.

Developing A Project Logic: A Guide for Project Design

9
Step 5. Pause and reflect. Check the logic of your thinking

• Developing an ‘outcomes hierarchy’, and overall project logic, is an iterative process,

take a step back and look at what you have done.
• Ask the group: What is missing? What needs refining? Is this realistic? Are the cause
and effect relationships you have depicted likely, or even possible? What could we
remove? Can we be accountable for achieving these outcomes?
Step 6. Capture the ‘outcomes hierarchy’

• When the group is satisfied that the project logic is what you, and your partners, are
endeavouring to achieve you will progress to further critiquing and then documenting
assumptions.
• You can take a series of digital photos of your project logic to make sure that it is
captured for turning into a diagram when you get back to the office.

Session 3: Articulate and Document Assumptions

An essential part of a project logic is the set of assumptions about how change is expected to
happen in the particular situation for a project. When you develop project logic, you are
developing a theory of what will change and describing how change occurs. In doing so you
will make a number of assumptions, e.g. that (A) leads to (B), or even that it is possible that (A)
will happen.

Assumptions are expectations, based on current knowledge and experience, about what is
critical to or important for a project’s success. Sometimes they are referred to as ‘pre-
conditions’. Sometimes the assumptions are not well founded in knowledge and experience,
particularly in pilot project designs. Articulate and document the assumptions that underpin
your project logic to determine whether they are sound or plausible. This will provide a focus
for testing and adapting the project logic during implementation.

To frame an assumption you say: “For this project to succeed it is assumed that (…this
condition is in place)……”

With your group:

• Stand back from the project logic model, ‘zoom out’.

• Consider the overarching assumptions you have made in the model, working through
each outcome level and outcome statement. (Ask your group these questions: What has
to be in place for this output to contribute to that outcome? What has to be in place for
this intermediate outcome to contribute to that end-of project outcome?)
• Write each assumption on a separate piece of paper (red paper is good here!) and put
them up on the wall on the ‘outcomes hierarchy’.
• Word the overarching assumptions positively (e.g. for this project to succeed it is
assumed that …. e.g. Government agency officers will be supported by their managers
and their organisations to implement what they have learned in the training).
• Prioritise the assumptions in terms of how important it is that you investigate them. You
can do this prioritisation with the workshop group being allocated ‘votes’ (e.g. coloured
sticky dots) to allocate to what they perceive are the most ‘wicked’ or risky assumptions.

Developing A Project Logic: A Guide for Project Design

10
 Document them in a table (example below). With the outcome hierarchy, the assumptions
form a vital part of your project logic.

Key assumptions Importance of finding out more

(focus on linkages between about this assumption (or
outcomes – use positive managing for risk)!
wording) High Medium Low
1.
2.
3.

Session 4: Further Critique the Project Logic

When developing project logic, it is always important to be aware of those factors that are
within the control or influence of the project (typically the lower levels in the project logic)
and those that are not. (Refer to Figure 1.)
At this point it is useful to think in depth about these factors, which will either help, or hinder,
the effectiveness of the project. Going through this process and documenting what is
identified and agreed will enable the factors to be accounted for when considering the extent
to which outcomes have been achieved. This process provides a reality check and a form of
risk assessment.
Working with your group identify the factors that might hinder the achievement of outcomes.
(e.g. write on orange post-its). Then identify, if possible, any measures you could take to
mitigate the factors. (e.g. write on blue post-its).
Then, identify the factors that could help the project and who could help you achieve them.
(e.g. write on green post-its.) Document this as part of you overall project logic.
Doing this will make your overall logic more robust.

Session 5: Identify the Risks Associated with the Assumptions

You have now completed your ‘outcomes hierarchy’ and have documented and prioritised
your assumptions. One final step you may like to consider is further identifying the risk
associated with the assumptions. Understanding the context, operating environment, and
systems in which the project will operate is critical when it comes to designing and assessing
the relevance of strategies and activities, anticipating operational problems, and finally
assessing a project’s contribution to change.
An implementing organisations control over factors in the project environment that influence
(support or impede) the achievement of outcomes decreases as you progress up each level of
the outcome’s hierarchy (see Figure 1 below).

Developing A Project Logic: A Guide for Project Design

11
Figure 1. The limits of control and accountability in a project

Foundational Immediate Intermediate Longer Term Aspirational Goal

(Getting (Activities) (End-project- Outcome
Ready) outcomes)
What is the project contributing
towards?
What overall can the project reasonably be held
accountable for influencing?
What is within the direct control
of management?
Degree of control and accountability reduces

It can be useful for your team to ‘brainstorm’ about what circumstances could present a risk
to the likelihood of an assumption being correct – that is, that the project activities may not
lead to the results assumed in the project logic. This is one part of assessing project risk and
assist risk mitigation and management strategies to be put in place.
Table 1 provides a more in-depth way for your group to think about how likely it will be that
the assumption is wrong and what will be the consequence for the project and if you can do
anything about managing the risk.

Table 1. Project logic risk worksheet

Assumption Likelihood of Consequence for Risk

assumption being intermediate and longer- management
wrong term outcomes if strategies
1-5 (1=rare, 5 = very assumption is wrong
likely) 1-5 (1=insignificant; 5=
extreme)

Add more rows as needed

Conclusion and Next Steps

You will now have a basic understanding of what project logic is, why and when you use it and
some experience in building project logic that is relevant for your work.

• Put your project logic up on your office wall – written out on A4 coloured paper, keep it
visible.
• Make sure that you and your team can explain it to people who do not know what you
are doing.
• Use the logic to test your activity decisions. Will this activity lead to this desired
outcome?
• Keep it alive and use it for framing your reporting and refining your approach.
• Celebrate when you have achieved important steps along the way!
• Keep an eye on your assumptions.

Output: A useful project logic: has been developed collaboratively, meets your needs for
describing your project and can be readily understood by your colleagues and project partners.

Developing A Project Logic: A Guide for Project Design

12
References

Source: Rogers, P. (2005) Logic Model, in Encyclopedia of Evaluation, edited Mathison, S. Sage
Publications, California. pp 232-235

1
The term ‘Longer term outcome’ is often used interchangeably with ‘Goal’.

Developing A Project Logic: A Guide for Project Design

13
Developing A Project Logic: A Guide for Project Design
14