How to Create a Project Plan – A Simple & Compact Guide

What Is a Project Plan?

The project plan is a central element of project documentation. It typically includes at least the following elements:

• Project scope (what is included and excluded)
• Work breakdown structure
• Schedule (with milestones and deadlines)
• Resource plan (personnel, materials, budget)
• Risk assessment

and answers the following key questions:

• WHAT needs to be done?
• WHO is responsible?
• WHEN must it be completed?
• HOW MUCH effort does it require?

A well-thought-out, realistic, and continuously updated project plan forms the basis for project controlling and monitoring. It allows you to regularly review progress and make adjustments as needed. This way, the desired project outcome can be delivered on time and within budget.

To create a project plan and be able to adjust it throughout the project lifecycle, it is recommended to use a project management tool like Allegra right from the planning stage. Such a tool ensures that the entire team — all stakeholders, management, and other project participants — stays informed, everyone knows what they need to do, and the current status of the project is always accessible.

Project Plan vs Project Manual

A well-managed project always has a project manual. The project manual describes the project-specific process. For example, it lists roles with their responsibilities and accountabilities but does not name the specific people assigned to those roles. The project manual may specify that there must be a test protocol for each component, but it does not describe the individual components and their functions. In other words, the project manual only names the classes of artifacts and tasks to be created, not their instances.

In contrast, the project plan considers every instance — all tasks, every artifact, and all functions. The project plan also establishes the schedule for the entire team.

Project Plan vs Work Breakdown Structure

In project management, the work breakdown structure (WBS) is an organized collection of tasks, subtasks, and work packages for a project. The information it contains is only a subset of the definitions and steps necessary for a project plan. For example, the WBS does not account for logical dependencies between work packages and tasks, and risks are not examined in detail. In communication with the team, a WBS can be a useful component of a project plan but is often represented directly as a Gantt chart in practice.

Project Plan vs Project Management Plan

The PMBOK Guide (Project Management Body of Knowledge) from the Project Management Institute (PMI) refers to the project plan as the project management plan. The two terms are therefore synonymous. Another synonym is the term “work plan.”

The 8 Steps of Project Planning

Creating a good project plan means that at the start of the project, you need to clarify a series of questions in a specific order. For example, you cannot set deadlines for various tasks if you don’t know the required effort. You cannot reliably estimate effort if you don’t know the desired project outcome. Therefore, it is best to proceed step by step as follows:

1. Define goals and requirements (scope)
2. Create a work breakdown structure
3. Estimate effort
4. Plan the workflow and milestones
5. Plan dates and timeframes
6. Plan resources and assign roles
7. Conduct a cost-benefit analysis
8. Create a risk register

The following sections define these steps in more detail.

Step 1: Define Goals and Requirements

Defining Goals

Mark Twain’s famous quote: “When we had lost sight of our goal, we redoubled our efforts” is still taken to heart in project work today. Trying to create a project plan without being clear about the project goals is simply not possible. Any ambiguity increases the risk of ending up with something different from what was envisioned — or at a higher cost, or at a later date, or all of the above. The SMART goals method helps define good objectives.

Solution Concept as Project Goal Definition

Describing the desired project outcome is the essential foundation for any project plan. In German-speaking countries, this is often done using a requirements specification (Lastenheft) and a functional specification (Pflichtenheft). In practice, a single solution concept jointly created by the client and contractor — essentially a blueprint — is often more effective than the purely requirements-focused perspective of separate specification documents.

Describing the project goal through requirements or by defining a solution concept requires the author to have a clear mental picture. The more concrete and detailed this picture is, the more reliably you can plan later. An inexperienced author will overlook many functions and tasks, and therefore not include them in the project plan.

Goals as High-Level Requirements

What is the difference between goals and requirements? A useful perspective is: none at all! Goals are the highest, most abstract level of requirements. Requirements become increasingly detailed over time, while goals do not change significantly.

Twin Peaks Model — Proven in Practice

In practice, the “Twin Peaks” model has proven helpful for defining requirements and a solution concept. It makes clear that when writing requirements, you must and may also operate in the solution space, because otherwise you won’t recognize many open questions in the problem space. The central result is a solution concept that describes the desired project outcome in a way that is equally understandable for both client and contractor, using appropriate formats (tables, text, diagrams).

Step 2: Create a Work Breakdown Structure

