What is a Project Plan, which questions help to create it and what is its importance in agile projects?
The project plan as the foundation for a project
If you ask about the project plan in a project, you will often get different answers. In some organisations the milestone plan with important dates is the central element for planning projects. In others it is a work breakdown structure. Or a flow chart, a cost plan, a resource plan. This is not really surprising for two reasons:
- All these plans try to structure essential aspects of a project logically.
- In practice, many of these plans are enriched with information that might also be contained in other plans. A schedule often links the tasks to be completed with resources and costs. The cost plan contains phases that are also used in a work breakdown structure.
So what is a project plan? A project plan contains the logical, i.e. content, structural, time, personnel and monetary planning of a project. As the “totality of all existing plans in the project” – as DIN 69901 puts it – the project plan can consist of one or more consistent documents. It thus forms the planning foundation for a project.
The project plan as the result of a process
The creation of a project plan – alternatively also called project management plan – can also be understood as a process in which incoming information – also called input – is structured and aligned in terms of content, time and logic to create an output – the project plan. It is often recommended to develop the input step by step via qualifying W questions:
- What is the starting position or situation? Which challenges need to be mastered, which information is already available, which aspects are already clear, which are unclear?
- Why should the project be carried out? What opportunities does the project offer, what benefits should be achieved? And what are the risks?
- Which objectives should be pursued and which not? Which results should be available at the end of the project?
- Who are the stakeholders, who is involved, to what extent and for how long?
- How is the project, the project work and the project team organised? Which methods, tools and mindsets are favoured?
- Which project phases make sense, which results should be available at which milestones, how long do the phases last?
- What expenditure may the project cause, what budgets are available, what employees and resources are needed?
Many of these questions lead to new questions such as how stakeholder management is carried out, how to generate the necessary attention of the management, who defines requirements and how, what happens with changes, how important is the project in relation to other projects etc. These questions are useful and important, but not all of them can be finally answered before a project is started and can be considered in plans accordingly. This is where an organisation also lives from its experience. In addition, the project plan can also differ depending on the project context. Keyword: agile and classic projects.
Project plan in agile and classic projects
An agile approach is increasingly recommended for complex and uncertain projects. Obviously, projects with uncertain framework conditions and unclear solution paths are difficult to plan, so that planning and measuring is often done in short cycles, and lessons learned are incorporated into the planning of the next phase. Nevertheless, even in agile projects there is a project plan, simply because in most cases the customer wants to know when something will be delivered. What – e.g. the scope of functions – he gets delivered is a different matter. A project plan in an agile project is therefore often less detailed than a corresponding plan in a classic project.
Of course, even complicated (classic) projects that have a long duration and involve many parties are anything but easy to plan. The Individual Competence Baseline (ICB) – a competence standard of IPMA – therefore rightly states:
“A project plan can be subject to numerous disruptions that make adjustments necessary. These can originate from various sources (changes in delivery objects, requirements, shortage of resources or money, or late deliveries or deliveries that do not meet the requirements) and may necessitate a revision of the plan. The flow chart and schedule should be compared with the tracing factor at regular intervals and adjusted if necessary.”
In other words: even in classic projects, project plans are adjusted, because changes are not unusual. And that means that the way project plans are handled in agile and classic projects is not as different as it may seem at first glance. But the image of the two is very different.
Impulse to discuss:
All plans and principles are neutral to begin with, it always depends on how people actually use them.
The first project plan approved by the project managers is also called the project baseline.
Here you can find additional insights from our Smartpedia section: