Project plan — structure, steps and an example

Plans are rarely written so that a plan exists. Usually one of four situations forces it: someone has to make a decision about the project, someone has to fund it, the team needs to know what to do, or the project is over and now you have to show what came of it.

That is why a plan is not judged by its length. A good project plan is long enough for a decision-maker to say yes or no, and short enough that someone actually reads it. A two-page plan with a measurable objective and a budget that matches the activities is more useful than thirty pages that never say what the project changes.

• The decision — management sees what the project costs, what the result is and what is lost if it is not done.
• Funding — grant applications, loan applications and investment cases all take their substance from the project plan.
• Delivery — the team sees who does what, in which order, and what had to be finished first.
• Closure — at the end you can compare what actually happened against the plan: deadlines, budget, result.

1. State the problem. Write three sentences on what is wrong now and what it costs someone — time, money, quality. If you cannot write them, there is no project yet, only a wish.
2. Make the objective measurable. Pick a number and a date: "processing time 21 → 7 days by March 2027". A measurable objective is the only thing you can later judge success against.
3. Draw the scope. Write down separately what is not part of the project. It is the cheapest way to defend the project later.
4. Break the work down. Split the project into phases and activities until each activity can be estimated and assigned. Only at that level can you build a schedule and a budget.
5. Set the schedule and dependencies. Decide what has to finish first and where the checkpoints are. Only now does it become clear whether the wanted deadline is possible at all.
6. Build the budget from the activities. Every cost line comes from an activity, not the other way round. Keep net amounts and VAT apart and say where the co-financing comes from.
7. Assess the risks and have someone else read it. Write the five most likely risks with mitigations, then give the plan to someone outside the project. Their questions are the decision-maker's questions.

A grant application is not a separate document written alongside the project plan — it is the project plan moved into the funder's structure and terminology. If the plan has measurable objectives, a budget built from the activities, risks and metrics, most of the application already exists.

So it pays to write the plan as an evaluator would read it: every activity tied to an objective, every cost line tied to an activity, every indicator measurable after the project ends. The requirements of EAS and EIS, KIK, PRIA and the European Union programmes differ in the details, but that logic is the same in all of them.

The structure in this guide is exactly what Projektiassistent fills in from your description. You describe the project in a couple of sentences — what you want to do, for whom and by when — and get objectives, an activity plan, a schedule, a budget, a risk register and team roles that are linked to each other: move a deadline and the schedule, budget and reporting move with it.

The substance stays yours: the AI produces a first version and you edit it. The system also tells you when the plan is not decision-ready yet — for example when the budget does not cover every activity or an objective is not measurable. From the same project you can draft a funding application and later the report, without the content scattering across three files.