Based on the goals, requirements, or a solution concept, you create a work breakdown structure (WBS) in the second step. The WBS shows the entire project structure in hierarchical form by dividing the project into sub-projects, subtasks, and work packages. This makes the project more understandable and manageable for the team and provides a solid basis for creating the project plan, including workflow, resource, and cost planning.

You can think of the work breakdown structure as the translation of the solution concept or requirements into a hierarchical tree structure.

Sub-projects make it possible to use different process models within an overall project. For example, it may make sense to use a classic waterfall method for developing electronics in one sub-project and to work with agile methods for the associated software development in another.

Subtasks are elements that can be further broken down within the work breakdown structure.

Work packages represent the lowest level of a work breakdown structure and can be further divided into activities or tasks during the planning process.

There are various approaches to structuring: object-oriented (based on physical components), function-oriented (by functions or task areas), or phase-oriented (along the project timeline).

This decomposition into individual steps or work packages makes the project manageable, calculable, and goal-oriented. It simplifies communication within the team. At this point, logical dependencies, effort estimates, and resources are not yet considered.

Step 3: Estimate Effort

Creating a project plan always includes an effort estimation. There are numerous methods and approaches for estimation. Unfortunately, none of these methods can replace experience with a similar project. Many effort estimation models have parameters that need to be calibrated first. Without reference to previous projects, you don’t have these parameters, and the models have limited practical value in project management.

Gathering Experience

When creating a project plan, more than anywhere else: experience is irreplaceable! There are many effort estimation methods, all based on the assumption that the new project can be adequately described by an existing, empirically validated model. This works better in some cases than others. For a residential building, you can use enclosed space as a metric; the same applies to a church. If you’ve built enough residential buildings, you’ll have a pretty good idea for the next one about how long it will take and what it will cost. If you used the same figures for a church, you’d be way off.

If there is no experience with similar projects, effort and schedule planning is speculative, and you should expect significant deviations. “More expensive” and “later” is the usual direction of the difference between planning and implementation — which is probably also because many clients don’t want to know how much it will really cost and prefer to award contracts to those who tell them what they want to hear.

Similar Previous Projects

The most reliable plans and estimates are based on similar previous projects with comparable tasks. They do not assume that general technological progress will noticeably reduce effort on the new project.

Estimation by the Future Responsible Person

It is important that effort estimates are provided by those who will be responsible for implementing the corresponding tasks. Planning from the ivory tower often ends badly. In some technology areas, the performance of individual team members plays a significant role. Especially in knowledge work, productivity differences of 500% are not uncommon. Unless you have very large teams where these differences average out, you should know your team members and involve them in the effort estimation.

Don’t Negotiate Down Estimates

Don’t negotiate down the effort estimates provided by your team members. As a rule, your staff underestimate the friction that occurs and overestimate their productivity.

Categorize Activities into Effort Classes

It can help to categorize activities into effort classes. In the agile context, “story points” with relative effort levels that roughly correspond to a Fibonacci sequence are commonly used. You can also define simpler categories, such as small, medium, and large.

You achieve a particular benefit when, at the end of each project, you calculate the average actual effort and merge it with averages from previous projects to create a new average value. For the next project and its planning, it’s then only about categorizing the tasks, while the actual effort is determined from the metrics of previous similar projects.

Don’t Assume a Productivity Gain

If you think it will be much faster this time than last time, you should have a sober justification. New tools and methods don’t count.

When introducing new approaches to increase productivity, expect that the hoped-for gain will be consumed by onboarding effort and lack of experience the first time around.

Creating a Project Plan with Planning Poker

Planning poker is an interesting method for project planning to arrive at reliable effort estimates. The estimators meet under the guidance of a facilitator. Each estimator receives an identical set of cards. You can buy such cards; one provider uses the numbers 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, and a ? for cases where an estimator feels unable to provide an estimate. The numbers can represent effort in days, or stand in another predefined constant ratio to actual effort.

At the beginning, a product manager presents the project deliverables. The team can ask questions if something is unclear.

Then each team member places the card with their estimate face down on the table. Once everyone has placed their card, the cards are turned over simultaneously.

The estimators with the highest and lowest values are given the opportunity to explain and justify their estimates. The group can discuss the points raised. Discussion time can be limited by the facilitator or project manager.

