The Coming into Force of the Contract

particular (cf. Fig.
30
).
• My view of the results of the project in relation to individual project objectives
is
. . .
• What worked particularly well was
. . .
?
• What worked particularly poorly was
. . .
?
• How do I feel overall about the completion of the project?
7
Use of Project Management Methods
In the following chapter the most important methods and tools are described in
detail and supplemented with practical examples.
The methods and tools are the basic know-how, the tools of the trade for the
project manager. Another crucial requirement for the effective and efficient use of
the
project management methods
is for the project owner and the core project
team to have a fundamental understanding of the
project management methods
.
In practice, the methods and techniques of project management are a key
component of skills enhancement measures for specific target groups.
Formal 
project
acceptance
Decision to end
project made
Release final 
project report
Draw up
final project 
report
Plan 
Project
close down
process
Complete proj.
documentation 
& safeguard 
knowledge
Handover 
residual 
activities
Fig. 30
Project close-down process
314
W. Rabl

---

The following method headings are described:
• Review of conformity to strategy
• Review of project-worthiness
• Project name
• Project logo
• Project order
• Project environment analysis
• Analysis of relationships with other projects
• Project structure plan
• Work package specifications
• Project activity distribution chart (responsibility matrix)
• Milestone schedule
• Milestone trend analysis
• Project bar chart (Gantt diagram)
• Plan for use of project personnel (project resources plan)
• Project costs plan
• Business case
• Claim management
• Organizational chart
• Allocation of competencies between the project and line operations
• Relational descriptions of project roles
• Project communications structures
• Project-specific ground rules
• Risk analysis of the course of the project
• Earned Value Analysis (EVA)
7.1
Review of Conformity to Strategy
The “project initiating” multiple project management process step involves
reviewing the project objectives contained in a project proposal in relation to
their conformity to the strategy of the multiple project management area of refer-
ence. The outcome of the review of conformity to strategy is a statement of the level
of conformity to strategy which is part of the basis of decision-making in relation to
project approval.
Preparatory area- or department-specific requirements must be established for
the use of a review of conformity to strategy. For this, the strategy of the business
unit must be described, which may, for instance, be derived from the corporate
strategy or result from the business unit’s product portfolio.
Furthermore, area-specific scaling must be established. Depending on the area of
use, various levels of detail may be useful in the scaling (e.g. project objectives
correspond to corporate strategy: 100 %; project objectives do not correspond to
corporate strategy: 0 %; or establishing of defined intermediate levels).
In the end, an area-specific assessment procedure must be drawn up in order to
assign the project objectives to the corporate strategy.
Project Management
315

---

7.2
Review of Project-Worthiness
A project is a scheme which is of such complexity in terms of content and its
organization that it demands the use of employees from several organizational units
(interdisciplinary make-up of the project team). The minimizing of the objective-
attainment risks (outcome risk, deadline risk, costs risk and quality risk) requires
the use of special tools, and it justifies the additional workload involved in planning,
budgeting for, monitoring, and managing the completion of tasks, as well as the
formation of a temporary project organizational unit.
The evaluation of project-worthiness is carried out by project services during the
project initiating process. Defined characteristics are used to differentiate between
standard tasks, schemes, projects and programs.
7.3
Project Name
Employees from various corporate and/or departmental cultures are involved in
interdepartmental or inter-company projects. If no specific project culture is defined
in the project team, these various cultures clash, and conflicts may arise. The
specifying of a project name can provide a sense of identity and contribute to the
creation of a project culture. A memorable and distinctive project name contributes
to the identification of the project and to improved external communication
(e.g. “prof pm reloaded” similar to the film “Matrix Reloaded”).
7.4
Project Logo
The provision of information and communication are a key factor in the success of
projects. Also, in
project-oriented companies
several projects are carried out
simultaneously and in parallel. Like the project name, a unique, distinctive project
logo contributes to the identification of the project, to the recognition of project-
related information, and to improved external communication. In addition, a
project-specific logo helps to establish a feeling of “togetherness” within the project
team, and it fosters team development processes as well as a project culture.
7.5
Project Order
The
project order
is a written agreement between the project owner and the project
manager regarding important framework conditions for the project. The
project
order
(cf. Fig.
31
) is the formal commission for the launching of a project and
consequently it is the trigger for the project start process. Through it the project
manager assumes responsibility for achieving the agreed objectives with the agreed
outputs within the agreed time schedules and the specified budget. In return, the
316
W. Rabl

