How to Write a Simple Project Plan and Schedule
Nine steps from idea to workable plan, with a complete worked example you can copy the shape of, including dependencies, parallel tasks and an approval gate.
Quick answer
A useful project plan defines the outcome, the scope, the work, who is responsible, the timing and how the project will be controlled. The schedule is one part of it, setting out when each task happens and how tasks connect. Write the plan in nine steps: define the outcome, agree scope, identify deliverables and tasks, assign owners, sequence the work, estimate durations against real availability, add milestones, check resources, costs and risks, then agree it and keep it current.
BSB40920 Certificate IV in Project Management Practice
Delivered by Vanguard Business Education (RTO 91219)
- Price: $1,970 AUD course fee, paid as 2 monthly payments of $985, or from $85 a fortnight on a payment plan (plans total $1,970 to $2,210)
- Payment plans: 2 monthly payments of $985 ($1,970 total), 3 monthly payments of $684 ($2,052 total), 6 monthly payments of $358 ($2,148 total), or 26 fortnightly payments of $85 ($2,210 total)
- Duration: self-paced, up to 12 months to complete
- Delivery: 100% online, self-paced, with qualified trainer support
- Included: qualified trainer support, all learning resources, assessments and SmartCoach™ learning assistance
- Entry requirements: no formal entry requirements
- RPL available: yes, Recognition of Prior Learning and credit transfer may apply
- Nationally recognised: yes, AQF Level 4
Enrol or find out more about the BSB40920 Certificate IV in Project Management Practice
Key takeaways
- The plan says how the project will run. The schedule says when. They are not the same document.
- A task with no named owner will not happen. A task nobody can tell is finished will not end.
- Duration is elapsed time, not effort. Three hours of work can take a fortnight.
- Approvals belong in the schedule. They take real time and they block real work.
- When something slips, record the change rather than quietly rewriting the original dates.
What is the difference between a plan and a schedule?
People use the words interchangeably and then talk past each other.
The plan describes how the project will be delivered and managed. What it will produce, what is in and out of scope, who is responsible, how costs and risks are handled, who approves changes, how anyone will know it is finished.
The schedule is one part of that plan. It sets out when each task happens, how long each takes, and which tasks depend on which.
A schedule without a plan is a list of dates nobody can defend. A plan without a schedule is a statement of intent. You need both, and the plan comes first, because you cannot sequence work you have not defined.
The nine steps
Step 1: Define the outcome
Write what the project will achieve, specifically enough that two people would agree whether it happened. “Improve efficiency” fails that test. “All customer enquiries arrive in one inbox and are answered within one business day” passes it, because you could check.
Then write how completion will be recognised. This is the question most projects never answer, which is why so many of them never quite end.
Step 2: Agree what is included and excluded
List what the project will deliver and, just as importantly, what it will not. Make the exclusions answer things people have actually raised, because those are the requests that come back.
Name who approves the plan and any later changes to it. One person, not a committee.
Step 3: Identify the deliverables and tasks
A deliverable is a thing the project hands over: a configured system, a trained team, a signed lease. A task is an activity that produces it. You can inspect a deliverable. You cannot inspect “configuration”.
Break the work down until each task is small enough for one person to own and clear enough that its completion is obvious.
Step 4: Assign responsibilities
Every task gets a named owner. Not a team, not a department, a person. Then note separately which decisions or approvals need someone else, because that is where the waiting happens.
Step 5: Put tasks in a workable order
Identify what cannot start until something else finishes. Those are your dependencies, and they are the difference between a schedule and a wish list.
Some tasks can run in parallel: drafting content while a venue is booked, for instance, since neither needs the other. Others cannot: you cannot test a configuration that does not exist. Mapping this is what lets you see a clash weeks before it bites.
Step 6: Estimate durations and check availability
Two different numbers here. Effort is how long the work takes. Duration is how long it takes to happen, given that the person doing it has a job. Three hours of effort can easily be a two week duration.
Build in supplier lead times, which are pure elapsed time, and check that the people you have assigned are actually available in the weeks you have assigned them.
Step 7: Add milestones and review points
A milestone marks a point where something is genuinely complete and checkable. Content approved. Testing signed off. Handover accepted. “End of month” is a date, not a milestone.
Decide how you will check progress and how often. For small projects, a weekly ten minute look at the schedule is usually enough.
Step 8: Check resources, costs and risks
Confirm the people, equipment and money the plan assumes actually exist. Note what could go wrong, what you would do about it and who is watching it. Where a risk affects timing, the schedule needs to reflect it rather than ignoring it.
These deserve more than a paragraph each, which is why they have their own guides.
Step 9: Agree, use and update the plan
Get the plan approved by whoever is accountable, then actually use it. Record progress against it, investigate delays rather than absorbing them, and seek approval for changes.
One discipline worth keeping: when a date moves, record the change and the reason, keeping the original visible. Quietly rewriting the plan means nobody can tell later whether the project ran to time, and nobody learns anything from it.
A worked project plan and schedule
A four-partner accounting firm is running a free one hour information session for about 40 small business clients on changes to reporting requirements. This example is fictional, and days are relative working days rather than calendar dates.
- Outcome
- Forty invited clients offered a session, at least 25 attending, each leaving with a handout and a named contact for follow-up questions
- In scope
- Venue, invitations, content, handouts, catering, the session itself and follow-up
- Out of scope
- Recording the session, a webinar option and individual client meetings on the day. All three were raised and all three are out
- Approver
- Managing partner approves content and any spend above the agreed catering budget
- Completion
- Follow-up emails sent and a short review note written
| Task | Owner | Duration | Depends on | Start | Finish | Completion evidence |
|---|---|---|---|---|---|---|
| 1. Confirm topic and date | Practice manager | 2 days | None | Day 1 | Day 2 | Written confirmation from partners |
| 2. Book venue | Practice manager | 1 day | 1 | Day 3 | Day 3 | Venue booking confirmation |
| 3. Draft invitation and content outline | Senior accountant | 3 days | 1 | Day 3 | Day 5 | Draft document circulated |
| 4. Partner approval of content | Managing partner | 2 days | 3 | Day 6 | Day 7 | Written approval |
| 5. Send invitations | Practice manager | 1 day | 2, 4 | Day 8 | Day 8 | Send confirmation and invitation list |
| 6. Track RSVPs | Practice manager | 10 days | 5 | Day 9 | Day 18 | RSVP list |
| 7. Confirm catering numbers | Practice manager | 1 day | 6 | Day 19 | Day 19 | Catering order confirmation |
| 8. Prepare presentation | Senior accountant | 4 days | 4 | Day 8 | Day 11 | Final slides |
| 9. Rehearsal | Senior accountant | 1 day | 8 | Day 12 | Day 12 | Rehearsal notes and timing check |
| 10. Print handouts | Administrator | 2 days | 7, 8 | Day 20 | Day 21 | Printed handouts counted |
| 11. Run the session | Senior accountant | 1 day | 7, 9, 10 | Day 22 | Day 22 | Attendance list |
| 12. Follow up attendees | Practice manager | 2 days | 11 | Day 23 | Day 24 | Follow-up emails sent |
| 13. Review and close | Practice manager | 1 day | 12 | Day 25 | Day 25 | Review note filed |
Milestones: content approved (end of Day 7), invitations sent (Day 8), numbers confirmed (Day 19), session delivered (Day 22), project closed (Day 25).
Three things this schedule shows
Parallel work. Tasks 2 and 3 both follow task 1 and run at the same time, because booking a venue and drafting content do not need each other. So do tasks 5 and 6 alongside task 8. Spotting parallel work is where schedules get shorter without anyone working harder.
An approval gate. Task 4 is the managing partner’s approval, and it blocks both the invitations and the presentation work. Two days is a realistic allowance for a busy partner, and leaving approvals out of schedules entirely is one of the most common reasons projects run late.
A real dependency chain. Handouts cannot be printed until numbers are confirmed, which cannot happen until RSVPs close. If RSVPs run two days over, printing and the session both move. That is visible here in advance rather than discovered on Day 20.
Common planning mistakes
- Tasks with no owner. Work assigned to everyone is chased by no one. One name per task.
- Tasks too vague to finish. “Sort out the venue” has no end. “Venue booked and confirmation received” does.
- Unrealistic timing. Durations built from effort rather than elapsed time, assuming people have nothing else on.
- Approvals left out. They are not administrative overhead, they are tasks that block other tasks and belong in the schedule.
- No definition of completion. Without it the project drifts into a permanent state of nearly finished.
- Rewriting the plan silently. Moving dates without recording why means nobody can learn from how it actually went.
Apply the method to your own project
Take something you are already trying to get done and work through this in order.
- Write the outcome in one checkable sentence, and how you will recognise completion.
- List what is in and what is out, and name who approves changes.
- List the deliverables, then the tasks that produce them.
- Put one name against every task.
- Mark what depends on what, and find the parallel work.
- Estimate durations as elapsed time, checking people are actually available.
- Add milestones at the points something is genuinely complete.
- Note the resources, the costs and five realistic risks.
- Get it agreed, then update it as things move, keeping the original visible.
This method is practical and widely used rather than a formally validated model, and it is the sequence taught in the BSB40920 Certificate IV in Project Management Practice, where you build the scope statement, work breakdown and schedule for a full project and have an assessor tell you where they would not hold up.
Frequently asked questions
What is the difference between a project plan and a project schedule?
The plan describes how the project will be delivered and managed: the outcome, what is in and out of scope, the deliverables, who is responsible, and how costs, risks and changes will be handled. The schedule is one part of that plan, setting out when each task happens and how the tasks connect.
How do you write a simple project plan?
Define the outcome so completion is recognisable, agree what is included and excluded and who approves changes, identify the deliverables and the tasks, assign an owner to each task, put the tasks in a workable order, estimate durations against real availability, add milestones and review points, check resources, costs and risks, then agree the plan and keep it updated.
What is a dependency in a project schedule?
A dependency is work that cannot start until something else finishes. Staff cannot be trained on a system before it has been configured and tested. Recording dependencies is what lets you see in advance that a delay in one task pushes everything that follows it, rather than discovering it at the time.
What makes a good milestone?
A milestone marks a point where something is genuinely complete and could be checked by someone else, such as content approved, testing signed off or handover accepted. A date with no completed work behind it is not a milestone, which is why calendar entries like end of month make poor ones.
What are the most common project planning mistakes?
Tasks with no named owner, tasks too vague to tell when they are done, durations that assume uninterrupted work, approvals left out of the schedule entirely, and no agreed definition of what completion looks like. The last one causes the most trouble, because the project cannot end.
Practise this on a full project
Building a plan once is useful. Building one, having it assessed, and being told exactly where it would not hold up is how the method sticks.
Ask About the CourseSee the practical work on the BSB40920 Certificate IV in Project Management Practice course page, delivered 100% online with no entry requirements.
