When Should a Project Management Plan Be Produced? (Most Teams Get the Timing Wrong)

Straight answer: a project management plan should be produced after the scope and objectives are agreed but before any real work starts, usually within the first 5 to 10 percent of the project timeline. Write it too early and you're planning against guesses. Write it too late and you're documenting chaos you've already created.

The timing question nobody answers

I get asked this constantly by clients who are either panicking because they haven't written one yet, or drowning because someone made them write a 40 page plan before anyone had agreed what the project was even for. Both are the wrong problem to have.

The plan needs to exist before execution begins. Not before scoping. Not during it. After scope is locked, before the first task is assigned. That's it. If you take nothing else from this post, take that sentence.

But the reason people get this wrong isn't stupidity. It's that most project management training teaches the plan as a document you write once, at a fixed point, and then reference forever. That's not how real projects work, and I've run enough of them across marketing, tech rollouts and events to know the difference between a plan that gets used and one that gets filed.

What happens when you write it too early

In 2019 I was brought in to advise on a CRM migration for a mid-sized professional services firm. The project manager, keen and organised, had produced a beautiful 22 page plan in week one, complete with Gantt chart, RACI matrix, risk register, the lot. Impressive document. Everyone in the kickoff meeting nodded.

Problem was, the scope hadn't been signed off by the client's legal team, who then spent three weeks arguing about data residency requirements that changed which platform they could even use. The plan had milestones for a system that got scrapped in week four. Every single date, dependency and resource allocation had to be rebuilt from scratch, and the team had already burned two and a half weeks working to a timeline that was fiction the moment it was printed.

That's the trap. A plan built before scope is settled isn't a plan, it's a wish list with dates attached. It looks organised and it isn't. If your tech stack decisions aren't locked, if legal or procurement haven't signed off, if the client is still "thinking about" a key requirement, you are not ready to plan. You're still scoping. Call it that and don't dress it up.

What happens when you write it too late

The opposite mistake is more common and quieter. Work starts on a verbal agreement, momentum feels good, and the plan gets written weeks later, usually because a stakeholder asked for one or because things started slipping and someone panicked. At that point the "plan" is really a retrospective justification document. It describes work that's already happening rather than shaping work that hasn't happened yet.

I've seen agencies do this on client retainers constantly: the campaign kicks off on a Monday call, three people start building assets by Wednesday, and the actual project plan gets drafted the following week because someone in finance wants to see resourcing against budget. By then the plan can't prevent the problems it should have caught, like two team members duplicating work or a deadline that was never realistic in the first place. It can only record them.

If you're producing the plan after work has started, you've lost the one thing a plan is for, which is preventing avoidable mess before it happens rather than explaining it afterwards.

The actual trigger point, step by step

Here's the sequence I use with clients, whether it's a six week marketing sprint or a nine month operational overhaul:

• Step 1: Project is proposed or approved, objectives agreed at a high level. No plan yet, this is a charter or brief.
• Step 2: Scope is defined in detail, deliverables listed, exclusions stated clearly. Still no plan, this is the scoping document.
• Step 3: Key stakeholders sign off on scope, budget, and timeline range. This is the trigger. The plan starts here.
• Step 4: Plan drafted within 3 to 5 working days for a project under three months, or up to two weeks for anything longer than six months. Longer than that and you're overthinking it or the scope isn't settled.
• Step 5: Plan reviewed with the team who'll execute it, not just stakeholders who'll approve it. This step gets skipped constantly and it's the one that catches unrealistic dates before they become promises.
• Step 6: Kickoff happens with the plan in hand, not before it.

Notice the plan sits after scope but strictly before execution. There's no overlap allowed. If you find your team is "planning while doing," you've already skipped the step that mattered.

The part most guides on this topic skip

Here's the uncomfortable bit. Most detailed project management plans, the kind with 15 tabs and a fully populated risk register, are barely opened again after week two. I've audited enough client project folders to know this isn't an exception, it's close to the norm. People produce elaborate plans because a template exists, or because a PMO mandates it, not because the project needs that level of documentation to run well.

The plan's real job is to force three conversations to happen before work starts: who owns what, what does done look like for each deliverable, and what's the realistic date range given the resources you have, not the ones you wish you had. A one page version that forces those three conversations beats a 30 page version that ticks a compliance box and gets ignored by week three. I'd rather see a client spend half a day producing a tight, honest plan than three days producing an impressive one nobody will follow. This is the same logic behind why a lot of businesses are quietly doing more with less right now, cutting the theatre and keeping the substance.

If your organisation needs the full formal version, fine, some regulated industries and large capital projects do. But don't confuse thoroughness with usefulness. Ask yourself who will reopen this document in week six, and write the plan for that person, not for the approval meeting.

How long the plan itself should take to write

As a rough rule I use with clients: the plan should take no more than 5 to 10 percent of the total project timeline to produce. A three month project gets three to six working days on the plan. A one year rollout gets two to four weeks, and that includes stakeholder review cycles. If drafting the plan is eating a bigger chunk of the calendar than that, either the scope isn't settled yet or the team is procrastinating on starting the actual work by hiding in documentation.

This mirrors something I've said for years about marketing plans specifically, that the point isn't the document, it's the discipline of thinking it through before you spend money. The benefits of a proper marketing plan and the benefits of a proper project plan come from the same place: you catch expensive mistakes on paper instead of in production.

What needs to be in it

Keep it to what people will use:

• Scope and deliverables, restated briefly, not copy pasted from the scoping doc
• Owner for each deliverable, one name, not a committee
• Milestone dates with buffer built in, never the optimistic date
• Dependencies that could realistically block progress, top five only
• How and when the team checks in, weekly stand up, biweekly review, whatever fits
• What changes if scope shifts, a simple change control note, not a legal contract

Everything else, the full risk matrix, the communications plan, the detailed budget breakdown, can live in separate linked documents that get referenced when needed rather than crammed into one file nobody rereads.

When to revise it, not just when to write it

One thing that gets missed constantly is that "when should it be produced" isn't a single moment, it's a first moment plus a rhythm. I tell clients to revisit the plan at every milestone, not just when something goes wrong. If a scope change happens mid project, the plan gets updated within 48 hours, not at the next scheduled review. Waiting longer than that means the team is working from a document that's already quietly wrong, and everyone knows it, which is worse than having no plan at all because it creates false confidence.

Related: product management: guidelines and how to pitch.

Frequently asked questions

Can a project start before the plan is finished?

Small preparatory tasks, like setting up shared folders or scheduling kickoff meetings, can start before the plan is signed off. Actual deliverable work should not begin until the plan is drafted and reviewed by the team executing it, otherwise you're building against assumptions rather than agreements.

What if the client or stakeholder demands a plan before scope is agreed?

Give them a scoping timeline instead and be honest that a detailed project plan built on unsettled scope will need rework, which costs more time than waiting a few days for sign off. Most reasonable stakeholders accept this once you frame it as saving them a rewrite later.

How detailed should a project plan be for a short project, like under a month?

One to two pages is usually enough: deliverables, owners, dates with buffer, and the top three risks. Anything longer for a short project is usually procrastination dressed up as diligence.

Does every project need a formal written plan?

No. A two day internal task doesn't need one. Anything involving multiple people, a client, a budget, or a deadline longer than two weeks does, even if it's just a shared document with owners and dates rather than a formal template.