Bernd Kaltenhäuser

Project Management

Anybody who wants to achieve, finds a way – everybody else finds

excuses!

Project Management
Literature

• The Project Management Institute Project Management

Handbook

• Walter Jacoby: Projektmanagement für Ingenieure. A good

textbook.

• Gesellschaft für Projektmanagement (GPM): Kompetenzbasiertes

Projektmanagement. Only recommendable as a reference work!

2
Projektmanagement
1. Projects and project management
1.1 Projects……………………………………………… 5
1.2 Project management…………………………….. 13

2. Business organisation………………………………. 20

3. Project management phase model

3.1 Principles………………………………………….. 41
3.2 Concept phase……………………………………. 62
3.3 Planning phase………………………………….. 112
3.4 Realisation phase………………………………. 138
3.5 Closure phase…………………………………… 164

4. Documentation………………………………………. 175
5. Communication and information…………………. 183

4
1. Projects and project management

How many of you have

worked on a project in the
past?

What is a project?

1.1 Projects: Characteristics of a project

A project is a non-recurring scheme with limited time and material

undertaken to realise a special task, examples being the creation of a
new product, a new service or the achievement of a new goal.

• A project is clearly defined (unambiguous target).

• A project is clearly marked-off from other undertakings.
• A project is non-recurring and new and will not be repeated in this form.
• A project has a clear starting and finishing deadline.
• A project solves a difficult problem with appropriate methods.
• The problem must be solvable.
• Team formation: Several people work on a project. Tasks and functions (e.g.
project manager) are clearly defined.
• Due to its complexity, a project cannot be solved using operational entities
already in existence (e.g. production lines). => Project structure!
• A project has process character and consists of several working steps.
• The resources employed for a project are limited.
• Project costs can be calculated or estimated.
6
1.1 Projects: Difference between project / non-project
An undertaking is never 0% or 100% new. Equally, other criteria are in
most cases not met completely or at all. A project is frequently considered
as such, even where not all 11 criteria required are met.

Project Borderline Non‐project

Clarity of goals Ambiguous goals
Intermixing with other
Delimited project scope
projects
Uniqueness & innovativeness Routine
Difficulty of task Simple
Problem is solvable Problem is not solvable
Project structure required Solution in line structure
Team formation: Several people Only one person
Process character Single working step
Starting and finishing deadline No clear deadlines
Limited resources  Unlimited resources
Costs can be calculated or estimated Costs unknown 7

1.1 Projects and non-projects

Are the following activities projects?

Yes No
• Construction of a wind park in the North Sea

• A weekly meeting

• Non-recurring task to improve a production

process

• Continuous improvement of a production process

• Your studies?

8
1.1 Projects: Project types
Projects can differ completely in nature, but always have the same
characteristics and the same basis in project management!
The following table illustrates different project types:
Research and Investment or
Organisation  Sales/Marketing 
development expansion  Agency projects
projects projects
projects projects
Development of 
Implementation  Market launch of  Development of 
Development  a new 
of a new  a product an advertising 
of a material organisation 
processing centre campaign
structure
Development 
Development  Integration of a  Organisation 
and 
of a new Erection of a  subsidiary in the  realisation of a 
implementation 
production  company building company  trade fair 
of a corporate 
process organisation appearance
identity
Development  Design and
of a new  Installation of a  Restructuring in  Conducting of a  implementation
model  PC network the company  company survey of an internet
(e.g. car) website
9

1.1 Projects: Examples

Start Planned Real Planned Real
Project Sector
year costs costs duration duration
Empire State Construc- 50 million 41 million 410
1930 410 days
Building tion USD USD days
Energy /
49 million 49 million
Hoover Dam Construc- 1931 6 years 4 years
USD USD
tion
102
Sydney Construc-
1959 7 million AUD million 6 years 14 years
Opera House tion
AUD
Apollo Space- 20 billion 24 billion
1960 8 years 9 years
project flight USD USD
Gotthard 6.6 billion 12 billion 11-13
Rail 1999 17 years
Base Tunnel CHF CHF years
>6.5
2.5 (95) - 4.5
Stuttgart 21 Rail 2013 billion € 8 years >9 years
billion € (09)
(2013)
400 billion
Desertec Energy 2015 ? 10 years ?
EUR
10
1.1 Projects: Project size
Personnel costs make up a large percentage of the costs of a project.
These costs are mainly estimated in man-years (=MY), i.e. a person who
works for a year generates costs equivalent to a man-year. 2 people who
work full-time for a half a year on a project also generate a man-year, etc.
One should therefore multiply the number of workers, proportionate time
on the project and the duration in all cases.

Classification of projects according to their size depends heavily on the

size of the company and the sector. Possibilities are:
MY Costs Size
< 0.5 < 100,000 EUR Very small
0.5 – 2.5 100,000 – 500,000 EUR  Small
2.5 – 15 500,000 – 3 million EUR Medium
15 – 50 3 million – 10 million EUR Large
> 50 > 10 million € Very large 11

1.1 Projects

Investigations from 1994, 1996, 1998 of 8300 software projects in the

USA with a total of 25 billion USD indicate that:

• were completed on schedule

• were completed late (with serious delays on occasions)
• were discontinued

These statistics, however, strongly depend on the sector.

12
1.2 Project management: Definition acc. to DIN 69901
What is project
management?

The DIN 69901 standard defines project management accordingly

as the "the totality of leadership tasks, organisation, techniques and
media for the initialising, definition, planning, control and conclusion of
projects".

To summarise, it can be said that project management is the planning

and control of problem-solving project processes to realise these true to
deadline and minimise the outlay.

The word “management” here not only means leadership tasks, but also
operative activities during control of a project.

A process is a chronological sequence of several activities which are

mutually dependent and also influence each other.
13

1.2 Project management: Problems

“We’d like to do project management, but we just don’t have the time!”

“The later I involve other people or departments, the less they can
interfere in my work!”

“I prefer doing product development to all that admin work!”

“Project management is only needed for major undertakings involving a

lot of people!”

“We've always managed very well up ’til now without project

management!”

=> Introducing project management can be a tough job

14
1.2 Project management: Why project management?
Project management reduces the outlay and duration associated with an
undertaking.

Red curve:

Blue curve:
15

1.2 Project management

Project management differentiates between project programs and
project portfolios.

Project portfolio

Program
Project Project

Project
Project
Program
Project
Project
Project Project Project

Project

Project Project Project

Project program: Projects in programs have common goals, are mutually

dependent and should be coordinated together.
Project portfolios: Projects in portfolios are not necessarily mutually
dependent and frequently compete for resources. 16
1.2 Project management
Project management differentiates between operative and strategic
project management.

Operative project management takes care of the planning,

implementation and control of projects. The approach is short- to
medium-term.

Operative multiproject management involves the common

coordination and control of several projects (particularly in project
programs). Examples include through universal project controlling,
scheduling (if projects need to be realised together), capacity planning
(control of access of several projects to common resources), universal
project reporting, knowledge management, standardisation of project
procedures, uniform quality management and project evaluation.

17

1.2 Project management

Strategic project management (= strategic multiproject management
= project portfolio management) represents a link between strategic
corporate goals and operative project management.
Tasks:
• Prioritization of projects pursuant to corporate goals (maximum benefit,
balanced risk in portfolio).
• Transformation of strategic corporate goals into operative project goals.
• Ensure that all projects are realised efficiently.
• Defines clearly defined rules for operative projects.
Furthermore, a differentiation is made between strategic and “normal”
projects: “Normal” projects chiefly need to be implemented to meet a
demand. Strategic projects, on the other hand, mainly involve the investment
of a substantial sum to realise essential changes or reorientations (to
increase profits in the long term). Strategic projects can therefore also create
the framework for numerous “normal” projects. An example of a strategic
project is the development of a new business segment.
Furthermore, an overall project leader of a larger project is often referred
to as strategic project leader. 18
1.2 Project management: Organisations and standarts
There are three bis organisations that define standards in project
management and offer certifications of project staff. The lessons are
executed by third-party companies. These organisations are:

• The IPMA (International Project Management Association) in

Switzerland. The German GPM (Gesellschaft für Projektmanagement,
society of project management) is a member of it. Leading in
Germany.
• The US-American PMI (Project Management Institute), which defines
the standart PMBOK (Project Management Body of Knowledge).
Leading in the US.
• The British company AXELOS, which defines the standart PRINCE2
(Projects in Controlled Environments). Leading in the UK.

The differences between these standarts are not very big.

19

2. Business organisation

You are appointed Managing Director

of a company to be newly formed which
intends to manufacture 3 different
vehicles. How would you structure your
business?

20
2. Business organisation: Classic line organisation
No subdivision in projects takes place.

Management

R&D Production Sales

21

2. Business organisation: Classic line organisation

The following illustration indicates the substructure of the R&D department.

R&D

Mechanics Electronics Software

Individual areas such as R&D are further divided into technical areas
where the firm is adequately big.

22
2. Business organisation: Classic line organisation

The following corporate hierarchy rules mainly apply in a classic line

organisation:

• Several employees form a team (group) and have a team leader

(group leader).

• Several teams form a department and have a department head.

• Several departments have a divisional director and, for example, form

a business unit.

• A manager is in charge of 3-20 employees in most cases. 7 are

employed in most cases as a rule of thumb!

Levels 1 2 3 4 5 6 7
Staff 1 7 50 350 2,000 15,000 100,000

23

2. Business organisation: Classic line organisation

In addition to the line, staff units are usually integrated in the organisation.

Management
S

R&D Production Sales

S S S

Staff units are originally a military concept. Their main purpose is to

ensure speedy and efficient coordination between individual areas and
hierarchies and ease the burden on the respective managers
associated with administrative tasks.
24
2. Business organisation: Classic line organisation
Line structure with a product developer as project manager.

Management

R&D Production Sales

PM
• A product developer is simultaneously project manager here.
• The team leader or department head is (simultaneously) the project
manager in the case of larger projects.

