Is your project properly scoped?

The ten points checked

The assessment reviews these ten dimensions. They are the ones that, across banking, energy and public-sector engagements, explained most of the overruns I had to recover.

1. 01 · Objective

   Is the project objective stated as a measurable outcome?

   A project whose objective is a feature list can never be declared a success or a failure: it has no criterion. Restate it as an expected outcome — a shorter lead time, a lower cost, a lower error rate — and set the target before writing the first story.

2. 02 · Decision-maker

   Does one single person settle scope disagreements?

   No single decision-maker is the leading cause of scope creep: every stakeholder adds their need and nobody has the mandate to say no. Name that role explicitly, and have the person confirm it.

3. 03 · Scope

   Is what is OUT of scope written down explicitly?

   Scope is not defined by what it contains alone. Writing the exclusions turns a painful end-of-project argument into a trade-off settled early, while it is still cheap.

4. 04 · Stakeholders

   Were the impacted teams consulted before kick-off?

   A team that discovers a tool on switchover day rejects it, even when it is better. Identify the impacted groups early — support, business, compliance — and have them contribute, even briefly.

5. 05 · Requirements

   Is the need split into independently deliverable pieces?

   A monolithic requirement can neither be prioritised nor delivered incrementally: everything lands at once, or nothing does. Split by business value rather than by technical layer.

6. 06 · Prioritisation

   Does prioritisation follow an explicit rule?

   With no visible rule, prioritisation turns into a power struggle. Even an imperfect method, applied openly, defuses most of the tension because it shifts the debate onto the criteria.

7. 07 · Acceptance criteria

   Are acceptance criteria written BEFORE development?

   Writing criteria afterwards means validating what was built rather than what was expected. Written up front, they serve as both specification and test, and remove most of the back-and-forth.

8. 08 · Risks and dependencies

   Are external dependencies identified and tracked?

   External dependencies — a vendor, a partner API, a compliance sign-off — are the most common and least anticipated cause of delay, precisely because they sit outside your team. Track them like tasks, with a name and a date.

9. 09 · Governance

   Is there a steering rhythm fixed in advance?

   A steering meeting that produces no written decisions is just a status update. The decision log, circulated after each meeting, is what stops the same trade-offs being replayed three months later.

10. 10 · Success measurement

    Will you be able to measure the outcome after go-live?

    Without a baseline recorded BEFORE go-live, you will never be able to demonstrate the gain: there is nothing to compare against. That figure is what justifies the budget for the next project.