Project evaluation focuses on what changes actually occur as a result of the project and how those changes align with the intended long-term effects. In the logframe, the chain goes from inputs and activities to outputs, then to outcomes, and finally to the goal or impact. Evaluation is most concerned with the outcomes—the changes experienced by beneficiaries—and the goal (or impact)—the broader, longer-term change the project aims to contribute to. Outputs and inputs are more about deliverables and resources and are typically the focus of monitoring rather than evaluation. For example, if training is delivered (an output), evaluation looks at whether participants gain skills (an outcome) and whether those skills lead to the broader objective like improved employment or income (the goal/impact). Therefore, the two levels most central to evaluation are outcomes and goals.

In development projects, switching to an assets-based approach means starting from what the team already has—people, skills, networks, resources, and institutional capacities—and asking how those assets can be mobilized to achieve the desired change. This shifts the focus from diagnosing and detailing a problem to leveraging existing strengths, which can accelerate action and build on what’s sustainable in the community. That makes Problem Analysis the best fit to be replaced in this context because it specifically centers on identifying the problem, its causes, and gaps; when teams adopt an assets-based view, they often bypass or downplay this deficit-focused analysis in favor of mapping and deploying available assets. For example, instead of dissecting why a community lacks clean water, you’d inventory local wells, water committees, technicians, funding partners, and other assets to design a practical plan using what’s already there. Other tools—Stakeholder Analysis, Decision Analysis, and Scenario Analysis—serve different purposes (who is SAMPLEinvolved, how to evaluate options, and how outcomes might unfold under different futures) and aren’t typically replaced by an assets-based approach, though they can complement it.

Procurement planning focuses on what to buy and how to buy it so the project can obtain the necessary goods or services at the right time and cost. The essential steps are to define needs precisely, decide the procurement method, prepare terms of reference or detailed specifications for bidders, plan the procurement timeline to align with the project schedule, and evaluate and select suppliers or vendors along with the contracting approach. Defining needs ensures clear, measurable requirements. Choosing the procurement method aligns the approach with market conditions and governance rules. Specs or terms of reference translate requirements into concrete bidding or contracting criteria. Planning the timeline coordinates all procurement activities with project milestones to avoid delays. Selecting suppliers establishes the sourcing strategy and contract framework. The other activities belong to different areas: risk management tasks involve the risk register and response plans, organizational planning covers assigning project roles, and communications planning handles stakeholder communications.

The Logframe hierarchy moves from the big, long-term change you aim to contribute to, down to the concrete tasks you must carry out. In this model, the top level is the Goal (the ultimate development objective you want to achieve). Next are the Outcomes—the changes in conditions or behavior that must happen for that goal to be reached. Below that come the Outputs—the specific deliverables or products the project must produce to bring about those outcomes. At the bottom are the Activities—the concrete actions and work you perform to create the outputs. This order is logical because you can only achieve the desired outcomes if you deliver the necessary outputs, and you can only deliver those outputs by executing the required activities. For example, to improve rural livelihoods (the goal), you need outcomes such as higher household income and better access to markets; to bring about those outcomes, you must produce outputs like training programs, market information systems, and improved seeds; and to produce those outputs, you must carry out activities like scheduling training sessions, distributing materials, and coordinating market events. The other sequences try to place activities before outputs or mix up the relationships between levels, which breaks the cause-and-effect flow that the logframe is built to represent. So the correct order is Goal, Outcomes, Output, Activities.