The estimation process with subsequent discussion is repeated until the group reaches consensus. The estimator responsible for delivering a partial result always carries more weight in this process than the other participants.

The numbering of the cards takes into account that estimation uncertainty increases with larger estimates. This way, with larger values, the estimator cannot feign precision but must choose between a pessimistic or optimistic value.

Effort and Duration

A common source of confusion is the distinction between “effort” and “duration.” Duration (or “activity duration”) is the length of the time interval between the start and end of an activity, excluding non-working time, measured in working days.

Effort (or “work effort”) is the total working time that must be spent on the activity from start to finish.

Watching a concrete slab dry can take a few days, but the work effort is minimal.

Step 4: Plan Workflow and Milestones

During workflow planning, the project schedule is created: work packages are arranged in a logical sequence. You must consider dependencies — for example, certain work packages must be completed before others can begin.

Identifying Dependencies

Workflow planning is done using an activity list that defines the order of work packages. The activity list contains the work package number, the name of the work package (activity), the estimated duration of the activity, and possibly the person responsible for execution (resource).

Defining Milestones

For later monitoring — for example, with milestone trend analysis — and for better overview and communication within the project, you should highlight the completion of important work packages or subtasks by linking them with a milestone. This way, project phases or significant intermediate stages can be marked.

Step 5: Plan Dates and Timeframes

Most activities require resources (team members) to handle their completion. These resources must be available between the start date and end date of an activity. Schedule planning and resource planning are therefore closely coupled.

Whether you first assign resources to activities and derive dates based on effort, or assign resources based on fixed dates, depends on where you have flexibility. If you cannot change either the resource availability or the dates, you won’t get a workable project plan.

Bottom-Up and Top-Down Planning

Creating a project plan is an iterative process in many organizations, where desired or required dates and budgets are initially set from the top down. Those responsible for execution then counter with their own time and effort estimates. In such cases, it is helpful to distinguish between the requested or desired dates and available budgets and the dates and effort that an assignee commits to.

Backward Planning with Milestones

Often the delivery date for the project outcome is fixed from the start — for example, due to trade show dates, customer commitments, or regulatory requirements. In such cases, it makes sense to plan backward, i.e., starting from the final date and arranging activities so that the project start date lies in the future. For daily prioritization and time management, the ALPEN method can be a valuable complement.

Step 6: Plan Resources and Assign Roles

In a project plan, resources are all people and items needed to execute the plan. In theory, it would be more efficient if each team member could focus on one project at a time without being constantly interrupted by other tasks. However, this is often not realistic. It should also be noted that team members can typically devote less than 80% of their time to actual project work.

Assigning Roles

Once it is clear which resources and team members are available for the project, the roles described in the project manual are filled with specific individuals. A RACI matrix can help clearly assign responsibilities and accountabilities. This results in responsibilities for these individuals that may not necessarily appear as work packages in the work breakdown structure.

Project Manager View and Team Leader View

In many organizations, employees are organized into teams and departments and are made available to projects by their departments. To maintain an overview of team member utilization — since they often work on multiple projects simultaneously — a resource view from both the line organization’s and the project management’s perspective is needed, as implemented in Allegra project management software.

Step 7: Cost Planning and Budget

No project should be started without an economic feasibility analysis. This requires knowing all incurred effort and costs. Work effort comes from the work breakdown structure; external costs and material expenses come at the latest from resource planning.

The cost plan is thus based on the estimates underlying the project plan. This underscores the importance of effort estimates that are as accurate as possible, since they have a direct impact on the result of an economic feasibility assessment.

Step 8: Create a Risk Register

Every project is exposed to risks that can jeopardize its success. A risk register helps identify potential problems early and plan measures to address them. It enables the project team to systematically monitor risks and take preventive action, helping to protect the budget and schedule by identifying and addressing risks before they threaten the project.

Example Project: Website for a Small Business

In the following, we will create a project plan using a small example.

Step 1: Formulate Goals and Document Requirements

The goals are:

1. Develop a user-friendly website for the business.
2. Implement an online shop to expand sales opportunities.
3. Optimize the website for search engines (SEO) and mobile devices.
4. Ensure a secure payment and ordering process.

We document the requirements in a separate document designed like the user manual for our new system. We use mockups for the user interface and UML use case and sequence diagrams to model our requirements.

