Projects rarely fail because nobody knew how to do the work. They fail because one phase was left behind unfinished: delivery started before the plan was approved, or the project was declared done while invoices were still open. The phases of a project exist to prevent exactly that — each phase ends in a decision rather than quietly fading out.
Why split a project into phases at all?
- Decision points. At the end of each phase someone asks: do we continue, change something, or stop? Without them, the only decision point is running out of money.
- Expectations. The client knows when they will see something and when they have to approve something.
- Risk over time. A mistake made early is cheap; the same mistake found late is expensive. Phases give you a place to look for them before they get expensive.
1. Initiation
This phase answers one question: is this project worth doing at all? You describe the problem, the expected benefit, a rough order of magnitude in time and money, and name the project manager and the sponsor.
Output: a short project charter. Decision point: do we green-light planning? The most common mistake is skipping this phase — six months later nobody can say what "successful" would look like.
2. Planning
The most work-intensive phase, where the project plan takes shape: scope, the work breakdown, a schedule with dependencies, the budget, team roles and the risk register.
Output: an approved plan and a baseline to compare reality against later. Decision point: is the plan defensible — can we explain why it is built this way? If the project needs external money, this is also where the funding application is written.
3. Execution
This is where the actual work happens: procuring, developing, building, training. The project manager's job here is not to do the work but to clear obstacles and keep the action plan current.
Output: the agreed deliverables. Decision point: every milestone — is this deliverable accepted?
4. Monitoring and control
This phase does not follow execution, it runs alongside it. You compare plan against reality: how much has been spent, what is late, which risks are materialising, whether the scope has quietly grown.
Output: status reports and change decisions. Decision point: for every deviation — do we cut scope, add resource, move the deadline, or accept the variance?
5. Closure
A project does not end when the work is finished. It ends when the result has been handed over, the invoices are paid, the documents are archived and the lessons learned are written down. In a grant-funded project, a final report and an audit trail are added to that list.
Output: an acceptance record, a final report, lessons learned. Decision point: is the project formally closed?
The five phases in one table
| Phase | Main question | Output | Decision at the end |
|---|---|---|---|
| Initiation | Is it worth doing? | Project charter | Do we plan it? |
| Planning | How will we do it? | Plan, budget, risks | Is the plan approved? |
| Execution | Can we deliver it? | Deliverables | Is the deliverable accepted? |
| Monitoring | Are we on course? | Status, change requests | What do we do about the variance? |
| Closure | Are we actually finished? | Hand-over, lessons | Is the project closed? |
Where projects actually get stuck
- Between initiation and planning. The idea exists, but nobody turns it into a defensible plan — the project sits in "preparation" for months.
- At the end of planning. The plan exists, but the decision maker cannot tell whether it is finished. That is how unapproved plans end up being delivered against.
- Just before closure. The result is handed over, but formal closing drags on. Lessons never get written down, and the next project repeats the same mistakes.
Does every project go through all five?
Yes, but not at the same rhythm. In waterfall, the phases run once, in order. In agile work, planning, execution and monitoring repeat in every sprint, while initiation and closure happen once. Which fits your project depends on how much is knowable up front — see our comparison of methodologies.
How Projektiassistent sets the phases up
Projektiassistent turns a project description straight into a phase-based structure: phases, milestones, tasks and their dependencies. The state of each phase is visible in the Gantt view, and the work in flight on the Kanban board. A stop control prevents the project from being approved until its prerequisites are met — so execution never starts on a half-planned project by accident.
Summary
The five phases of a project — initiation, planning, execution, monitoring and closure — are not bureaucracy. They are a series of decision points. Each phase ends with a question someone has to answer. When the answer never comes, the project has not moved forward; it is just spending time.
Set your own project's phases up today: projekt2.projektiassistent.ee.
Do this in Projektiassistent
Theory is one thing. See how Projektiassistent does it from your own project.
Keep reading on this topic
Project team workload and resource planning: how to avoid overload
A schedule can be flawless and still impossible. All it takes is three parallel tasks assigned to the same person. On a…
The project status report: what management actually wants to know
Most status reports are written so the project manager can say "I informed you". Nobody reads them. A good status…
Scope creep: how to recognise it and stop it before it eats the budget
No project fails because of one big decision. It fails because of twenty small ones: "let's add one more view", "let's…