---

project owner promises to provide the project manager with the agreed resources
and the agreed budget. Their signatures underline the reciprocal agreement.
Adjustments and additions may be made however in the course of the
detailed planning, so that a distinction can be made between the provisional and
the final
project order
. If in the course of the project the framework conditions
alter to such an extent that the main factors (those relating to timing or of a
factual or social nature) change, this necessitates the updating of the project order
and the associated concluding of a fresh agreement between the project owner and
the project manager.
The
project order
is drawn up based on the
delineation of the project
and the
analysis of the project context, and it must have at least the following contents:
• Project name
• Start date/time; end event/time and date
• What are and are not project objectives
• Content of the project (project phases)
• Project resources and costs
• Project owner, project manager, core project team
My view of the project results...
Really well! –
what has gone particularly well?
Personal 
interactions 
Teamwork 
contributions 
Constructive 
working
Quality of the 
results
Achievement of 
objectives
we are
really going places
at Salomon
Outcome of the 
portfolio 
management 
concept
Living the 
PM role
Management 
support
Personal 
interactions
Negative (need for improvement!) -
what went particularly badly?
Many team mem-
bers have left
Failure to involve 
sub-team
Resource 
availability 
Prioritizing
Individual team 
members not 
interested in 
various WPs
Priorities 
Time
Hiving off of 
various WPs to 
individuals 
no 
contributions 
from core team
Resources 
situation
Lack of gen. 
mgt. Involve-
ment (project 
mgt., branch, 
GWS)
How are things 
going?
PE skills 
enhancement
Project coaching
Project manager 
coaching
Development of PM 
guidelines and 
project standards
Establishing of 
project portfolio 
management
Fig. 31
Examples of methods of working and issues relating to the completion of the project
Project Management
317

---

7.6
Project Environment Analysis
The project environment analysis is based on the analysis of the project’s social
context. It is a tool for managing the social relationships within a project, and it
examines the project’s relationships with the relevant environments. Relevant
environments means all the people or institutions which may have an influence
(positive and/or negative) on the project (cf. Fig.
32
).
The project environment analysis firstly involves collecting, listing and grouping
all the relevant environments within the project team. They are then represented in a
project environment diagram. If all the relevant environments have been recorded
in a structured form of presentation, the project environments can be analyzed in
terms of their relationships to the project (reciprocal expectations, potentials, and
conflicts).
Based on this, it is possible to develop strategies and measures for organizing
relationships in a project environment table. Moreover, continual “social control-
ling” can be supported throughout the project period.
7.7
Analysis of Relationships with Other Projects
A project is frequently connected with other projects which are being carried out or
are planned. The so-called factual context analysis involves analyzing the
connections with other projects and the corporate strategy from the perspective of
the project, and organizing them in the form of measures.
Such relationships may produce synergies or lead to conflicts. This analysis
facilitates the organizing of the transfer of information and the organizing of
consultations. As in the case of the project environment analysis, either a diagram
(cf. Fig.
33
) or a project table (cf. Fig.
34
) can be used as the actual tool.
7.8
Project Structure Plan
The project structure plan (PSP) is a structured representation of the outputs that are
to be provided in a project. The outputs can be subdivided into phases (2nd level
process-oriented) and work packages (3rd and following levels process- and object-
oriented).
The work packages should be able to be planned and monitored, i.e. the through-
put period for any work package should not be longer than the sequence of the
project controlling cycles. In addition, they need to be clearly assigned by the
person who is responsible for work packages.
The PSP is the key planning and controlling tool as well as the key communi-
cation tool for the project owner, project manager, project team and relevant project
environments, and it forms the integrative basis for all the following planning tools
(time schedule, personnel resources plan, costs plan, activity distribution chart,
work packages specification). The PSP is drawn up within the core project team
318
W. Rabl

---

Fig. 32
Next project example of a project order
Project Management
319

---

Fig. 33
Next project project environment analysis
320
W. Rabl

---

