Program review or program evaluation? Not just semantics
Read enough RFPs and the pattern shows up fast. One asks for a program review, then lists deliverables that describe an evaluation. Another asks for an evaluation, but every question in the scope of work is really about structure.
These sound like the same request. They are not. Confusing them costs time and money before the work even starts.
What a program review asks
A program review looks at the whole system: all the programs, policies, and structures currently in place to address a problem. It asks whether that system, taken together, still fits what is needed now. Sometimes the answer points to one structure. More often it points to several, or to how they connect, or fail to connect, with each other.
This was the real question behind the Elder Abuse Strategy Review I led some years ago. The assignment was never to judge a single program or agency. It was to look across an entire strategy, involving many programs and structures, and ask whether the pieces still added up to the right response. That turned out to be a much bigger question than reviewing any one part on its own.
A review can surface overlap. It can surface gaps. It can point to duplication that nobody upstream can see, because they are only looking at their own piece of it. The finding is a judgment call about the system, built on pattern recognition across many organizations facing the same kind of question.
What a program evaluation asks
A program evaluation is narrower. It tests one program's outcomes against the goals it was funded to achieve. Did this specific initiative do what it promised. Would it be worth funding again, and why.
That question needs a credentialed evaluation method to answer with any confidence. It is a different kind of rigour than a structural review, built for a different kind of question, and it deserves to be scoped as its own piece of work rather than folded into a broader review as an afterthought.
None of this means the two never overlap. A review can turn up a specific program that clearly needs its outcomes tested. An evaluation can reveal that the real problem was structural all along, and no amount of evaluating that one program will fix it. The point is not to keep review and evaluation in separate boxes forever. It is to know which question you are starting with, so the scope of work matches what you actually need answered first.
What good looks like
Before you scope either piece of work, get clear on which question you are actually asking. If you are not sure whether the whole system still makes sense, start there. If the system is sound and the real question is whether one program is delivering, that is an evaluation question, and it should be scoped as one.
Getting this distinction right before the work begins saves months of confusion later. It is the difference between a report that answers the question your organization actually had, and one that answers a question nobody was asking.
Susan Underhill is the founder of Connor Claire Group, a policy and management consulting firm working with government and non-profit organizations across Canada.