Step 2: Create a Work Breakdown Structure (WBS):

1. Project Initiation (part of Step 1)

   • Requirements gathering
   • Goal definition and budget planning
   • Kick-off meeting

2. Design and Layout

   • Create wireframes and mockups
   • Select color palette and layout
   • Feedback and adjustments

3. Website Development

   • Frontend development (HTML, CSS, JavaScript)
   • Backend development (database, CMS)
   • Integration of e-commerce features

4. Content and SEO

   • Create and upload content (text, images, videos)
   • SEO optimization (keywords, meta tags, site structure)

5. Testing and Quality Assurance

   • Functional tests (forms, buttons, links)
   • Browser and device testing (desktop, mobile)
   • Security tests (payment processing, data encryption)

6. Launch and Maintenance

   • Website launch and public relations
   • Bug fixes after go-live
   • Ongoing maintenance and updates

In Allegra, this looks like this:

Step 3: Estimate Effort

We now estimate the effort for each work package. We involve the likely responsible parties for these packages — where known — or look for other experienced staff who have worked on similar tasks before. In most cases, we assume that the effort corresponds to the duration of an activity, minus all non-working days.

Step 4: Plan Workflow and Milestones

In this step, we add the logical dependencies between work packages and also set a few milestones. In Allegra, this looks like this:

Step 5: Plan Dates and Timeframes

Now we plan all dates that are not dictated by logical dependencies. We can also fix certain dates against changes — for example, if they are externally mandated. It is also wise to build buffers into the critical path to allow room for reaction in case of unforeseen events.

Step 6: Plan Resources and Assign Roles

In this step, we assign team members or responsible persons to individual work packages. Project managers must ensure that the resources actually have the required available capacity. The assigned team members must review the previously estimated efforts and adjust them if necessary.

In Allegra, this looks like this:

Step 7: Cost Planning and Budget

A project should be economically viable, meaning it must not exceed a previously determined cost framework. We distinguish between the budget and the planned value. The budget is a top-down target set by management, for example, based on strategic considerations or economic viability. The project planned value is based on estimated costs for all work packages and other expenses. It is determined bottom-up. The top-down budget should never be less than the bottom-up planned cost values.

In Allegra, we enter the budget at the highest hierarchy level and transfer the effort estimates for each work package into the planned value field.

Step 8: Create a Risk Register

Here is an example list of possible risks:

1. Technical Risks:

   • Risk: Insufficient website compatibility with mobile devices.
   • Mitigation: Conduct extensive testing across various platforms and devices.

2. Schedule Risks:

   • Risk: Development delays due to unforeseen technical issues.
   • Mitigation: Build buffer time into the schedule and hold regular status meetings.

3. Budget Risks:

   • Risk: Budget overrun due to additional features.
   • Mitigation: Create a clear feature list and require approval for changes.

4. Quality Risks:

   • Risk: Insufficient functionality or bugs at launch.
   • Mitigation: Conduct detailed testing and quality assurance before launch.

5. Security Risks:

   • Risk: Security vulnerabilities in the e-commerce system.
   • Mitigation: Use secure payment systems and conduct regular security audits.

In Allegra, we maintain the risks not as separate activities but as a document. This makes handling easier. Here’s how it looks:

Frequently Asked Questions

How do I write a project plan?

To create a project plan, follow these 8 steps:

1. Define goals and requirements
2. Create a work breakdown structure
3. Estimate effort
4. Plan workflow and milestones
5. Plan dates and timeframes
6. Plan resources and assign roles
7. Conduct a cost-benefit analysis
8. Create a risk register

Follow these steps to successfully create a project plan.

What should a project plan include?

A well-structured project plan contains clear work steps, processes, and responsibilities. This ensures that your team always has an overview of who is doing what by when. A project plan also helps to understand the relationships between different tasks and to ensure that everything runs according to plan. This way, a smooth project workflow can be guaranteed.

What are the 4 phases of a project?

The 4 phases of a project are initiation, planning, execution, and closing. Each phase is an important step in the project management lifecycle and guides your project from start to finish. In project management, these phases are used to ensure the success and efficiency of the project.

Who creates the project plan?

The project plan is usually created by the project manager at the start of the project and is continuously updated. Creating the project plan is a core task of project management, especially for larger projects, as it requires significant time. Project management ensures a structured and efficient execution of the project.