Escalations are nothing bad in the project or program. They are the demand for spontaneously necessary or not yet taken decisions in a defined way – provided that a regulated governance is established.
Rules
The facts of the case should always be described and agreed upon by both parties (customer and contractor).
Contents of the escalation
Precise description of the facts so that they can be understood directly by third parties.
In what area and at what time did the facts arise?
Who put the facts on the agenda in which reporting medium (e.g. weekly status report)?
What has been done to avoid the original risk or problem, to solve it when it occurs or to mitigate it?
Who was involved in the solution search?
Howtime-critical is the situation or by when is a solution needed?
Identification of the degree of risk and evaluation of the impact.
Which activities are proposed for the solution?
Description of the solution approach with estimation of the timeline, the resources and the name of the person responsible for the solution.
Communication
Escalation always via e-mail. Mails that do not contain all of the above should be returned.
Clear mention of the word “ESCALATION” in the subject line as well as in the mail itself.
All possible measures should be taken to resolve an escalation issue at the lowest level. Before starting an escalation process, the consequences should be clearly articulated.
At each stage, an attempt should be made between both parties to find a solution. If this is not possible, the escalation issue should be passed on to the next escalation stage after prior agreement and taking into account the number of escalation days. (Escalation days = length of stay in working days at an escalation level)
The project manager is responsible for solving the problem and remains so at every escalation stage.
Despite all standardization, special consideration – especially in international project portfolios – must be given to cultural differences among the project participants. The differences should at least be “intercepted”, if not used to advantage. The focus of a project portfolio manager’s work in an international project environment is shifting somewhat away from classic portfolio management tasks such as standardization towards cultural moderation and catalysis. Catalysis in the sense of cleansing intercultural differences and at the same time accelerating intercultural learning.
If there are problems with cooperation in international projects, these usually emerge more strongly than in national projects. Nevertheless, a well-managed international project is praised with more success than a purely national project. With the involvement of a “cultural agent”, these positive synergy effects can be leveraged.
However, not every problem of international projects has cultural origins.
But there are also intercultural problems that are not seen as such.
Cultural differences in international project portfolios
This article is an excerpt of my project study work 10 years ago in the context of the certification as Senior Project Manager (GPM).
Already in 2002, the GPM’s “International Project Work” Section conducted a survey of internationally experienced German project managers and identified the following important problem areas [Hoffmann, H.-E. et al., International Project Management, Munich 2004, pp. 13-14]:
Cultural differences
Communication / Language
Legal and political aspects
Technology / Infrastructure
Personal aspects
The greatest importance was attached to the cultural differences.
Differentiation of international differences
This paper does not deal with differences in laws, norms, guidelines or standards of the project business. Although these may also be influenced by the cultural conditions in different countries. Here only the differences or effects of culture on the project are to be considered. Culture is defined as “the change of nature through human actions and expressions and, based on this, the totality of life and work forms of a human group (people, class, religious community, etc.)”. [Wissen Media Verlag, https://www.wissen.de/lexikon/kultur-allgemein]
The concept of culture
Keller defines culture on the basis of various characteristics [Keller v., E.: Management in foreign cultures: goals, results and methodological problems of culture-comparative management research, Stuttgart, 1982, p. 114ff]:
Culture is man-made. It is a product of collective social action and individual thinking.
Culture is supraindividual and a social phenomenon that outlasts the individual.
Culture is learned and transmitted through symbols.
Culture controls behaviour through norms, rules and codes of conduct.
Culture strives for inner consistency and integration.
Culture is an instrument for adaptation to the environment.
Culture is adaptively adaptable in the long term.
Hofstede presents culture as a group-specific, collective phenomenon of shared values. [Hofstede, G./Bond, M. H.: The Confucius connection: from cultural roots to econonmic growth, in: Organizational Dynamics, Spring 1988, S. 21]
The cultural programming of a project employee / cultural layers
How does culture influence people, and why can Hofstede speak of a “collective programming of the mind”? A person is always born into a culture and absorbs it directly. Cultivation”, i.e. cultural programming, takes place as early as the baby age – at the age of 7, most of the culture is already internalized. [Dahl, Stephan (2000) “Introduction to Intercultural Communication”, from the book by Stephan Dahl: „Intercultural Skills for Business“, ECE, London, 2000]
People are suited to different cultural strata in different stages of life depending on their social environment: [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 17]
The innermost and thus first layer originates from childhood and is characterized by
the country,
the social class,
the ethnic group,
the religious faith or also
the region
where they grow up.
The second layer is made up of vocational training. It often turns out that people from the same occupational group but with different cultural backgrounds understand each other better than people from the same country but from different occupational groups.
The third and last layer is made up of company-specific norms and behaviours. This is the so-called layer of corporate culture.
Since the majority of people often only move within one cultural group – and a confrontation with another culture takes place only superficially, if at all – “cultural programming” is rarely conscious either. International project management is a pioneer of change here. According to my own experience, only after typical project durations of more than 9 months do questions comparing cultures become more strongly discussed. After about 3 months in the course of the project, the respective advantages of the different cultures involved are adapted. After about 6 months, the first “frustrations” appear in the cultural field. After 9 months the cultural aspects are considered more strongly and also really considered. This means that for project durations of less than 9 months, a mature understanding of culture cannot be expected among those involved in the project. The project team member/leader continues to behave according to his cultural background and interprets all incidents according to his cultural programming. Thus, the behaviour of foreign project staff is often dismissed as “funny”, as it cannot be explained by their own cultural programming. An open discussion with another culture is therefore subliminally problematic because it can shake one’s own value system and challenge the questioning of basic values. It therefore seems at least understandable that many project participants avoid this confrontation to its full extent and withdraw into the familiarity of their own culture. This confrontation is unavoidable for project leaders who live in another country for a longer period of time. It takes about 12 months just to master the obvious rituals and behaviour under the assumption that the local language is spoken fluently. [Dahl, Stephan (2000) “Introduction to Intercultural Communication”, from the book by Stephan Dahl: “Intercultural Skills for Business”, ECE, London, 2000]
Another approach without exact origin provides for the following “culture shock phases”:
Phase 1 refers to euphoria, travel preparation, travel fever and curiosity about the other country. It usually doesn’t last long.
Phase 2 is the time of cultural shock when everyday life begins in the new environment.
Phase 3 is called acculturation, i.e. cultural adaptation, when one learns to live under new conditions, when one already knows some of the foreign values and integrates them into one’s own behaviour.
Phase 4 is then the mental stability finally gained, which can take on 3 different forms. Either
Strangers continue to feel strange
or in the new environment just as well as at home, so can live in both cultures
or more comfortable in a strange place.
The length of the phases is variable and depends on the duration of the stay in the foreign country.
Conversely, foreigners are also experienced by insiders (locals) in 4 phases:
Curiosity means positive interest in strangers.
Ethnocentrism means that insiders judge guests/newcomers/foreigners according to their own standards. One’s own little world is seen as the centre and pivot of the world. Ethnocentrism is related to a culture the same as egocentrism is related to the person.
Polycentrism means that different people have to be measured with different standards, as well as the ability to understand strangers on the background of their own norms. A moderate form of multiculturalism.
Xenophilia means that in a foreign culture everything is seen as better than at home.
The cultural programming of a culture
A culture is a group of people who all have the same or at least very similar cultural programming. This means that they almost all behave according to the norms and values of the culture, and measure the behavior of other people against these norms and values. Of course, this does not mean that all persons within a culture are totally identical – they behave only relatively similarly compared to behaviour in another culture, not necessarily compared to their own culture.
Models of cultural contexts
Various models have been developed in the search for explanatory patterns that help to understand the logical connections between norms and rules of a culture. “A model is a simplification of reality. A model can never be complete because it is always a simplification and cannot reflect all aspects of reality. For this reason, there are also different models for intercultural cooperation, each of which represents different aspects. For a project situation it is therefore helpful to be able to compare several models. [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 32]
Cultural levels according to Edgar Schein
Schein distinguishes three cultural levels [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 22]:
The first level contains the directly perceptible characteristics such as clothing, food, music or manners. Although these are visible, they require interpretation.
The second level consists of values and norms that provide guidelines for behaviour in a culture. These are also persons of the respective culture also only partly conscious. Cultural members often assume that these guidelines must also be identical in other cultures.
The third level contains beliefs that are so self-evident that they are ignored.
The cultural dimension “context reference” by Edward Hall
Hall compares cultures with regard to the strength of their contextual reference [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 25]. Under context a situation or message can be understood anything that could be related to it (e.g. tone of voice and experienced or inexperienced colleague) [http://changingminds.org/explanations/culture/hall_culture.htm]. The degree of influence of the context on a situation is cultural and therefore interesting for Hall to define. A culture with a high contextual reference is a culture in which the context enjoys a high degree of attention [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, p. 25].
“Gifts are a sign of appreciation and are expected in cultures with a strong contextual reference to business initiation.” [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 65]
Cultural dimensions according to Hofstede
In order to capture culture, a wide variety of approaches were shaped and studies carried out. One of the most important and yet trend-setting studies, which has come into its own in the meantime, records the following four most important dimensions (see table at the end of the article): Hofstede study. The higher the value, the more pronounced the index.): [Hofstede, G.: Intercultural co-operation in organisations, in: Management Decisions, 5-6/1982, p. 53ff; Index and classification: http://www.clearlycultural.com/geert-hofstede-cultural-dimensions/ ; Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, p. 26ff]:
Power distance: The power distance expresses how high the acceptance is to accept power differences.
Individualism versus collectivism: Here it is described whether the individuals see themselves as individuals and independent or as members of a group/culture.
Masculinity versus Femininity: Masculinity in a culture is recognized as performance-related or success-related and self-confident. A feminine culture, on the other hand, pays great attention to interpersonal relationships and cooperation.
Uncertainty avoidance: Threat from uncertain or unknown situations and their avoidance.
The other dimensions are descriptive or approach supporting dimensions, which were added in 1987:
Time concepts: Here it is defined how strongly a culture is oriented towards the present, the past or the future.
Conceptions of space: Here it is recorded how socially distanced or introverted members of a culture behave.
Contextuality: There is a direct or indirect communication. This means how much context or non-verbal communication is anchored in the culture.
Cognitive processes: How are the thought patterns, the way of thinking, judging and conclusions pronounced in a community. E.g. Analytical, rational versus synthetic, intuitive.
Religious Concepts: Depending on their religious beliefs, the respective cultural members tend to regard their fate as self-controlled or under foreign control.
Effects of cultures on the project business: In the following, the first four cultural dimensions will be used to record the differences in the international project business.
Power distance
If employees from different cultures are deployed in a project and thus follow different power distances, different aspects have to be considered. My Indian colleagues have a higher power distance than my Scandinavian or German colleagues. This means that an Indian colleague expects more individual instructions and wants to make fewer decisions without consulting his project manager in order to be in his comfort zone. This should be applied up to operational guidelines with which a Mexican colleague as well as the Indian colleague feels “more comfortable” with very detailed guidelines, e.g. when preparing a status report. In comparison, induction training should be more detailed and systematic – based on the same project experience. An Indian colleague feels misplaced in a strongly cooperative project structure and expects clear structures and thus stability in his cultural structures.
Individualism versus collectivism
This dimension deals with the setting of priorities within society on the individual or on the group. In an individualistically pronounced society, the individual is at the forefront. In projects with employees from different cultures who represent different individualism indices (degrees of individuality), measures should be taken to support team building. Cultures such as the USA are considered very individualistic, which means that project staff from this country should be absorbed particularly intensively in the team spirit. Asian employees need intensive feedback continuously during the course of the project. They are dependent on feedback from many colleagues. They will actively demand feedback from all sides. It is advisable to include a feedback round in weekly or 2-weekly meetings / telephone calls that are already planned. North American projects required more portfolio-driven coordination rounds than, for example, Asian projects. The approach and coordination in Asian projects is more culturally rooted.
Masculinity versus Femininity
The Hofstede study found that the differences between women and men in this dimension were less pronounced. The cultural differences among men are more pronounced towards the poles versus . In my Scandinavian colleagues, the focus on interpersonal relationships and quality of life was very clear. Pressure to perform is not conducive in such environments, even rather harmful. The target values of a project are usually defined differently there than in comparison to projects initiated in German-speaking countries. This could be particularly clearly determined with the sensitive topic location dissolutions. Topics which were especially discussed differed between the sites in Sweden and Switzerland. In Switzerland, the focus was on the effectiveness of the closure (short project duration) compared to Sweden, where particular emphasis was placed on employee-oriented scheduling.
Uncertainty avoidance
Uncertainty avoidance can be defined as the degree to which the members of a culture feel threatened by uncertain or unknown situations. The differences can be seen in dealing with these threats. Societies with a strong tendency to avoid uncertainty seek to influence uncertainty through rules, laws, codes of conduct and security measures. Accordingly, particular emphasis should be placed on risk identification in countries with low uncertainty avoidance. In “emerging countries” such as Singapore, Hong Kong and Indonesia, the project environment should place emphasis on detailed risk identification. Project managers from these countries tend to overlook or ignore project risks. Project managers in countries with a high degree of uncertainty avoidance, such as Portugal, quickly identify risks on their own, but are more likely to have problems working out risk avoidance. This means that these project managers tend to bring the same risks to the table without taking the necessary measures. These are more “blocked” by the identified risks compared to other cultural circles.
Time concepts
Essentially, two concepts of time were identified in Hofstede’s study. The linear and the cyclical conception of time. In simple terms, cultures in industrial societies are more subject to a linear concept of time than cultures, e.g. in Asia. The linear approach represents the idea that what was in the past is over forever. In contrast, the cyclical time approach is based on the assumption that there is a constant change between day and night, moons, seasons and meal cycles. This approach is based on the assumption that a current performance weakness can be compensated in the future. These different approaches were actually identified in my portfolio. The degree to which objectives have been achieved and, above all, forecasts are strongly influenced by the cultural perception of time in the project manager’s home country. My Asian project managers are strongly guided by the approach that the current performance weakness of the project can be compensated in the near future. Generally speaking, project progress reports are more optimistic in cultures with a cyclical view of time than in cultures with a linear understanding of time such as the USA and Central Europe.
Another difference in the field of time perception can be observed in sequential or synchronous thinking. This means that in sequential thinking the idea prevails that things should be done one after the other. In contrast to the synchronous concept of time, which is based on the assumption that several things can be done simultaneously. In my portfolio, I was able to recognize this tendency not culturally, but person-specifically. This means that I could derive the differences in phase models, for example, less from their origin than from the personality of the project manager.
The German culture says: Everyone can use his time most efficiently if he has to wait for others as little as possible. The Spanish coinage leads: Everyone can make the most efficient use of their time when the issues at hand are closed in a meeting and no further discussion is necessary. In Spain, the one who breaks off a meeting to keep the next appointment is considered rude. [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 20]
Contextuality
The distinction here is made whether in the cultural sphere much context prevails in the spoken (e.g. non-verbal communication; “reading between the lines”) or whether more direct, explicit communication prevails. My European project managers are much more direct / “blunt” in their communication than colleagues from Asia.
Cognitive Processes
Essentially, a distinction can be made here between western and eastern thinking styles. In the West the analytical style prevails and in the East (very pronounced in Asia) the synthetic style. In the West, the problem is broken down, in the East the problem is captured holistically and interlinkingly. Rational and systematic thinking style in the West in comparison to the intuitive and holistic thinking pattern in the East.
Cognitive orientation can also be found in the diversity of problem-solving styles. One of my Indian colleagues is strongly influenced by the “encircling thought”, which means that the problem is surrounded and encircled holistically. Progress is slower, but ultimately more complete and conclusive. In contrast, a German project manager breaks down the problem into its individual elements more strongly and solves subproblems for subproblems. Individual progress can be recognized more quickly, but may require subsequent holistic correction.
Religious concepts
Depending on religious beliefs, different cultures tend to see their fate as foreign or self-directed or controlled. I could not confirm the effects on religious beliefs in my portfolio, since cultural circles with a typically foreign-controlled background nevertheless produce project managers with a strong self-drive. It seems that changes have taken place since the study was conducted or that I have identified exceptional cases.
The cultural dimensions of Fons Trompenaars
Another cultural model was developed by Fins Tromenaars and Charles Hamptopn-Turner with the following seven dimensions: [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 29ff]
Universalism / Particularism: In universal cultures (e.g. Anglo-Saxon and German-speaking countries, Holland and Scandinavia) all people are treated according to the same rules and laws. In particularist cultures, on the other hand, rules and laws are respected by one person, unless an important person would be disadvantaged. The same applies to concluded contracts: [ Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 67]. In particularist cultures, exceptions to contracts are made on a case-by-case basis. Universalistic cultures do not allow this.
Individualism and collectivism: Identical with Dimension von Hofstede.
Emphasis on emotions: This is a comparative measurement of how feelings such as joy, sadness or commitment are shown. Project team members from the Middle East raise their voices to emphasize your emphasis. Asian project workers are associated with a loud voice, anger and lack of control.
Specific / diffuse cultures: Specific cultures (e.g. Anglo-Saxon countries, Scandinavia and Holland) clearly define roles and assign concrete situations or localities to them. In such cultures, the role of the superior is not necessarily transferred to another (e.g. private) environment. In diffuse cultures (e.g. Arab countries and Africa), assuming a role means that it also applies to a change of environment.
Performance versus origin: In performance-oriented cultures (e.g. Anglo-Saxon and Scandinavian countries), superiors are respected who perform their tasks competently and demonstrate adequate professional competence. In cultures based on origin (e.g. China and Malaysia), on the other hand, the project manager receives his status through his title, age or family affiliation.
The relationship to time: In polychronic cultures (e.g. Latin America, Africa, the Middle East, France), time is an unlimited, simultaneous commodity that can stretch. One plans, but can easily adapt the plans. Several things are done simultaneously. For this reason, one can observe a French project team member approaching a meeting and important telephone calls in parallel. In monchronic cultures (Saxon, northern and central European countries), on the other hand, time is considered a limited commodity that must be carefully planned and adhered to. Work is more sequential, i.e. linear.
Relationship to nature: Indoor controlled cultures (e.g. Anglo-Saxon countries, Northern Europe) want to keep their environment and environment under control. This is closely linked to the belief that one can influence one’s destiny through action. Externally controlled cultures (e.g. Arab, African and Asian countries) shape people in such a way that they see themselves as part of nature and should therefore adapt it to their environment.
Nonverbal Communication
Non-verbal communication and body language is not a direct cultural dimension, but a collection of behaviours. A direct connection with a cultural dimension as described above does not seem to exist, at least not directly. Basically one can assume, however, that in Asia in particular body language is rather subdued, whereas in Southern Europe body language is used more. It is therefore advisable to familiarise oneself with the most common symbols before interaction.
Avoidance of intercultural misunderstandings
Intercultural competence is defined as the ability to move successfully in cultural areas other than one’s own. The acting persons should be able to understand the ideas, motives and problems of interlocutors from other cultural areas and to react appropriately. However, since there are still no clear findings in science about the key factors for human adaptation to foreign cultures, there is also no clear understanding of what intercultural competence ultimately consists of.
If a project manager or project member perceives a violation of rules by a person of another culture, his conclusion should not be “he violates the rules”, but “he violates our rules”. [Hoffmann, H.-E. et al., International Project Management, Munich 2004, pp. 18-19]
“So it’s important to understand the behavior of others in the rules of your culture.” [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 19]
Cultural misunderstandings can also be reduced by applying universal communication rules:
Meta-communication: Meta-communication is communication via communication. It is about communicating the meaning and intention of what is said by talking about the rules and patterns according to which communication takes place.
“My intention is to … experience …”
“How would you proceed in your culture if you had that intention?”
Active listening: Active listening means picking up the others in their emotional world. Active listening includes the following techniques:
Repeating the heard facts – the listener reproduces what the speaker says in his own words. “You mean that…”
Speaking to feelings – The listener tries to express in words what feelings and sensations he has perceived in the speaker.
“I have the impression you enjoy it.”
Inquiry – Inquiry offers the opportunity to present the problem situation even more clearly and to understand it better. “What do you mean by…?
Promoting qualities for learning intercultural competence:
Ambiguity tolerance the ability to cope with unstructured and contradictory situations
problem-solving skills
Empathic ability to read out the empathy, concerns and interests of others from vague hints, gestures or other signals.
Tolerance of frustration to deal adequately with errors, misunderstandings and failures.
Conflict ability and conflict tolerance
Readiness to learn with curiosity
Strong individual-cultural identity awareness of one’s own cultural imprint as a prerequisite for dealing with people from other countries/cultures
Distances ability to view oneself from a certain distance
Humor, the ability to laugh at oneself.
Prejudices and stereotypes
“A collection of information on what behaviours and norms typically prevail in a culture is called a stereotype. [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 19] Stereotypes help people to interpret the behaviour of people from another culture.
This in turn allows the classification of further information.
The prejudice arises when the embossed stereotype is no longer changed by new information.
Nobody meets the standards in all points, some even deviate strongly from each other [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 21]:
Population distribution and stereotypes
Moreover, some countries are in such a state of flux that there are clear cultural differences between parts of the younger and older generations, such as the former communist states. [Hoffmann, H.-E. et al., International Project Management, Munich 2004, p. 33]
Country
Power Distance
Individualism
Masculinity
Uncertainty avoidance
Malaysia
104
26
50
36
Guatemala
95
6
37
101
Panama
95
11
44
86
Philippines
94
32
64
44
Mexico
81
30
69
82
Venezuela
81
12
73
76
China
80
20
66
40
Egypt
80
38
52
68
Iraq
80
38
52
68
Kuwait
80
38
52
68
Lebanon
80
38
52
68
Libya
80
38
52
68
Saudi Arabia
80
38
52
68
United Arab Emirates
80
38
52
68
Ecuador
78
8
63
67
Indonesia
78
14
46
48
Ghana
77
20
46
54
India
77
48
56
40
Nigeria
77
20
46
54
Sierra Leone
77
20
46
54
Singapore
74
20
48
8
Brazil
69
38
49
76
France
68
71
43
86
Hong Kong
68
25
57
29
Poland
68
60
64
93
Colombia
67
13
64
80
El Salvador
66
19
40
94
Turkey
66
37
45
85
Belgium
65
75
54
94
Ethiopia
64
27
41
52
Kenya
64
27
41
52
Peru
64
16
42
87
Tanzania
64
27
41
52
Thailand
64
20
34
64
Zambia
64
27
41
52
Chile
63
23
28
86
Portugal
63
27
31
104
Uruguay
61
36
38
100
Greece
60
35
57
112
South Korea
60
18
39
85
Iran
58
41
43
59
Taiwan
58
17
45
69
Czech Republic
57
58
57
74
Spain
57
51
42
86
Pakistan
55
14
50
70
Japan
54
46
95
92
Italy
50
76
70
75
Argentina
49
46
56
86
South Africa
49
65
63
49
Hungary
46
55
88
82
Jamaica
45
39
68
13
United States
40
91
62
46
Netherlands
38
80
14
53
Australia
36
90
61
51
Costa Rica
35
15
21
86
Germany
35
67
66
65
United Kingdom
35
89
66
35
Switzerland
34
68
70
58
Finland
33
63
26
59
Norway
31
69
8
50
Sweden
31
71
5
29
Ireland
28
70
68
35
New Zealand
22
79
58
49
Denmark
18
74
16
23
Israel
13
54
47
81
Austria
11
55
79
70
The higher the value, the more pronounced the index.
In project portfolio environments or even for project directors themselves, it is often not easy to get clear signals from the projects. This is to check whether they are on the right track. Often quite extensive and complex project portfolio control systems are used to determine exactly this. Practice shows that due to the heterogeneity of the projects (very large vs. very small, in country X or country Y, in business area A or B) these are not available the same number of reliable measurement points for the most diverse projects. This report shows how 10 identical simple questions provide reliable early warnings for a wide range of project sizes and types.
Why do I need a simple project early warning system?
I have already described another early warning here, which has completely different measured variables. Depending on the usage, one these approaches should be applied. In a company with highly standardized methods, processes and tools in project management, the next logical step on the way to even more quality for projects is to check the compliance of these specifications. The project management handbook describes processes, provides templates and tools to handle all types and sizes of projects in a standardized way. Even the specific usage of standard applications such as MS Project is often described and specified in detail. Compliance criteria therefore arise in the areas of policies, processes, templates and tools.
Because efficient and above all uniform methods are often lacking, which could quickly identify core problems of projects (and can quickly avert them), senior management – despite high standardization in project management – is often surprised by projects which
are behind schedule,
overrun the budget
and do not achieve the agreed scope
which in turn leads to
Customer dissatisfaction and
not achieving the business goals
An early warning system (EWS) contains questions on the project status, which are to be answered monthly by the project managers in the form of a questionnaire.
Objectives of the early warning system
The objective of the Early Warning System is to develop and/or integrate a set of tools and processes that quickly identify potential project problem areas and provide a meaningful tool for escalation and problem resolution as long as they are still available in a simple form to avoid surprises.
The detail goals can be:
Introduction of a simple, scalable system that is easy to maintain through state of the art technology.
Introduction of a system that enables problems in projects to be identified and eliminated in the quotation phase, start up phase and run & maintain phase.
Introduction of processes and tools that cannot be bypassed and ignored; to confirm compliance to processes and tools.
Use the EWS results to extend existing reports with the EWS information.
Ensure tight time-boxing from problem identification to resolution.
Develop a management communication plan to continuously inform senior management about the consistent implementation and enforcement of EWS tools, processes and reporting across the organization.
The success factors of the early warning system
In order to ensure a global early warning system, the following success factors must be observed:
Timely and accurate evaluation of program/project status related to key indicators.
Line management with profit & loss responsibility for programs and projects is responsible for responding to negative responses and tracking actions until completed.
The questions must be examined intensively by senior management.
The questions must be used globally unchanged in all possibly existing regional systems.
Program and project managers answer these questions monthly for each project.
Standard reports are made available to program/project sponsors to support action tracking.
Objectives of the early warning system
The following questions represent a selection for an early warning system. When adapting for specific organisations, the relative deviations are also adapted in the form of numerical values. The so-called risk response indicates the response option, which leads to a forced commenting of the entry and serves as an “alarm signal” in a consolidated evaluation.
#
Question
Risk Response
1
Did the last customer survey score more than 3.5 points (out of 5)?
No
2
Is the project plan updated and recalculated weekly with work done and remaining work?
No
3
Are all approved change requests mapped in the project plan?
Yes
4
Does the staffing run according to the planning in the project plan?
Yes
5
Has joint project governance been adopted?
Yes
6
Has a steering committee been held in the last 30 days?
No
7
Is the Schedule Variance > 10%?
Yes
8
Is the cost variance > 10%?
Yes
9
Has the project done any work outside the approved project defined scope?
Yes
10
Have all deliverables performed so far been accepted?
No
In a database system, the questions in the “Answer” field must be answered with “Yes/No”.
If a question is answered positively, then this question is finally answered.
If the answer to a question is negative, the project managers are asked to enter measures to solve the negative situation.
“Action” field: Enter measure to solve the negative situation
“Responsible” field: Select the name of the person responsible for the action.
“Planned date” field: Enter the date by which the task is to be completed (planned date).
“Status” field: Select the status of the action.
The results are ideally presented in a company-wide web-based EWS tool to create central reports and evaluations.
The link with a project management handbook questionnaire
If (worldwide) uniform guidelines, processes, tools and templates are available in the project management area, an extension of the questionnaire should be considered.
A detailed survey should be carried out initially at the start of the project and in the case of significant project changes by means of a detailed self-assessment questionnaire, which clearly goes beyond the following possible questions on the EWS supplement.
#
Question
Risk Response
1
Was the project definition template from the project management handbook used?
No
2
Has the estimation procedure and the estimation templates been used according to the project management handbook?
No
3
Is there a weekly Earned Value calculation based on the current project plan?
No
4
Are problems, risks, acceptances, change requests continuously recorded in the template from the project management handbook?
No
Personal observations on the EWS
I was able to observe the following findings during the supervision of project managers on the subject of EWS and the evaluations:
Despite very precise and unambiguous questions, additional explanations (ideally in the form of a manual) to the project managers and, in the other direction, comments on specific issues by the project managers are often required. Uniform guidelines by the central authority for specific non-standardized cases are to be ensured. This ensures the quality of the early warning system in these cases as well.
The project management handbook supplementary questions confirmed that only project and program managers who had already been trained could provide meaningful answers. It is better to not ask as a mandatory question in order to not dilute the quality of the statements.
When analysing the adaptation of a comparable system in an organisation, the following basic considerations arise:
The first questions can be transferred almost completely to other companies.
Such a supplementary (parallel) reporting can only be enforced by global guidelines. Regional or even departmental initiatives would experience too much resistance.
An automatic notification and reminder for the creation of the EWS report must be provided.
A monthly frequency may prove to be too low for companies with smaller projects on average.
An automatic analysis of the results is required, taking into account the additional manual comments. An analysis without consideration of the additional comments results in a wrong picture of the overall evaluation.
As with all other reporting, it should also be noted here that an early warning system can also be excluded for particularly confidential projects / customer environments.
The reports must be mapped IT-technically in such a way that they (almost) cannot be circumvented and ignored; in order to confirm the compliance to processes and tools. These should, for example, be linked to the filing of the official status report.
The EWS results should be integrated into existing reports in order to inform the classic addressees of the project status report about the additional status of the early warning system. This ensures that this group of recipients also carries out a direct or indirect quality assurance of the information.
The results of the early warning system should be regularly compared with complete project or programme audits in order to validate and continuously improve the meaningfulness.
In a project, the early warning system must not be triggered initially by the first filing of a project status report, but by the creation of project numbers or project codes, for example.
The early warning system should be introduced in stages. First, only projects with high project volumes or complexity should be included in the scope (it is important to apply hard criteria). This also allows the analysts to better manage the project manager’s support efforts.
If you are leaving a program, you should consider a few things when preparing and handing over the program. Here, a 6-phase approach has proven to be the best for me, which I use again and again.
1. Preparation (as early as possible!)
Align with stakeholders
Outline Knowledge-Transfer-Plan
Agree budget for knowledge transfer period
Search for successor and receive okay on specific person from stakeholders
Confirm final start date of successor (adapt timeline of knowledge transfer plan)
2. On-boarding (-3 weeks)
Successor starts on project as additional source
Project assignment to be defined
Onboard successor following all regular administration activities as access rights, calendar invites, handover process documentation etc.
Introduce successor in newsletter
Shadowing (-2 weeks)
3. Shadowing (-2 weeks)
Successor is your current stand in if anyhow possible
Successor attends all of your meetings too
Successor is watching all of your core activities
Successor updates and amends joint knowledge transfer plan and ticks off activities
4. Re-Shadowing (-1 week)
Show less presence, only attend team
meetings but no customer meetings
Be there for any help for your
successor
Be prepared to take over some
operational activities
Send all still incoming requests /
questions to your successor
5. Backup (starts with day of handover)
Show less presence, only attend team
meetings but no customer meetings
Be there for any help for your
successor
Be prepared to take over some
operational activities
Send all still incoming requests /
questions to your successor
6. Phase Out (+1 week)
Process all off-boarding activities
for yourself
Release Project Assignment
Be there to help your successor
Do not take any operation tasks
anymore
Give a farewell party and say good
bye in the newsletter.
Send all still incoming requests /
questions to your successor
Leave! (+2 weeks)
Success factors for a proper handover
Involve customer and all stakeholder
in an early stage.
Do not arrange processes program /
stream person centric but process / accountable centric.
Do
not be single point of contact for multiple processes yourself,
Instead
make each of your team member accountable for one or more processes from the
beginning of the engagement (Management by Objective).
Plan and prepare your leave as an
own project itself.
Prepare a knowledge transfer plan
which must be agreed by all stakeholders.
Break
down knowledge transfer in granular activities (1-3 hours).
Ask
your successor to maintain this plan and tick each closed activity off.
Handle
this plan and update it like any other project plan.
Communicate your leave to whole team
latest at beginning of knowledge transfer period.
Foresee a backup period after
successful knowledge transfer of up to two weeks.
Define a clear handover date in
knowledge transfer plan.
Agile work or delivery is only possible if necessary decisions can always be called up. It also does not work without appropriate governance. There is huge similarity in turnaround situations of classical projects with the approach of agile projects. The focus here is on short iterations and close coordination with the customer. The introduction of agile principles should be based on this observation. Agile principles will continue to spread differently in different industries. But whoever thinks of agility about method or technology is wrong! Early results in the project and close coordination with the real customer are not method or tool results.
Agile project management does not work without appropriate governance
Agile work or delivery is only possible if necessary decisions can always be called up. In my article “Communication Principles in a Project” it is easy to see that the short time until a decision is made is extremely important. This is often slowed down or even blocked by the middle layers of management in a company. This so-called permafrost cannot comprehend the need for agility often sensibly identified by top management. Likewise, decisions necessary in the course of the project cannot be made by the senior management themselves, as are not be placed correctly with them.
Agile project management is very similar to the approach of classic projects in turnaround situations
In both cases, the focus is on short iterations and close coordination with the customer. The introduction of agile principles should be based on this observation. The classic project plan is then usually only a reference for contract-relevant delivery items. The chain of failure in projects is the customer relationship and thus the governance structure, then the tools and processes and at the latest the employee frustration. When introducing agile principles, the sequence is exactly the other way around. In my experience, the team atmosphere in project organizations can indicate a wide variety of problems at any time, and not only that “something” is wrong, but also in which project management domains (see my article SmileyPoints). It would also be interesting to use this method when introducing agile project management.
How will the agile vortex spread now?
As can be deduced from my article “Project Manager in 2030“, the agile principles will continue to spread differently in different industries. What this “agility” will look like, whether pure SCRUM, SRUM of SRCUM, Kanban, scaled agile, SAFe, LeSS, Spotify will be shaped by the customer and company environment (i.e. products, services, industry, size, etc.). Is “classic project management” dead? Certainly not, because there are certain complex (very large programs) and complicated (repetitive projects) for which classical project management will be the better alternative. Nevertheless, it makes sense for the classic project manager to make tool picking out of the agile box. But whoever associates agility with method or technology is wrong! Early results in the project and close coordination with the real customer are not method or tool results. Concepts and planning are required in both approaches. Approaches such as scaled agile approaches e.g. SAFe take this aspect particularly into account.
The challenges for product owners or project managers
The challenge for the drivers of ventures, whether product owner, project manager or program manager, will now be that they should play different instruments in different environments. Because the dogmatic orientation “we only do agile single projects” can only take place in companies that have no need for diverse interfaces and environments. The exclusive product owner or program manager will therefore rather remain the rare species. A stigmatization of the two approaches is therefore certainly not meaningful, but the combined application or simply said the agile classical project is the future. Early and constant results and close end customer coordination are the success factor in all projects.
Summary: Using a project planning and control software only as a visual representation of the planning status is a waste of time. A few tips have to be followed and MS Project and Co are also very useful for project monitoring and control.
I often hear from prospective project managers, but also from experienced project managers, that a project management tool such as MS Project is not practicable. It is too complicated and the actual control is not really possible.
If you consider the following tips nothing will go wrong anymore:
Set in the options that MS Project or the tool of your choice will base the planning on “fixed work”.
The availability (hourly capacity and holidays) of resources/qualifications must be entered in the project calendar.
Do not set a manual date (fixed date), except project start or finish date.
For each task / work package, a predecessor (at least the project start milestone) and successor (at least the project end milestone) must be entered.
Do not enter a duration, only the effort for the task / work package.
Only one resource/qualification should be entered for each activity.
Always display the critical path in the schedule (Gantt). This must be displayed throughout the entire project duration without interruption. Otherwise there is an error, e.g. manual date set.
Only plan detailed for a maximum of 2-3 months in advance (resources and effort).
And the last obstacle is again and again that your company does not invest an MS Project license for you. Then get ProjectLibre as Opensource or another freeware.
The first hours or at least days within a project do shape most of the ongoing communication in a project or program. In other words: if you do not or too late define communication principles in a project you will need to cope with issues in a later stage.
All soft topics like usage of mobile phones or laptops during meetings, respect between each other, listening to colleagues, confirm understanding, participation by all in meetings, avoid mails but call instead, and so on and so forth are topics which are often more easy to follow than the individual behavior in following topics. Therefore guidance should be given.
A set of my standard communication set up in projects from day 1 onwards as an example below.
Useful communication principles
I would like to ask you to follow these communication principles:
To minimize our mail traffic and an easier organization of our mailboxes we should agree on the following rules:
Only send mails towards the team members who need the information!
Sounds funny, meant is: avoid big distribution list without need! (same with copy!)
As long as we are working on drafts or on finalization of templates the drafts are only send around the nominated team
Often big copy distribution lists in mails are used for escalation just to be sure in case this could be needed: Please contact and inform the Program Manager respectively the needed team member before. The Stream Leads are asked to design a workaround for internal escalation handling in their streams.
We agree that the work of all of us is very important for this program! For that reason only mails with a critical timeline are marked as urgent.
Mails with a critical impact for the program content have to be marked with URG at the beginning of the subject.
To avoid overload the capacity of our mail server we send links where ever it is possible
Last but not least: Don’t bury the needed information’s in mail chains …
Mail naming convention
All Mails have to be marked with the kind of information is given with the e-mail
INF: Information; an information is given to the addressees, no action required
ACT: Date, Action; and action is required by the addressee
DEL: Delivery; a required action is delivered
URG: urgent information’s start with this prefix e. g. URG: DREAM: SP01: … – see also file naming convention
Mail subjects needs to include a short and clear description of the content
Addressees on copy have in general no action !
Escalations In general the escalations come up as followed:
Team Members to Subproject Managers
Subproject Managers to Project Management
Project Management to Program Sponsor / SteercoE.G.: INF: DREAM: SP01: Mail Convention
Document naming convention
All documents in the program are named as followed:
Date (yyyymmdd)
Project Name (DREAM) and sub project number (e. g. SP01)
Document name
Version (drafts V 0.1 ff; finalized versions V 1.0 ff)
2min.Effective meetings are always a challenge. There are many guidelines and checklist available for meetings. But up to now I have not found a good template for an effective meeting agenda.
In my daily usage I identified the need for two different agenda formats depending on the length of the meeting or better the number of agenda topics.
Having a telco I always use following simple format (in case not many topics need to be covered) since years:
INITIAL SITUATION/AUSGANGSSITUATION
Project status needs to be reported to steerco until Friday 12:00 CET
Please update your work packages until Thursday 10:00 CET Server Link (ALL)
Please update action items status / resolution Server Link (ALL)
Update reporting template (ML)
AGENDA
Review interface issues between work packages (MW)
Align on action items across work packages (MW)
Align on Team Discussions items on project server (ML)
Issues and risks to be aligned on (ML)
RESULTS EXPECTED OF THE MEETING/ ERWARTETE ERGEBNISSE DES MEETINGS
Aligned view on the project status
NEXT STEPS AFTER THE MEETING/ NÄCHSTE SCHRITTE IM NACHGANG ZUM MEETING
Report to be consolidated (ML)
Report to be reviewed and send to steerco (MW)
For face2face workshops or long lasting telcos I prefer using following format also for many years:
Berlin, Hauptstr. 14-16, 1.OG, Room E1.15a, Monday 05. Feb 2018 – CMO FMO Big Picture Goal: Common understanding of CMO and FMO Big Pictures and related activities Approach: Time Boxing Preparation: Presentation: Link on Server Materials: 2 beamers, moderation suitcase
Time (CET)
Topic
Host
Input and preparation needed / Owner
Result expected / Owner
Attendees
09:30 – 10:00
Introduction and target of meeting
MW
Introduction – no preparation needed
All
All
10:00 – 10:30
CMO Picture Overall
LI
Slide deck / LI
Common understanding of the CMO
All
10:30 – 10:45
Break
All
10:45 – 12:45
CMO / FMO INM
LI
Understanding CMO slide deck on specific process / LI
Black Board FMO Picture / CS
LI, CS, MA, UA and UA
12:45 – 13:30
Lunch break in restaurant
All
13:30 – 14:15
CMO / FMO PRM
LI
Understanding CMO slide deck on specific process / LI
Black Board FMO Picture / CS
LI, CS, MA, UA and AB
14:15 – 15:00
CMO / FMO CHM
LI
Understanding CMO slide deck on specific process / LI
Black Board FMO Picture / CS
LI, CS, MA, UA and SE
15:00 – 15:30
CMO / FMO CFM
LI
Understanding CMO slide deck on specific process / LI
Black Board FMO Picture / CS
LI, CS, MA, UA and ME
15:30 – 15:45
Coffee Break
All
15:45 – 16:15
CMO / FMO CPM
LI
Understanding CMO slide deck on specific process / LI
Black Board FMO Picture / CS
KE, CS, MA, UA and KL
16:15 – 17:00
Wrap up and next steps
MW
Action item log updated. / MW
Work package descriptions amended. / work package owners
Does the project manager still exist in 2030 – as we know him today? The answer in a nutshell: No. The tasks of the project managers will change in the areas of leadership, organization and project implementation.
I was tempted to take part in the German Projektmagazin’s blog parade. Because on the one hand we are talking here about a term “project manager” that has come under intense discussion (especially in the German speaking project manager community using terms project managers and project leaders slightly differentiated) and on the other hand about a period of time that is very long even for futurologists. The researchers do not believe to be capable to define changes in this time dimension.
The project manager as a term
Both parts of the word project manager are currently in great discussion as to whether they are meaningful or even contemporary. Projects as such like in BI unit of Otto are no longer seen as necessary. The (project) leader or project manager is not intended in the pure agile set. Here, leadership will be given an even more important focus than it already is today. Managers in the sense of controlling and directing will become less and less relevant due to the already visible developments.
It is problematic to give a future statement about the project manager in 2030, if already today the term as such no longer has the anchoring, as perhaps in the preceding decades. Let us dare an attempt.
Time as a yardstick
It’s 12 years till 2030. Appears long. If you think about what the world looked like 12 years ago, backwards from today 2018: There was no iPhone, no Android, no app stores, no Youtube, no Spotify, no Kindle, no Tablet, no digital full format sensor in a serial camera (to put my hobby into context). One recognizes it happens more in 10 or 12 years than one assumes. That’s why futurologists don’t calculate in years, but in weeks in order to emphasize the short-term nature and to evaluate future models and statements faster and make them more comparable. The futurologist assumes 50 weeks per year. How many weeks have passed since New Year’s Eve? Three. So less than 50 weeks to New Year. In these three weeks not many things happened according to the human feeling. In the best case, you have planned three weeks and reflected them three times. But the “cross-week” tactical themes don’t seem significant. Nevertheless, project managers, Scrum Masters or one-man companies are working on the revolutionary aspects of the future. In the next 597 weeks until the year 2030.
What will the project environment look like in 500 weeks?
What will the world look like in 500 weeks? It seems pretty certain that in 500 weeks I and 70% of the German population will no longer own a car. In 500 weeks we won’t have any smartphones anymore. In 500 weeks we will no longer be using a supermarket. In 500 weeks we will produce more electricity in our households than we consume. In 500 weeks we will eat meat bred in laboratories. In 500 weeks we will receive ears for people from the 3D printer as medical spare parts. In 500 weeks robots will support the care of elderly people. In 500 weeks, 40% of the German population will have intelligent non-medical implants. In 500 weeks …
All these endeavors – let’s call them projects here for simplicity’s sake – are accompanied by people. This is not about generating ideas, but about implementing them. The fact that the creation, definition and implementation of ideas should be close to each other in terms of personnel is supported by some and criticized by others.
Requirements for today’s project managers in 2030
What impact does this have on me and all the other project managers from 2018? The visionary project manager who drives this one idea will no longer exist. We can already see today how complex the world of work and the world as such has become. This can no longer be united by one person. So it will have to be more and more a team effort. Which is good. This naturally has an effect on the aspect of leadership. We recognize trends already in agile beginnings which do not represent however yet the end of the road. The following generations have and demand a different attitude to work. I have experienced this many times myself and already talk like my grandfathers (“The young people today”). But also this change is good, because …
“No change, no development.” Birgit Ramlow (*1948), employee and hobby aphorist
Transformation vs. Revolution
And now a much criticized term from the business economics: Transformation. When I think in weeks and design endeavors in a manageable time frame, there are transformation aspects. It is revolutionary when we experience a complete technological or paradigm shift. The smartphone was not a revolution, but a courageous and creative combination of available technologies. The push came somewhat delayed by the apps. But even these are not a classic revolution, but a further development on another platform and therefore used by more users. Why was the smartphone ultimately perceived as revolutionary and has this outward appearance? Well, my thesis is that managers of competitors like Nokia and Siemens weren’t brave enough and didn’t listen to the market. Imagination and creativity were not lacking. Because carmakers are also being predicted the whole development today and the reactions to it are, in my opinion, too hesitant. In development periods of 4 years per real model change, i.e. 200 weeks, you can no longer act today. So what can we deduce from this for the project manager?
He will work a lot in transformation projects and will contribute to the revolution by quickly placing new projects with courageous and fast acting managers.
Company management or committees in 2030
The biggest changes will certainly be one level higher in the hierarchy (if you want to talk about it at all – today at least one level higher) required at the portfolio board, at the product owners or however a company implements strategic decision making for itself. At Otto in the product area, in the agile environment by the product owner – as a representative for the management or the portfolio board in classical project management. These committees will certainly have to meet the defined requirements even more than in my article, written in 2016, in order to enable the timing between the transformations to revolutions. And let’s be honest, in the ~ 60 weeks since this article was written, the claim is still not fulfilled. So there is a need for action.
Different demands on the project managers
Will the development depend on the type of project?
There will no longer be a project manager who can manage projects universally in all industries and project types. At least today’s challenging attitude will be less and less correct.
In the area of software development, agile approaches and hybrid mix forms will develop for large programs. A design of these hybrid forms is material for another blog post.
Investment projects will continue to be similarly organized as today. And thus also the role and tasks of the project manager. Even if today’s examples, such as Berlin Airport, are not promising.
The young project manager in 2030
But what about the young project manager who will manage projects for the first time in 2030? He starts with a handicap. Because he himself, but also his IT architects and other colleagues, will not have experienced any more “journeyman years” here in Germany, since all “journeyman activities” were already relocated from the last century nearshore or offshore in the 1990s. It will no longer be so easy to start a career as a project manager, however shaped it may be. This can be observed today in environments that have changed for some time, such as the textile industry. Here in Germany today there are often problems to find qualified seamstresses for the sample collection. For this reason, companies themselves have to relocate business-critical areas such as design and sample collection abroad. This will also be the case with the project managers of the future. In the virtual world, with the supporting technologies, it will always be easy to carry out projects here in Germany. But also the proximity to the customer is less and less important due to the virtual support technologies. This means that in 2030 it will also be possible to carry out projects completely from a remote location (including project managers) without missing customer proximity in Germany.
Why does the topic of committees move us as project managers? We need clear decisions for our projects in cases where our empowerment is not sufficient. Why is it often difficult to obtain these necessary decisions promptly, clearly and precisely?
For this we have to understand that there are countless terms for one and the same … and many terms are used several times in practice.
I will come to the typical problems with the committees that result from this later.
Where can we find a solution? PMI braces role descriptions and organizational structure. So we cannot be helped here. Prince2 defines the mentioned committees in detail and harmoniously with IPMA or GPM.
DIN 69901-5 defines the project board as a “superordinate body to which the project manager reports and which is available to him as a decision-making and escalation body”. This does not really help much.
Then let’s see how the PM3 of the GPM supports us.
What are steering committees? They can align the ship’s rudder in all directions on all seas.
These steering committees are … internal and … cross-project. Patzak/Rattay defines steering committee, steering group and project advisory boards as synonyms. The task of this committee is to analyse, observe and control the selection of projects and the interrelationships between projects.
The project board is also very well defined in the Duden … in my opinion ….. Namely as the “Committee for Economic Steering”. In contrast to the steering committee, this is not about defining the general meaning of a project, but about economic observation and influence. The project board is therefore represented at the steering wheel in the car on specified roads and can decide which direction to take at which intersections.
This committee, the steering committee, can also include external partners such as important suppliers or the end customer.
The PM3 states that there are no uniform rules in the organizations how control boards should work. It therefore differs from company to company. However, a typical responsibility can be worked out. The steering committee
appoints the Project Manager
selects projects
stops projects
initiates projects and shapes the
sets high level targets.
The PM3 also describes typical areas of responsibility for the project board. These are
project progress tracking
to clarify conflicts and powers between line and projects
accept milestones and project results
escalation in corporate management or portfolio management and
possibly, if there is no separate change board, the decision of amendments.
What do we as project and program managers have to do to be successfully supported by committees? Based on my experience I will explain the most important points.
we need to shape these bodies by
integrate necessary external partners
attract members to the committees who are highly placed in the hierarchy
demand that a spokesperson for the panel be appointed
escalation instances and solution durations at the respective escalation stages and also to
agree change management process.
What prerequisites and knowledge are required in the steering committees? According to Patzak / Rattay, they must have transparency and knowledge about the corporate strategy and knowledge about the project portfolio. Otherwise, the steering committee or portfolio board cannot act sensibly.
In order to be able to use the committees properly, we must observe a few basic rules.
Children and managers have at least one thing in common. They can only remember 3 things.
In your remarks as project manager in the project board, I therefore recommend that you address
the most important status information
a decision request and
a wish to cooperate
to the management.
Always pay attention to formulate these core messages concisely and precisely, because since the year 2000 until today, the attention span with us humans has fallen from 12 to 8 seconds. Thanks to the new technology and the new lifestyle.
Now I come to the typical problems that have already been announced. Experiences from my projects.
Berlin. Public project. In public projects, it is often very difficult to separate the project client and the shareholders. Especially the governance organization becomes complex. Defining the requirements in such a construct is particularly difficult, as is managing changes. A “reinstatement” – this verb sounds already governmental or public – is preprogrammed here.
South Africa. A project at an energy company with several divisions, which is to standardize central processes and IT systems. Due to the sheer size of the project, several external parties are required. In large-scale projects, the project offices are often staffed by external consulting companies to underline the challenging and neutral character.
Even as the largest contractor, it can be difficult to formulate uniform committee definitions and appointments. Agreeing on maximum solution times for escalated problems at the respective escalation levels is often an impossibility, but critical to success.
Israel. Again an energy company with several subsidiaries to harmonize their procurement organizations and processes. A further problem with the committee use is the decision fixation and above all the enforcement of decisions. In the run-up to committee meetings, pre-socialised decision alternatives and decisions are often questioned or not enforced again after the meeting has taken place. Here the cultural influence is formative and steering out. Decision making can take many times longer.
Bonn. Escalation levels are not mirrored for the client and contractor, i.e. there is a different number of hierarchy levels. Problems are inevitable. A further problem unfortunately arises from frequent statements and implementation of “an internal project must also function without LA”. How is that supposed to work?
I would like to conclude with the typical problems here.
What 3 core messages should you take with you today?
We must understand the differences between the Project Board and the Steering Committee and always recognize the two types of bodies, and
