Chapter 2: Define Success Before You Optimize Delivery

The dashboard is green

The monthly product council at KijaniPay is nine minutes old when Zanele Dlamini, delivery lead for the merchant platform launch, puts the dashboard on the screen. Every row is green: schedule, budget, scope, open risks, all inside tolerance. The launch is nine weeks out, and the mood is good.

Amara Osei, head of growth, is the first to speak. “Two markets on launch day. Lagos and Nairobi. That is what success looks like.”

Kwame Mensah, head of risk, disagrees without hostility. “Launching before the fraud controls are proven is how a platform gets eaten alive. Success is fraud losses under half a percent of processed volume in the first quarter.”

Thandi Mbeki, head of compliance, raises a hand. “Neither of those matters if a regulator withdraws our authorization. Success is regulatory confidence: licenses in place, examiners satisfied, an audit trail that holds.”

The support lead has spent a month listening to merchants, and her definition is the quietest. “Success is a merchant who can see her settlement and borrow against it. If that is not in the picture, we have built a payment button, not a platform.”

Zanele looks at the room. The charter, approved six weeks ago, defines the project as “a merchant payments and working-capital platform operating in two markets.” The sentence is a delivery description, not a success definition. It says what will be built. It does not say what must be true when the build works.

“Before we talk about dates,” she says, “we need to agree on what green means. Right now every leader in this room has a different dashboard, and all of them are green.”

That request is the subject of this chapter.

What the triangle does not tell you

The oldest model of project success is the triangle of time, cost, and scope, sometimes with quality at its center. Its value is real. You cannot fix all three corners independently; a change in one usually moves another, and the leader has to say openly which trade is being made. Every project leader should be able to explain it in one breath.

Its blind spot is larger than its value. The triangle is a constraint model, not a success model. It asks whether work can be delivered within limits; it does not ask whether the work should exist, whether anyone will use it, or whether it changes anything that matters. A project can hit all three corners and fail: on time, on budget, to spec, and useless. A project can miss all three and be the right call: an early pivot that sacrifices the plan to save the purpose. The triangle describes the delivery box. It says nothing about what the box is for.

Define success, then, in five domains, each with different evidence, different owners, and a different moment when it can be judged. Delivery success means the agreed outputs were produced within the agreed time, cost, and quality; the project team owns it, and it can be judged on the day of handover. Product success means the outputs work as intended: usable, reliable, fit for purpose; product and engineering own it, and real-world use judges it. Adoption success means the people who should use the output do use it, in the way intended. The project designs for it; operations co-produces it; usage after handover is the evidence. Benefit success means the measurable advantages appear, revenue, cost, risk, time, health, access; named benefit owners, accountable before the project began, verify it. Strategic success means the change moves the organization toward its purpose and earns its place in the portfolio; leadership owns it, and it is judged last and least precisely.

The domains cascade in time. Delivery precedes product, product precedes adoption, adoption precedes benefit, and benefit precedes strategic impact. Early reporting is therefore dominated by delivery success, the only domain with evidence so far, and delivery success is a poor guide to the rest. A success profile that stops at the delivery box is a plan in search of a purpose.

The five domains say what kind of success you are judging; the radar says how strong your evidence and position are. A success profile must not quietly drop dimensions that are hard to measure; the radar keeps them visible. Score each spoke from 1 to 5, and the shape shows where the project is strong and where it is guessing.

Figure 2.1: The success radar, KijaniPay at the month-one review
(score 1-5: how strong is evidence and position on this spoke?)

   value          ████████░░  4
   time           ████████░░  4
   cost           ████████░░  4
   quality        ██████░░░░  3
   adoption       ████░░░░░░  2
   risk           ██████░░░░  3
   sustainability ████░░░░░░  2
   learning       ████░░░░░░  2

Delivery is strong; adoption and learning are guesses. Sustainability often lands low because it is measured late, which is exactly why it needs a spoke. The shape is not a secret to be discovered; it is a decision to be made and defended. No spoke gets deleted because it is inconvenient; a low spoke is a risk statement, not a rounding error.

