Objective-oriented project planning (OOPP)

Objective-oriented project planning starts with the change a project is meant to create, then works backwards to the results, evidence, assumptions, and activity needed to create it. It is a practical way to stop a project plan becoming a schedule of busy work with no credible connection to value.

The method is particularly useful at the uncertain front end of a project. A team makes its causal reasoning visible before it commits heavily to scope, budget, or delivery dates. The finished plan is compact enough to guide a kickoff and structured enough to support monitoring, review, and later evaluation.

When to use it

Use OOPP when a project is strategically important, involves several functions, or depends on behaviour and conditions that the delivery team cannot create directly. It is also useful when:

• stakeholders agree on the activity but not the purpose;
• a project has many deliverables and no shared definition of success;
• a schedule exists before the team has tested whether the proposed outputs can create the intended outcome;
• critical dependencies are being discussed as risks but not built into the project logic;
• a project needs a concise design that can sit above an agile, predictive, or hybrid delivery plan.

For a small, well-understood task, a brief or checklist may be enough. OOPP earns its effort when the causal path, evidence, or external conditions need serious discussion.

Origins

Objective-oriented project planning is closely associated with the logical framework approach used in international development. One tradition calls the method ZOPP, from the German term for objectives-oriented project planning. Terry Schmidt's Strategic Project Management Made Simple adapts the same family of ideas for general management through an accessible sequence of project-design questions and a logical framework matrix.

This KeyModels version retains the useful core - causal objectives, measures, verification, assumptions, and action - while using plain business language and treating the plan as an evolving hypothesis rather than a fixed contract with the future.

What it is

OOPP combines two views of one project:

1. A causal hierarchy that explains how activity is expected to create progressively higher results.
2. A project strategy matrix that adds success measures, evidence sources, and external assumptions at every level.

The hierarchy reads from delivery to strategy:

Activities and inputs -> Outcomes -> Purpose -> Goal

Activities and inputs

are the work, people, money, technology, and time the team manages.

Outcomes

are the concrete results the team commits to deliver or make operational.

Purpose

is the project-specific change expected when people use, adopt, or benefit from those outcomes.

Goal

is the broader organisational or strategic result to which the project contributes but cannot achieve alone.

The direction matters. Plan from the top down by asking how each higher result could be achieved. Test from the bottom up by asking whether each lower level, together with its assumptions, is plausibly enough to create the level above.

Four design questions

Answer them in that order. Beginning with tasks makes it easy to optimise delivery of an output that does not solve the problem.

The project strategy matrix

The matrix is not merely a reporting table. Reading down tests the design from strategy to action. Reading across tests whether each objective is measurable, verifiable, and exposed to an understood environment.