(interdisciplinary approach) with the aid of creative techniques (post-its), and
it should be presented with the help of IT systems.
The starting point for drawing up the PSP is the delineation of the project from a
timing and factual perspective. If the project is sufficiently complex, the drawing up
of a PSP requires the presentation of a results plan which subdivides the overall
entity into corresponding areas to be focused on (partial results/deliverables).
Firstly, the 6–8 phases of the project are defined. In this regard, the process-
oriented presentation of the phases is a critical factor in achieving structures which
can be continuously planned and controlled. In line with the phases, corresponding
work packages are defined in a top-down manner which comprise the verb (activity)
and noun (object). Each work package and each phase must be provided with a PSP
code so that each work package can be clearly assigned.
Based on the PSP, the detailed work package specifications and the workflow
plans and time schedules can then be drawn up, the manpower requirements
estimated, the project costs planned, and risk planning and quality assurance
can also be carried out and the project can be documented. Figure
35
shows the
next project project structure plan as an example.
Program Q
Project C
Program R
Project D
Project A
Project B
Project
Fig. 34
Factual context analysis
Project / 
Program
Relationship 
(potential / conflicts)
Measures
Responsi-
bility
Dead-
line
Project X
•
Market analysis 
may be useful
•
Competes for same 
resources
•
Obtaining of 
the results
•
Agreeing of 
availability
Fig. 35
Factual context analysis table
Project Management
321

---

7.9
Work Package Specifications
The work package specification is based on the project structure plan (PSP) and
provides a detailed description of work packages (objectives, tasks, inputs/outputs).
This method provides a high level of guidance, in particular for extensive and
complicated work packages.
The work package specification provides a detailed description and delineation
of the content and results of a work package (WP) from a quantitative and quali-
tative perspective in order to ensure that all the people who are involved in the
project (above all the project manager and the person who is responsible for work
packages) have a common understanding of what a specific work package is. Work
package specifications may also contain further information, such as resource
outlays, duration, or criteria for measuring progress with outputs, as shown in
Fig.
36
. A specification is not required for all work packages, but only for those
the nature and scope of which is unclear.
Work package specifications are drawn up by the person who is responsible for
work packages and are agreed in the project team. As well as the increased
precision of planning which they allow, work package specifications are also a
valuable supplementary tool for the controlling of outputs.
7.10
Project Activity Distribution Chart (Responsibility Matrix)
Due to their complexity, projects require cooperation between several people, and
often even cooperation between several organizational units. The activity distri-
bution chart (cf. Fig.
37
) is used for the detailed planning of the allocation of tasks,
as the basis of objectives agreements, and for conflict management. The starting
point for the activity distribution chart is the project structure plan (PSP), and also
the project organization and the project environment analysis.
An activity distribution chart is arranged in the form of a 2-dimensional matrix.
The work packages are listed in the rows, and the project roles are listed in the
columns (project owner, project manager, project team members). The roles which
are to be undertaken are shown in the intersection cells of the matrix
(V
¼
responsibility, i.e. person responsible for work package; M
¼
cooperation;
I
¼
receives or provides information, and E
¼
decision).
7.11
Milestone Schedule
A milestone is a key event in the course of the project, e.g. the project start, the
putting together of a work package, the issuing of an approval, or the end of the
project.
322
W. Rabl

---

The milestone schedule provides the rough time scheduling of the whole project
by listing the timing of key, critical project events. In addition, during controlling
the milestone schedule provides an overview of the current status of the project, and
it is therefore a suitable tool for communicating with the project owner.
The basis for the milestone schedule (cf. Fig.
38
) is the project structure plan
(PSP). Initially, time-critical events within the project are defined and listed. Then,
dates are assigned to the milestones (base/current/actual), which are expressed in
terms of events and comprise a verb and a noun.
Seven to nine milestones should be defined per project, and the project start and
end are obligatory milestones. A milestone should be formulated for each phase/
controlling cycle. The milestone dates can form the basis for milestone trend
analysis.
Fig. 36
Next project project structure plan
Project Management
323

---

7.12
Milestone Trend Analysis
The milestone trend analysis is used for the monitoring of time scheduling. It is
mainly an information and visualization tool, but not a tool for researching causes.
Preconditions for the use of milestone trend analysis are a realistic time schedule
and an open work atmosphere. Since the estimating of adherence to milestone dates
can only be carried out subjectively, it is important to create an atmosphere in which
it is possible to admit to mistakes.
Figure
39
shows how in the case of milestone trend analysis the originally
scheduled milestone dates are entered in a right-angled triangle along the
vertical axis, and the reporting time points are entered at the same scale along the
horizontal axis (depending on the project period these vary between every 2 weeks
and every quarter).
The response of the person who is responsible for a milestone to the question:
“When will your milestone be reached” provides both the reporting date/time and
the coordinates of the milestone. If dates are repeatedly postponed, the line rises.
If the schedule is adhered to, the line is horizontal. If the line falls, deadlines are
reached earlier than planned.
Fig. 37
Next project work package specifications
324
W. Rabl

