Project planning can sound like a request for nine documents, a detailed schedule and a confident finish date before anybody has done the work. That is usually not what a project needs.

Planning is the work of agreeing what you are trying to achieve, what needs to happen, who is involved, what could get in the way and how you will make decisions as information changes. On a small project, several of those answers may fit on one page. On a more complex or regulated project, your organisation may require separate plans, approvals or evidence.

So which types of planning are useful? Let’s walk through the main areas and what a project manager can actually do with each one.

Start with the outcome and the reason for the project

Before building a schedule, check that the sponsor and delivery team can explain the intended outcome in similar terms. What should be different for users or the organisation? How will you recognise that it has changed? What is outside the work?

Keep the organisation’s wider strategy in view, but do not confuse it with a project plan. Strategic planning decides where an organisation wants to go and what it will prioritise. Project planning works out how a particular piece of change can contribute, within its authority, funding and constraints.

A quick conversation with the sponsor can expose gaps early:

• What problem or opportunity is this project addressing?
• Who benefits, and what would they notice?
• What result would make the sponsor say the work was worthwhile?
• What assumptions or external changes could alter that view?
• Who can approve a change to the intended result?

SWOT or PESTLE analysis may help when the external or organisational context is uncertain. They are prompts for a conversation; completing a template does not prove that the project is viable. You can read my practical guides to using SWOT in project management and PESTLE analysis.

Plan scope and acceptance

Scope planning makes clear what the project will deliver, what it will not deliver and how people will decide whether the result is acceptable. A title like “improve customer service” is a useful intention, but it is not yet a testable scope.

For each important deliverable, record:

• What will be produced or changed?
• Who will use it or accept it?
• What does acceptable mean?
• What is explicitly outside this piece of work?
• Which assumptions, dependencies or approvals affect it?

For example, a customer-service process project may include a new hand-off process and team guidance. It may not include replacing the contact-centre software. Confirm that boundary with the sponsor and affected teams; otherwise, people can reasonably picture different projects from the same sentence.

Requirements and acceptance criteria can become clearer over time, especially when the team is learning through prototypes or staged delivery. Record what is agreed now, what remains open and how proposed changes will be assessed. My guide to writing useful requirements covers this in more detail.

Plan the work and schedule

A schedule connects activities, dependencies, people, external lead times and decision points to a forecast. Start with the next work that is understood. Add detail as estimates improve; do not pretend every activity has the same level of certainty.

For a complicated delivery, break the outcome into manageable deliverables and work packages, then identify the activities and dependencies needed to produce them. A work breakdown structure (WBS) is one way to organise that decomposition. It is not the same thing as a flowchart or a list of dates.

When dates matter, check the logic: what must happen first, which activities can happen in parallel, and which approvals or supplier lead times could move the finish? Critical path analysis can help identify the chain of dependent activities that currently drives the forecast. It does not make uncertain estimates certain. Revisit the schedule when assumptions, dependencies, progress or resource availability change.

In a Scrum team, planning still happens, but it is adapted to the framework: the Scrum Guide describes Sprint Planning as setting a Sprint Goal and creating a plan for the Sprint, then adjusting the plan as the work and learning evolve. Agile is broader than Scrum, so agree planning and forecasting practices that fit the approach actually being used. The official Scrum Guide explains the framework.

For a worked example of marking unknowns and using a near-term plan while the wider approach is clarified, see my guide to bringing order to a messy project.

Plan people, time and other resources

Resource planning checks whether the skills, capacity, equipment, information and support needed are available when the work needs them. Ask the people who manage those resources; a name in a spreadsheet does not confirm that someone has time.

When several activities need the same specialist, decide what matters most. You may move work and accept a later finish, change sequencing, reduce or phase scope, secure other capability, or ask for a decision about the priority. Each option has a cost or trade-off; explain it rather than hiding the conflict in the dates.

Resource levelling may adjust the schedule to fit resource availability and can affect the finish date or critical path. Resource smoothing uses available float without changing the critical path. These terms have precise meanings in scheduling practice, so do not use “smoothing” to mean hiring people or adding equipment. PMI’s Project Management Institute lexicon distinguishes the techniques.

For a small project, a named owner and a realistic availability check may be enough. For a larger project, coordinate resource needs across teams and competing work.