25

2. Business organisation: Business segment organisation

Structuring a company according to its business segments.

Management
S

Maschines Special-Mas. Ultrasound-t.

S S S

R P S R P S R P S

This type of structuring is found in many companies and sectors.

26
2. Business organisation: Pure project organisation
Structuring a company according to projects.

Management
S

Project 1 Project 2 Project 3 Project 4

PMS PMS PMS PMS

R P S R P S R P S R P S

In the case of projects, staff units are often referred to as PMS (project
management support) and, in the case of larger projects, the PMO (project
management office) if the staff unit consists of several people. The main
tasks are the independent processing of project issues, coordination
between different disciplines and the organisation of meetings, incl.
invitation, minutes and log shipping.
27

2. Business organisation: Pure project organisation

Structuring a company according to projects.

Management
S

Project 1 Project 2 Project 3 HR Law

PMS PMS PMS

R P S R P S R P S

Central administration departments such as human resources (HR)

and legal department (law) can also be managed as a line
organisation in this context.

28
2. Business organisation: Pure project organisation
Pure project organisation for large projects.

Strategic project leader project 1

PMO

PL R&D PL P PL S
PMS PMS PMS
R&D Electronics
R&D Mechanics

R&D Software

P Electronics
P Mechanics

S Americas
P Software

S Europe

S Asia 29

2. Business organisation: Project house

Line organisation with project house.

Management
S

R&D Production Sales Projecthouse

S S S PMS

R P S

A so-called project house is sometimes established for projects. Employees

are released here from their actual areas and are, in the main, subordinate
in disciplinary terms to the project manager.

30
2. Business organisation: Pure project organisation
Advantages of pure project organisations and project houses:

Advantages:

31

2. Business organisation: Pure project organisation

Disadvantages of pure project organisations and project houses:

Disadvantages:

32
2. Business organisation: Matrix organisation
Matrix organisation in case of small projects.

Management
S

R&D Production Sales

S S S

PM1

Projects
PM2

PM3

A pure project structure is constructed in addition to the line structure.

33

2. Business organisation: Matrix organisation

Matrix organisation: Simplified depiction to clarify the matrix.

Management

R&D Production Sales

PM1
Projects

PM2

PM3

34
2. Business organisation: Matrix organisation
Advantages and disadvantages of matrix organisations:
Advantages:

35

2. Unternehmensorganisation: Matrix-Organisation
Advantages and disadvantages of matrix organisations:
Disadvantages:

36
2. Business organisation: Matrix organisation
Matrix organisation in case of small projects.

Management
S

R&D Production Sales

S S S

PM1

Projects
PM2

PM3

Mixed forms frequently exist, with some projects organised as a matrix

and others in a line organisation.
37

2. Business organisation: Matrix organisation

Matrix organisation in the case of large projects (without staff units here).

Management

R&D Production

Mech. Elec. Mech. Elec.

PM
R

SPM 1
PM
P
PM
R

SPM 2
PM
P

38
2. Business organisation: Matrix organisation
Matrix organisation in the case of large projects (without staff units here).

Management

R&D Production

Mech. Elec. Mech. Elec.

PMR

SPM 1
PMP
PMR

SPM 2
PMP
Sub-project managers can also be subordinate to a line department. 39

2. Business organisation: Functional organisation

Mixed form: Functional organisation in the case of large projects.

Management

R&D Production

Mech. Elec. Mech. PMP

PMR
SPM 1
PMR

SPM 2
PMP

Also called a functional organisation

where sub-project managers are subordinate to the line. 40
3. Project management phase model
3.1 Principles

What is a project?

41

3.1 Sub-projects and work packages

A project should be divided into several sub-projects (SP) to improve

clarity and control. These in turn are subdivided into work packages
(WP). A work package consists of tasks which are closely related in
topical and chronological terms and are realised by a single person. It is
the smallest unit which the project manager needs to consider.

Project

Sub-project Sub-project Sub-project

WP SP WP WP WP SP SP

WP WP WP WP WP WP

42
3.1 Development models

3 development models exist for projects, and these are used as a

basis for planning work packages, project organisation and milestones
are planned.
In the component model, the product is divided into several components
(components, modules) developed exclusively for themselves alone.
=> higher coordination effort between individual components.
For example, automotive development: Tyres, steering wheel, engine,
transmission, etc.

In the layer model, each new model encompasses a defined range of

functions. The layers lying above draw on this function range and expand it.

Examples: Software development, electronic equipment

43

3.1 Development models

The prototype model involves the manufacture of components in several

development steps in a process which is increasingly more suitable for
series production. This means the first prototype is produced by hand, the
second with a prototype tool which is only suitable for a total of 100 units.
Only subsequent to this are series production tools manufactured and used.
All components manufactured with test tools are called prototypes in this
context. Parts manufactured in a near-series production process with
series tools are called series machined parts (SMP), the first of which
these being termed the initial series machined part (ISMP).
Where several consecutive prototypes are realised in an elaborate
development process, these are frequently designated the A-sample, B-
sample, etc.
When it comes to prototypes, only particularly significant aspects are
realised in many cases to permit their testing (analogous to the layer
model). In the case of complex products, the prototype model is frequently
combined with the component model (i.e. prototypes exist for all
components).
Examples: Mechanical engineering, automotive
44
3.1 Project management phase model
A project is not only subdivided in terms of issues. The process is also
divided into 4 phases (sub-processes) to improve the planning, monitoring,
control and inspection of a project, despite the complexities involved.

Concept Planning Realisation Closure

phase phase phase phase

Project Project Project Project

concept setup realisation closure
0 1 2 3 4

Each milestone concludes one phase and starts a new one. Each
milestone delivers a verifiable result in this respect.
The milestones or results are as follows:
MS0:
MS1:
MS2:
MS3:
MS4: 45

3.1 Project management phase model: Problem solving process

Every milestone can be considered a problem in this context which is

solved in the next phase. As with a project, each problem solving
process can be divided into 4 phases with a result defined in each case.

Analysis Draft Realisation Validation

(MS0) MS1 MS2 MS3 MS4

Every phase is also concluded here with a milestone (MS) which delivers
a verifiable result.

The milestones or results are as follows:

MS0:
MS1:
MS2:
MS3:
MS4: 46
3.1 Project management phase model: Problem solving process
Depiction is possible with a waterfall chart:
Problem

Analysis What are the

milestones for?
Task

Draft

Plan

Realisation

Solution

Validation

Val. solution

I II III IV Time 47

3.1 Project management phase model: Milestones

Sub-goals (milestones) have a motivating effect on the project team
and result in consistent project performance throughout the entire
process.
Process without milestones:

Goal

Process with milestones:

Goal

48
3.1 Project management phase model: Milestones

Moreover, milestones ensure that the project is developing along the right
route and all employees are working together in the same direction.

Project section

Milestone Milestone

Problem Solution

Agree Quality monitoring

requirements
Secure the Make experience /
way knowledge useful

Synchronize
progress / tasks
49

3.1 Project management phase model: Milestones

All project milestones are defined in advance with a deadline and

verifiable result (= variables). On achieving a milestone, all
specifications are checked on the basis of the results and necessary
measures initiated where appropriate.

This generally occurs in a so-called milestone test in which all relevant

parties involved in the project participate (see section 3.4).

Necessary checks and uncomfortable decisions are often postponed for

too long in the absence of milestones. The leads to work packages
without results, sub-projects which drag on, deadlines being postponed
and, frequently, failed projects.

50
3.1 Project management phase model: Problem solving process

Each project phase begins with a given problem and should deliver a
validated result. For this reason, each phase is tackled through the
problem solving process.

The project realisation sub-process subdivided into the project solving

process in the following depiction:

Concept Planning Realisation Closure

phase phase phase phase

Analysis Draft Realisation Validation

51

3.1 Project management phase model: Problem solving process

It is frequently necessary to pass through the problem solving process
several times.

Realisation phase

Analysis Draft Realisation Validation

The milestone ultimately generated in each pass through is of particular

relevance for the project manager.
Each pass through creates a new interim state in most cases (technical
projects: prototype).
Interim states (IS) are only created in many cases because the
specifications and requirements have changed in the meantime or did
not yet exist completely at the project start.
Incomplete software states are frequently generated in the context of the
layer model. 52
3.1 Project management phase model: Problem solving process
Depiction of three iterations in a waterfall chart:
Prob.

Ana. Ana. Ana.

Draft Draft Draft

IS 1 IS 2

Rea. Rea. Rea.

Val. Val. Val.

Val. sol.

Time 53

3.1 Project management phase model: Spiral model

Serial progress can also be illustrated in the spiral model.

54
3.1 Project management phase model: Process models
Depiction of three iterations in each case in different process models.

Ana Ana Ana iss

Dra Dra Dra
Rea Rea Rea Spiral
Val Val Val model

Ana Ana Ana ips

Dra Dra Dra
Rea Rea Rea
Val Val Val SCRUM

Ana Ana Ana isp

Dra Dra Dra
Rea Rea Rea
Val Val Val

Ana Ana Ana ipp

Dra Dra Dra
Rea Rea Rea Simultaneous
Val Val Val
engineering 55

3.1 Project management phase model: Process models

iss:
• Serial sub-processes, serial process clusters
• Good clarity, but long project duration

ips:
• Parallel sub-processes, serial process clusters
• Project still clearly comprehensible, processing time shorter than iss.
• SCRUM: Software development process standard

isp:
• Serial sub-processes, parallel process clusters
• Difficult for project management to understand, easy for work package
manager to comprehend. Shorter processing time than iss

ipp:
• Parallel sub-processes, parallel process clusters
• Difficult to understand, but extremely short project duration. Mainly
standard, due to competitive pressure
• Simultaneous engineering
56
3.1 Project management phase model: Process models
Example: You are writiting an instruction manual.
Ana Ana Ana
Draft Draft Draft ips
Rea Rea Rea
Val Val Val