Thresholds, targets, and guardrails

Four words do most of the work in a success profile, and they are not interchangeable.

A threshold is the floor: below this level the outcome is unacceptable no matter what else succeeds. Fraud losses above 0.5 percent count as failure even if the launch is on time. A target is the aimed value, above the threshold but not guaranteed; targets are tradeable, thresholds are not. A guardrail is a hard boundary on a constraint that must not be crossed: a license, a safety limit, a privacy obligation, a continuity commitment. Guardrails are the nonnegotiables; crossing one is a decision for a level above the project. A trade-off rule is the explicit statement of what happens when targets collide: which dimension wins, who decides, and at what level. Without a rule, trade-offs are settled by whoever is loudest when they surface.

Guardrails usually originate outside the project, in an obligation: law, license, safety, contract, privacy. Thresholds originate in the project’s own judgment about acceptable performance, though a sponsor or regulator may impose either. The distinction says who may move what: obligations are not yours to trade; judgment is.

The minimum viable form of all four is one table. KijaniPay’s first draft looked like this.

Figure 2.2: The trade-off matrix, first draft (KijaniPay)

Put thresholds into money and the argument changes character. KijaniPay projects about 2.4 billion (local-currency, nominal) of processed volume in the first quarter after launch. At a 0.3 percent fraud-loss target, expected fraud cost is about 7.2 million; at the 0.5 percent threshold, about 12 million. The 4.8 million gap is the exposure band the launch-timing decision controls. If an earlier launch means the controls are less proven and fraud lands near the threshold instead of the target, that cost is quantifiable. Weigh it against the margin from two months of extra volume. The arithmetic does not make the decision; it makes it discussable by the people with authority, instead of by the loudest voice in the room.

Two failure modes bracket this work. Everything labeled a guardrail, so nothing can move and no decision is possible; its signal is meetings that cannot conclude. Or everything tradeable, so guardrails leak and the project crosses a license or safety boundary “temporarily”; its signal is someone discovering the crossed line after the fact.

The person who signs

The success profile names owners per domain. The benefit owner map goes one step further: it ties each benefit to a person outside the project, with a baseline, a target, and a measurement date, signed before delivery starts. It exists to answer one question at handover: who is accountable for the value this project promised? If the answer is “TBD,” the value will not be pursued; it will be inherited by no one.

The minimum viable form is a table of benefit, owner, baseline, target, measure, and check date, and the owner signs their row. Created at authorization, refreshed at handover, reviewed after closure by whoever owns benefits. The failure mode is the map that exists but nothing is signed: a page of intentions that gives everyone cover and no one an obligation.

Leading and lagging indicators decide what the map measures. A lagging indicator reports what already happened: fraud losses in the first quarter, adoption at month six, revenue in year one. A leading indicator predicts what will happen: the rate at which merchants complete onboarding, the coverage of tests on settlement-critical flows, support tickets per new merchant, the staffing of operations before opening day. Leading measures are weaker evidence and arrive earlier; lagging measures are stronger evidence and arrive later, often after the decision window has closed. A measurement system needs both. Every leading indicator needs a named lagging outcome it is meant to anticipate, and a reason to believe the link holds; otherwise it is a number in search of a story. One subtlety: the same measure can be lagging for one domain and leading for another. Merchant activation at month two is lagging for adoption and leading for benefit. When the team fights over whether a metric is leading or lagging, ask: leading or lagging for which future, and owned by whom?

The day you stop

The least comfortable part of a success profile is the part that says when success is no longer achievable. Write three to five stop-or-pivot conditions at authorization, each with three parts: the evidence, the threshold, and the decision forum. KijaniPay’s own profile carried three: if active merchants are below 60 percent of plan at month three, the forum reviews adoption blockers before any second-market launch; if fraud losses breach the 0.5 percent threshold for two consecutive weeks, new merchant onboarding pauses until root cause is fixed; if a regulator imposes conditions that change the unit economics beyond the business-case tolerance, the project re-baselines or stops.

