Escalation Rules

2 min.

Summary

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?
  • How time-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.

Further information on the communication rules can also be found here.

Escalation steps

  • 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.
Escalation Pyramid

International project portfolio management taking cultural differences into account

19 min.

Summary

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:

  1. Curiosity means positive interest in strangers.
  2. 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.
  3. 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.
  4. 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 IndividualismMasculinityUncertainty 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.

Project Early Warning System in 10 questions

6 min.

Summary

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.

#QuestionRisk Response
1Did the last customer survey score more than 3.5 points (out of 5)?
No
2Is the project plan updated and recalculated weekly with work done and remaining work?
No
3Are all approved change requests mapped in the project plan?
Yes
4Does the staffing run according to the planning in the project plan?Yes
5Has joint project governance been adopted?Yes
6Has a steering committee been held in the last 30 days?
No
7Is the Schedule Variance > 10%?
Yes
8Is the cost variance > 10%?
Yes
9Has the project done any work outside the approved project defined scope? Yes
10Have 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.

#QuestionRisk Response
1Was the project definition template from the project management handbook used?No
2Has the estimation procedure and the estimation templates been used according to the project management handbook?No
3Is there a weekly Earned Value calculation based on the current project plan?No
4Are 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.

Handover of a Program in 6 Phases

2 min.

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.

Have fun in your new project / program!

Agile vortex?!

3 min.

Summary

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.

Project planning software – everything just crap?!

2 min.

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.

Communication Principles in a Project

3 min.

Summary

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

  1. 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
  1. Mail subjects needs to include a short and clear description of the content
  2. Addressees on copy have in general no action !
  3. Escalations
    In general the escalations come up as followed:
  1. Team Members to Subproject Managers
  2. Subproject Managers to Project Management
  3. Project Management to Program Sponsor / SteercoE.G.: INF: DREAM: SP01: Mail Convention

Document naming convention

All documents in the program are named as followed:

  1. Date (yyyymmdd)
  2. Project Name (DREAM) and sub project number (e. g. SP01)
  3. Document name
  4. Version (drafts V 0.1 ff; finalized versions V 1.0 ff)

E.g.: 20170220_DREAM_WP01_name convention_V 0-1.doc

The four elements are separated by an underscore.

All documents which have been reviewed follow this naming convention:

  1. <Name of Original Document>
  2. Rev<Initials of Reviewer>
  3. Date (yyyymmdd)

z. B.: 20170220_DREAM_WP01_name convention_V 0-1_RevMW_20170307.doc

Meeting Agenda

2 min.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

PREPARATION NEEDED / ERFORDERLICHE VORBEREITUNGEN (including owner)

  • 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

Steering Board Decision preparation / LI

 All

 

Project Manager in the year 2030

6 min.

Summary:

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.

Steering committees and project boards – understand, shape and use

4 min.

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?

  1. We must understand the differences between the Project Board and the Steering Committee and always recognize the two types of bodies, and
  2. actively design.
  3. Feel free to contact me for active exchange.