If sub-processes are parallelised, Chapter 1-3 of the direction are

corrected by the superior (validation), while Chapter 4 and 5 are still to be
written by the employee (realisation), to give an example.
Ana Ana Ana
Draft Draft Draft
Rea Rea Rea isp
Val Val Val

If process clusters are parallelised, the legal requirements are changed

during the realisation phase, to give an example. However, the direction is
completed and validated on the basis of old specifications, while analysis
of the new requirements is already begun.

57

3.1 Project management phase model: Process models

Likewise, work packages and sub-projects have to be processed in
parallel.

Ana Ana Ana

Dra Dra Dra
SP1
Rea Rea Rea
Val Val Val

Ana Ana Ana

Dra Dra Dra Where would you set the
SP2 Rea Rea Rea milestones here?
Val Val Val

Ana Ana Ana

Dra Dra Dra
SP3 Rea Rea Rea
Val Val Val

Time

58
3.1 Project management phase model: Workload

The effort involved in a project increases over time and only reduces at
the end of the realisation phase.
Effort

Realisation

Planning
Closure
Concept Time

The realisation phase takes up more time than other phases in many
projects. However, this should not be underestimated!
Effort

Realisation

Planning
Closure
Concept Time 59

3.1 Project management phase model: Workload

It is even greatly more efficient to invest more time and/or effort in the
concept and planning phase. While reducing the effort in the realisation
and closure phase, this also reduces the overall effort and the effort in
aftersales (after the project, e.g. customer complaints, etc).

Why is it usually not

Effort

Realisation done like that?

Planning

Closure
Concept Time

60
3.1 Project management phase model
Overview of tasks and methods in individual project phases.

Concept Planning Realisation Closure

phase phase phase phase
- Target definition - Product structure plan - Processing of - Preparation of
- Development of - Project structure plan work packages final report
Activities

solution concept - Project organigram - Coordination of - Holding of

- Compilation of - Schedule with sub-projects project closure
requirements and milestones - Reaction to meeting and
performance - Budget plan plan deviations closure meeting
specification - Achievement of with the client
Project goal - Securing
- 4-What-questions - Top-down & knowledge for
- 6-W-questions bottom-up future projects
- Stakeholder - Committee mana-
- RASI charts - Disbanding of
analysis gement
project team
- Ishikawa diagram - To-do lists - Archiving of all
Methods

(with ABC analysis) - Project reports documents

- SMART
- Milestone
- Brainstorming
trend analysis
- Brainwriting
- Card technique - Task force
- 635 method management
- Questionnaires
- Morphological box
- Utility analysis 61

3. Project management phase model

3.2 Concept phase

Concept Planning Realisation Closure

phase phase phase phase

„Tell me how your project starts, and I will tell you how it ends.“
(Gero Lomnitz)

62
3.2 Project charter

Every project begins with the project charter which the client (cl)
assigns to the contractor (co). The client and contractor can also be
employees of the same firm (e.g. client=board and contractor=project
manager).
Project  Requirements 
charter: and 
Agreement  performance 
co:
between cl  specification:  Project 
cl Planning
and co on: co:  Details of: result
and
What? Concept What?
reali‐
How? How?
sation
When? When?

The client and contractor also need to talk again about the project charter
in most cases during the concept and/or realisation phase, specifying or
adapting it where necessary.

Errors in the project charter have enormous long-term effects. A project

charter should therefore be drafted as precisely as possible. 63

3.2 Project charter

Contents of a project charter:

• Project name
• Client
• Initial situation
• Project content, goals and, where available, initial solutions
• Project requirements (e.g. regarding the contractor)
• Project boundaries
• Risks and risk factors already known, and termination scenarios where
appropriate
• Structural organisation, project manager and project team
• Duties, competencies and responsibility of the project manager
• Any project committees and their composition
• Most important deadlines and any milestones
• Probable workload and scheduled budget
• Type and form of results to be delivered
• Legal components such as general terms and conditions (=> claim
management)
64
3.2 Concept phase

If the project charter is granted, the actual project begins with the
concept phase.

The following steps are taken in this context:

Project charter
Understanding the problem
Definition of goals which solve the problems
Looking for solutions which meet the goals
Requirements/performance specification &
go/no go decision

Results of the concept phase include the project goals, solutions,

envisaged are recorded in the requirements and performance
specification. On that base, the management makes the go/no go
decision.
Moreover, feasibility is checked and estimates made of costs and
risks.
65

3.2 Concept phase

The following methods are available for understanding the problem and
identifying goals and solutions:

Problem Solution identification

• 4-What-questions • Brainstorming
• 6-W-questions • Brainwriting
• Ishikawa diagram • Card technique
(if applicable with ABC analysis) • 635 method
• Stakeholder analysis • Questionnaires
• Morphological box
Goal definition
• Utility analysis
• SMART method

„A problem well stated is a problem half-solved.”

(Charles Kettering)
66
3.2 Problem analysis: 4-What-questions

4-What-question method:
The problem should be clarified.

Question Alternative question
Where do I stand?
What is given?
What is my initial state?
Where do I want to go to?
What is needed?
What is my target state?
What options do I have?
What can I do?
What leverage is available?
What is the barrier?
What is stopping me?
What could go wrong?

67

3.2 Problem analysis: 6-W-questions

6-W-question method:
The problem should be clarified and demarcated.

Non‐problem
Question Problem Solution
(for demarcation)
is the problem? (see
What is not the problem?  should the solution achieve?
4‐What‐questions)
does the problem 
hoW is it normally?  should the solution look?
exhibit itself?
is it not a problem
Why is it a problem? is the solution needed?
for others?
is not affected by 
Who reports the problem? could also use the solution?
the problem?
does the problem  does the problem  could the solution also be 
Where
occur? not occur? used?
does the problem does the problem should the solution be
When
occur? not occur? available?

68
3.2 Problem analysis: Ishikawa diagram

All influencing factors are grouped into topics in an Ishikawa diagram

(fishbone diagram) and depicted as arrows.

Moreover, it is possible to allow “prefixed” influencing factors to act on

other influencing factors. This creates a complex tree which can also
contain circles.

Cause 1 Cause 2

Problem

Cause 3 Cause 4

69

3.2 Problem analysis: Ishikawa diagram

Topics can, for example, be determined using the 7 Ms method:

Man Power, Machine, Material, Method, Milieu (environment),
Management, Money.

Method Material Money Machine

Problem

Milieu Management Man Power

70
3.2 Problem analysis: Ishikawa diagram

Example: Ishikawa diagram for fuel consumption in a car

Method Material Money Machine

Tyres Fuel prices Engine
Oil
Perform
Salary ance
Driving Petrol
Usage‐
related fuel
Temperature consumption
Route choice
Season
Driving
Traffic

Milieu Management Man Power

71

3.2 Problem analysis: Ishikawa diagram

The magnitude of dependency or coupling can be illustrated through the

number and thickness of the arrows.

These diagrams are usually very complex. The diagram can also be
broken down into sub-diagrams in this case. Only the most importance
causes and effects should be included in the overview.

The decision on which influencing factors are most important can be

made with the aid of an ABC analysis.

72
3.2 Problem analysis: ABC analysis
All influencing factors are evaluated in the ABC analysis. Here, they are
sorted according to their value, then the values are accumulated, and then
the factors are subdivided into three groups (A, B, C): A factors have a
major, B factors a medium and C factors a minor significance.
Example of an ABC analysis:
Unit price Cumulative Kumulierte
Component Group
per product unit price Wichtigkeit
Microprocessor 80 € 80.0 € 80,0 % A
Circuit board 10 € 90.0 € 90,0 % B
Switch 6 € 96.0 € 96,0 % B
Connector 1 € 97.0 € 97,0 % C
Housing 0.8 € 97.8 € 97,8 % C
Cable 0.6 € 98.4 € 98,4 % C
Small switch 0.6 € 99.0 € 99,0 % C
Sockets 0.5 € 99.5 € 99,5 % C
Logistics 0.4 € 99.9 € 99,9 % C
Insurance 0.1 € 100 € 100 % C 73

3.2 Problem analysis: ABC analysis

The three groups are most frequently depicted according to the Pareto
principle: The most important 20% of factors have 80% of the influence.

Examples:
• Firms generally make 80% of turnover with the most important 20% of
products.
• Equally, 80% of turnover is generated with 20% of customers.
• Similarly, 20% of all families in a country hold 80% of the capital.

The Pareto principle is expanded to 3 groups in the ABC analysis:

Influences and effects are sorted according to their influence (monetary
evaluation), added and subdivided, with A factors accounting for 80%
of the influence, B factors 16% and C factors (the majority in terms of
numbers) the remaining 4%.

74
3.2 Problem analysis: ABC analysis

Cumulative unit price

Components

75

3.2 Problem analysis: ABC analysis

The ABC analysis can also be realised with regard to the strength of the
influence or customer benefits.

Examples:
• What percentage of fuel consumption is each aspect responsible for
(aerodynamics, engine, etc.)!?
• Which features of a product do customers regard as important!?

This allows one to decide in project management which components, etc.

should be prioritised!

76
3.2 Problem analysis: ABC analysis

Example of an ABC analysis of the importance of aspects in the case of

mobile phones:

Component Importance for  Cumulative Group

customers significance
Display 80 % 80.0 % A
Reception 10 % 90.0 % B
Battery life 6 % 96.0 % B
Apps 1 % 97.0 % C
Buttons 0.8 % 97.8 % C
Accessories 0.6 % 98.4 % C
Loudspeaker 0.6 % 99.0 % C
Connector 0.5 % 99.5 % C
Size 0.4 % 99.9 % C
Brand 0.1 % 100 % C

77

3.2 Problem analysis: Stakeholders

Stakeholders are all persons affected by the project, with an interest in

it and/or can exercise influence on it.

Project