An authorized project is a provisional investment, not a promise to finish. Conditions change: a competitor redefines the market, evidence refutes the value hypothesis, a dependency collapses. Stopping on evidence, with the learning captured and the decision made in daylight, is a success in selection and judgment, not a defeat. What is not a success is continuing because stopping feels embarrassing, or stopping because truth-telling is awkward. Governance makes stopping honorable by making it routine: stop decisions are evidence reviews, not blame ceremonies. The conditions must exist before the pressure arrives, because pressure is exactly when nobody wants to write them.

The workshop where KijaniPay agreed on green

Zanele runs the workshop the following week. It is uncomfortable on purpose.

The growth row lands first: 40,000 active merchants across both markets by month six, with 60 percent of onboarded merchants transacting at least weekly. No one has a baseline for merchant behavior in these markets, and everyone knows it. The target is a hypothesis with a review date; the profile says so in its assumptions line.

The risk row: fraud losses under a 0.3 percent target, a 0.5 percent threshold, measured on processed volume. Kwame asks for the draft’s fraud guardrail; nobody votes against fraud control, and the fight is about what else moves when it happens.

The compliance row: Thandi asks for the authorization guardrail, and after a long silence the room agrees. A launch without authorization is not a launch; it is a violation.

The trade-off matrix states the resolution in one line: guardrails do not move for dates. What moves are the launch date, the market sequence, and the working-capital feature scope. Each move is a re-baseline decision with owners in the room.

The merchant voice changes the last row. The support lead drafts adoption success as “a merchant who can see her settlement and borrow against it.” The room rewrites it into measures: settlement funds available within 24 hours for 99.5 percent of merchant accounts, and 25 percent of eligible merchants applying for working capital by month nine. Zanele marks the second measure as a benefit owned by the finance lead, with a baseline to be established in the pilot.

Four weeks later the dashboard looks different. Delivery is still green. Adoption has a number now, and the number is weak. Nobody is surprised, because the room agreed in advance what weak would mean and what would happen next: adoption blockers first, second-market launch second. The argument they would have had at month six, with two markets live and merchants churning, happens months early, where it costs a re-plan and not a reputation.

What the delivery style changes

The five domains are method-neutral; the life cycle changes how the profile is maintained. In a predictive setting, the profile is fixed at authorization; changes go through change control with the same discipline as scope changes. Benefits are tracked after handover against the business case; stability is the point. In an adaptive setting, the profile is a set of hypotheses, especially in the adoption and benefit rows. Every review checks evidence against hypotheses and reorders work. A refuted hypothesis is a finding, not a failure; revision is explicit, logged, and owned. In a hybrid setting, some rows are stable and some experimental. KijaniPay’s guardrails, the license and the fraud stop trigger, stay stable; its adoption targets are revisable. The seams between them are named, so revisiting one row does not silently move another.

The discipline in every mode is the same: guardrails stay stable, targets move on evidence, and every move is a decision with an owner and a date.

The single green metric

The dashboard says green. The project is failing.

The mechanism is mundane: one metric carries the whole story. The team reports platform availability at 99.96 percent and features shipped at 100 percent of scope, so the project is declared healthy. Active merchants sit at 11 percent of plan, and nobody has asked who owns adoption. The availability number is real and worthless for this failure: the platform is stable in the hours nobody uses it. The features number is real and worthless too: shipping a feature is not the same as a merchant relying on it. Competent people produce this failure every quarter, because the metrics they can report cleanly are the ones about their own work, and the metrics that reveal value belong to other people.

The tell: every metric on the dashboard is owned by the team that reports it, and the domains that depend on other people, adoption and benefit, have no row at all. The correction is structural: a measure and an owner for every domain, and one standing question at every review: which of these numbers could be green while the project is failing?

Practice

1. A quick classification. Classify each statement into the five success domains or “activity”: “All 40 planned features shipped on the launch date.” “Settlement reconciliation completes within 24 hours for 99.5 percent of merchant accounts.” “Sixty percent of onboarded merchants transact at least weekly by month six.” “Merchant churn falls by an estimated 15 percent as settlement time drops to same-day.” “KijaniPay becomes the payments platform small businesses recommend to one another.” “The team logged 900 hours of testing this quarter.”

