The project structure plan (WBS)

The project scope planning is part of the project scope management. In this post, we will focus on project scope planning. A core element of project scope planning is the work breakdown structure.

The project scope management

Goal of project planning

Project planning is a central and very important technique of project management (some mistakenly confuse project planning with project management). Planning is essential to complete a project successfully.

Project planning is an important prerequisite for project controlling (some consider it part of project controlling). The earned values analysis for example requires project planning and a WBS. See our posts:

How to create successfully a project planning ?

A clear and formally approved project order with the desired project scope and project budget is the basis for starting project planning. A clear and formally approved project order including the aimed project scope and project budget envelope is the basis to start the project planning. The project scope includes:

Project specific consistent goals
Project-specific consistent requirements

The definition of the project order can be part of the project initiation phase or provided by an internal business department or an external customer.

With uncomplete or even not provided project order some project managers start already to work with MS project trying to produce a Gantt chart. This quality gap leads to several subsequent gaps and don’t generate a reliable value.

To monitor and complete a project successfully a clear project order, entry criteria and a systematically structured planning process are needed.

The project charta

The project has a unique timeline and achieves deliverables following unique requirements and fulfilling unique goals. Therefore the planning process is very crucial as a creative act projecting the planned exceution into the future. As already mentioned, the basis of precise project planning is the determination of individual goals, which should be

SMART(Specific, Measurable, Achievable, Realistic, Time Bound)

The goals should be already aligned with the most important stakeholders. The goals should be already checked and approved in the context of a clear business case of a demand initiative, if they are defined by an internal demand unit. The goal could be structured hierarchically and have different priorities.

Therefore you should have enough Spend time on this until really concrete goals are defined, which are also supported by the most important stakeholders.

To meet the goals project specific requirements have to be defined. The requirement engineering process could be part of the project itself or also provided by a client (Scope Statement), demand unit (Epics).

We recommend setting requirements at least on the epic level before beginning the project planning process. The requirements should also be SMART and related to the project goals they meet (traceability requirements <> Goals). The “raison d’être” of requirements is given by serving a goal!

Based on the project goals and main requirements a preliminary estimation leads to an approved budget envelope. The project goals, requirements and budget framework build in general the projetc charter, which should be worked out clearly before starting the planning process.

The planning process

Project planning includes according to PMBOK the following primary planning processes and secondary planning processes:

Core Planning Processes:

project scope planning – WBS
acitivity planning
resource planning
cost planning
budget planning

Secondary planning processes:

quality planning
communication
planning
risk planning
organizational planning
purchase planning

The project planning process should consider the following projects parameters:

scope
complexity
duration
project team

Project scope planning: WBS

Project scope planning

Project scope planning is part of project scope management. Project scope management deals with the planning, monitoring and control of the project scope. In this post, we will focus on project scope planning. A core element of project scope planning is the work breakdown structure. All projects, not just large and complex ones, require a detailed description of the project work and the deliverables, the project must deliver.

Please differiate between:

Product scope:The features and functions that characterize a product, service, or result.
Project scope: The work performed to deliver a product, service, or result with the specified features and functions.

Definition of project structure plan (WBS)

“The Project Management Body of Knowledge defines the work breakdown structure as “a hierarchical decomposition of the total scope of work that must be performed by the project team to achieve the project goals and produce the required deliverables.”

See link

As soon as the project charter and scope statement are clearly defined the project manager can start to break down the “work” to achieve the project objectives and requirements. This is the most crucial task to establish a planning baseline for subsequent steps and avoid uncontrolled project scope changes in the future. The work breakdown structure is the most valuable, easiest and most underestimated project management tool.

A project is generally a complex undertaking and needs to be decomposed into manageable scope sub-components, which can be planned and controlled. The result of this process is the work breakdown structure (WBS). The complete WBS is a hierarchical display of all elements of a project scope, in a similar form to that of an organization chart or a list view with numbering and indentations. The list and the graphical view are identical.

A work-breakdown structure (WBS) is a deliverable-oriented breakdown of a project scope. It is a hierarchical decomposition of the total project scope to be carried out by the project resources to achieve the project objectives and required deliverables.