78
3.2 Problem analysis: Stakeholders
A stakeholder analysis
1. lists all stakeholders (e.g. via brainwriting),
2. describes their qualitative stakes in the project (particularly with regard
to costs, quality, deadlines) and
3. then checks all with regard to dimensions:

Numerous other dimensions exist in literature (e.g. impact of the project on

someone), but these can be pooled in the above dimensions in most cases.
Impact, for example, results in interest. If no interest is shown, then impact
also does not play a major role.
4. Stakeholders are then classified with the above dimensions on the
basis of diagrams.

79

3.2 Problem analysis: Stakeholders

The influence of the stakeholder is mapped relative to interest in the first

diagram.

Influence
high

S1
S6
S3
S2
Interest /
negative positive attitude
S7
S4
S5 S8
low

Stakeholders can, for example, also be classified in coloured groups in

this context (e.g. company-intern and extern stakeholders, or
indirect/direct influence). Also, further dimensions can be included by the
size of the circles or a ‘+‘ or ‘–‘ in the circle. 80
3.2 Problem analysis: Stakeholders

Stakeholders are integrated into the project and managed differently in

each quadrant.

Influence

high
negative positive Interest /
attitude
low

81

3.2 Problem analysis: Stakeholders

Group A: low influence => preferably disregard (check occasionally).

• Ensure that their influence does not grow.

Group B: low influence => preferably disregard.

• Integrate them actively in the project to preserve their positive sentiment:
keep them in the information flow and ask regularly for their opinion.

Group C: high level of influence and negative sentiment => greatest

problem!
• make concessions in some aspects to change their sentiment from
negative to positive (particularly in the case of very impressionable
stakeholders).
• Alternative: reduce their influence by, for example, excluding them from
the information flow (particularly in the case of unimpressionable SHs).

Group D: use their high degree of influence for the project

 integrate them actively in the project,
• form a coalition to prevent their attitude from becoming negative.
82
3.2 Problem analysis: Stakeholders

Critical stakeholders can also be identified by mapping their

controllability in contrast to their influence. Their interest should be
marked in colour for this purpose.
Controllability

high
0 + +
0 ‐
‐
Influence
low high
‐
+ 0 ‐
0 +
low

Difference between Tasks / Problems:

• easy to control: tasks!
• difficult to control: problem! => High priority!
Latents / Key players: caution, they might be controlled by others as well. 83

3.2 Formulating targets

Once the problem is analyzed, the targets can be formulated.

People are not lazy – usually,

Why do we have to define
there are just no targets!
targets?

84
3.2 Formulating targets
Targets can be formulated when the problem is analysed. These have a
variety of tasks in the project. Accordingly, they should also meet
different requirements.
Task Description Requirement
• Clear
Orientation of all project activities towards 
Orientation • Known (everybody
a desired state.
familiar with goals)
Coordination of all involved and their  • Known
Coordination activities with each other (content, time,  • Accepted
capacity). • Consistent
• Quantified
Decision Decision on alternatives.
• Prioritised
Determining of project progress and  • Complete
Assessment project success based on fulfilment of  • With deadline
objectives. • Current
• Practical
Stimulation of those involved through 
• Positively formulated
Motivation personal challenge and pride in the 
• Challenging
project.
• Feasible 85

3.2 Target classes

Project goals can be subdivided into different classes:

Project goals

Earnings Management Human Implementation

targets goals goals goals
• Function • Process • Customer and • Deadlines
• Performance improvement supplier • Costs
• Quality • Use of satisfaction • Financing
• Defect costs resources • Employee
• Product costs • Development of satisfaction
• Sales know-how • Personnel
• Operating costs development

Marginal conditions Marginal conditions Marginal conditions Marginal conditions

• Standards • Business • Staff • Capacity
• Laws processes • Customers • Know-how
• Patents • Business
• Dev. costs strategy
86
3.2 The project target triangle

The target triangle (“magic triangle”) contains the quality (or

performance), costs and project duration dimensions. The black
triangle, which should have a consistent area at all times, symbolises
the fact that, for example, lower costs lead to lower quality or longer
project durations. However, this is not a method, but merely a depiction of
correlations. Therefore, these should be harmonised when determining
targets.

(higher) (higher)
quality quality

(lower) (shorter) project (lower) (shorter) project

costs durations costs durations
87

3.2 Target defining steps

Weighting of targets

Quantifying of targets

Analysis of target
relationships

Search for target

ideas

88
3.2 Formulating targets

Project goals (= targets) can be formulated initially as ideal goals,

meaning without consideration of restrictions (limited resources). These
can be transformed into real goals by adding restrictions.

Ideal goals can continue to aid orientation (e.g. by scrutinising (alleged)

restrictions).

Example:
Ideal target: We offer 24-hour customer service.
Real target: We offer customer service from 8 a.m. – 10 p.m..

It is frequently no longer clear at a later stage which restrictions resulted

in fixing the time from 8 a.m. – 10 p.m. Was it a question of costs or the
availability of personnel?
Therefore, the reasons for such decisions should also be recorded
(=> decision database).

89

3.2 Formulating targets

Example: Targets of a bicycle navigation system

1. Market leadership in bicycle navigation systems

2. Preferably compact unit with a large display
3. Robust design
4. Ergonomic user interface
5. Introduction on the market before the end of the year
6. Strict financial limit
7. Low cost product How do you rate
8. With USB-interface these targets?
9. Preferably with Wifi

90
3.2 Formulating targets

Verifiable criteria always need a variable and a verifiable value

(= criterion).

In this context, there are:

• fixed marginal conditions which must be adhered to. There
observance indicates whether the project goal has been achieved.
• softer quality criteria which maximise the problem solution. They
indicate the quality of the problem solution.

91

3.2 Formulating targets

Example: Favourable targets of a bicycle navigation system

Marginal 
Target Variable Quality criterion
condition
1. Market leadership Market share > 30% As high as possible
2a. Compact design Housing volume < 200 cm³ As low as possible
2b. Large display Display (diagonal) 10 cm < d < 12 cm As high as possible
3. Robust design Drop height > 2 metres As high as possible
4. Ergonomics One‐off training < 30 minutes As low as possible
4. Ergonomics Function access time < 1 second As low as possible
Rapid market 
5. Project duration 8 months As low as possible
maturity
6. Low R&D costs Project budget 250,000 € As low as possible
7. Low unit price Production costs < 30 € As low as possible
8. USB interface available yes ‐
9. Wifi interface available ‐ yes

92
3.2 Formulating targets: SMART

Systematic formulation of criteria is possible with the SMART method

and their examination for suitability. The following table illustrates the 5
associate criteria and the respective opposites which are used too
frequently.

Criterion Characteristic Opposite

Clearly defined, comprehensible, precise, 
Specific concrete, understandable, action‐oriented,  Vague and general
but “solution‐neutral”.
With qualitatively and quantitatively Non‐verifiable, 
Measurable
measurable criteria for target achievement. interpretable
Positively and actively formulated, 
Assignable motivating, action‐oriented, ambitious, The word “avoidance”.
challenging.
Achievable, realizable, can be influenced, 
Realistic Unachievable
broken into sub‐targets where appropriate.
Time‐ Fixed, latest target achievement time,  Open‐ended, as soon as
related suitable as milestone. possible
93

3.2 Formulating targets: SMART

Example of target criteria with the SMART method:

Initial situation: “We don’t want to sell any more poor quality navigation
systems”.
The formulation is unattractive, vague and not measureable.

Criterion Characteristic
Specific Durability at least 10 years
Measurable Customer satisfaction > 95 %
Assignable We want to develop and sell high quality bicycle navigation systems
Realistic Customer satisfaction > 90 %
Time‐related Achievement of customer satisfaction > 90 % within 18 months

Result:
We wish to increase the quality of our bicycle navigation systems so
that they last more than 10 years and we achieve a customer
satisfaction of 90 % within 18 months.
94
3.2 Solution identification: Brainstorming

The object of brainstorming (using the brain to storm a problem) is to

generate as many solution options as possible for a given problem or
achievement of targets. The expert group present during this is familiar
with the problem and targets. Each can contribute an idea for a solution in
brief, as well as taking up other ideas and developing them further.
However, the ideas may at least initially not be evaluated or criticised. A
moderator chairs the group and records the ideas.
Advantages:

Disadvantages:

Solutions:
95

3.2 Solution identification:

Brainwriting and card technique

Brainwriting functions in exactly the same manner as brainstorming,

except all group members note their ideas in advance for themselves.
This prevents ideas being lost if the discussion turns towards a specific
solution.

The card technique (= metaplan technique) represents an additional

tool, with all group members noting their individual ideas on a card.
These are collected anonymously and affixed to a board. Similar ideas
are placed in groups. The ideas are discussed subsequently, and they
can also be evaluated by the group.

96
3.2 Solution identification: 635 method

The 635 method involves a meeting of 6 participants. Each notes 3

ideas on a sheet and has 5 minutes to do this. The sheets are then
passed to the respective neighbour. He or she then develops the ideas
found further by, for example, generalising them, specialising them or
combining them with his or her own ideas.
The ideas are discussed subsequently in the group.

Advantages:

Disadvantages :

Miscellaneous:

97

3.2 Solution identification: questionnaires

A problem can be examined systematically from all sides with the aid of
questionnaires such as SCAMPER, SCAMMPERR and the Osborne
checklist.
Method Can I solve my problem by … Example
replacing  replacing a  replacing part of 
Substitute components,  subordinate  an existing 
materials or people? problem? solution?
combining 
combining functions  combining it with 
Combine several existing 
or aggregates? other problems?
solutions?
adapting 
adapting functions of  functions from  adapting 
Adapt
another component another device  solutions from 
(possibly modified)? (possibly  other devices?
modified).
enlarging or 
enlarging or reducing  enlarging or 
reducing an 
Magnify components or  reducing the 
existing 
functions? problem?
solution?
98
3.2 Solution identification: questionnaires

Method Can I solve my problem by … Example

modifying the design,  modifying an 
modifying
Modify colour, haptic,  existing 
functions?
acoustics, etc.? solution?

transfering it
Put (“Put to  finding other uses or 
theoretically to
another use”) applications?
another area?

removing elements or  reducing it to the

Eliminate simplifying it?
components? core functions?

changing its internal  changing the 

organisation, changing  configuration of 
Rearrange
sequence or components? an existing 
processes? solution?

standing it on its finding a 

Reverse turning it inside out?
head? contrary use?

99

3.2 Solution identification: morphological box

Many problems/solutions are so complex that they need to be broken

down into numerous partial problems/partial solutions.

As not every partial solution can be combined with another, they are
represented separately with the aid of a morphological box.

Possible partial solutions in each case are linked together with lines.

In most cases, those of the available solutions which promise the highest
benefit are selected. Naturally enough, risks (=> risk analysis) and
investments need to be taken into consideration in this respect.

A unique morphological box can also be created for each component in

the case of complex products. The partial solutions are then combined
with each other in a superordinate morphological box.

100
3.2 Solution identification: morphological box

Characteristic / Solution variants / Costs

Target
cheap expensive

Market share 40 % 30 % 20 %

Unit price 25 € 30 € 50 €

Display 10 cm 11 cm 12 cm

Function
1 s 0,7 s 0,5 s
access time

USB interface No Yes

Wifi interface No Yes

Solution: A B C D
101

3.2 Solution identification: utility analysis

The “best” combination can be found through utility analysis. Several
criteria are defined for the extent of target achievement and weighed up
in this context. Combinations are evaluated with these.
Solution Solution A  Solution  Solution B 
Criterion Weighting Points system
A weighted B weighted
40 %: 10 points
Market
60% 30 %: 8 points 10 6.0 8 4.8
share
20 %: 3 points
12 cm:10 points
Display 30% 11 cm: 7 points 7 2.1 7 2.1
10 cm: 5 points
USB Yes: 10 points
10% 0 0 10 1
interface No: 0 points
Total 100 % 17 8.1 25 7.9

Instead of a points system, each criterion is evaluated monetarily during

a feasibility analysis. Generally speaking, the benefit must also be
considered in every case! 102
3.2 Solution identification

Comparison of methods

Number of 
Method Difficulty Effort/Outlay
people
Brainstorming 3 ‐ 12 Simple Low
Brainwriting 3 ‐ 12 Simple Low
Card technique 3 ‐ 12 Simple Low
635 method ~ 6 Simple Low
SCAMMPERR 1 – (numerous) Medium ‐ High High
Morphological box 1 – (numerous) Medium ‐ High High
Utility analysis 1 – (numerous) Medium ‐ High High

103

3.2 Requirements & performance specification

When the problem is understood, the goal defined and possible solutions
identified, the requirements specification is written on this basis.

The client specifies the scope of the project from his point of view in the
requirements specification (i.e. the totality of claims relating to the
contractor’s goods and services). It represents a detailing of the project
charter, so to speak. Previously defined targets and solutions are
assimilated herein.

The contractor specifies the scope of performance from his point of view
in the performance specification (i.e. the totality of deliveries and
services which he pledges to realise).

Comprehensive requirements and performance specifications are compiled

for projects in the case of external allocations in particular.

The performance specification is the technical part of an offer that

describes also the commercial issues, especially costs and terms of
delivery. 104
3.2 Requirements & performance specification

Tender
Requirements spec.

Offer
Client Performance spec. Contractor

Award of contract

Acceptance of order

As the requirements and performance specifications should ultimately corres-

pond to each other, several coordination iterations are frequently run through.
Amendments in the requirements specification are then marked in colour.
In the event of submission of several offers by several contractors for the
same project (tender), the different performance specifications should also
correspond to each other after several iterations. 105

3.2 Requirements & performance specification

The requirements and performance specification should ultimately

correspond to each other. They can also be compiled together, combined
in a single document and signed by both parties.

In the case of good requirements specifications, the performance

specification can be compiled as a delta specification (i.e. the contractor
only enters those items which the requirements specification contradicts).
Greater transparency is achieved for the client as a result, particular in the
case of comprehensive specifications or offers from several bidders.

Example:
Requirements specification: The housing should be fitted with a black
connector with round connections and a delta pin configuration.
Performance specification: The housing is fitted with the connector
pursuant to the requirements specification. Difference: Plug is red.

106
3.2 Requirements & performance specification

Requirements and performance specifications should be compiled as

accurately as possible to avoid later problems.

Formal requirements:

107

3.2 Requirements & performance specification

The requirements and performance specification can, for example, be

compiled on the basis of the VDI model or project-oriented:
Pursuant to VDI 2519
1. Introduction to the project
2. Description of initial situation (actual state)
3. Task (target state)
4. Interfaces
5. System engineering requirements.
6. Commissioning and operating requirements
7. Quality requirement
8. Project management requirements.
9. System engineering solutions (performance specification)
10.System engineering (characteristics) (performance
specification)

108
3.2 Requirements & performance specification

The requirements and performance specification can, for example, be

compiled on the basis of the VDI model or project-oriented:
Project-oriented
1. Initial situation: Why the need for a project?
2. Objective pursuant to SMART criteria
3. Product use: What should the product do, and under which
general conditions?
4. Functional requirements: Which specific functions should the
product offer?
5. Non-functional requirements: Which requirements should be met
above and beyond this (e.g. efficiency, expandability, reliability,
etc.)
6. Scope of delivery
7. Project phase planning and milestones
8. Unresolved items still to be clarified
9. Acceptance criteria and quality requirements
109

3.2 Requirements & performance specification

The more comprehensive the calculation of costs, the more complex and
expensive it is. Conversely, costs can be estimated with greater
accuracy, thus reducing the project risk.

Optimistic (Unknown)  Pessimistic 

estimation true value estimation
Low
effort
High risk No risk
Secure order No order

Exact calculation 
High value
effort Moderate risk
Uncertain order

Experience from earlier projects should be carefully recorded to enable

efficient estimation of costs. Also, a qualitatively good offer leaves a good
impression. 110
3.2 Project organigram

As effort and outlay estimations are often extremely complex, technical

departments are mainly consulted here and the first (potential) project
staff and the project manager determined during this. The cornerstones
of the project organigram to be compiled later are determined as a
consequence.

It is particularly important here to also clarify the organisation form in

order to define the authority of the project manager (including technically
or only coordination / purely organisation) with his or her duties,
competencies and responsibilities (see section 3.3).

111

3. Project management phase model

3.3 Planning phase

Concept Planning Realisation Closure

phase phase phase phase

“If I had 8 hours to chop down a tree,

I’d spend 6 of those hours sharpening my axe.”
(Abraham Lincoln)

112
3.3 Project planning

The project is prepared for realisation in the planning phase. All

important decision for the project procedure are taken during the
realisation phase in this connection.

Results and procedures of the planning phase:

Product structure plan (What is being made; product components)
Project structure plan (How is it subdivided; sub-projects and WPs)
Project organigram (Who does what)
Milestone schedule (When is it done)
Budget plan (When is how much paid)

Each module provides the basis for the next in this context!

113

3.3 Product structure plan (parts list)

A product structure plan (= parts list) is compiled (in coordination with

technical experts where appropriate). This is a hierarchically divided list
of all parts in a product (i.e. the product is broken down into its
components).

Product
Vertical structuring

Product part A Product part B Product part C

A1 A2 A3 B1 B2 B3 B4 C1 C2 C3

Horizontal structuring

114
3.3 Product structure plan (parts list)

In addition to all the components of the product, a product structure

plan also contains information on its assembly. It therefore represents a
construction plan for the product to be developed.

In addition, it contains information including details of the documentation

to be delivered at the end of the project. Equally, intermediate products
such as prototypes can be recorded, or machines which are required to
manufacture the products or prototypes.

115

3.3 Product structure plan (parts list)

As many components have similar designations such as “electronic

component”, “housing” or “holder”, every part must be assigned an
identification number.

The following options are available for this purpose:

• 219.213.012.069, 219.213.012.013, …
• 0001, 0002, 0003, …
• III.A.25, IV.B.26, ….

The best overview is obtained if individual numbers are separated by dots,

do not contain any Roman numerals or letters and are assigned according
to a specific system or even have a meaning (Example: 219 at the front is
the product number).

116
3.3 Product structure plan (parts list)

Example of a parts list:

Vertical structuring
Horizontal structuring

117

3.3 Product structure plan (parts list)

Procedure for compiling a product structure plan.

The intuitive pro-

cedure is the top-
down approach.
The product is first
dismantled into
several main com-
ponents during this,
with these in turn
being dismantled
into even smaller
sub-components,
etc.
However, the main components of a product are not always immediately
evident, so the bottom-up approach is adopted. One begins with a
collection of elementary parts here or, for example, product interfaces
and groups these according to their commonalities. These commonalities
are then the main components (to give an example). 118
3.3 Project structure plan

At least in the case of technical projects, the product structure plan (parts
list) leads to the project structure plan. This is a hierarchically divided
plan of all sub-projects and work packages.

Project

Sub-project Sub-project Sub-project

WP SP WP WP WP SP SP

WP WP WP WP WP WP

119

3.3 Project structure plan

The compilation effort is justified by the solid basis created for further
steps such as the project organigram, scheduling and budgeting.

Requirements:
• Completeness
• Overall consideration (not tasks on their own, but in the overall
context).

A project structure plan is often developed during the submission of an

offer. A rough plan with which project costs can be estimated with
adequate accuracy is enough in this case.

Each part of a project plan is compiled by a responsible sub-project

manager in most cases.

120
3.3 Project structure plan

The project structure plan branches in a tree-like structure over several

levels until the individual work packages (WP) are reached. 6 branching
options are available here at each hierarchical level:

121

3.3 Project structure plan

It is advisable to exhaust one structuring option before beginning with the

next, rather than using the options in a confused manner.

A project structure plan very quickly becomes very elaborate and

complex. Only the uppermost hierarchical levels should be depicted as a
tree for this reason. Detailed planning is either realised in the form of a
list (e.g. using Excel) or with appropriate project management software
(e.g. MS Project, ProjectLibre, Visio).

122
3.3 Project planning: Project organigram

If the project structure plan is compiled, the project organigram can be

created from this to determine the project staff and their duties,
competencies and responsibilities.
Here, a name must be assigned to every task.

PM
Name / Dept.
PMS
Name / Dept.

Sales Compliance Purchasing Controlling Design

Name / Dept. Name / Dept. Name / Dept. Name / Dept. Name / Dept.

Legal Development Quality IT Logistics

Name / Dept. Name / Dept. Name / Dept. Name / Dept. Name / Dept.

123

3.3 Project planning: Duties, competencies

and responsibilities and RASI charts

Typical duties, competencies and responsibilities of the project

manager

Duties:
• Formation of a project team with regard to technical and personal qualification
• Leadership of the project team
• Delegation of tasks
• Checking handling of delegated tasks
• Holistic and comprehensive analysis, evaluation and development of product
solutions for the project scope ordered in the context of prescribed priorities /
periods.
• Compiling of project reports and decision papers including decision
recommendation for top management / the client (taking all necessary/agreed
functional areas into consideration)
• Presentation of decision papers
• Development of solution proposals in case of need for action
• Taking on critical tasks (e.g. negotiations with suppliers)
• Change management

124
3.3 Project planning: Duties, competencies
and responsibilities and RASI charts

Typical duties, competencies and responsibilities of the project

manager

Competence:
• Ability to head project meetings
• Basic knowledge of all sub-sections
• Process know-how for handling delegated topics and cooperation with the
committees
• Decision-making authority

Responsibility:
• Representation of project issues in relation to the client
• Illustration of issues currently being tackled with regard to status, utilisation of
capacity and content, regularly and in case of conflict
• Achievement of transparency with regard to costs, achieving target costs,
deadlines and quality. Transparent depiction of change content and scope
(technical and commercial)
• Compilation of decision-making drafts
• Processing of delegated duties true to deadline
• Clarification of compliance conformity 125

3.3 Project planning: Duties, competencies

and responsibilities and RASI charts
Exactly one responsible person must be appointed for each task or
work package (topic-oriented project steering, or TOPS). However,
other people also continue to work on the WP. This division of tasks and
labour is illustrated through a RASI chart.

The individual letters stand for:

• R: Responsible
• A: Approval (e.g. the client)
• S: Support (e.g. with technical expertise)
• I : Informed

In addition, further letters are also used, including C (confirmed),

C (consulted), V (verifying) and A (accountable). As some characters
are not unambiguous, the explanation should in all cases be included in
the chart.

126
3.3 Project planning: Duties, competencies
and responsibilities and RASI charts
Example: Excerpt from a RASI chart for the further development of a
Nissan engine for use in a Daimler vehicle. Development by a service
provider.
R: Responsible, A: Approval, S: Support, I: Informed
Task / Sub‐project Daimler Service provider Nissan
Project management S R S
Development of basic engine I I R
Development of adapted engine S/A R S/A
Validation of basic engine I I R
Validation of adapted engine S/A R S/A
Purchase of engine parts I I R
Software A S R
Calibration A R S/A
Quality approval R S I

127

3.3 Scheduling

Scheduling can be realised if the work packages and respective

responsibilities have been clarified. In most cases, the project manager
draws on his or her experience to draft a rough schedule with the most
important milestones. This is distributed to the respective sub-project
managers. The schedule is then fixed in a collective meeting. Sub-project
managers complete their detailed planning pursuant to the superordinate
milestones.

The schedule is depicted using an appropriate method, depending on the

size and complexity of the project:
• Timetable: Low complexity
• Bar chart: Medium complexity, greater effort, more transparency
• Precedence
High complexity, enormous effort, for detailed planning
diagram:

In the case of small projects with few tasks and fewer people involved,
a timetable can created with Excel. In particular, target dates
(milestones) should be entered here! 128
3.3 Scheduling: Gantt chart

Scheduling is mainly illustrated as a bar chart (Gantt chart) using

suitable software. This provides a high degree of clarity and involves a
manageable effort.

The project structure plan with the work packages is shown vertically, the
time is shown horizontally.

The effort (duration) required for each work package needs to be

estimated in this context. Furthermore, correlations between the work
packages should be taken into consideration.
129

3.3 Scheduling: Gantt chart

4 options exist for the correlation between two procedures:

Dependency Sequence type Relationship between 2 procedures

A Finish to Start  Normal 
B begins when A ends
B (FS) sequence

A Both procedures should start 
Start to Start (SS) Start sequence
B simultaneously

A Finish to Finish  Finish  Both procedures should finish 

B (FF) sequence simultaneously

A Start to Finish  B must finish when A begins 
Jump sequence
B (SF) (calculated backwards)

The first WP has no predecessor and the last no successor.

All other work packages have at least predecessor and one successor.
The dependency most frequently used is the normal sequence.

130
3.3 Example: automobile master schedule

Usually, schedules feature the corresponding milestones or other

important information. The project manager frequently only compiles a
rough overview with the mist important milestones. Sub-project and
work package managers then compile their detailed planning on this
basis to achieve the superordinate milestones.

Project Master
2017 2018 2019 2020
1 2 3 4 1 2 3 4 1 2 3 4 1

2 3

Development A B C

Prototypes A B C

Testing A B C

Registrations
131

3.3 Scheduling
As the numerous procedures start simultaneously...

…scheduling results in capacity utilisation pursuant to the following

diagram:

132
3.3 Scheduling
The solution consists of 2 parts:

Buffer

Use of the buffer to stagger two work packages results in a more even
capacity utilisation.

133

3.3 Scheduling: Precedence diagram

Buffer times are in most cases not easy to calculate, and a precedence
diagram needs to be used instead of a bar chart. The earliest and latest
start and finish deadlines can thus be calculated for each procedure from
mutual dependencies. This is mainly only employed for critical sub-
projects.
Gearshift Parts list Components
designed compiled ordered
2 10 12 12 2 14 14 14 28
2 0 12 12 0 14 14 0 28

Development Housing Housing

order prepared designed constructed
0 2 2 2 20 22 28 35 63
0 0 2 8 6 28 28 0 63

Description of procedure

Earliest possible start /d Duration /d Earliest possible finish /d

Latest possible start /d Buffer /d Latest possible finish /d
134
3.3 Scheduling

Exploitation of all buffer times generally results in a more even capacity

utilisation within a project.
Effort

Realisation

Planning
Closure
Concept Time

Were projects are realised in parallel, but staggered in time, a uniform

usage rate is achieved for the company.
Overall usage rate for company
Effort

Time 135

3.3 Scheduling: Costs

Where scheduling is completed, the effort/outlay for each work package

can be estimated. As the respective duration and persons involved are
already known, personnel costs can be estimated from these.

Added to these are overheads (HR department, building, etc) which are
transferred as a flat rate to personnel costs and the costs of machinery
and material.

This also enables the insertion of “milestones” for payments in the

schedule, provided an externally awarded project is involved.

136
3.3 Schedule: Workload
The cumulative outlay indicates that the greatest effort occurs in the
planning and realisation phase.

K4 K3
Cumulative outlay
K1 K2 Realisation

Planning
Closure
Concept Time

Problem for the contractor:

Problem for the client:

137

3. Project management phase model

3.4 Realisation phase

Concept Planning Realisation Closure

phase phase phase phase

Why do we make a plan?

So that we‘ve got something we can change!

138
3.4 Realisation phase

Previously planned work packages should be processed in the

realisation phase.
The realisation phase should always start with a kick-off event.

This involves:

The main task of project management in the realisation phase is

• the coordination of different sub-projects and
• to react appropriately to deviations from the plan, thus managing
the project so that the defined project goal is ultimately achieved.

139

3.4 Realisation phase

This project management is also known as project controlling. The

term project controlling is frequently only used in relation to cost
controlling in a project, but it really means project steering (a game is
steered with a Playstation controller).

Important project controlling instruments are established for this purpose:

• Committees / project meetings and
• Milestone tests.

Committees are project meetings held regularly in which all relevant

issues are discussed and different employees are coordinated.
Respective employees report from their particular topical field or area of
responsibility in this respect, and further tasks are assigned.

140
3.4 Committee management

Different committees meet as early as the concept and planning phase.

These grow enormously in importance at the beginning of the realisation
phase, as the project is almost completely controlled through these. A
possible project organisation for a larger project is illustrated below:

Steering committee
Management: Overall project manager
Participants: Client, contractor, dept. managers
Frequency: E.g. monthly or after MS tests

report selected topics and project progress (project report)

Project manager meeting Milestone tests

Management: Overall project manager Management: Overall project manager
Participants: Sub-project managers Participants: Sub-project managers
Frequency: Weekly Frequency: At milestones

report selected topics report project progress (status report)

Sub-project committees
Management: Sub-project managers
Participants: Sub-project members
Frequency: Weekly
Component 1 Component 2 Technical group
141

3.4 Committee management

Operative work is realised at the sub-project manager and associated

committee level. Committees exist here for individual product
components and topical areas, depending on the structuring and size
of the project. Representatives of all contingents take part in these
(i.e. development, sales, legal department, etc.)

Committees can also be set up for sales or, for example, the legal
department.

If committees exist with different subdivisions, a double structure is

achieved with sub-project managers of product components or topical
areas and project managers from technical departments

The heads of all these committees (=sub-project managers) report on

current issues and respective project progress in the project manager
meeting which should also be held weekly. The project manager
meeting also aids coordination and synchronisation of the different sub-
projects.
142
3.4 Committee management

Tests at the most important milestones are possible approximately every

