Project Structure Plan

The project structure plan is the basis for every project plan.

A project structure plan answers the question of what needs to be done within the entire planning process. Depending on the method, this structuring of a project into individual elements is called project structure plan ( DIN 69901-5), product structure plan ( PRINCE2) or Work Breakdown Structure ( PMBOK® Guide 2017).

All these plans have in common that they include all elements of a project and their relationships to each other. The elements are arranged hierarchically in a tree structure, without making a statement about the exact temporal course of the processing.

On the basis of this “plan of plans”, the scheduling and process planning, resource planning and cost planning are addressed in the later planning stages.

The structuring of a project structure plan (PSP) is done according to DIN69901-5 with three types of elements:

• Subprojects

• Subtasks

• Work packages

Subprojects make it possible to use different process models within an overall project. For example, it may be useful to use a classic waterfall method for the development of electronics in one subproject and agile methods for the associated software development in another subproject. In Allegra, you can use hierarchical workspace structures with different workspace types for this purpose.

Subtasks are elements that can be further broken down in the project structure plan. In Allegra, we call subtasks “parent items” or “collective items”.

Work packages represent the lowest level of a project structure plan and can be broken down into items or tasks in the further planning process. We also model work packages in Allegra as “parent items”.

In this form, the project structure plan appears activity-oriented with a focus on the activities and less on the results. A product structure plan emphasizes the results, while a Work Breakdown Structure requires the combination of activity and verifiable result.

Finding Items

In order to be able to create a project structure plan or product structure plan, you first need to find the corresponding elements. In Allegra, we call such elements “items”. Imagine two points in time: The initial situation and the final situation. If the final situation can be described by objects that are to be created during the course of the project, you break these objects down into sub-objects. You continue to break down the sub-objects if they are not purchased or primitive. So you create the plan product-oriented.

If the projects are those with a strongly activity-oriented character, such as a move, you collect the activities and try to categorize them. In the case of a move, the rooms, for example, offer themselves as the highest category level.

The collection of elements for the project or subproject can be supported by mind mapping or brainstorming.

Arranging Elements in the Project Structure Plan

So how do you arrange the elements for your structure plan? For the project structure plan, there are three suggestions according to DIN 69901 to achieve a good structure depending on the type of project:

• Object-oriented structure

• Function-oriented structure

• Time-oriented structure

In the following, we will go through these principles using the example of building a small workshop.

Object-oriented Structure

This approach is best when the project goal is a concrete object, such as a garage, an office building or a gas burner. The object-oriented structuring results in a plan that is very similar to a product structure plan according to PRINCE2.

The advantage over a function-oriented approach lies in the better traceability during project execution. A result is easier to check than activities. Process testing basically requires real-time project monitoring, while testing based on process results can easily be done much later.

An object-oriented structured project structure plan is basically a product structure plan, if you not only see the final products, but also intermediate products such as design documents or test reports.

Function-oriented Structure

The function-oriented structure is best when the project can be more vividly described by the activities or work packages to be carried out than by the results of the activities. For example, for a move, you could describe what the result should look like. However, you would miss the essential point, namely the moving of objects from the starting point to the destination.

For comparison, the function-oriented project structure plan for a new workshop construction is set up in the next figure. Unlike a move, a function-oriented approach is also possible in this case.

Time-oriented Structure

In a time-oriented structuring, you create the plan directly from the necessary tasks. You think about the course of the project, i.e. what needs to be done one after the other. You write these activities on a list or enter them directly into the system. If the list gets longer, you structure the process into phases. For a move, for example, you could plan a phase for each room and sub-phases for furniture and small items.

Which Structuring Principle to Apply?

The choice of structuring principle depends on the type of project. Whenever possible, you should prefer the object-oriented approach and only use the function-oriented methodology if that does not fit. The function-oriented structure is suitable in projects when the project can be more vividly described by its activities than by the results of the activities.

Coding in the Project Structure Plan

In order to be able to uniquely identify the individual elements in the project structure plan, it is important that they receive a code. This allows later efforts, resources or changes to always be clearly assigned to a work package. The coding must reflect the hierarchical position of the element. Various types of coding are distinguished:

• Numeric coding: Use of digits, e.g. 1, 1.1, 1.1.2…

• Alphabetic coding: Use of letters, e.g. A, AA, AB, …

• Alphanumeric coding: Mix of numbers and letters, e.g. A, A1, A.1.1 …

• Decadic coding: Digits in 10 format, e.g. 1000, 1100, 1110 …

Allegra always and automatically uses numeric coding. Please note that an item receives a different code if its position in the structure plan changes.

How Detailed Do You Need to Plan?

A major challenge in creating a project structure plan is finding the right level of detail. It would be pointless to plan steps early in the project that depend on many boundary conditions and where it is in no way predictable what these conditions will look like at the time of implementing the plan.

As a rule of thumb, work packages on the lowest level should not last longer than the gap between regular project meetings. This way, deviations can be detected at the latest in the meeting after next.