Four useful starting scopes

A request for “a better system” needs a smaller decision before it becomes a project. The options below describe different first deliverables for UK organisations. They are planning examples, not fixed-price packages or accounts of completed client work.

Explain a service people already misunderstand

A fictional association receives repeated calls from applicants who cannot distinguish student membership from full membership. The application software may be functioning correctly. The immediate work could be a clearer comparison page, a better explanation of the evidence required and a route for uncertain cases.

The first scope would identify the approved eligibility information, the pages visitors encounter and the content owner. Acceptance could ask an unfamiliar person to choose a route for two representative situations and explain what happens next. Building a new portal before fixing the explanation would not necessarily reduce the calls.

Make a pending item visible

A training team knows that an enquiry was received but cannot tell which colleague is arranging it. A small staff queue may be more useful than a broad CRM replacement. The record needs a responsible person, a meaningful state and a way to distinguish waiting for the customer from waiting for an internal decision.

The scope would include how an item arrives, how responsibility changes and what counts as finished. It should also cover absences: a queue that works only when the original recipient is present simply moves the dependency to a new screen. Workflow breakdowns examines this problem in detail.

Investigate a specific failure

An inherited PHP application may fail only when staff correct an older record. A bounded investigation can reproduce that path, identify relevant dependencies and explain whether a repair is feasible. It should deliver evidence and limits, not a guessed diagnosis followed by a large rebuild proposal.

The organisation supplies appropriate access and the expected result. The investigation records what was tested, which uncertainty remains and what the next decision would cost to resolve. PHP repair describes the service.

Move content with its purpose intact

A redesign can begin with a content decision map before templates are built. An old event page, an enduring guide and a member-only document each need a destination based on their current purpose and audience. The map can expose missing owner decisions while change is still inexpensive.

The output is useful whether the organisation later commissions a complete rebuild or keeps most of its current site. It records the old URL, the intended treatment and the reason. Content migration covers implementation and acceptance.

Choose the evidence you need next

A first deliverable should remove a real uncertainty or create a usable improvement. It need not include every future idea. State what the organisation will know or be able to do afterward, who can accept it and which dependencies remain outside the boundary.

The planning guide helps assemble those decisions. If you are unsure which starting scope fits, describe your current task and include what makes it difficult today.