2 months, depending on the project length. Naturally enough, milestones
should be planned accordingly. A status report on each sub-project
should be compiled in this respect.

The highest committee is a steering committee in which the overall

project managers report to the client, contractor management and, where
applicable, any involved department heads. A comprehensive project
report should be compiled in each case for this purpose.

Pioneering project decisions are also madein this committee.

In small projects without sub-projects, the project manager meeting can

be dispensed with and sub-project committees reduced to a project
committee.

In any event, committees should meet regularly and not only “when
needed”.
143

3.4 Committee management

The committee landscape can be simplified greatly in the case of small

projects. A possible committee structure for a small project (up to 10
project staff) is illustrated below.

Steering committee
Management: Overall project managers
Participants: Client, contractor, dept. managers
Frequency: E.g. monthly or after MS tests

report selected topics and project progress (project report)

Project committee Milestone tests

Management: Overall project managers Management: Overall project managers
Participants: All project staff Participants: All project staff
Frequency: Weekly Frequency: At milestones

144
 3.4 Cooperation in projects

In a cooperative project, team members are usually working together

with employees at the same hierarchy level.

Contractor Client
Steering committee

Report / controlling Report / controlling

PM PM
Cooperation

Report / controlling Report / controlling

Project team Project team

Cooperation

145

3.4 To-do list

The most important element of any committee is the to-do list. It contains
all information and issues collected during a regular meeting.
Example: Development of an automatic gearbox
Respon‐ Partici‐ Target  Actual Comment 
ID Date Cluster Topic TID Description Status
sibility pants date date / Result
B sample
successfully 
001 03.02.14 Solenoid Test results I Meier ‐ ‐ 01.02.14 Done ‐
passed testing in 
the gearbox
Compare rattling
Vehicle between 
Overall 
002 03.02.14 measure‐ T conspicuous/  König Müller 17.02.14 Open
system
ments inconspicuous
vehicle
10.02.14: 
Realisation EMC  Electronics
measurement  has passed
003 03.02.14 Electronics EMC T Jex ‐ 10.02.14 10.02.14 Done
with Type “C”  EMC 
component measure‐
ment
Type “C” 
Schmidt 
004 03.02.14 Electronics Version D component is  Jex ‐ ‐ Done ‐
(PM)
used   

146
3.4 To-do list

Each line of the to-do list should contain the following information:

• Sequential number
• Recording date of topic
• Topic cluster for sorting where appropriate
• Topic (short title)
• Category (TID)
• Description of topic and information, measure or decision
• Responsible person
• People involved
• Target date (if planned)
• Actual date (if done)
• Status in case of measures: unresolved, done or due
• Additional comment or result if measure is completed

147

3.4 To-do list

The contents of the list are subdivided into 3 categories:

• I: Information: If only one item of information is distributed among all
involved in the project.
Example: Mr Müller from Logistics reports that the missing
parts have arrived.

• T: Tasks: for all tasks assigned on the basis of available information.

Example: Mr Schmidt from Logistics is checking when the new
parts should arrive!

• D: Decisions: For all decisions taken in the project meeting.

Example: Mr Meier from Development reports that both a round
and flat connector can be used. Decision: The round connector
will be used!

148
3.4 To-do list
In general, the following applies:
• The respective sub-project manager or his PMS manages the list
• There should only be one list per committee.
• Equally, each committee has a dedicated list.
• In the case of critical topics, the list can be shown to everyone again at
the end of the meeting (via a projector).
• No drawings, etc. are added to the list. However, hyperlinks to files can
be added where appropriate.
• The list is mainly forwarded as a report. It is regarded as accepted if
nobody complains.
• Insofar as no clocked meeting is held in which employees can only join
the discussion to contribute their topics at specific times, the to-do list
can be used as an invitation.
• The to-do list is not sent continuously backwards and forwards so that
everybody can add something (=> version conflict).
• A new weekly version can, however, be filed at a sharepoint so that team
members can enter their items and results in advance of the meeting.
149

3.4 To-do list

Important fields on the to-do list frequently contain “conditional

formatting”. This colours the important field red or green, indicating
immediately which deadlines have been exceeded.

Topics which have been dealt with are usually masked out with the drop-
down menu.

150
3.4 Status reports

Initial deviations from planning are recorded with the to-do list, enabling a
reaction to these if necessary. In addition, status reports on all sub-
projects should be compiled and presented at the milestone tests. These
are compared with the milestones.

To improve the comparability of sub-projects, a binding template

should be compiled by project management for status reports by closure
of the planning phase at the latest.

Each status report should contain at least information on the current

status incl. deadline, the level of progress and quality achieved and
the budget already used and that which is probably still needed.

All costs accrued are booked to the respective sub-project with the aid of
a computer. Consequently, a data evaluation automatically provides
information on the current state of the budget.
151

3.4 Status reports

Use of a traffic light system contributes to more clarity:

green = on target
yellow = not on target, but can still be achieved with measures
red = the plan can no longer be adhered to

Steering committee

Milestone
test

Sub-
projects

Each topic occasionally gets several lights (one for costs, one for
resources, one for deadlines, etc.)
152
3.4 Status reports

Yellow and red topics diminish in most cases as the project progresses,
with the green topics increasing.

100 % MS 2 MS 3
Green and
'done' topics

Yellow topics
Red topics

A rule applies at all times when defining the project status that requires
a sub-project or work package to be either 0% or 100% completed. No
values in between are used. Work packages should therefore be
selected to be small enough.

153

3.4 Project reports

The project control group is kept informed of the project progress
through project reports. In general, the following applies: The control
group learns little about a lot of topics, whereas the technical department
learns a lot about a few topics! Reports should be at all times kept as
short as possible, but as comprehensive as necessary.
Topics for project reports are: performance, deadlines, costs and risks with
countermeasures!
Because: „It‘s no drama if the project is not within the plan, it‘s a drama if
the project manager doesn‘t know about it.“ (Peter Hobbs)

154
3.4 Project control

In the event of deviations from planning becoming apparent at

milestone tests or in committees, project management should react to
these through appropriate interventions. It may be necessary to correct
the original plan.

The target triangle for projects with quality (or performance), costs and
project duration dimensions applies again as an orientation aid.

(higher) (higher)
quality quality

(lower) (shorter) project (lower) (shorter) project

costs durations costs durations
155

3.4 Project control

It is possible to react according to priority in the event of a deviation:

Priority Possible reactions

Quality priority

Cost priority

Deadline priority

156
3.4 Project control

Implementation options for different reactions:

Reaction Implementation options

Increase capacity

Increase productivity

Reduce quality /
Simplify functions

157

3.4 Project control

Typical indications of problems in a project:

158
3.4 Milestone trend analysis
A milestone trend analysis (MTA) involves determination of project
progress at regular intervals (measurement times, e.g. at milestones). An
estimation is also made in this context to ascertain whether the continued
project procedure can be maintained. This estimation is plotted graphically:
Measurement times Measurement times
MS1 MS2 MS 3 MS4 MS1 MS2 MS3 MS4

Planned
Planned

t1 t2 t 3 t4 t5 t6 t 7 t 8 t9 t10t11t12 t1 t2 t 3 t4 t5 t6 t 7 t 8 t9 t10t11t12

time
time

MS4 MS4
Project time Project time

Milestones
Milestones

MS3 MS3

MS2 MS2

MS1 MS1

159

3.4 Milestone trend analysis

Measurement times Measurement times

MS1 MS2 MS3 MS4 MS1 MS2 MS3 MS4
Planned
Planned

t1 t2 t 3 t4 t5 t6 t 7 t 8 t9 t10t11t12 t1 t2 t 3 t4 t5 t6 t 7 t 8 t9 t10t11t12
time
time

MS4 MS4
Project time Project time
Milestones
Milestones

MS3 MS3

MS2 MS2

MS1 MS1

160
3.4 Milestone trend analysis

Measurement times Measurement times

MS1 MS2 MS3 MS4 MS1 MS2 MS3 MS4

Planned
Planned

t1 t2 t 3 t4 t5 t6 t 7 t 8 t9 t10t11t12 t1 t2 t 3 t4 t5 t6 t 7 t 8 t9 t10t11t12

time
time

MS4 MS4
Project time Project time

Milestones
Milestones

MS3 MS3

MS2 MS2

MS1 MS1

161

3.4 Milestone trend analysis

Measurement times Measurement times

MS1 MS2 MS3 MS4 MS1 MS2 MS3 MS4
Planned
Planned

t1 t2 t 3 t4 t5 t6 t 7 t 8 t9 t10t11t12 t1 t2 t 3 t4 t5 t6 t 7 t 8 t9 t10t11t12
time
time

MS4 MS4
Project time Project time
Milestones
Milestones

MS3 MS3

MS2 MS2

MS1 MS1

162
3.4 Task force management

A task force can be set up if a massive problem arises in a project or

sub-project (mainly deadlines which are not observed or technical
problems). This involves a committee dedicated exclusively to solving
this problem.

A task force differs from a normal project committee with regard to the
following:
• Higher management attention (possibly a weekly report to
management)
• Possible leadership through a manager with greater decision-making
competence
• Access to personnel and resources with higher priority
• Frequently organised as a project house

163

3. Project management phase model

3.5 Closure phase

Concept Planning Realisation Closure

phase phase phase phase

It's not over until the fat lady sings.

164
3.5 Closure phase - Project closure

Project closure is realised when the clearly defined project goal is

achieved. The intensity of work reduces again during this phase.

Activities in the closure phase:

Holding of a final project meeting
Compilation of a final report
Holding of a final meeting with the client
Securing of knowledge gained for future projects
Archiving of all documents created

During this phase (and probably already during the realisation phase),
the project team is disbanded successively and the personnel given
new assignments (e.g. return to the line or a new project).

165

3.5 Closure phase - Project closure

The project team meets for the last time during the final project meeting.
Contents of the final project meeting

166
3.5 Closure phase - Project closure

Securing of knowledge is an important aspect of the project closure. All

experience gained is still very fresh, so the lessons learned and best
practices (methods which have proven their value) should be recorded
immediately (and not later) and incorporated into future projects.

All knowledge gained can, for example, be added to the company-intern

project management manual. Use of project staff on new projects also
helps to secure knowledge.

167

3.5 Closure phase - Project closure

Knowledge gained in the final project meeting is also recorded in the

final report.

Contents of the final report

• Project goals
• Planning documents
• Actual documents (latest status)
• Final analysis incl. costs (in the form of a an examination to
ascertain whether targets were adhered to and specification of
deviations)
• Lessons learned

If applicable, two different report will be compiled. One for internal

use and lessonds learned, one for the client.

168
3.5 Closure phase - Project closure

A final meeting is also held subsequently with the client. The client
accepts the results of the project on the basis of this final client meeting
and the final report.

The client checks the following in this context:

• Whether the results are complete
• Whether all targets have been achieved, particularly:
• whether the desired quality was achieved
• whether deadlines were adhered to
• and, where appropriate, if the budget was observed.

This acceptance should be recorded so that each party can protect itself
against any subsequent claims. Successful acceptance means the last
payments are due, and the warranty period and limitation period for
claims begin.

169

3.5 Closure phase - Project closure

The project results need not be accepted if goals have not been
achieved. The contractor has an obligation to remedy or replace any
defects in this case. The client is entitled to delay payment accordingly.
Different points of view frequently come to the surface here. For this
reason, the acceptance criteria should be already clearly defined in the
requirements /performance specification at the beginning of the project.

A project frequently continues following project closure (e.g. in the form

of series production support). In this case, the actual project (i.e. the
development) is concluded in its totality, and all unresolved issues,
documents, etc. are transfered to series.

170
3.5 Closure phase - Project closure

Problems in the closure phase

• Employees do not wish to return to line work and tend to delay work
towards the end of the project.
• Nobody wants to be the last person in the project and have to take
care of unpleasant residual work or be made responsible at the end
for problems in the project. Many employees leave the project too
early for this reason.
• The project is not concluded cleanly, but rather peters out at the end.
The closure should therefore also be planned in advance.

As part of project closure, and in

particular in relation to projects with
a longer duration, a leisure
event can be held for personnel. This
can also act as a team building event
at the start of the project.
171

3.5 Project success

The most important success factors for achieving the goals of a

project are:
• Unambiguous goals
• Support from top management
• Good relations between those involved
• Qualified personnel
• Continuous monitoring and control
• Troubleshooting / Change-Management
• Information provision
• Organisation adjusted to the project
• Good risk management
• Project members contributing to the
milestone planning
• Authorization of the project manager
• Project manager‘s knowledge on project
management 172
3.5 Project success

A project is considered to be successfully concluded if project goals have

been achieved. However, a project can still fail subsequently if, for
example, the product does not sell or newly introduced processes are not
as efficient as planned.

For this reason, the ultimate level of

sales of the product should also be Success is not always visible
examined subsequent to the project, at first glance!
along with the efficiency of new
processes, etc. A customer survey can
also be conducted.

Mistakes which have been made

during the concept phase can also be
identified here.

Also, a bad mood among the employees

resulting from the project can becloud the
total result. 173

3.5 Project success

Iceberg theory: Reasons for poor project success:

1/8 factual level and 7/8 relationship level

Factual level

Relationship
level

174
4. Documentation

175

4. Documentation
Order documents Organisation documents
• Project charter • Organigram
• Project profile (goals & solutions) • Duties, competencies
• Tender / Requirements specification and responsibilities
• Offer / Performance specification • PM manual
• Calculation documents • QM manual
• Checklists
Planning documents
• Product structure plan Control documents
• Project structure plan • Meeting reports
• Deadline and milestone schedule • To-do lists
• Risk documents • Status reports
• Project reports
Closure documents • Change requests
• Final report including post-
calculation Working documents (not PM)
• Lessons learned • Drawings
• Handover protocol • Measurement results
• Employment contracts
176
4. Documentation

Complete documentation of all significant working steps (with comments

where appropriate) is vital in projects. Project documentation generally
serves as a basis for the final report. Documents are not deleted once
they have been created, being archived when the project concludes.

A document management system (DMS) must be set up, both for

actual project documents created by or available to project management
and for working documents from project personnel (e.g. drawings).

The following have to be regulated in this respect:

• How and where are documents filed?
• Who can access which documents and with which rights (read/write)?
• Who controls access rights?
• How are documents backed up?
• How can a search be conducted for documents or their contents?
• Who ensures that the drives are always sorted?

177

4. Documentation

All documents should be compiled in a manner comprehensible to

others to ensure transparency for all employees and avoid
misunderstandings and numerous inquiries.

In addition, each document should contain the following information:

• Project name
• Document title/topic
• Reason / purpose / type of document
• Creation or release date
• Responsible person (e.g. project manager)
• Author (e.g. PMS)
• Distributor (obliged/authorised to read = cc)
• Keywords where appropriate for sorting or locating documents

178
4. Documentation

A few documents are illustrated briefly below:

Many project personnel have their own personal notebook into which
they enter generally unsorted information which is of relevance to them.
No information is lost, as this involves a book from which no pages are
removed.

A personnel table contains all those involved in the project and their
respective duties, skills and responsibilities.

Analogously, a resource table contains all the resources available to the

project and their scope of use.
Example: Test rigs which can be used for the development of an engine
(performance test station 18 from 01.04.2014 – 31.07.2014).

A decision database is a file in which all project decisions are pooled.

This involves an Excel table in most cases.

179

4. Project management manual

According to DIN 69905, a project management manual is a

“compilation of information, standards and rules which apply to a
particular project”. The rules contained therein usually do not apply solely
to a project, but rather an entire company. It is necessary to define a
uniform project understanding and uniform processes in an enterprise.

The effort invested into its creation pays off in the avoidance of
misunderstandings.

All company employees involved in projects should be trained in

accordance with the PM manual.

A quality management manual is necessary to obtain certification in

quality management conforming to ISO 9000. Large parts of both
manuals may be identical, due to the close interlinking between project
management and quality management.
180
4. Project management manual
Example of the structure of a project management manual. The focus is
not on the explanation of individual tasks and issues, but rather on
standardisation in the company.

1. Introduction
• When is this manual used?
• Terminology definitions
• Process model
• How can the standard process be adapted to suit a specific project?
2. Concept phase
• Criterion governing the requirements and performance specification
• Project calculation requirements
3. Planning phase
• Standard project organisation
• Duties, competencies and responsibilities of project participants
• Committee structure
• Milestone requirements
• Rules for creating deadline and process schedules
• Risk analysis requirements
• Sample project structure plan 181

4. Project management manual

4. Realisation phase
• Rules for project documentation
• Realisation of progress analyses and milestone tests
• Rules for project control
• What aids can we avail of for project planning and control
• Dealing with change proposals
5. Closure phase
• Handover of lessons learned
• Final project report requirements
6. Further information
• Contacts
• Links
7. Appendices
• Checklists
• Forms

182
5. Communication und information

„Good informationen is hard to get.

It‘s even harder to use it.“
(Sir Arthur Conan Doyle)

183

5. Information flows: Communication

Essentially speaking, a project manager communicates with 4 groups.

Management

Colleagues, other Friends, social groups,

teams & customers organisations

Employees

184
5. Information management

In addition to communication, the provision of information is one of the

main duties of a project manager:

• Who has which information?

• Who needs which information in which form?
• When does who need which information?
• How does one ensure that everybody has all the required information at
the right time?
• When, how and from whom can each individual obtain the information
he or she needs?
• Which media do we choose for communication?

185

5. Information flows: Communication

Project communication encompasses every form of communication

relating to a project between management, the project team and affected
employees. Project should also steer and optimise communication in the
project.

Communication Development of a Intensification and

between all levels of consciousness for expansion of
project participants. organisational communication right
change. from the planning
phase.

186
5. Information flows: Communication

The probability that spontaneous communication takes place

during a week already diminishes to less than 10% at a spatial
distance of 20 metres (i.e. in an open-plan office).
Probability that
spontaneous
communication
occurs during a
week [%].

Spatial distance between employees [m]

187

5. Information management
Information management can also be divided into 4 phases.

Collect Store Filter Use

information information information information

Ensure that all - Provision of a Filtering of Use of filtered

relevant suitable platform significant information for
information is for the information project control,
available and administration required to solve presentation,
this is reliable and archiving of a task or decision-
and correct project data preparation for a making, problem
- Backup of all decision. solving, etc.
information

188
5. Information management
Different people need to be informed and measures taken, depending
on how important information is and who it effects.
Type of information To be informed Measure
Information which could  • Client
Crisis meeting with client
endanger project success • Project manager
Information which could lead 
• Client Internal project crisis 
to a delay or entail greater 
• Project manager meeting 
effort or outlay
Information which affects the  • Project manager Treatment in the context of 
entire project team • Project team regular project meetings
Information which affects  • Project manager Discussion in the context of 
several project participants • Involved personnel subordinate meetings
Information that only affects 
• Affected person Processing by those affected
one project participant

189

5. Information management: Problems

The majority of employees perceive the cause of errors or mistakes as
lying with other people, the process or upstream or downstream areas.
Survey: Where do you perceive the severest conflicts to be in the
company? (440 persons interviewed in an industrial enterprise with 5,500
employees)
Internal
Cooperation with direct Cooperation with other
departmental
superiors organisation units
cooperation
25 % 63% 12%

190
5. Information management: Problems
Furthermore, project employees were questioned on information:

Results:
• Almost everybody is missing 1/5 of documents!
• Around half of employees receive 1/5 of documents unnecessarily!
• 80% of all employees receive 1/4 of the required documents too late!
• 67% of all employees use up around 2 hours a day to clarify inadequate
documents!
• 1/3 of all employees do not know who they should address queries to!

Conclusion:

191