---

Fig. 38
Next project activity distribution chart
Project Management
325

---

7.13
Project Bar Chart (Gantt diagram)
Bar charts are suitable for the diagrammatic representation of simple project work-
flow structures. They illustrate the timing and logical dependencies of the
work packages and the associated project phases.
The project structure plan (PSP) serves as the basis for the project bar chart.
Depending on their complexity, the work package deadlines or phases are shown in
the form of time bars, and milestones can also be incorporated into the bar chart. If
due to the complexity of the project it is necessary to illustrate the logical sequence,
further detail can be provided in the form of linked bar charts.
As in the case of the milestone schedule, a distinction is also made in the
controlling activities related to the project bar chart between the deadline, the
basis plan and the current plan (cf. Fig.
40
).
7.14
Plan for Use of Project Personnel (Project Resources Plan)
The plan for use of project personnel is based on the output planning, and it quanti-
fies the resource requirements (manpower requirements) for each work package or
phase of the overall project. It provides an overview of staff availability in con-
junction with the time schedule so that resource constraints can be identified.
In the plan for use of project personnel all the project’s human resources are
planned according to empirically ascertained values, and based on the project struc-
ture plan. The manpower requirements (in person days) for the project are shown in
a table format in (cf. Fig.
41
). The detailed planning of the use of manpower can be
carried out both at the work package and the phase levels, and the level of detail of
the planning should match that of the controlling for reasons of comparability.
Fig. 39
Next project project milestone schedule
326
W. Rabl

---

The plan for use of project personnel consequently facilitates not only the use of
staff and cost control, it is also used for ascertaining the success of the project and
for monitoring the project’s profitability.
At each deadline
date the current
milestone dates
are re-entered
on a time axis
The scalability of the two 
time axes should be identical
in order to produce a 45 degree
actual deadline area
Deadline is deferred
by the same amount
of time as
the period since the 
last deadline date
If the 
milestone 
is prior to the 
deadline date,
the latter must be
met and cannot
be deferred any
further
Current
deadlines
Milestones
Deadline dates
Project controlling
Actual deadline
area
Deadline 
met
The first milestone 
remains firmly fixed
in the plan 
throughout
the course of the 
project
Fig. 40
Milestone trend analysis
Fig. 41
Next project project bar chart
Project Management
327

---

Fig. 42
Next project overview of resources
328
W. Rabl

---

7.15
Project Costs Plan
The project’s costs plans are drawn up based on the output plans and the types of
costs that will be incurred in the project, and they provide information about the
planned costs (budget) of the project and help to identify resource constraints
(cf. Fig.
42
).
The basis of the cost planning (cf.) is the project structure plan (PSP). Firstly, the
cost categories (personnel, materials etc.) are defined. The detailed costs planning
can be carried out both at the work package and the phase levels, and the level of
detail of the planning should match that of the controlling for reasons of compar-
ability. Then, a specification of inputs is drawn up for each cost category and phase/
work package, and the overall costs are determined. When doing this, care must be
taken to ensure that only the costs which can clearly be allocated to the project
between the start and end of the project are included.
The project cost plan consequently facilitates not only cost control, it is also used
for ascertaining the success of the project and for monitoring the project’s
profitability.
7.16
Business Case
The business case involves a comparison of two or more alternatives which are of
sufficient complexity and entail sufficient risks to warrant the effort of carrying out
a detailed analysis and evaluation. The method involves the analysis of the actual
and target state, and the development of potential solution options, including
implementation planning for the meaningful assessment of benefits, costs and risks.
The business case is used to reveal the profitability of a project, and it concerns
itself with the scheme regardless of its project-worthiness or
project delineation
.
An assessment requires detailed planning of alternative versions using appropriate
assumptions. Project costs are therefore one or more of the relevant payment flows
for the business case. The project budget is not necessarily identical to the business
case, but it frequently forms a part of it (cf. Fig.
43
).
The business case starts out by showing the actual situation, and it then sets out a
desired target state and describes alternative approaches that can be taken to
achieve it as well as detailed plans. This is followed by the (financial) evaluation
using the methods of conventional investment analysis (cf. Fig.
44
). Finally, the
decision is formulated and implemented.
7.17
Claim Management
According to DIN 69901-5 issued by the German Institute for Standardization
(
2009a
,
b
), claim or claims management is the “monitoring and evaluation of
deviations and/or changes and their economic consequences for the purpose of
ascertaining and asserting claims”. In project business, claim management is one of
the tools that is available both to the principal and the contractor. Its aim is to
clarify, with both parties’ agreement, the commercial consequences of events which
Project Management
329

