Introduction

1.1 Project Management, What for?

The dynamics of change in business and research are high. Innovative organisations
have recognised project management as a critical success factor. The products and
services of tomorrow emerge from temporary, targeted, and interdisciplinary coop-
eration. For this, it is necessary to design the optimal working methods and
organisational forms according to the situation, so that efficient management and
communication channels are possible.
Project management was developed in the 1950s in the aerospace and plant
construction industries. Special planning methods such as the network planning
method (Critical Path Method) or PERT (Programme Evaluation and Review Tech-
nique) were developed for these projects. They were used to solve complex tasks not
only for technical undertakings, but also for problem and crisis situations in all
management functions: for example, for marketing, and in human resources, finance
and organisation in private-sector companies and public administrations. The tradi-
tional approaches are still valid today and are widely applied. However, in various
areas such as product or software development, they have reached their limits. Agile
methods such as scrum help and increasingly rely on the principle of self-
organisation of teams. They are deliberately lean and focused on fast, iterative
delivery of results and prototypes. Mixed forms have developed from the traditional
and agile approaches, which are referred to as hybrid project management. If projects
include operational, structural, organisational, or personnel aspects, project manage-
ment is often also called change management.

1.1.1 The Taylor Tub

In the industrial age of Taylorism, traditional project management helped to create

efficient procedures. Today, in the knowledge age of the network economy, com-
plexity and dynamics determine the everyday life of companies. Bernd Oestereich

# Springer-Verlag GmbH Germany, part of Springer Nature 2023 1

J. Kuster et al., Project Management Handbook, Management for Professionals,
https://doi.org/10.1007/978-3-662-66211-3_1
2 1 Introduction

Share of value added

Machine complicated
Efficiency
Man pressure complex

Who? How? Who?

Efficiency Knowledge
Craft Method Trying it out
Rules Meaning
Innovation
pressure
Zeit
1900 1980 2000

Taylorism Network
Manufactury
Industrial age economy

tight local markets wide global markets tight global markets

Market pressure

Fig. 1.1 Taylor tub

and Claudia Schröder illustrate this using the model of the Taylor tub by Wohland
et al. (2004) and Pflaeging and Hermann (2015) in Fig. 1.1.
Companies have to adapt to the intense competition and the increased demand for
personalised offers. In order to master the high dynamics and complexity of every-
day life, they tend to use agile approaches in project management. Depending on the
situation in which an organisation finds itself, it then chooses the appropriate
approach accordingly.

1.1.2 BANI Is the New VUCA

Science is constantly developing new explanatory models for changes seen in the
world; e.g. the sensemaking model BANI by Jamais Cascio (Facing the Age of
Chaos, April 2020). It describes four trends that are increasingly observed in today’s
world:

• Brittle: many systems have become unstable and can collapse at any time
• Anxious: a diffuse basic fear has taken hold of the world
• Non-linear: linear logic has long since reached its limits
• Incomprehensible: previous explanatory models are increasingly losing their
value
1.2 What are Projects? 3

The VUCA model (W. Bennis, B. Nanus, 1987) was developed after the end of
the cold war and consists of the following four elements:

• Volatility: Fluctuations and rapidity in the digitalised world

• Uncertainty: Difficulty in predicting events and trends
• Complexity: Many influencing factors are interdependent
• Ambiguity: Clear and unambiguous decisions are rarely possible any more

This great speed of change also repeatedly leads to adjustments in the under-
standing of project management. In summary, the following features characterise
this domain:

• A flexible and quickly reactive temporary organisation ensures the optimal

handling of the respective project.
• Project management facilitates and promotes direct, interdisciplinary
cooperation.
• The competences of leadership are clarified in the project organisation.
• Direct communication channels within and outside the project are easily
accessible.
• The existing performance potential is activated through teamwork and a
stimulating atmosphere.
• Clear affiliation to the project team makes it easier to identify and deal with
conflicts of loyalty.
• Involving the people concerned makes it possible to form a learning organisation.

1.2 What are Projects?

A generally valid definition of the term project has not been agreed upon yet.
Organisations define projects differently according to their needs. The following
common characteristics can be singled out:

• Projects are goal-oriented. They bring about changes that can result in very
different reactions: from euphoria to resistance, from scepticism and fear to joy
and motivation. They require great organisational-psychological demands to
manage.
• Projects are innovations. Either they push the limits of what has been technically
or organisationally feasible so far (e.g. new information and communication
technologies), or they are something completely new for the organisation, for
which knowledge has to be acquired at first (e.g. by means of self-organisation).
• Projects are undertakings having clear boundaries: They are one-off, limited in
time and under deadline pressure.
• Projects are interdisciplinary: they go beyond the usual organisational structure
and touch on different disciplines and areas of responsibility.
• Projects are of high content and social complexity.
4 1 Introduction

• Their character changes from a phase to the next (vision, concept, execution), and
they require different management skills at every step.
• Projects are difficult to plan and control, they require special organisational
measures as well as clear and unambiguous decisions.
• Projects need extraordinary resources in terms of leadership, knowledge, person-
nel, and finances.
• Depending on their size and complexity, projects also carry various risks, namely
risks of a financial, personnel, technical, and scheduling nature.
• Projects are social systems: they need their own project organisation for their
execution.

The team of authors defines a “project” as follows:

Definition
A project is a unique, cross-departmental, time-limited, goal-oriented, and
interdisciplinary undertaking that is so important, critical, and urgent that it
cannot be handled within the existing line organisation, but requires special
organisational framework conditions.

Projects which are not really projects, but in which individual elements of project
management are applied, include:

• one-off special assignments that can essentially be fulfilled by one person,

i.e. without a separate project organisation.
• continuous processes such as learning, production, development, or change
processes without a defined end. They are more like a stream. However, projects
can be embedded in them. For example, the conception and introduction of a
quality management system is usually handled as a project in order to install
on-going feedback and learning processes.

The principles and methods of project management can on the whole be adopted
for such projects, too.
Each organisation can and should set criteria based on its level of project
management maturity as to the scope and complexity of a project. It is often a
good idea to classify projects. A higher number of governance documents and
processes are prescribed for projects with a higher classification. Table 1.1 shows
an example of project classification.
Other criteria used in practice for classification can be:

• Personnel expenses internal/external

• Content/social complexity (Sect. 1.2.1)
• Internal vs. customer projects
• Project duration
• In addition to the project-specific classification, projects can also be grouped
together in programmes according to their interdependence, see Sect. 2.7.3.
1.2 What are Projects? 5

Table 1.1 Example of a project classification

Criterion A Projects B Projects C Projects D Activities
Project costs >€1m > 250 k€ > 100 k€ ≤ 100 k€
Complexity Group-wide Business unit Maximum Maximum
3 departments 2 departments
Strategic High Medium Low Low
importance
Risk Very high High Medium Low
Default All Many Some mandatory, No
documents mandatory mandatory, many optional specifications
according to some optional
matrix list
Governance Monthly Regular steering Ad hoc steering Optional
structure steering committee committee at the
committee (business unit) request of the PL
(group)
Classification (A, B, C, D) is based on the highest criterion

Table 1.2 Project characteristics

Task Closed Known, clear task with limited solution options, e.g. structural
extension for certain uses
Open Many possibilities regarding content and approach without solution
ideas, e.g. improving the flexibility and reaction speed of an
organisation
Social Deep Unproblematic cooperation, e.g. few stakeholders, little differences in
complexity interests, cooperation mainly in one field of expertise
High Interdisciplinary, politically explosive, different user interests, great
potential for conflict

1.2.1 Project Characteristics

The character of a project gives the project manager important information on how to
structure the project, define the project organisation, and see what resources are
needed. There are different ways of characterising projects.
A distinction is made between projects according to the nature of their task:
closed or open, and according to their social complexity.: low or high (Table 1.2).
Four project characteristics can be derived from this (Fig. 1.2):
6 1 Introduction

High
Extends across departements
or areas, interdisciplinary,
complicated causal
relationships

Social complexity
Acceptance project Pioneering project
Standard project Potential project

Low
Cooperation mainly within one
specialist field, simple causal
relationships, low risk

Goals
Closed Open
Clear goals Goals with a wide range
of possibilities in terms of
content and approach

Fig. 1.2 Project characteristics

• Standard projects can draw on a wealth of experience and can therefore be

handled in a standardised and simple manner. Examples: technical customer
project, replacement investment.
• Acceptance projects are projects with clearly defined tasks. Based on experience,
methods and tools can be formalised and standardised to a certain extent. As they
are often associated with acceptance problems, communication with stakeholders
plays a crucial role. Examples: a road construction project, or a complex software
project.
• Potential projects are tasks with open questions, but which are not (yet) closely
linked to the project environment and are not too risky in this respect. The project
organisation here is usually simple and small. This category includes studies,
potential clarifications, feasibility studies, often also research projects. Examples
would be: product innovations, and the development of new business models.
• Pioneering projects are interventions having far-reaching consequences in the
organisation; they span several areas, have a high novelty content, and are
threatening and risky for many of those affected. The scope of the task is difficult
to estimate. Examples might be, for instance, the merger of two companies, or the
development of self-driving vehicles.
1.2 What are Projects? 7

Many projects alter their project character during their development from the
initialisation phase to the introduction. They often change from a potential project to
a pioneer project and then turn into an acceptance or even a standard project.
This typology can not only provide information about the basic project manage-
ment approach, the choice of the project organisation, the characteristics of the
communication, or the methodological focus, but also about the necessary strengths
and qualifications of the project manager. For example, a construction project
requires different qualifications than a change project, a development project, or
an order processing project.
The traditional approach is well suited for the handling of standard projects. On
the other hand, agile approaches are better suited for the handling of pioneer projects,
potential ones, and even acceptance projects. Estimating dates and costs is easier in
standard and acceptance projects. Dates and costs can be planned with a low
tolerance. In contrast, the estimation of the effort needed and the derivation of a
possible schedule in potential and pioneer projects is much more demanding and
tends to be associated with a higher degree of uncertainty and fuzziness.

1.2.2 Project Types

Another way of classifying projects is to arrange them according to their purpose.

For some purposes, separate project procedures have been developed and
standardised by appropriate bodies. Typical project types are:

• Investment projects
• Product development projects
• Organisational development projects
• Change projects
• Information and communication technology projects (ICT projects)
• Software development projects
• Order processing projects, customer projects
• Process optimisation projects, efficiency improvement projects
• Infrastructure projects
• Building projects
• Research and development projects

1.2.3 Emergence of Projects

Projects can arise in different ways as shown in Fig. 1.3.

Depending on how the project originated (as an internal project or customer
project), depending also on what its history is, what type of project it is, or what
project characteristics it has, the project manager has to adapt his approach accord-
ingly. These points have a direct influence on the selection of processes and tools, as
shown in Table 1.3.
8 1 Introduction

Company

Project order
B

Management Employees
external customer
Idea, suggestion for
C
Request for proposal improvement = Project request
A
Signing
Proposal = Project order

Contract negotiations

External contract

Fig. 1.3 Emergence of projects

1.3 What Is Project Management?

Every company wants to achieve strategic and operational objectives. The objectives
set cannot always be achieved through the line organisation. Depending on the
situation, it makes sense to approach and implement plans and measures as a project.
This makes it possible to bundle and focus forces. With regard to the management of
projects, the traditional and agile approaches pursue different approaches.
In the traditional approach, the following steps have proven to be very successful:

• Subdividing the procedure as a whole into phases and work packages

• Defining decision-making, leadership, and technical competence per phase

In the agile approach, the focus of the elements is slightly different:

• Empowered, self-organised teams are to continuously review and adapt

• Timebox procedures with early and frequent deliveries

" Project management is understood as a generic term for all planning, monitoring,
coordinating, and controlling measures that are necessary for the redesign or
reorganisation of systems, processes, or problem solutions.
1.3 What Is Project Management? 9

Table 1.3 Different project types and characteristics require different approaches
Order processing project An external customer has a problem. The company has
made a binding offer to the customer. Deadline and costs
are fixed and legally binding, perhaps a contractual penalty
has been agreed upon. The project manager focuses on
proven standardised processes, low-risk and on-time
execution, and effective cost control
Internal development project at Management has initiated a strategic project to realign the
own risk company. Objectives and deadlines are not set in stone. In
case of new findings, targets, deadlines, or costs can be
discussed and adjusted
Suggestion for improvement, idea Motivation and knowledge are given. The supervisor must
from own employees have the employees’ backs in that they have sufficient
resources to be able to work on the project efficiently in
addition to all routine tasks
Small project Individual phases or activities can be passed over. The
project manager works according to the standard process,
decides at the start of the project to skip individual steps and
reviews. He records this in the project documentation
Acceptance project If major resistance is to be expected in a project, the project
manager will involve all relevant stakeholders at an early
stage and draw up a carefully coordinated information and
communication concept
Innovation project, pioneering The company has reached its limits with its product line and
project needs to rely on a completely new technology in
manufacturing. The project manager will use a balanced
mix of people with a wide range of abilities and experienced
specialists and have both types of work in self-organised
teams

The procedure for achieving the solution, the resources required for this, their use
and coordination are more important than the solution itself. In contrast to project
management, line management is more concerned with day-to-day business and its
management of the organisations involved.

1.3.1 Hierarchies in Project Management

The “project management” method permeates the entire organisation. Different tasks
are carried out by different hierarchical levels in the company.
Programme management is about coordinating different interdependent projects,
aligning priorities and allocating all resources, such as labour and finances, accord-
ingly. Examples: Research programme, development programme, etc.
A project portfolio consists of the projects and/or programmes of a company or a
division. They do not necessarily have to be related to each other, but they have
access to the same pool of resources, i.e. mostly to people and finances. It is about
making the best use of the organisation’s resources and achieving the organisation’s
strategic objectives while minimising risks.
10 1 Introduction

Product management encompasses all strategic and operational activities of a

position or person responsible for a product or service in all areas of the company.
Whoever is responsible for product management is usually also the contact person
for customers. Developments, introductions, or problem solving in connection with
a product may very well be regarded and handled as projects.

1.3.2 Dimensions in Project Management

The dimensions in project management can be illustrated well using the IPMA “Eye
of Competence” (see Fig. 1.4).

1.3.2.1 Competence Area Perspective

This competence area deals with the context of a project. It contains the following
topics:

• Strategy
• Governance, structures, and processes
• Compliance, standards, and regulations
• Power and interests
• Culture and values

People Practice

People Practice

Perspective

Perspective

Fig. 1.4 Eye of Competence from IPMA (International Project Management Association)
1.3 What Is Project Management? 11

These topics set the framework and define the environment in which the project is
carried out. In this handbook on project management, these topics are addressed in
various places of this reference work and explored in greater depth.

1.3.2.2 Competence Area People

This competence area deals with personal and social competences. It contains the
following topics:

• Self-reflection and self-management

• Integrity and reliability
• Personal communication
• Relationships and engagement
• Leadership
• Teamwork
• Conflicts and crises
• Ingenuity
• Negotiations
• Results orientation

This area of competence is key to the success of a project. A project is successful

if it succeeds in shaping the relationships between people and teams in a constructive
and positive way. In this handbook on project management, these topics are dealt
with in Chaps. 3 “People” and 5 “Teams”.

1.3.2.3 Competence Area Practices

This area of competence deals with methods employed in project management. It
contains the following topics:

• Project design
• Requirements and objectives
• Scope of services and deliverables
• Procedure and dates
• Organisation, information, and documentation
• Quality
• Costs and funding
• Resources
• Procurement
• Planning and control
• Opportunities and risks
• Stakeholders
• Change and transformation

To master a project successfully, mastering the craft is an indispensable prerequi-

site. However, the decisive factor for project success often lies in the question of how
to manage the relationships between people and teams. In this handbook on project
management, these topics are mainly dealt with in Chap. 2 on “Methodology”.
12 1 Introduction

1.3.3 Principles of Procedure

The following principles and attitudes have proven effective in practice:

• From the general sketch to more detail

• Investigate alternatives; variant formation
• Arrangement of phases
• Problem-solving methodology

The principles “from the rough and general to greater detail” and “investigating
alternatives” are explained below. The two other principles (phase structuring Sect.
1.4.2 and problem solving Sect. 2.3.14) are so crucial to project management that
they are dealt with separately.

1.3.3.1 From a Rough Sketch to a More Detailed Depiction

The principle shown in Fig. 1.5 is an important basic attitude in the handling of a
project. It is described as follows: At the beginning of the project, the field of
observation should be broadly defined and then gradually narrowed and focussed.
This applies to both the investigation of the problem area and the design of solutions.

Level A
Area of investigation

Area of design
Procedure from rough to detail

Level B

Level C

Fig. 1.5 Procedure from the rough to the detailed

1.3 What Is Project Management? 13

Only when the problem area has been first structured in a more general way,
embedded in its environment and delimited, or when interfaces to the environment
have been defined, can detailed surveys begin.
When designing the solution, general objectives and a general solution frame-
work must first be defined. Their level of detail and concretisation is to be elaborated
step by step in the course of the project.
The principle of “top-down” can be reversed to “bottom-up”. The bottom-up
approach can make sense under special conditions, e.g. for improvements in
existing, functioning solutions, in the so-called empirical procedures. In the case
of a conceptual approach, i.e. in new approaches or large-scale redesigns, it is
usually more effective to develop an overall concept from the outset, so that an
orientation framework is created for the sub-steps to be carried out.
During implementation, it becomes apparent that a circular approach of “top-
down” and “bottom-up” leads to the necessary common view. This coordination also
significantly increases the commitment of each individual involved to take responsi-
bility for a structure or plan created in this way.

1.3.3.2 Variant Formation

Figure 1.6 shows an indispensable part of good planning. It is a basic methodological
approach and, if the principle of “from the rough to the detailed” is observed, works
without any significant additional planning effort. If this principle is not observed,

Problem:
Car ready for the scrapheap
Spontaneous project idea: New car

Solution
principles

Variants on
the concept

Detail
white red blue
variants

Fig. 1.6 Example of a step-by-step variant formation

14 1 Introduction

there is a greater risk that fundamentally different solution approaches will only be
introduced into the discussion at an advanced stage of planning.

1.4 Process Models in Projects

Depending on the type of project, the size and complexity of the project, and the
given framework conditions, different process models are used.

• Agile methods are often used in software development, in other sectors such as
plant engineering or product development, in transformation projects and
organisational development.
• For standard projects (Fig. 1.2), the traditional project management (waterfall
model) is widely used: e.g. for customer projects in which an existing technology
is adapted to specific customer requirements. Here the phases are arranged
sequentially.
• In hybrid project management, traditional and agile approaches are applied
together. The project is managed traditionally vis-à-vis customers or the internal
organisation. Internally, parts such as development are handled agilely.
• In change projects, elements from the agile and traditional approaches can be
integrated. However, in order to shape change successfully, independent process
models are needed.

Each process model has its advantages and drawbacks. It is important to select
and apply the best one for the respective situation. To say it again: the future lies in
the golden mean. It is not about a traditional or agile approach, rather about a
situationally skilful combination of agile and traditional elements.
In this handbook on project management, the traditional and agile approaches are
not treated separately. In the sense of hybrid project management, the elements of the
traditional and agile approach are explained and elaborated on the basis of the phases
of traditional project management (project commissioning, initialisation, concept,
realisation, and introduction).

1.4.1 Agile Approach

Traditional approaches have made and continue to make significant contributions to

project management. In product and software development, however, it has been
shown that many projects that were carried out with a waterfall method did not bring
the desired results or even failed. The reasons for this are to be found in task
complexity, faster working environments, and there being constant changes. Agile
methods such as Scrum, Large Scale Scrum (LeSS), Extreme Programming, Kan-
ban, or the Scaled Agile Framework (SAFe®) are employed to maintain control.
Agile methods also help to realise a customer or user-specific and functioning
software in the shortest possible time span, without the complete requirements
1.4 Process Models in Projects 15

having to be defined in detail at the beginning. Agile project management refers to an

