BT MANAGEMENTBUSINESS & STRATEGY
Contact
A London project team agrees the scope and owner of a customer portal before implementation.

Journal

A one-page project charter: get clear before the work begins

Projects often start with apparent agreement rather than a bad plan. People nod at phrases such as “customer portal”, “CRM rollout” or “order automation”, while picturing different results. Work begins, the deadline approaches, and the first review reveals that nobody settled what should change, what is inside the project, or who can make the final call.

An SME does not need a thick pack for every initiative. It needs a short decision record that can be read in five minutes and used when choices become difficult. A one-page project charter is not the delivery plan. It is the team’s working agreement on why the project exists, where its boundaries sit, and what evidence will count as success.

Start with the problem, not the proposed solution

Describe the current condition and its consequence first. Instead of “implement a new system”, try: “Orders are re-entered across three files, so we cannot reliably see the status of a job.” Then describe the desired change. This keeps room to discover that a smaller process change, a data fix or a different tool may solve the problem better.

Attach observable evidence and a baseline to the outcome. It might be processing time, the number of manual handoffs, or whether agreed data is available at the point of decision. The GOV.UK Service Manual stresses that without a baseline you cannot tell whether the project improved the situation. If the baseline is unknown, assign someone to establish it by a date; do not manufacture a figure.

Seven fields that fit on one page

  • Problem and reason: what is happening now and why it is worth addressing.
  • Outcome and evidence: what will be different and how the team will verify it.
  • In scope and out of scope: what the project will and deliberately will not deliver.
  • Owner and approver: who drives the work and who makes the final decisions.
  • Milestones: a few points where direction is reviewed and continuation is approved.
  • Assumptions, dependencies and risks: what must be true and what needs testing first.
  • Change rule: who may alter the scope and how effects on time, cost and quality are recorded.

The out-of-scope section matters as much as the deliverables. It is not a bin for good ideas. It prevents those ideas from entering an already committed deadline and capacity without a choice. A new request can be accepted, but only after deciding what is added, removed or delayed, or what extra capacity is funded.

Illustrative example: a customer portal

Illustrative example: a 12-person service company wants to launch a customer portal in eight weeks. The initial brief says only that customers will “see their jobs online”. At kickoff, the team defines the first outcome: customers can see the status of an open job and download an approved document. Invoicing, chat and a mobile app are explicitly outside the first release.

The operations lead owns delivery and the managing director approves scope. The riskiest assumption is that the existing system exposes sufficiently current data. Instead of building the whole portal immediately, the team tests an export and the clarity of its status labels on a small sample in week one. If the assumption fails, the approver chooses whether to fix the source, narrow the release or stop the project.

Use kickoff to close ambiguity

Send a draft charter beforehand and do not spend the 60-minute kickoff presenting it. Work through disputed phrases: exactly what success means, which requests are out, who decides when priorities conflict, and which assumption could invalidate the plan. Give every open question an owner and a due date. Start only after explicit approval, not after silence that looks like consent.

A practical first-five-days sequence

  • Day 1: the owner drafts one page without attempting a detailed schedule.
  • Day 2: delivery and operations colleagues mark ambiguity, dependencies and missing evidence.
  • Day 3: the approver closes the outcome, boundaries and decision rights.
  • Day 4: the team tests the riskiest assumption or defines a credible test.
  • Day 5: approve the charter, keep it visible, and connect milestones and the work list to it.

A charter can change, but it should not drift silently. Record the reason, decision and impact of each material change. The page then remains a live reference instead of launch-day paperwork. Its value is not perfect wording; it is the habit of comparing small delivery choices with one shared outcome and a visible set of boundaries.

BT Management can help an SME shape the charter, facilitate an English-language kickoff workshop and establish a light review rhythm. The engagement is tailored to the business context and does not replace legal, tax or specialist technical advice.

People and efficiency

Put these ideas to work in your business.

Tell us about your situation. Together, we can choose a sensible first step and agree the scope of support.

Explore the serviceSend an enquiry
Your privacy

Analytics is on by default. We use Google Analytics and Microsoft Clarity to measure visits and website usage. Select “Reject analytics” to turn measurement off. We respect your saved opt-out. Forms and contact options work without analytics. Traffic statistics

Cookies and analytics are on.

Privacy settingsSettings

Analytics is on by default. We use Google Analytics and Microsoft Clarity to measure visits and website usage. Select “Reject analytics” to turn measurement off. We respect your saved opt-out. Forms and contact options work without analytics. Traffic statistics