PM KNOWLEDGE: PROJECT SCOPE PLANNING – THE WBS

• The core planning processes
• Project scope management: The WBS

Project planning - the basis for project implementation and controlling

Project planning is a central and very important technique of project management (some people mix up mistakenly project planning and project management). Without an accurate planning a project will never be a success !

Project planning is a key precondition for the project controlling process (some people consider it as part of the project controlling).

How to create successfully a 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 – on epic level

The project order definition could be part of the project initialisation phase or provided by an internal business department or external client. The cut and mapping of the business (demand) portfolio requirements aiming product specific requirements to specific project scopes should be done by the demand or portfolio management department.

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

Only with clear project order and entry criteria and a systematically structured planning procedure you will later successfully complete your project and monitor them.

The project charter

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 an accurate project planning is:

SMART project goals (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. In a dedicated post I will explain in details how goals can be specified.

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). I recommend to have the requirements at least on epic level before starting the project planning process. The requirements should be also SMART and refer to the project goals they meet (Traceability requirements <> goals). The “raison d'être” of requirements is given by serving a goal !

TBC: 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 processes

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

Core planning processes

1. project scope planning - WBS
2. activity planning
3. resource planning
4. cost planning
5. 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

The chosen granularity of the project planning process should create a balance between maintainability and the ability to control the project

My Experience

Project scope planning

The project scope planning is part of the project scope management. Project Scope Management deals with planning, monitoring and controlling 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 WBS

The Project Management Body of Knowledge defines the work-breakdown structure "A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables."

https://en.wikipedia.org/wiki/Work_breakdown_structure

As soon as the project charter and scope statement are cleraly 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 an organisation chart or 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 most important design goal for a work breakdown structure is the complete and unique recording of all relevant scope components of a project. In order to achieve his goal, starting from the top level, the project itself, a uniform structuring principle - orientation - is applied for each level when creating the next lower level. The orientations permitted according to the DIN standards 69900 ff. are:

• The object-oriented WBS (product-oriented) breaks down the project scope into individual objects that need to be created. It makes sense, if the project scope is largely identical with the (material) objects to be created, for example in plant engineering or software programs.
• The function-oriented WBS considers the functional areas of the project-executing organisation. The main focus 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 organisation units, such as procurement, marketing, partner management.
• In the phase-oriented WBS, there are the project phases at the highest structure level. However, the time orientation of the work breakdown structure should not be only or primary structuring principle. The WBS should continue to differ from activity planning and be based on the outcome of the project

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. These forms then the second or third level of the work breakdown structure, depending on the structuring type. You should 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, 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, the so-called work breakdown structure code (WBS code). This code describes, to which sub-project the element belongs and at which hierarchy level
it is located. 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 their preparation.

The WBS is growing continuously

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. The WBS is therefore detailed as far as possible. WBS tasks in the far future are considered as planning work packages to be detailed later on. For past, present and upcoming 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 principles

100% rule

The 100% rule states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, 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, 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 or made 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 specially monitored.

Plan outcomes / results, not actions

To make sure that the complete project scope (and only this) is planned, it is necessary to plan outcomes or results (deliverables) instead of 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 (Software, concept ...).