How to create a project plan?

A project plan is a collection of  activities or “tasks“, the completion of which should lead to the desired project result. Each activity has a start date, a finish date, at least one responsible engineer, and an expense required to complete the process. Processes can be interdependent, eg the floor can only be tiled when the screed is dry. The project plan also contains such dependencies.

Step 1: Collect requirements

The most important prerequisite for a good project plan is the most accurate idea of ​​the project result. In classic project management, a specification sheet is created. In the agile process world one speaks of “Epics” and “User Stories“. The creation and management of these documents is part of the requirements management.

Step 2: Create a solution concept

Based on the requirements collected and structured in the first step, a “solution concept” or a “blueprint” is created. In classical project management, the solution concept can be an integral part of a “specification” . For example, if you build a house, the solution concept consists of the drawings of the architect with the different views (east, south, west, north), ground plans of the floors, sewer connections, location on the property, etc. For a better illustration, a real or virtual can also be used 3D model to be created. It is essential that the solution concept clearly and comprehensibly describes the desired project result for all project participants. The solution concept is one of the most important documents in a project.

Step 3: Find and structure processes

The solution concept from step 2 describes the project goal as an arrangement of components and subcomponents. To stay with the house: The building is on a plot and has several floors. The floors consist of floor, ceiling and rooms. Each room has doors and windows as well as a heating and electrical installation. The electrical installation consists of switches and sockets. Components that contain other components are called “parent components” or “collection components“. The components contained in it are called “subcomponents” or “child components“. Subcomponents can also be parent components themselves. For example, the room is a subcomponent of the floor and a parent component for the electrical installation.

In order to create a project plan that fits the solution concept, you assign a work item to each component and subcomponent in a first step. The work item can be formulated as an activity (“install switches and sockets”) or simply names the desired result (“electrical installation”). The first variant is called work package structure, the second variant is called product structure” or “deliverables breakdown structure” (DBS). It is usually better to create a product structure plan than a work package structure because a product, such as a document, is easier to review and track than an activity. If there is a finished document, it must have been created by someone, ie there was also an activity to do so. However, having someone work on a document for four weeks does not necessarily mean that this document is in a usable form. At each hierarchy level, the PSP or WBS should have between three and ten elements. With five hierarchical levels, you can now organize between 250 and 100,000 transactions. Large projects or projects with different subcomponents may be subdivided into subprojects at the project level. For example, you can define a hardware subproject, a software subproject and a mechanics subproject to develop a complex mechatronic system. Subprojects have the advantage that they can be divided into independent phases, and that access to them can be individually controlled. Common representations for structure are Gantt diagrams , as found in modern online project management software .

Intermezzo: How detailed must a plan be?

A big challenge in creating a plan is finding the right level of detail. It would be nonsensical to plan things that depend on many constraints and where it is unpredictable how these conditions will look at the time the plan is realized. Not every planable process should therefore be planned. In complex, rapidly changing situations, it has proven to be easy to plan and to delegate the detailed planning to those responsible for the execution. The more uncertain the planner feels, the more detailed his plans will become. This in turn leads to even more uncertainty. Overly detailed planning becomes confusing and requires a lot of effort to keep it up to date. How detailed a plan must be depends on how quickly you can determine that it is not being complied with. As a rule of thumb, a task is detailed enough if its duration is half the time between two project progress meetings. For weekly project progress meetings, a task should have a duration of two to three days. Planning in more detail only makes sense if different people are involved and they need to be informed accordingly.

Step 4: Determine Dependencies

In many cases, there are dependencies between operations. The most common type of dependency is an end-to-start (ES) relationship, that is, a successor operation can not begin until its predecessor is completed. There are also the rarer end-to-end (EE), start-to-start (SS), and start-to-end (SE) relationships.

Step 5: Expense Estimation

An important benchmark for project success is the punctual delivery of a product or service at a previously agreed price. Deadlines and costs can only be met if the planning and effort estimation are reliable. There are numerous methods and approaches for planning and estimation.

Unfortunately, none of these methods can substitute experience with a similar project. Many effort estimation models have parameters that need to be calibrated first. Without recourse to previous projects you do not have these parameters and thus the models have little benefit. The most reliable planning and estimates are based on similar predecessor projects. They do not assume that the overall technical progress of the new project halves the effort. The effort estimate for a transaction should be made by those responsible for its implementation.

Step 6: Determine appointments and assign resources

Most processes require resources (editors) to take care of getting things done. These resources must be available between the start date and the finish date of an operation. Project plan scheduling is thus strongly related to resource planning. Whether you first allocate the resources to the operations and thus receive the appointments based on the effort or allocate resources on the basis of fixed dates depends on the direction in which you are flexible. If you can not change the resource availability or the deadlines, you will not get a working plan.