---

Fig. 43
Next project overview of costs
330
W. Rabl

---

occur during the course of the project but which were not foreseeable at the time
when the contract was concluded. Claim management consequently comprises all
the tasks involved in averting claims, making provision for claims, dealing with
claims, and also establishing claims.
In practical terms this means preventing claims from arising, keeping the
additional costs involved in carrying out the project low, enforcing (justifiable)
claims against another contracting party, mounting a defense against (unjustifiable)
claims made by another contracting party, and avoiding expensive legal disputes.
Claims may relate to quantitative and/or qualitative deviations or changes in
performance/outputs, or consist of time delays and/or additional costs.
7.18
Organizational Chart
The organizational chart presents the project’s organizational structure and conse-
quently clarifies who works on the project and in what role. It provides an overview
of the
temporary organization
of the project. At the same time, it acts as a
communication tool and provides the basis for the definition of responsibilities
within the project organization. It shows details of the structuring of the project
organization into project roles, the relationship of the people who have roles in the
project to each other, and the functional composition of the project team.
Presentation in a “network form” is recommended rather than a hierarchical
form of presentation (cf. Fig.
45
). This focuses much less on the hierarchy than on
the cooperation between the role holders and/or on their communication structures
within the project. Project roles can also be carried out by people from outside the
department or company as part of an integrated project organization.
Magic
project triangle
Outputs
Deadlines
Resources,
costs
Objectives/ benefits of the project
e.g. in the event of an IT 
migration: operational savings of €
10,000 / yr.
Taking account of 
"teething troubles"
e.g. project costs of 
€ 40,000.00
e.g. project benefits 
of € 75,000.00
€
t
€
t
...
Fig. 44
Example of the connection between a business case and a project
Project Management
331

---

7.19
Allocation of Competencies Between the Project and Line
Operations
With regard to the organizational integration of projects, three types of project
organization can be distinguished:
Influence Project Organization
The project staff remain in their specialist departments (cf. Fig.
46
); the manage-
ment of resources is carried out by department managers. Disadvantages of this are
extended decision-making procedures, time-consuming escalation, and the
members of the project team not fully identifying with the project. The project
2
0
1
3
5
6
Years
€
Discounted
net cash flows
Cumulative
net cash flows
Interpolated
break even
4
Fig. 45
Example of a business case in practice
Project
team member
Project
employee
Project assistant
Financial
controller
Project
employee
Project
team member
Core project team
Project team
Project steering committee
Project manager
Project
coach
Project
employee
Project
employee
Project
sub-team
Project
sponsor
Claim Manager
Fig. 46
Example of a project organization
332
W. Rabl

---

manager does not have the authority to issue instructions; line activities frequently
take priority over the project.
Pure Project Organization
A separate project organization exists alongside the permanent organization
(cf. Fig.
47
). The project staff concentrate fully on the project, and decisions are
taken speedily. Problems may nevertheless arise in relation to the provision of staff
and the coordination of resources; the project staff lose their links to the permanent
organization.
Matrix Project Organization
The project organization is temporarily interwoven with the line organization, and
the project team members remain assigned to their respective departments
(cf. Fig.
48
). This leads to a flexible, planned use of staff between the line
Management =
project sponsor
Project 
manager A
Controlling
Purchasing
Production
R&D
Sales
Fig. 47
Example of influence project organization
Project
PE
PS
Permanent 
organization
Management
Purchasing
Production
R&D
Sales
Project 
organization
Fig. 48
Example of a pure project organization
Project Management
333

---

