Pocket PMO
Sign In
Back to blog

Your first week on a project: the setup checklist that prevents rework

August 26, 2026
Your first week on a project: the setup checklist that prevents rework

Almost every project that goes badly wrong in month three was set up badly in week one. Not through incompetence, but because the first week is chaotic: everybody wants a plan, nobody has agreed the scope, and the fastest way to look productive is to start typing tasks.

This is the checklist that stops that. It takes about a day and a half of real effort spread over five days, and it removes most of the rework that arrives later.

Table of contents

Day one: sponsor, outcome, boundaries

Find the one person who can say yes. Not the steering group, not the programme board, one named sponsor with budget authority. Projects with two sponsors have none.

Then write three things down and get them confirmed in writing:

  • The outcome — what will be true when this is done, in the sponsor's own words.
  • In scope — the material deliverables. Five to ten lines.
  • Out of scope — the things people will assume are included and are not. This list saves you more time than any other artefact you will produce.

If the sponsor cannot describe the outcome without describing a solution, you have a requirements problem, and it is cheaper to surface it now.

Day two: governance level and cadence

Decide how heavy this project needs to be, and write down the decision. Two levels are usually enough:

  • Light — small change, low risk, short duration. Plan, RAID log, decisions, weekly status. No stage gates beyond start and close.
  • Full — regulated, capital, cross-functional or high-value. Stage gates, baselines, formal change control, benefits tracking.

Choosing deliberately prevents the two classic failures: a £30k piece of change carrying board-level governance, and a £3m programme with no change control. Then fix the cadence in the same conversation: weekly status day, fortnightly delivery review, monthly steering. Put them in diaries this week or they will never happen.

Day three: the plan skeleton

Do not build a 200-line plan. Build a skeleton:

  1. Phases or stages, with a gate at the end of each.
  2. Between five and nine milestones for the whole project. Fewer than five means you cannot see progress; more than fifteen means nobody reads them.
  3. The critical dependencies, including the external ones you do not control.
  4. Tasks for the current phase only, in detail. Later phases stay at milestone level until you know more.

Planning distant phases in detail feels thorough and is almost entirely wasted. Plan the next phase properly, and re-plan at each gate. If you are adding tasks and want the downstream dates recalculated automatically, see auto-scheduling project plans.

Day four: RAID baseline and resources

Open the RAID log on day four, not month two. On a new project you should be able to name at least six risks immediately, because they are the same six every time: unclear requirements, unavailable people, dependency on another team, supplier lead times, data quality, and adoption.

For each risk, record the impact, the likelihood, the owner and the mitigation. A risk without an owner is a note.

Then agree resources properly: named people or named roles, with the percentage of their time you actually have, confirmed by whoever manages them. "Available as needed" means unavailable.

Day five: reporting and the first report

Issue a status report in week one, even though nothing has been delivered. It sets three expectations at once: that reporting is regular, that the format is fixed, and that you will state the position honestly.

Week one's report is short: here is the outcome, here is the scope boundary, here is the governance level and cadence, here are the top three risks, here is what I need from you. Use the same five blocks you will use for the next twelve months, described in how to write a weekly status report in five minutes.

The four traps

  • Starting with tasks. Tasks before outcomes produce a plan nobody can defend at the first gate.
  • Skipping the out-of-scope list. This is the single cheapest piece of scope control available to you.
  • Accepting soft resource commitments. Percentages and names, or you are planning fiction.
  • Deferring governance. It never gets easier to introduce change control later, and you will need it exactly when the project is under pressure.

A one-page week-one output

By Friday you should be able to hand the sponsor one page containing: the outcome, in and out of scope, the governance level, the cadence, five to nine milestones with dates, the top three risks with owners, the resource commitment, and the date of the first gate.

If any line on that page is blank, that gap is your biggest risk, and it belongs in the RAID log before the weekend.

Related reading

Frequently asked questions

How long should project setup take?

About a day and a half of focused effort spread across the first week. Longer than that usually means a decision is missing rather than that the setup is complex.

How many milestones should a project have?

Five to nine for most projects. Fewer and you cannot see progress between reports; many more and the milestone list becomes a task list nobody reads.

Should I plan the whole project in detail up front?

No. Plan the current phase in detail, hold later phases at milestone level, and re-plan properly at each gate when you know more.

What if the sponsor will not confirm scope in writing?

Record your understanding, send it, and state that you will proceed on that basis unless corrected. Then log the lack of confirmation as a risk with the sponsor as owner.