How To Build A Project Structure Plan

How To Build A Project Structure Plan

January 21, 2010 Email This Post Email This Post Print This Post Print This Post

The project structure plan is the most important plan for your project.

It is the basic document for the internal project communication in the project team because it is the basis for the project manager to assign work packages and to communicate them with the responsible team members.

This increases the transparency of your project tremendously because each team member knows what to do next and what the others have to tackle simultaneously.

A structure plan helps you to estimate and to control your project costs. It is indispensable to analyze and to manage potential risks concerning costs, performance and appointments without having a plan which breaks the complex structure of a project down into applicable building blocks.

The project structure plan is the basis for the time scheduling and the sequence planning which are very often presented in form of network plans and bar diagrams.

And although structure plans are obviously crucial for the success of projects, they are still totally underestimated in modern organizations.

Humans tend to be too self-confident about the issues of their daily business. Sometimes they seem to forget that a project not a part of their daily business.

A project is always something very unique and special. A project manager should not be so self-assure. He or she should rather try to benefit from all the great advantages of a well-designed project structure plan.

To build a structure plan you have to know something about the essential aspects you should consider in your planning, like:

  • Breaking the project structure down into applicable building blocks,
  • Finding an adequate principle of arrangement and
  • Choosing a compatible form of planning.

We’ll talk about each of them in the following paragraphs.

Breaking the project structure down into applicable building blocks

The basic building blocks of structure plans are called work packages.

Work packages are enclosed work units that can be assigned to a person.
They are subtasks of the project that cannot be divided up into new subtasks.

That means that they are located on the lowest level of all project tasks as you can see in the following image:


There are 4 general requirements to work packages:

  1. Clearness/Specification
  2. Completeness
  3. Measurability
  4. Responsibility
  5. Adequate number

Considerung these requirements you should describe and define your work packages as accurate as possible in order to increase the quality of your planning enormously.

The more details you can integrate in the description of them the better you can estimate costs, plan performances, identify risks and control the corresponding results.

A detailed work package is also an important requirement for a competent communication between you as project manager and the team member the work package has been assigned to.

In the best case you have something like a “wanted poster” for every work package and subtask of your project that contains information about:

o Name of the work package
o Actions
o Requirements
o Problems
o Risks
o Responsibility
o Estimated costs
o Estimated appointments

These data help a lot to meet the requirements described above especially concerning clearness, specification and completeness. But even more important is the question of responsibility and measurability of your wok packages. Who will be responsible for the agreed results and how are you going to measure this? What will be the decisive indicator for you to assess the degree of success?

Personified responsibility is necessary to motivate your folks by challenging them with relevant contributions to the success of the project.

On the other hand you need a clear contact person for each package to discuss the project status without shifting responsibility from one to another. This increases your productivity enormously.

Finding an adequate principle of arrangement

Projects can be structured function-oriented or object-oriented.

Function-oriented project structures represent the progression of the project in form of actions that have to be executed.

For example: If you want to build a table you have to define your requirements at first.

Then you must draw the table and its components in order to fix the corresponding dimensions and materials. After that you will have to buy the materials, shape parts of them and assemble the parts to something that looks like a table.

This is a very simple example for a function-oriented structure plan.

This structure is often deduced from the process organization of a company or an institution. Sometimes it is just a copy of it.

An object-oriented plan has just another focus:

The table consists of a plate, a frame and four table-legs.

You can build them consecutively or parallely and assemble them in a certain order to complete the table. So you divide the table up into its single parts in order to find out what to do first, secondly etc.

Object-oriented project structures consider the internal structure of the product you want to realize. This can be a table, a website, a machine or a big party.

You always have the choice to ask for the actions that have to be done in order to draw nearer to your goal or you ask for parts and components of your product that have to be completed in order to complete the whole product.

Which approach you choose depends strongly on the kind of project you work on.
In most cases both structures are applied simultaneously. Based upon my personal experience I can recommend this mixture by starting with the object-oriented approach.

Afterwards you should ask for all the actions that have to be done in order to realize the identified parts and components.

But the approach you choose is not carved in stone. It can vary from project to project.

Choosing a compatible form of planning

You can choose between two main forms of planning:

To plan something top-down means to start your planning at the end of your project and to develop your subtasks and work packages until you reach the beginning of the project.

So you start with the goal and the question: What is the last task that has to be finished in order to achieve the defined project goal? Then you ask the same question again and again just until you come to the first subtasks and work packages.

Project managers choose this approach when they have worked on very similar projects in the past.

For example: A project manager who has realized lots of website-projects in his life would be able to explain you instantly what a well-designed website consists of: domain, design, content, affiliate programs etc.

Such a project manager would rather plan top-down in order to recapitulate each single step in detail.

Project managers who are confronted with very innovative and unknown contents would choose the bottom-up approach by arranging workshops e.g. where all team members have the opportunity to partake with their special experiences and talents by defining necessary actions and activities.

Brainstormings and other creativity techniques comply very well with this approach.

The affected results are concentrated and formed to work packages and subtasks afterwards. You can observe how your structure tree grows from the bottom up to your project goal.

Don’t think in rigid rules

Building and designing project structure plans is something very individual. The whole planning process depends on the sort of project, its complexity and circumstances as well as on the configuration of the project team.

Everyone has to find a personal approach to a specific project. But all this mainly impacts how you design your planning. We can discuss a lot about that. But there is no question about what you must do at least in order to accomplish:

Find applicable work packages, arrange them adequately and plan transparently with as much team expertise as you can obtain.

Related Articles

Post to Twitter

Tags: , , , ,
Posted in Project Management on Jan 21st, 2010, 20:35 by haukeborow