Through the WBS a project is divided into subtasks and work packages within the process of structuring. Hierarchical WBS subtasks are elements that must be further subdivided, work packages are elements that are located at the lowest level in the WBS and are not subdivided further there.

The WBS covers the complete project scope.
All child WBS elements describe completely the scope of the parent WBS element without overlap.

The WBS is an important information and controlling instrument providing the necessary transparency especially in complex projects. The high planning effort to create the WBS is very profitable investment. The WBS is also very important for the preparation of activity and cost planning and the monitoring based on this.

structuring principles

The key purpose of a work breakdown structure is the complete and unique recording of all relevant scope components of a project. In order to achieve this goal, and starting from the top level, the project itself, is a uniform structuring principle i.e. – orientation – and it is applied for each level when creating the subsequent next lower level. The orientations permitted according to the DIN standards 69900 ff. are as follows:

The object-oriented WBS (product-oriented) breaks down the project scope into individual objects that need to be created. This makes sense, if the project scope is largely identical to the (material) objects that are to be created, for example in plant engineering or software programs.
The function-oriented WBS considers the functional areas of the project-executing organization. The main focus here is on the type of activity to be performed. This WBS type is useful if the project has aspects that go significantly beyond the material object involving several organization units, such as procurement, marketing, partner management.
In the phase oriented WBS, these are the project phases at the highest structural level. However, in order to achieve the design goal, it is recommended in practice to use only one orientation method for one WBS level. The WBS should continue to differ from activity planning and be based on the outcome of the project.

The mixed forms of the structuring methods are possible insofar as different levels can be created according to different orientations. However, in order to achieve the design goal, it is recommended in practice to use only one orientation method for one WBS level.

The top-down approach

When a project is very large, it is divided into sub-projects. This forms then the second or third level of the work breakdown structure, depending on the structuring type.

It is recommended to only divide the project into sub WBS elements until the lowest level of the work packages is reached. These are assigned to unique deliverables and to the corresponding organizational unit of the company, essentially to a project team member or an external company for execution.

The sensible size of work packages is an important criterion here. Each element of the work breakdown structure gets a unique identifier, known as the work breakdown structure code (WBS code). This code describes, to which sub-project the element belongs to and at which hierarchy level it is located to.

A WBS directory (WBS dictionary) is created using the WBS. The directory lists all defined WBS elements. It displays the hierarchical relationship between the WBS elements in tabular form and describes each WBS element and the required resources, process, and further requirements for its preparation.

The WBS is growing continuously

At the beginning of the planning process, sufficient information is usually not always available to allow the detailed planning of certain sub-tasks into the subdivisions of work packages.

At the beginning of the planning process there are often not enough information ready to plan certain sub-tasks very detailed in all their subdivide work packages. Mapping each work package of the work breakdown structure allows for a good review of the results. The results should serve the overall project goal by providing a measurable value (software, concept…). The work breakdown structure is therefore given in as much detail as possible. WBS tasks in the far future are considered as planning work packages to be detailed later on. For past, present and future deliverables, the work package level should be planned in detail. With the contentious time progress the WBS gets also a progress in the detail level.

design rules

The 100% rule states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – with regards to the work which is to be completed, this including project management.
The sum of the work at the “child” level must equal 100% of the work represented by the “parent” and the WBS should not include any work that falls outside the actual scope of the project, that is to say that it cannot include more than 100% of the work… “

Effective Work Breakdown Structures by Gregory T. Haugan

"Make or Buy"

The WBS must also clearly document which WBS elements are purchased from suppliers and which are developed internally by the project team (Make or Buy). The buy of project deliverables always means a greater dependency and greater risk in project implementation. Therefore, the “Make or Buy” decisions must be visible in the PSP and be specifically monitored.

Plan outcomes/results, not actions

To make sure that the complete project scope (and specifically this) is planned, it is necessary to plan the proposed outcomes or results i.e. the deliverables rather than the activities. The mapping of every work package of the WBS is a good sanity check. The deliverables should serve the whole project goal by providing a measurable value such as for example the software or the concept.