elastic, nimble, process-oriented, reflexive, learning approach. Its principles and
values were published in the Manifesto for agile software development (Beck
et al., 2001, http://www.agilemanifesto.org):

• Individuals and interactions are more important than processes and tools
• A software that works well is more important than extensive documentation
• The cooperation with project stakeholders is more important than contract
negotiations
• Responding to change is more important than sticking to a rigid plan

The agile manifesto follows these 12 principles:

• Our highest priority is to satisfy the customer through the early and continuous
delivery of valuable software.
• Welcome changes in requirements even late in development. Agile processes use
change to the customer’s competitive advantage.
• Deliver working software regularly within a few weeks or months, giving prefer-
ence to the shorter time span.
• Subject matter experts and developers have to work together on a daily basis
during the project.
• Build projects around motivated individuals. Give them the environment and
support they need and trust them to get the job done.
• The most efficient and effective way to communicate information to and within a
development team is face to face.
• (Well-)functioning software is the most important measure of progress.
• Agile processes promote sustainable development. The project owners,
developers, and users should be able to maintain a steady pace indefinitely.
• Constant attention to technical excellence and good design promotes agility.
• Simplicity—the art of maximising the amount of unnecessary work not done—is
essential.
• The best architectures, requirements, and designs are created by self-organised
teams.
• At regular intervals, the team reflects on how it can become more effective and
adjusts its behaviour accordingly.

The values and principles of the agile manifesto can also be applied to areas
outside of software development. In an agile approach, the dimensions time and
budget are rigid, the result (the scope) is flexible. In a traditional approach, the scope
is usually set while the time and budget dimensions remain flexible (or they are
estimated based on the scope). This is a principle that often leads to time delays and
budget overruns in projects.
In this project management handbook, scrum is examined in depth as an agile
process model.
16 1 Introduction

1.4.1.1 Scrum
Scrum was initially very strongly influenced by the lean and innovative ways of
product development in Japan (lean management). Scrum consists of a few rules.
Figure 1.7 shows schematically the procedure according to scrum. The start phase
(initialisation and product conception) is followed by iterations or sprints during
pre-planned intervals of time (i.e. within timeboxes). The agreed-upon partial
assignments are processed by teams that do and organise things acting largely on
their own responsibility.
The basic principle underlying these forms lies in the relatively short and
predefined iteration cycles (timeboxes), within which highly motivated teams inde-
pendently develop and test solutions (increments). In the process, learning
experiences or new user insights flow into the next cycle.
In scrum there are three roles (responsibilities): product owner, developer, and
scrum master. The role of the traditional project manager either does not exist or is
divided up between the two roles of product owner (technical and content-related
control) and the scrum master (method specialist who removes any hurdles).
The requirements for this are recorded in a prioritised product backlog. The
content and prioritisation of this product backlog changes continuously during the
project, which means that changes can be dealt with easily and flexibly. It is the
product owner who controls the product backlog and determines the prioritisation.
Scrum is an empirical process that follows a credo of “inspect and adapt”. The
achieved result (increment) and the ways of working are thus regularly assessed in
the sprint review and improved retrospectively. This ensures continuous
improvement.
A sprint is planned in such a way that at the end an increment is created which
represents added value and is functional. This focus on the delivery of added value

Start-up Sprint 1 Sprint 2 Sprint 3

phase
•
Product •
•
Target •
•

•
Product •
•
Backlog •
•
Sprint Product Sprint Product Sprint
Backlog Increment Backlog Increment Backlog
Release
•
• 1 1 2 2 3
• • • • • •
Plan •
•
•
•
•
•
•
•
•
•
•
•
…

Time

Fig. 1.7 Schematic representation of the agile procedure according to SCRUM

1.4 Process Models in Projects 17

prevents one from being preoccupied with anything unimportant. In sprint planning,
the product owner specifies his priorities, wishes, and the sprint goal. Ultimately, the
developers themselves decide on the effective content of the sprint according to the
pull principle. This promotes personal responsibility and self-organisation. In addi-
tion, the pull system avoids systematically overloading the developers. It is also
advisable to identify and address problems and obstacles at an early stage. Especially
in the first sprints, the sticking points should be tackled and directed towards a
solution.
Scrum is hard work. New rules have to be learned, old habits discarded, obstacles
overcome, and problems solved. Successfully applying scrum is a constant learning
process that also requires time and patience. It is the central task of the scrum master
to support the developers and the product owner in overcoming these challenges and
to apply scrum successfully.
The phase concept can also be applied to scrum in an adapted form. In the initial
phase of a scrum project, it is essential that a product goal is first developed. This
concretises the idea. The product goal describes the benefit for the future user of the
product or service and the essential performance features. Furthermore, the initial
product backlog and the release plan must be created in the beginning phase. Agile
approaches have proven to be more flexible, faster, and more economical than
planning-oriented project management in complex areas.

1.4.1.2 Kanban
Kanban has its origins in the mid-twentieth century at Toyota. Kanban was devel-
oped as a method to increase flexibility and efficiency in production. The transfer of
kanban’s ideas to the management of projects was later undertaken by David
J. Anderson.
Kanban does not prescribe any processes or structures. Like scrum, kanban
promotes self-organisation in that the employees or the team independently pull
tasks to themselves (pull principle). Kanban is based on four basic principles and six
practices.
The four basic principles of kanban are:

• Start with what you are doing right now.

• Aim for incremental, evolutionary change.
• Respect current processes, roles, responsibilities, and titles.
• Promote leadership and responsibility at all levels of the organisation.

The six practices of kanban are:

• Make the work visible (Kanban board, see Sect. 2.5.2).

• Limit the amount of work started.
• Measure and manage flow.
• Make process rules explicit: clear and known.
• Develop feedback mechanisms.
• Make collective improvements.
18 1 Introduction

The principles of kanban can be combined well with other agile methods such as
scrum or the traditional approach to project management.

1.4.1.3 Scaled Agility

An agile approach using scrum is suitable for teams with a size of three to ten people.
If larger teams or an entire company want to work agilely, an approach like scrum is
not sufficient. The two best-known approaches to scaling agility are Scaled Agile
Framework (SAFe®) and Large Scale Scrum (LeSS). SAFe® and LeSS provide
approaches for agile working and synchronisation across multiple teams. Both
approaches are based on teams working according to scrum or a scrum adapted
approach.
In SAFe® several teams are grouped into an “agile release train”. These release
trains are aligned with value streams. Quarterly big room planning takes place in
which the next product increment and the work for the next 3 months are planned.
The implementation then takes place in sprints during the next 3 months. At a higher
level, a programme backlog is kept and each team also keeps its own backlog. There
is a product owner for each team and also a product manager at this level, who
among themselves divide up the work of the product owner. This also applies to the
work of the scrum master. At a higher level there is a release train engineer. For large
organisations, several agile release trains can be combined into one solution train. At
the company level, management is carried out according to the principles of lean
portfolio management (see Sect. 2.7.2).
The LeSS framework is closer to the scrum method. It divides events such as
planning, review, and retrospective into a general part for all teams and an individual
part for each team. In addition, there are further synchronisations between the teams
during the sprint.
SAFe® and LeSS are efficient approaches to scaling agility across the whole
organisation. They are oriented towards scrum and lean management. Part of the
autonomy and self-organisation in the teams is given up in favour of a common
orientation. In addition to the methodological support of these frameworks, it is also
crucial to develop the attitude and mindset of the people involved in the direction of
agility. If this is not done, there is a high risk that the methodological approach will
be changed, but the old problems will be retained or simply reorganised.

1.4.2 Traditional Approach: Phase Concept

The principles of “from the rough to the detailed” and “variant formation” mean the
following for the processing of problems: namely that the Idea, development,
implementation planning, and the realisation of a solution are divided into individual
work packages, and these in turn into phases that can then be logically and tempo-
rally separated from each other. The purpose of this is to split the development of a
solution as a whole into manageable stages. This enables a graduated planning,
decision-making, and concretisation process with predefined milestones or correc-
tion points.
1.4 Process Models in Projects 19

Assignment Initialisation Concept Realisation Introduction

Milestone: Size of the rhombus as a measure of the probability of a project break-off

Project break-off

Fig. 1.8 The ideal phase concept

In Fig. 1.8, the phase model is described in its simplest, ideal-type form.

Number of Project Phases

The number of project phases and also the formalism with which they are handled
depend considerably on the type, scope, risk, and importance of a project and also on
the influence the project owner wants to have.
Smaller projects can be seen through with a smaller number of phases and less
formalism. On the other hand, compared to the theoretical model, phase extensions
are also possible, e.g. by including a feasibility study, a prototype phase, a test phase,
or an acceptance phase.
The representation as a block diagram or as a “waterfall model” and the designa-
tion of the phases are of secondary importance, as they are influenced by the
industry, the task and the terms used in the company. Some common phase models
are listed in Fig. 1.9. The decisive factor is that in decision-making meetings
between the stages, the complexity of a problem and the risk of a wrong decision
can be reduced by the targeted structuring of the work packages into individual
planning and realisation stages.

1.4.2.1 The Project Commissioning Phase

This phase, which is usually rather unstructured, comprises the period between the
recognition of the problem and the decision to do something concrete. The problem
can either be formulated in real terms or merely be the result of vague assumptions. It
is not important where the impetus for redesigning or reorganising comes from.
What is important is that it is received, accepted, and approved in a project agree-
ment by those authorised to allocate the necessary human, financial, and
organisational resources.
20 1 Introduction

Systems Engineering Product development Building projects SIA IT projects with Scrum
projects projects

1 Preliminary 1 Preliminary 1 Strategic planning

project project 1 Initialization
2 Preliminary studies
2.1 Feasibility
2.2 Selection process 2 Rough concept

3 Project Planning
3.1 Preliminary project
2 Main project 2 Development
3.2 Building project
3.3 Approval process

3 Detailed project 3 Production 4 Tender process 3 Sprints

preparation Iterative programming
5 Realisation Introduction and
5.1 Detailed design acceptance

4 Implementation 4 Pilot series 5.2 Execution

5 Introduction 5 Serial 5.3 Commissioning

production

6 Facility Management
6.1 Operation
6.2 Maintenance

Fig. 1.9 Phase models and phase designations

The preliminary work and activities of this first “definition phase” ideally result in
a project factsheet. The project factsheet contains information on the strategic
reference and the expected added value, an initial rough schedule and the expected
costs. It names the central project roles and, together with the business case, serves as
a basis for deciding whether the project should be approved and included in the
project portfolio.

1.4.2.2 The Initialisation Phase

In the initialisation phase, binding statements on feasibility, risks, and stakeholders
must be developed. Essential bases for this are the analysis of the current situation as
well as clearly agreed-upon objectives and the formulation of requirements for the
outcome of the project, e.g. for the product to be developed.
At the beginning of the project, knowledge about the project content and
solutions is low. The risks and the importance of decisions are greatest at the
beginning. This can be alleviated or resolved with a feasibility study in the
initialisation phase.
In this phase, the project order is written. This sets out the objectives and the
framework conditions for the project. The following thematic blocks are worked out
and fixed in the assignment:
1.4 Process Models in Projects 21

• Elaborate requirements: What should be realised?

• Determine project organisation
• Identify and analyse stakeholders
• Identify risks and develop measures to reduce them
• Structure and roughly plan the project

The project owner is responsible for transforming the proposal into a project
order. From a tactical point of view, the project owner often delegates the prepara-
tion of the project proposal to the project manager, who conducts the “kick-off” at
the end of the phase.
If one decides to abandon the project at the end of the initialisation phase, this is
neither a “mistake” nor some kind of failure, but rather a conscious decision based on
newly attained knowledge.

1.4.2.3 The Concept Phase

The purpose of the concept phase is to develop solution variants. In this phase, the
planned achievement of objectives, functionality, expediency, and economic effi-
ciency is to be assessed in a well-founded manner. Attention is focused on the
elaboration of possible solution variants.
The result of the concept phase is to come to a decision about which solution
variant to go with. Plans are then drawn up for the variant selected, ready for
implementation, and solution concepts are developed that describe how the
requirements are to be set up. The next step is to plan the chosen solution in detail.
Subsystems or individual aspects of the overall system are often worked on here.

1.4.2.4 The Realisation Phase

In the realisation phase, the plans from the concept phase are put into practice.
Typical work steps of the realisation phase are:

• Manufacture plants and equipment

• Create software
• Create user-friendly documentation or operating instructions
• Establish organisational arrangements in the event of disruptions, etc.
• Determine support organisation, maintenance concepts, etc.
• Perform tests

Often, individual subsystems are also built here which are integrated into the
overall solution. Comprehensive project controlling helps to ensure that the targeted
objectives are achieved. Any change requests are managed via the change request
process and therein taken to the decision-making stage.

1.4.2.5 The Introduction Phase

Introduction
Only relatively small and simple solutions can be introduced as a whole without
taking a great risk by keeping them in one piece. With large and complex systems, an
22 1 Introduction

abrupt introduction of a change does not make sense because of the large number of
incalculable side effects and dependencies. It is therefore advisable to proceed in
stages: With the overall concept in sight, further steps are taken based on the first
experiences made with the introduction.
In practice, this—superficially seen—very technical phase often turns out to be
delicate and lengthy. The project team has already been occupied for a long time
with the innovation or change that the project brings with it, and no longer even
notices the drastic change that this introduction means for all of the other people
involved. This disparity between the two systems, project and line, requires good
cooperation within the leadership team.

Handover
The success of a system introduction largely depends on the way and extent to which
the knowledge transfer takes hold. This means whether it is possible to train and
inform the system administrators and the users comprehensively and with adequate
quickness. The goal is to make the development and implementation teams super-
fluous as quickly as possible.

Closing
Every project finally comes to an end. Even aborted projects need closure, and that,
too, is work. If project closure is not done consciously, no one knows whether the
project is finished or not.

The following work is to be carried out for project completion:

• Complete project work, i.e. clearly assign and schedule possible remaining work
or postpone it to a future release
• Elaborate final account
• Complete project documentation and ensure archiving
• Hand over tasks, competences, and responsibilities to the users or an operating
organisation
• Submit project documents of the operational or maintenance organisation
• Project closure with the project owner to “hand over the project” and with the
project team to dissolve this team. In both systems it can be useful to hold a
critical project review, on the one hand, to let go of the project, but above all
because recognised mistakes are a great learning opportunity in the sense of the
learning organisation. Possible questions to ask might be: What went well?
Where did problems occur? Could the planned efforts (personnel, costs, time)
be kept within predicted limits? What might be done better in the future?

1.4.2.6 The Utilisation Phase

When the project is completed, the utilisation phase begins. After a predefined
period of time an evaluation or control of the project outcome takes place.
Depending on the type of project, work is recorded under warranty or for an
improved version of the solution in a new release. Usually, an effectiveness review
1.4 Process Models in Projects 23

or project evaluation is carried out here: How precise have the business
forecasts been?

1.4.3 Hybrid Project Management

Fewer and fewer projects are so clearly positioned that only the traditional or agile
approach is suitable for their management. In practice, they usually lie somewhere in
between, so that a combination of both project management approach models
becomes obvious (Fig. 1.10). The best way to combine them is to handle selected
project phases or sub-projects differently. For example, in a product development
project in which the requirements are only known roughly at the beginning, an agile
phase can be switched on in order to afterwards continue in the traditional way. In a
complex customer project with sub-projects, software development with scrum can
be more advantageous, while the traditional approach is more suitable for the other
sub-projects.
It is also possible to use individual components of the traditional approach such as
daily stand-up meetings, kanban board, planning in cycles and iterations, or using
retrospectives gained from the agile approach. This form of hybrid project manage-
ment has a lot of potential. Often, corporate structures require that a project is set up
in a traditional way towards the outside environment. This means that existing
reporting structures or stage-gate processes can be utilised. In order to maintain

Traditional and agile settlement of phases

Set up of
Manufacturing
Initialisation Conception Realisation production
planning
line

Traditional and agile settlement of subprojects

Realisation
Initialisation Conception Introduction
Hardware I

Realisation
Hardware II

Realisation
agile Software
traditional

Fig. 1.10 Traditional and agile phases

24 1 Introduction

the necessary flexibility in project management, it is advisable to work agilely in the

project. The aim is to skilfully combine traditional and agile elements.
From the point of view of project management, the “both and” approach places
high demands on flexibility. Whereas in traditional project management the focus
lies more on rational connections, planning, and direct control, in the agile approach
it is on the evolutionary and social aspect as well as on indirect control. Both
approaches require a different understanding of organisations, roles, and leadership.
Individual methods can be “hybridised”. But the rule here is: only mix them in a
targeted and conscious way, otherwise there is a risk of weakening them. For
example, the kanban method can be used in a traditional project sequence with
parallel work packages, as it is more flexible and transparent than bar charts.

1.4.4 Procedure in Change Projects

Every project brings about change. The term “change project management” covers
all projects that aim at radical, comprehensive, and interdisciplinary changes within
the organisation. This can be: introduction of new processes, mergers, implementa-
tion of new strategies, etc. In the process, new behaviours and cultures are often
aimed at, e.g. communication culture, error culture, etc. In contrast to change
projects, we exclude “continuous improvement” (CIP, KAIZEN).
The procedure in change projects depends very much on the context in which the
change or transformation takes place. In order to understand this context, it is advisable to
carry out a context analysis as a first step. Kurt Lewin developed the basic cycle of change
management consisting of unfreeze (initiating change), move (shaping the transition
process), and refreeze (institutionalise the new state). Building on this, John P. Kotter
developed the traditional approach of the eight-step model for change projects (Kotter,
2012). Since change projects often do not run in a linear fashion and can therefore only be
planned in advance and to a limited extent, an agile approach such as Jason Little’s lean
change cycle can also be used in change projects. See also Sect. 5.5.10.

1.4.5 Further Process Models

1.4.5.1 V-Model
The V-model is another sequential process model. The procedure is suitable in
industries and areas putting high demands on safety, such as medical technology
or aviation. On the left branch of Fig. 1.11, the project object is specified step by step
from the loose design to the detailed design (top-down specification). On the right
branch, the different realisation and verification stages are gone through from the
bottom-up (bottom-up integration).

1.4.5.2 Simultaneous Engineering

Simultaneous engineering (also called concurrent engineering) is a response to the
demand for shorter development times. The partial parallelisation of processes speeds
1.4 Process Models in Projects 25

Stakeholder Validation Validation

Requirement Release

System requirements Verification

System test
System specification

Architecture, techni-
Integration test
cal detailed design

Fine architecture, Component module

Component design or unit test

Development
Programming

Fig. 1.11 V-model

up project realisation. The various areas involved in product development should be

included as early as possible and ought to work together at least partially overlapping
in time, as shown in Fig. 1.12. This requires a close coordination between the
departments, which then often has to be moderated by the project manager.
Many projects are carried out according to this principle. The simultaneity of a
wide range of activities requires the project manager to constantly monitor compli-
ance with objectives and plans. This task is often made more difficult if one is also
involved in the project as a subject matter expert or in other projects. If simultaneous
engineering is required or approved of by the project owner for a tightly scheduled,
parallel project procedure, the project manager should be able to devote himself fully
to the control of the project, free from other work.

1.4.5.3 Version Concept

The version concept can be used as an iterative procedure for developments of any
kind (machines, systems, hardware, and software). It is also referred to as the spiral
model or as prototyping.
In the version concept, the solution is not created in one go. Instead, a first
version, a first rough, unrefined prototype is created early on and made available
to the user for evaluation. Based on the user’s feedback, improvements then take
place over several iterations, which become possible as a result of operational
experience (Fig. 1.13). The advantages of the version concept are the customer-
oriented development method, the rapid and concrete progress for tasks that are
difficult or not easy to precisely specify, and the on-going learning that takes place if
there is a high degree of uncharted territory. The biggest risk of the version concept
is getting bogged down in “happy engineering”, as there is always another round
26 1 Introduction

Sequential project procedure

Correction loop Correction loop Correction loop

Preceding phase Engineering Procurement Succeeding phase

Simultaneous Engineering

Time saving
Preceding phase

Coordination

Optimised market introduction

Engineering

Originl market introduction

Coordination

Procurement
Project start

Coordination

Succeeding phase
t

Fig. 1.12 Simultaneous engineering as an overlapping phase concept

Step 4: Step 1:
Planning next iteration Analysis, Feedback
De
tai
led
Ro de
ug sig
hd n
Ta es
rg ign
ets

Step 3: Step 2:
Realisation Evaluation

Fig. 1.13 The version concept (spiral model)

1.4 Process Models in Projects 27

attached. To prevent this, it must be clarified at the beginning at which point good is
good enough. Hence, termination criteria have to be defined, e.g. three iterations of
2 weeks each or optimising until test users give a certain grade. This concept is very
similar to the agile approach according to scrum. Another development method with
a high user focus is the design thinking described in Sect. 2.8.2.6.

1.4.6 Choice of a Process Model: Traditional, Agile or Hybrid?

The choice of the most appropriate process model for the situation depends on
various factors:

• Characteristics of the project

– For a standard project, the traditional approach is recommended.
– For an acceptance project, a potential or pioneer project, an agile or hybrid
approach is more recommended.
• The project type very often specifies a process model. Construction projects are
handled according to the relevant industry standard, such as that of the Swiss
Society of Engineers and Architects (SIA).
• Companies, customers, or the regulatory authorities also specify which standards
and requirements must be met.
• Complexity of the task
– With the Cynefin framework (David J. Snowden, Fig. 1.14) and the Stacey
Matrix (Fig. 1.15) the complexity of the task or project can be determined.
– The traditional approach is more suitable for simple or complicated tasks,
whereas an agile approach is more suitable for solving complex and chaotic
tasks.
• Stability of the requirements
– An agile approach is more suitable for volatile requirements.
– In the case of stable requirements, the traditional approach brings more
security and plannability in the implementation.
– It is also important to consider how to deal with changes in the project.
• Competences, qualifications, and experience of the project team members as well
as affinity of the management to agility are further decisive factors.
• Planned team size
– Agile methods are very suitable for small teams with fewer than nine people.
– Large teams, for example, can work very well in an agile way using LeSS
(Large Scaled Scrum) if they have profound knowledge and experience in the
application of agile methods. Otherwise, a hybrid or traditional approach is
more advisable.
• Spatial distribution of the project team
– For an agile approach, it is recommended that the project team works in a
common room or at least in the same building.
– The application of agile methods in distributed project teams is demanding.
Therefore, in the case of spatial distribution, a hybrid or traditional approach is
the first choice.
28 1 Introduction

complex complicated

• everything is in flux and unpredictable, • the system is predictable,

• no correect answers, several unknowns, • cause and effect are present but
• recognisable orientation patterns, not everyone can see it,
• many competing ideas, • expert advice is needed, but
• creative and innovative approaches are more than one correct answer.
needed.
senss – analyse – respond
probe – sense – respond

er
ord
Dis
chaotic simple

• high turbulence, • repeatable patterns and unique

• no cause-effect relations, events
• big unknowns, • clear causes and effects,
• many decisions under high time • clear relationships,
pressure. • there are correct answers.

act – sense – respond sense – categorise – respond

Fig. 1.14 Cynefin framework according to David J. Snowden (simplified representation)

unclear

ch
ao
tic
WHAT: Requirements

co
po

m
liti

pl
ca

ex
l

co
m
pl
ica
te
d
sim

vis
pl

ion
e
clear

ar
y

certain HOW: Technology uncertain

Fig. 1.15 Stacey matrix

1.5 Projects are Based on Teamwork 29

Table 1.4 Criteria for selecting a suitable process model

Traditional Agile Hybrid
Characteristics Standard project Potential project or pioneer Pioneer project,
of the project project acceptance project, or
potential project
Complexity of Simple or Complex or chaotic Complicated or
the task complicated complex
Stability of the Stable Volatile Volatile
requirements
Team member Inexperienced in Experienced in agile Experienced in agile
qualifications agile approaches approaches approaches
Team size Small and large Ideally less than nine Large teams
teams people. Multiple networked
teams possible
Spatial Local or Locally in one room or at the Distributed over several
distribution distributed over same site locations
several locations

The choice of a suitable process model is a demanding task. It should be done at

the beginning by the project owner together with the project manager. It is possible
to change the process model during the course of the project, but this should be done
in a well-considered and conscious manner. Making ad hoc changes in the process
model is not advisable. It can still be observed too often that companies use agile
methods and processes in projects or parts of them, but do not enable the
corresponding teams to act in an agile manner. Table 1.4 provides guidance for
the selection of the process model.

1.5 Projects are Based on Teamwork

Project work is always teamwork. An individual cannot manage the complexity of a

project doing it alone, but only in association with others. This makes teamwork an
essential success factor in project management. The model of the three levels of
cooperation in Fig. 1.16 summarises the requirements for teamwork.

1.5.1 Content: Working in the System

The scope is always the deeper meaning and the reason for the existence of a project,
whether it is a product, a service, an application, a process, or the further develop-
ment of the organisational culture. In some way, added value must be created for the
organisation or the customer.
In order for several people to work towards a common scope, they must know it
and know what it is about. Objectives and restrictions guide them to make the right
decisions and to create the appropriate documents, e.g. concepts, specifications,
project orders or product visions, product backlog, and sprint backlog. The produc-
tive work is also located at this level.