From a Vague Request to a Clear Project
Most projects start with something like this from a manager: "Can you sort out the meeting room booking mess?" That is a request. It is not a project yet. Nobody knows what "sorted" looks like, when it is due or what is included.
In this level you will turn a request like that into three things:
- SMART goals: what success looks like, in measurable terms.
- A scope statement: what is in, what is out, and the assumptions and constraints.
- A one-page project brief that your sponsor signs.
The example used throughout: the Leeds office has 40 staff and 6 meeting rooms. Rooms are booked on a paper sheet, and double bookings happen about 10 times a month.
Step 1: Rewrite the Request as SMART Goals
SMART is a checklist for writing goals. George T. Doran introduced it in Management Review in 1981. His original letters were Specific, Measurable, Assignable, Realistic and Time-related. The version most often used today is:
- Specific: says exactly what will change.
- Measurable: has a number or test that proves it happened.
- Achievable: realistic with the people, money and time available.
- Relevant: matters to the organisation and to the person asking.
- Time-bound: has a deadline.
Do this:
- Write down the request word for word.
- Ask the requester: "What would be different if this went well?" and "How would we know?"
- Turn each answer into a sentence that passes all five letters.
- Add one or two success criteria. These are the measures you will check at the end.
Example:
- Vague: "Sort out room booking."
- SMART: "By 31 January 2027, all 40 Leeds staff book the 6 meeting rooms through one online booking tool, and double bookings drop from about 10 a month to none during February 2027."
- Success criteria: (a) the paper sheet has been removed; (b) no double bookings are logged in February 2027.
Check: cover the deadline and the numbers with your hand. If the goal now reads like a wish, it was not SMART.
Step 2: Draw the Scope Line
Scope is the boundary of the project. Think of it as a fence. Work inside the fence is your job. Work outside it is not, unless the sponsor formally moves the fence.
Do this:
- List everything the project will deliver (in scope).
- List the related things people might expect but the project will not deliver (out of scope).
- Write the out-of-scope list as carefully as the in-scope list. Most disagreements later on start with something nobody wrote down.
Example:
| In scope | Out of scope |
|---|---|
| Choose and set up one booking tool | Catering orders for meetings |
| Add all 6 Leeds rooms | Other offices |
| A 15-minute guide and drop-in session for staff | New screens or video equipment in rooms |
Step 3: Record Assumptions and Constraints
These two are easy to mix up:
- An assumption is something you believe is true but have not proved. If it turns out to be wrong, the plan may change. Example: "IT will give us admin access to the calendar system by 15 November."
- A constraint is a fixed limit you must work within. Examples: "Budget is capped at £2,000." "No changes to room layouts." "Must go live before 31 January 2027."
Do this: write three to five of each. For each assumption, add who can confirm it.
Step 4: Fill In the One-Page Project Brief
The brief collects everything above on one page. The name depends on where you work:
- UK (PRINCE2): a project mandate is the starting request from senior management. It can be as short as an email. The project brief is the document built from it.
- US (PMI): a project charter is the document, issued by the sponsor, that formally authorises the project and gives the project manager authority to use resources.
At this size of project they do the same job. Use whichever name your organisation uses.
Template: copy this and fill it in for the room booking example
- Project name:
- Sponsor (the person who owns the budget and signs off):
- Coordinator:
- Background (two sentences on the problem today):
- SMART goal(s):
- Success criteria:
- In scope:
- Out of scope:
- Assumptions:
- Constraints (budget, dates, rules):
- Target end date:
- Sponsor sign-off (name, date):
Keep it to one page. If it runs over, you are probably writing a plan. Planning comes in later levels.
Step 5: Check It With the Sponsor Sign-Off Checklist
Before you ask for a signature, check every box:
- Every goal has a number or a test, plus a date.
- Someone who did not write the brief could say what "done" means.
- The out-of-scope list has at least three items.
- Assumptions and constraints are listed separately.
- The budget and end date match what the sponsor told you.
- The whole brief fits on one page.
- The sponsor has signed and dated it.
Then do this: walk the sponsor through it in 10 minutes. Ask: "Is anything here wrong or missing?" Make the changes, get the signature and save the signed copy where the team can find it.
Key Takeaways
- A request is not a project. SMART goals and success criteria tell everyone what "done" means.
- Writing down what is out of scope prevents arguments later.
- An assumption is believed but not yet proved. A constraint is a fixed limit.
- PRINCE2 (UK): the mandate is the starting request and the brief is built from it. PMI (US): the charter formally authorises the project.
- Keep the brief to one page, check it against the checklist, and get the sponsor to sign it.