organization and the project. Due to the dual reporting responsibilities of the project
team members, the matrix project organization is however very demanding in
resource management terms. Overall responsibility for the project lies with the
project manager.
A recommended way of settling the allocation of competencies is to answer six
questions which are shown in Fig.
49
.
7.20
Relational Descriptions of Project Roles
Project roles are basically described in terms of tasks (responsibilities) and compe-
tencies (authorities). The tasks which are assigned and the responsibilities which
result from them should go hand in hand with the transfer of competencies.
A relational (reciprocal) defining of roles gives the people who are involved in
the project the opportunity to agree with each other what their respective expect-
ations and competencies are. These agreements provide guidance on how to act in
the relationships between the role holders, and therefore help to prevent conflicts
about roles.
For this, it is firstly necessary for the project manager to define the expectations
which the project owner might have of him, and the competencies which he in turn
expects the project owner to give him. He then puts into words what he himself is
looking for from the project owner and the tasks which he sees as falling within the
latter’s area. In a discussion with the project owner the project manager coordinates
and agrees the formulated expectations and authorities with the project owner
(cf. Fig.
50
).
A similar procedure can take place between the project manager and the project
team. If they are provided, the standard role descriptions in the company project
management guidelines can be used as a basis for discussion. This makes it easier to
allocate tasks and to ensure the provision of competencies.
Management
Controlling
Purchasing
Production
R&D
Sales
Project 
management
Fig. 49
Example of matrix project organization
334
W. Rabl

---

7.21
Project Communications Structures
Project communications structures govern the project’s periodic communication
requirements (cf. Figs.
51
and
52
). They facilitate the provision of information and
decision-making, and the structuring of environmental relationships. Examples of
possible forms of communication are one-to one discussions, meetings, workshops,
and presentations. Communications structures should be planned on a cyclical basis
and decided on within the project team.
Project meetings are a key management tool, and they enable, for example, the
exchanging of information, coordination of results, decision-making, and/or the
agreeing of objectives. The communicating of differing types of information
requires different types of meeting of various length to be held at various fre-
quencies with different people attending them. It is important to distinguish
between meetings about content (e.g. sub-team meetings to discuss detailed
problems and agree technical concepts and solutions, etc.) and periodic project
management meetings, such as controlling meetings and project owner meetings, in
which project management subject matter (objectives, outputs, deadlines, resources
and costs as well as the organization and context) are the main focus.
If project communication problems arise in the course of the project, the cause
may lie in the communications structures that have been defined. Examples of
possible ways of amending them are changes to their frequency or content, holding
additional meetings or cutting out some meetings, or making changes in terms of
the people who attend them.
Create clarity regarding managerial authorities
in terms of 
content 
in terms of 
personnel
What?
Work package, 
contents
Tasks, 
competencies
When?
WP deadlines, 
time limits
Holidays, 
time off in 
lieu 
How?
Methods, 
procedures
Skills 
provision, 
equipment
How 
well?
Quality
Performance 
assessment
How 
much?
Resources, costs
Salary, 
bonuses
Who?
Person resp. for 
WP
Selection of 
PTM/PE
Goals
Project manager
of project employee
Employee's
supervisor
Employee, 
line and project
Fig. 50
Competency matrix for project and line roles
Project Management
335

---

7.22
Project-Specific Ground Rules
Project-specific ground rules provide guidance for cooperation within the project
team. Particularly in the case of complex projects, ground rules may foster the
establishing of an appropriate project culture.
It is the project manager’s job to establish a common culture defined by values,
standards, communication and ground rules etc., and to reflect it in the project
controlling activities, and/or to initiate appropriate management measures. Ground
rules should be jointly devised within the project team. In order to underline their
binding nature, ground rules can also be documented in the project manual, as
shown in Fig.
53
.
7.23
Risk Analysis of the Course of the Project
Risk analysis is the systematic identification of potential loss events/deviations
from target and their implications. Risks associated with the course of the project
are identified and assessed using the criteria of adherence to deadlines and budget
Reciprocal 
expectations
»
Tasks
»
Authorities
»
Responsibilities
Definition of role
of project manager
»
Tasks
»
Authorities
»
Responsibilities
Definition of role 
of project sponsor
L
T
R/K
Reconciliation
Fig. 51
Relational defining of roles
336
W. Rabl

---

and attainment of actual goals, as shown in Fig.
54
. The fundamental task is to
identify risk factors and their negative impact on the progress of the project.
The first stage of risk analysis is to identify risks by assessing the following
criteria: meeting deadlines (D), attainment of actual objectives (O), adherence to
budget (B). The risk evaluation which follows this determines the probability of
their occurrence and the possible implications for the progress of the project. This