Success measures and the bounded project brief

By the end, you can

• Define a success measure and explain how it differs from a project's broader benefits (PM-1).
• Assemble a goal, scope, assumptions, constraints and success measures into one bounded project brief (PM-1).
• Identify which of the five brief elements is missing from an incomplete project brief (PM-1).

Before you start

This is Module 1, Lesson 3 of the AI-Powered Project Management course, and the last lesson before Module 2's work on planning with AI. It builds on Lesson 1's goal and scope and Lesson 2's assumptions and constraints, and closes this module by assembling all five into one document: a bounded project brief.

Success measures: how you'll know it worked

A goal states the aim. A success measure states how you'll know, concretely, whether the project actually got there. APM's project management glossary defines "success criteria" as "the satisfaction of stakeholder needs for the deployment of a project," and draws a deliberate line between that and a project's broader benefits: success criteria are, in the glossary's words, "a different performance measure to benefits, which are focused on the strategic intent and delivering beneficial change." APM defines a benefit itself as "a positive and measurable impact of change."

The distinction matters in practice. A benefit is often slow, indirect and hard to attribute to one project alone — "reduced staff turnover" might take a year to show up and could have several causes. A success measure should be closer to hand: something you can check at or shortly after delivery, tied to what the project itself produced. For the onboarding project from Lesson 1, "new hires reach full productivity within three weeks" is close to a benefit claim — useful, but slow to confirm. A success measure sitting underneath it might be: "90% of new hires can name their assigned buddy and onboarding contact by day two," which you can check within the first month of the new process running, without waiting a full year to see whether turnover actually falls.

Assembling the bounded project brief

A bounded project brief is not a new invention — it extends what APM's glossary calls a scope statement: "a documented description of the project that identifies the project boundaries, its output, approach and content." The same glossary entry adds that a scope statement "is used to provide a documented basis to help make future project decisions and to confirm or develop a common understanding of the project's scope by stakeholders." This course's brief adds the two elements Lesson 2 introduced — assumptions and constraints — and a named success measure, so the document states everything a reviewer needs to check before treating the project as ready to plan.

A bounded project brief has five elements, and a brief missing any one of them is not bounded, whatever else it contains:

AI can draft a first pass at all five from a rough idea, the way Lessons 1 and 2 showed — the US National Institute of Standards and Technology's (NIST) AI Risk Management Framework's own description of an AI system as something that "can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions" is exactly why a draft brief is a starting point, not a finished one. What makes the brief real is the same discipline both lessons already established: the named sponsor or lead reviews, corrects and confirms each element using knowledge the AI never had access to, before anyone treats the brief as agreed. Signing off a bounded project brief is itself the kind of call OWASP's guidance on excessive agency has in mind when it recommends that a human "approve high-impact actions before they are taken" — committing a project's scope, budget assumptions and success bar is exactly that kind of high-impact action.

• Goal — the result the sponsor wants, in plain language.
• Scope — what work is in, and what is explicitly out.
• Assumptions — what is being taken as fact, not yet verified, and by when it needs checking.
• Constraints — the fixed limits the project must work within.
• Success measures — how you'll know, concretely and checkably, that the goal was met.

A worked example: a nonprofit's volunteer training programme

A mid-size nonprofit's programme director wants to launch a volunteer training programme. She has drafted a goal and scope with an AI assistant, following Lesson 1's pattern, and a list of assumptions and constraints, following Lesson 2's, and now assembles the whole brief before taking it to her director for sign-off.

Goal: "New volunteers complete their first supervised shift within two weeks of applying, rather than the current six." Scope: in — an online orientation module, a mentor pairing for the first month, a written role checklist; out — changes to the volunteer application form itself, which a separate project already owns. Assumptions: "assumes enough current volunteers will agree to mentor" (unverified — she will confirm with the volunteer coordinator this week); "assumes the online orientation platform the nonprofit already uses can host new content without a paid upgrade" (unverified — she will check with IT). Constraints: "must launch before the autumn recruitment drive"; "no budget for new software." Success measure: "80% of new volunteers complete a supervised first shift within two weeks, measured for the first three months of the new process."

Before she takes this to her director, she notices the brief is missing something: nobody has stated who decides whether the programme continues if the 80% target isn't met after three months. She adds a line naming her director as that decision-maker, because a brief that states a success measure but not who acts on the result is still missing an element the review will need.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Project management glossary — APM (Association for Project Management). Defines "success criteria" as the satisfaction of stakeholder needs, distinct from "benefits," and defines a "scope statement" as a documented description of the project's boundaries, output, approach and content, used to help make future project decisions and to confirm or develop a common understanding of the project's scope by stakeholders.
2. AI Risk Management Framework 1.0 — NIST AI Resource Center. Frames an AI system as an engineered system that generates outputs such as predictions, recommendations or decisions — not a self-directing decision-maker.
3. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends human-in-the-loop control requiring a person to approve high-impact actions before an LLM-connected system takes them.