The first is delivery success, outputs on time. The second is product success, the output working as intended. The third is adoption success, people using it. The fourth is benefit success, a measurable advantage; note that it is an estimate, so it belongs to the plan, not yet to the evidence. The fifth is strategic success, position and purpose. The sixth is activity, real and possibly useful, but not a success domain; the common error is treating effort as a domain.

2. Build your own profile. Choose a project you know from work, community, or study. Build a one-page success profile with the five domains, a measure and an owner per row, and mark the two rows with the weakest evidence. Write one sentence about what each weak row implies for the first decisions of the project.

The exercise succeeds when every row has a measure and a name. The weak rows are usually adoption and benefit, because their evidence appears after handover. A defensible answer treats a weak row as a risk with a mitigation (a pilot, a baseline study, an owner who signs) rather than as a reason to delete the row.

3. A decision room. Two weeks before launch, KijaniPay’s board asks to add a third market, Accra, because a competitor announced expansion. The trade-off matrix says licenses are a guardrail in each market and the launch date is tradeable. Decide: add, decline, or offer a conditional alternative, and defend the trade-off.

The matrix decides the shape, not the answer. Adding a market touches every domain: delivery (dates), product (localization and support), adoption (merchant support in an unproven market), benefit (spread thinner), strategic (competitive response). A defensible answer declines and offers staged entry after first-market evidence, or accepts under explicit conditions: Accra authorization in place, fraud controls proven in the first two markets, and a named owner for whatever is deferred. The unsafe option is accepting to please the board while quietly dropping the fraud stop trigger or the adoption plan. Good answers name the evidence that would change the recommendation: competitor data or onboarding capacity.

4. The mastery drill. At the month-three review, the dashboard shows: platform availability 99.96 percent (green); features shipped 100 percent of scope (green); onboarding completions 132 percent of plan (green); fraud losses 0.46 percent against the 0.5 percent threshold (amber); active merchants 11 percent of plan (red); licenses in both markets (green). Which metric could be green while the project is actually failing, and which is the most reliable tell?

The green that hides the failure is onboarding completions: sign-ups at 132 percent of plan prove nothing about use, and they look good precisely because they are easy to produce. The most reliable tell is active merchants at 11 percent of plan: it is the leading-for-benefit measure that connects the product to value, and it is red while delivery is green. Platform availability is real but measures the wrong thing; features shipped is delivery success and cannot certify adoption. Fraud at 0.46 percent is amber but not a breach: a guardrail approached, not crossed. The review trigger (below 60 percent of plan at month three) has already fired, so the adoption-blocker review begins before any second-market launch. A strong answer also names the missing row: the benefit domain has no revenue or churn measure yet.

5. Transfer question. In your organization right now, which of the five domains has no owner for the project you lead or work on? What would the project look like if that row were owned by a named person with a signed baseline?

Success is not a target you hit once; it is a decision about what must be true, owned by named people, revised on evidence, with guardrails that do not move and stop conditions that get used. The most common next failure comes from skipping the systems view: a success profile built in one room for a system that lives in many rooms, with causes that feed back, dependencies that surprise, and stakeholders who were never in the room. That is the subject of the next chapter, “Read Context, Complexity, and the Whole System.”

Notes

• KijaniPay is a composite case created for this book; no real organization is depicted. Its merchants’ need for predictable settlement and cash-flow visibility is introduced here and investigated fully in Chapter 6, “Discover the Real Problem.”
• The five success domains, the success radar, and the threshold, target, guardrail, and trade-off-rule vocabulary are the author’s synthesis, not terms drawn from any standard. ISO 21502:2020 and the PMBOK® Guide, Eighth Edition (Project Management Institute, November 2025) treat related ideas in outputs, outcomes, benefits, and constraints; readers should consult the official publishers for the current text.