Plan costs and funding

Cost planning estimates what the agreed scope and schedule are likely to require. Depending on the project, this may include staff time, suppliers, equipment, licences, training, support after launch and costs of transition.

Record the basis for important estimates: quantity, rate, source, date and assumptions. Keep the approved budget distinct from the latest forecast and actual spend. If you identify contingency for a particular risk, explain what it covers and who can authorise its use. Do not assume that a project manager can spend a reserve without approval.

If the project has no new cash budget, there is still a resource and opportunity cost. Identify who will contribute time, what other work may be delayed and what the sponsor has agreed to prioritise. My articles on projects with no budget and what to do when a project is over budget go further.

Plan for risk and uncertainty

Risk planning asks what may happen, how it could affect the outcome and what the team will do. A useful risk entry says what might happen, why, and the effect—not simply “supplier risk”. Then give a named owner a response to take and a date to review it.

Separate a possible future event from an issue that has already happened. For each major uncertainty, ask:

• What evidence or early warning would tell us this is changing?
• What can we do to reduce the likelihood or impact?
• What decision or fallback would we need if it happens?
• Who has authority to accept the remaining exposure?

Do not try to list every imaginable problem. Focus on uncertainties that could change a decision, outcome, schedule, cost or safe operation. If the impact is beyond the project’s agreed tolerance or authority, raise it through the right route.

Plan quality, testing and acceptance

Quality planning makes the expected standard clear before work is complete. Define acceptance criteria with the people who will use, support or approve the deliverable. Include testing, review, accessibility, security or compliance checks where they apply.

For a new customer hand-off process, quality might mean that staff can complete the hand-off, required information reaches the next team, exceptions are handled, and the process meets policy. Agree how you will test these things and who can accept the result. “Looks good” may be a useful first reaction, but it is not enough if the project needs evidence.

Plan for quality throughout delivery. Finding a test environment or a required approver only at the end can turn a small check into a schedule problem.

Plan communication and decisions

A communication plan should help people take action or make a decision. List the audiences, what each needs to know, who supplies the information, how often it is useful and which channel is appropriate.

A delivery team may need a short weekly view of dependencies and blockers. A sponsor may need changes to the forecast, decisions required and impacts. They can receive different summaries, as long as they draw from the same current facts.

Also define how decisions are captured: the decision, date, decision-maker, reason or conditions, and any follow-up action. If the team does not know who can approve a change, clarify that before a commitment is made. More meetings will not fix missing authority.

My article on making a Steering Committee useful looks at decisions and escalation in that setting.

Plan procurement and external dependencies

If you need a supplier, contract, specialist service or equipment, plan the procurement and approval lead time alongside the delivery schedule. Check the organisation’s purchasing and legal processes early. A project manager should not promise a supplier start date before the required approval and contract are in place.

Be clear about what the supplier must provide, when, how the work will be accepted and what happens if a dependency moves. The appropriate detail varies with the purchase and organisational controls.

Bring the plans together

These areas affect one another. A new acceptance requirement may add testing time. A specialist may be available only next month. A supplier delay may shift a milestone and extend costs. When one assumption changes, check the linked parts of the plan and explain the effect.

You can begin with this compact planning check:

1. Outcome: what should change, for whom, and how will we recognise it?
2. Scope: what will be delivered, accepted and excluded?
3. Next work: what happens next, who owns it and what does it depend on?
4. People and cost: are the needed skills, capacity and funding available?
5. Uncertainty: what could change the approach, and who owns the response?
6. Quality: how will the output be checked and accepted?
7. Decisions and communication: who needs to decide or know what, and when?
8. Suppliers and approvals: what external lead times or controls affect the plan?

Review the plan when evidence changes, a decision is made or a key assumption proves wrong. The plan should help people coordinate and make choices. If nobody uses a document, find out whether it is too detailed, hard to find or disconnected from the way the work is managed.

You do not need a separate document for every planning area. The UK Government’s Project Delivery Functional Standard, version 2.1 (2025), is one formal example of expectations for government projects and says frameworks should be tailored to context. It is not a universal rulebook for every organisation. Check your own governance, contract and regulatory requirements, then use the level of planning that helps your project make sound decisions.