Definition of goals in the “Six Interdependencies” playing field

4 min.

Summary

Project objectives are the establishment of requirements which are as quantified as possible and which must be met in order for a project to be considered successfully completed. Conflicts of objectives are to be avoided. An absolute prioritisation of the goals is recommended. In the case of objectives, one must always pay attention to the combination of SMART objectives, completeness of the objectives and, above all, the delimitation of benefit and non-objectives. An absolute prioritisation across all goals in order to be aware of one’s own priorities is helpful. In addition to the magic triangle, the aim is to distinguish between non-targets, benefit targets and now consciously the negative benefit targets as damage and to provide resource planning optimised for all organisations involved.

What are goals and how should they be?

Project objectives are the establishment of requirements that are as quantified as possible and that must be met in order for a project to be regarded as successfully completed. DIN 69901-5:2009-01 defines the project objective as “the totality of individual objectives achieved by the project”.
A complete definition of objectives requires the identification of all relevant stakeholders, which can lead to conflicts of interest. Conflicts of objectives are to be avoided, i.e. the different project objectives must fit together.
The magic triangle defines performance (including quality), costs and deadlines. The magic triangle is supplemented by further dimensions through the six interdependencies.
The goals are to be defined as SMART:

Specific/Simple Simple, understandable, concrete
Measurable Operationalized, quantified
Achievable/attainable Achievable, socially accepted, worthwhile
Realistic/Relevant Objectively attainable
Timeable/Timely Concretely planned in terms of time

Define objectives in a delimited way

Often there is talk of “never-saturated stakeholders”, I have experienced in practice that it helps to have absolute prioritisation across all goals in order to make people aware of their own priorities. In other words, in addition to the must-can-target categorization, a prioritization with a clearer definition of what is the 1st, 2nd, 3rd, 4th, 5th, … x most important goal is recommended.

One must always pay attention with the goals to the combination of SMART goals, completeness of the goals and above all the delimitation of benefit goals (= business benefits/business objectives) and also non-goals. A consideration of these target categories certainly helps to encourage the stakeholders to make a clear statement or to hold on to their expectations in advance, to commit them even better.

The benefit of the project can be defined by the benefit goals of the project. And just as with risks and opportunities, there is a positive and negative sign here. With the “Six Interdependencies” I have consciously chosen the negative sign (i.e. damage here) as the initial viewing angle, as with risk management, in order to deliberately provoke this lighting. In the past, benefits and thus benefit goals were often and well defined by project managers (in contrast to their performance goals).

Social goals

In my opinion, an example of “training on the job” within the framework of the project is a good example of a social goal that can be well defined in terms of objectives, provided that “training on the job” takes place during the course of the project. If, on the other hand, this “training on the job” takes place in the follow-up of the project on the basis of the use of the project object (e.g. use of the implemented software in everyday operations after the end of the project), it is a clear benefit goal and must also be defined as such. If, on the other hand, the training is essential for the implementation of the project, it is a performance goal, because otherwise the object of performance will not be completed or achieved.

Goals in the playing field of the Six Interdependencies

The supplemented interdependencies help my perception according to the clear definition of the project object and the demarcation by the use of this and the well definition of the basic conditions (context determination) in the framework of resources, damage and stakeholder satisfaction.

In my opinion, the Six Interdependencies bring more to light the things that have so far been defined, in part neglected, on the edge, next to the magic triangle, by benefit goals, resource planning (but so far only with the focus on the project and not as is now the case with the Six Interdependencies of the entire (parent) organization(s) involved). In practice, I have already achieved positive, more conscious and more complete goal definitions and delimitations. Thus the six interdependencies show all known practice-proven project methodical aids like magic triangle, in addition delimitation of not goals and use goals and now consciously the negative use goals as damage, conscious restriction of the resources and however not only for the project (as it happens classically with the resource planning primarily), but also for all organizations involved an optimized resource planning.

Thus, the Six Interdependencies are a combination of already known, previously independently considered influences and now additional consideration of damage and cross-organizational resource consideration together:

Six Interdependencies

What now newbie? Or who does not ask, remains stupid …

3 min.

Summary

You come to a new company and take on a new role or you take on a new project? How you plan a good handover was described in handover of a program in 6 phases. Now you are in a conversation with one of your new colleagues to determine where the shoe pinches or what needs to be tackled first. Since you will usually not only have an interview with a single colleague in order to have an overall view of the situation, it is advisable to conduct these interviews in a structured manner. For this purpose, I have collected a few questions over the years that are suitable for each interview and can raise interesting aspects.

How do I organise the interviews?

You should always differentiate between team-related and individual questions, because in the beginning it is easier to talk about the team or the overall situation than directly about your own sensitivities.

  • Team or overall situation
    • What is the biggest challenge we face right now or in the near future?
    • Why are we facing this challenge?
    • What are the most promising and untapped growth opportunities?
    • What do we have to do to realise their potential?
    • If she were me, what would you focus on?
  • Individual
    • How satisfied with your task? In which direction do you want to continue?
    • What do you expect from your job in the short / medium term?
    • What do you expect from me?
    • What are your strengths / what do you want to contribute to the team?
    • Which work processes can be improved?
    • What is the cooperation/productivity in the team/team atmosphere like?
    • What do you / the team / the department need to perform better?
  • Wishes to the genie in a bottle?
    A question that often brings up ideas that have not yet been expressed is the question about the three wishes to the fairy. Specifically this means which 3 wishes would you put to the fairy in the given context. Surprising and often very helpful answers come up. These often round off the picture or bring out completely new aspects.

How do I ask?

If the flow of conversation comes to a standstill, you want to recognize a clear priority or you want to find something out more precisely, then the following questions are appropriate.

  • Conversation fit
    It is very important to find out whether something is depressing the other person and whether the conversation is not meaningful at the moment.
  • Alternative or comparative questions
    • What’s better: this or that? Either way? Here or there?
    • If that, then what? If not so, by what means?
    • Scaling questions: On a scale from 0 to 10, how do you deal with this situation?
  • Determination of causes
    If you believe that the mentioned cause or reason is not yet substantially addressed, then follow up like a small child with 5 times “Why? If you don’t dare to use them, the 5-Why-method is also popular with scientists.
    Asking for the “why” can also reveal the reasons for the behaviour and the motivation of the behaviour.
  • Paradoxical questions or worsening questions can help in the event that creative solutions are needed or a new perspective is to be adopted. Example is, what do I have to do to make the product a flop?
  • Circular questions help to look at situations from different angles. For example, what would Mr Müller say?
  • As an alternative to the genie in the bottle question, you can also place the wonder question: The initial situation is that, as if by magic, all problems have been solved and you ask what would be different, how do you know that the problem is gone, how did the cooperation change or which other question of change can be helpful?

Achieving regularity

Carry out such discussions immediately after entering the new role or task and, above all, regularly. This will keep you on the ball. If you want to record changes early on and across the entire workforce or the entire team, my contribution to team spirit and early indication is ideal. The questions are also a good basis for an employee interview.

Stakeholder Management as an Element of the Six Interdependencies

4 min.

Summary


In order to identify the right stakeholders of the project, the environment analysis is carried out as a precursor. The social environment factors are included in the stakeholder analysis and it is recommended to consider them according to the following dimensions: Power and conflict potential. The objective of the stakeholder analysis is to group the stakeholders in the individual quadrants of a 4-quadrant portfolio in order to represent a corresponding number of stakeholder strategies. If I consolidate the stakeholders in a stakeholder portfolio quadrant, I have the chance to plan a consolidated measure using the common strategy of the quadrant. Various sources of error in the preparation of the stakeholder analysis are pointed out.

What is a stakeholder?

As already mentioned in my “Six Interdependencies“, the consideration of stakeholders is an essential component for project success. Stakeholders are individuals, groups of people, organizations or the entirety of all those who are involved in the project, directly or indirectly affected by it or have a justified interest in it.

Environmental analysis as a basis for stakeholder analysis

In order to identify the right stakeholders of the project, the environment analysis is carried out as a precursor. The project environment analysis is a systematic, forward-looking consideration, observation and analysis of the positive (supporting) and negative (disruptive) influences of the project environment on the project, to be introduced as early as the initiation phase. A distinction is made between the social and factual environmental factors. A further distinction can be made between project-internal, project-external or company-internal or company-external factors. A differentiation exclusively between internal and external factors is not specific enough. Opportunities and risks in the further course of the project planning can be determined from the objective environmental factors and interfaces of the project can be made conscious.

Stakeholder analysis and its determination

The social environment factors are included in the stakeholder analysis and it is recommended to consider them according to the following dimensions: Power and conflict potential. Other dimensions such as influence, interest can be qualitative but not necessarily clearly grouping dimensions. Interest and influence can be positive, negative, high or low. The advantage of power and conflict potential is that they can be high and low, but not positive or negative at the same time. Why do we only want to record high and low values of the two dimensions and not e.g. values with very high, very low etc.? Low conflict potential stands for (potential or actual) promoters and high conflict potential for (potential or actual) opponents. In practice, a constant consideration of the (potential) opponents and promoters is necessary anyway.

The objective of stakeholder analysis is to group the stakeholders in the individual quadrants of a 4-quandrant portfolio in order to subsequently reflect a corresponding number of stakeholder strategies in it. It therefore makes sense to group the stakeholders in a portfolio into high and low power, high and low conflict potential. A direct allocation of stakeholder strategies can then take place directly.

Stakeholder strategies and their allocation in the portfolio

The following strategies can be included in a stakeholder portfolio:

  • Participative strategy based on participation and active involvement, communication and information of the project environment actors, e.g. joint decision making workshops,
  • discursive strategy, which (mostly reactive) is geared to the objective analysis of the project environment, e.g. by means of conflict resolution instruments,
  • repressive strategies characterised by the use of organisational, informational or factual power, e.g. management requirements or selective information.

For the fourth quadrant, it is recommended to provide for purely informational measures, which, however, do not represent a real strategy and are therefore not referred to as such.

A meaningful stakeholder portfolio thus looks as follows:

Stakeholder-Portfolio

Stakeholder strategies – why is that?

Why do I want to look at strategies and not just measures for each stakeholder? Measures per stakeholder are time-consuming and costly. If I now plan individual measures for each stakeholder, I have a complex bundle of measures. If, on the other hand, I consolidate the stakeholders in a stakeholder portfolio quadrant, I have the opportunity to plan a consolidated measure using the joint strategy of the quadrant.

Typical sources of error in stakeholder analysis

If stakeholder strategies are mapped on the basis of dimensions other than power and conflict potential, there is a danger that the stakeholders will not be clearly classified. If, for example, the stakeholder’s interest is highlighted instead of the power dimension, secretly positive, negative, high and low groupings are possible and therefore multiple allocation to portfolio quadrants is likely. I have observed this in many misguided stakeholder analyses.

Another problem can be the failure to conduct a continuous stakeholder analysis. You should always look at stakeholders anew. Shifts in power in a company can change the dimension of power, but above all the characteristics of the dimension of conflict potential can change again and again. The stakeholder’s potential for conflict with the project can change as a result of changes in attitudes towards the project as a result of project developments.

A renunciation of the combined indication of names or roles already in the environment analysis and then also in the transfer into the stakeholder analysis can lead to a generalization and to an overlooking of important characteristics. Mr. Mayer-Schulze can be a pedantic, conflict-laden comrade-in-arms, but his role as a user does not necessarily suggest this.

Grouped environmental factors such as “steering committee” instead of the performance of all individual steering committee members may lead to lump sums and thus the overlooking of specific interests and influences.

What belongs in the status report?

2 min.

Summary

A regular status report is important in the project. The status report is the basic information for the members of the steering committee. It is advisable to create a list of the typical contents of a report, which can be used in any presentation form. Also the status light colours must be well defined to ban the watermelon effect.

Addressees and occasion

A regular status report is important in the project. Regular means that a predefined cycle or on certain predefined occasions is created and delivered to the specified recipients. The objective is to present the progress of the project, to address decision-making needs and to point out risks and problems. The status report is the basic information for all members of the steering committee.

Content

Each status report should include the following:

  • Management Summary
  • Status light
  • Defined indicators (often performance, deadline and costs) and optionally their development in an Earned Value analysis
  • Achievements in the reporting period
  • Planned but unachieved in the period
  • Initiated or planned measures
  • Planned for the next reporting period / upcoming milestones
  • Top (3) risks
  • Necessary decisions

Status Light Colours and the Eternal Controversy

Again and again there are energetic discussions about which colour the status light should have. It often doesn’t make sense to take part in them and as a project manager you should have a clear and above all simple, easy to understand and valid definition for all levels at hand in order to be able to avert the watermelon effect (red inside, green outside). The following definition can be of help:

  • Red = Problems exist which can no longer be solved at the reporting level and which have a negative effect on the defined indicators (usually performance, deadline, costs) or which have already had an effect. Measures were not effective or not possible. There is a need for decision or action at the higher level (level above that of the reporting party).
  • Yellow = The defined indicators show plan deviations. Problems exist that the reporting person plans to solve. Measures have been or are being taken (list of measures required). The need for decision or action on the part of the higher authority is foreseeable if the measures taken do not have an effect.
  • Green = No problems at the reporting level. The defined indicators show no deviations from the plan.

A possible file naming convention for the status report can be found here.

How do I put together the best team?

2 min.

Summary

Team composition and understanding of roles are a success factor for successful project implementation. The Belbin model can be used to analyse and define an optimal mix of colleagues in the team with a wide variety of characteristics. My observation is that in international teams the mix is often easier to achieve due to the different cultural backgrounds. In teams without clear leadership authority it is even more elementary that the team members are deployed according to their strengths and the composition of the team is “optimal”.

Why do I have to take care of this?

In addition to my firm conviction that international and thus interculturally assembled teams are the best, we should take a closer look at why this is so. An analysis in an environment where leadership is given without epaulettes is particularly relevant. This is where optimally assembled teams become particularly important.

The origins of intercultural effectiveness with regard to team composition are determined by the cultural dimensions (e.g. according to Hofstede) and thus the stronger or weaker character of the people involved.

What does Belbin say?

Meredith Belbin presents nine roles in 1981, which should be taken into account when putting together a team. These nine roles are divided into three groups.

  • Action-oriented roles
    • Implementer = implements ideas and plans
    • Finisher = Ensures quality-conscious work and ensures that deadlines are met
    • Shaper = Encourages the team to improve. Eliminates problems.
  • Communication-oriented roles
    • Co-ordinator = Coordinates the team and promotes results orientation.
    • Teamworker = promotes team building
    • Resource Investigator = Promotes the exploitation of opportunities and forms a network in the project environment.
  • Knowledge-oriented roles
    • Plant = Shows ideas and possible solutions.
    • Monitor-Evaluator = Analyzes options for action for their feasibility.
    • Specialist = Brings in his expertise.

How does it work?

Team members and managers can identify the respective strengths and weaknesses in their own team by looking at the various roles and reflecting on them in order to use the potential of the individuals as well as the potential for the composition of teams. The team can be “balanced” through a mutual understanding and awareness of the characteristics. Surely the above mentioned roles will never be found in their pure form, because everyone assumes different roles depending on the project context or the project task, but nevertheless the understanding at least about the tendencies in the role characteristics for team cooperation helps.

From the “Triple Constraints” to the “Six Interdependencies”

3 min.

Summary

The project objectives, the Magic Triangle, Triple Constraint or also called Objectives Triangle is a consolidated representation of the project objectives. In the course of time, a further target variable has been added to represent stakeholder satisfaction, especially client satisfaction. The project is carried out in the context of organisations. At least one organization provides resources in the form of project personnel and material resources. A simple resource planning of the project optimized for the project isolated from the context is not target-oriented. Further each project has not only positive aspects, but causes also a damage. These are the “six interdependencies” which also apply to agile project management approaches.

Origin and Development

The project objective variables, the magic triangle, triple constraint or also called objectives triangle is a consolidated representation of the project objectives on the basis of the measurement variables

  • scope or service,
  • cost (hours or person days and costs) and
  • time (duration and dates).

In the course of time, a further target variable has been added, which is to represent stakeholder satisfaction, especially customer satisfaction. An extension to the magic square did not take place, but was seen as an extension of the magic triangle.

A magic square in connection with project management was mistakenly included in the literature, in which the quality was recorded separately. However, we must clearly distance ourselves from this, since quality is inherently anchored in the aforementioned goals.

We can therefore state that there are at least four indicators for the success of a project: scope, time, cost and stakeholder satisfaction.

Project success in the context of the environment

The project will be carried out in the context of organisations. At least one organisation provides resources in the form of project personnel and material resources. These are also limited and it is a component of the planning duties and thus criterion of the project success, how effectively the project personnel and how careful/limited the project resources are used for the entire organization. Because the project personnel is often entrusted with other tasks in the line and / or the coworkers are just as urgently looked for in other projects. The material resources such as an excavator become just as important for the course of the project on another construction site, for example. A simple resource planning of the project optimized for the project isolated from the context is not goal-prominent. The optimization needs which the project director, the project portfolio manager or the specialist departments specify for project resources are not only a one-sided process. Perhaps the consideration of this interdependence resource optimization in project success would also nip in the bud the thought construct of “thinking of project members only as inputs”.

Every project not only has positive aspects, but also causes damage. For example, an implementation of software may lead to job losses. Or an environmental protection project for the creation of a new nature reserve leads to the loss of a farmer’s arable land. This causes damage to the farmer, even if he is certainly compensated for it. So here we have a clear contribution to the project success in this case with a negative sign. We cannot simply deduct this negative contribution from the performance. Here we would make it too easy for ourselves, because the service is the desired dimension of the client and automatically does not take the damage into account.

In addition to scope, time, cost and stakeholder satisfaction, we have now established two further success criteria such as resource optimization and project damage.

We have thus outlined the “Six Interdependencies”.

Six Interdependencies

Agility and the reflection of the Six Interdependencies

Now you might think the magic triangle was never relevant for me as an agile product owner anyway, because the performance is never relevant due to “fix” number of story points that can be processed in a sprint. This is deceptive and not really true, because by prioritizing the backlog the most important performance is of course defined as “part” of the project. Reprioritizing, adding or removing stories at the start of each sprint deliberately changes the performance of the project. So the six interdependencies are also likely to be relevant in agile practice.

Activity list – why is that?

3 min.

Summary

After work package planning has been completed, the activity list is created as a table. It is the following method to be applied according to the work breakdown structure. The activity list is the link between the work breakdown structure and the schedule.
The real added value is the task list, as a means of reducing the project duration, in that the core team with its expertise and the project manager identifies as many logical sequences as possible that can contribute to reducing the project duration. Even in an agile environment, dependencies need to be identified and taken into account. Splitting user stories without creating additional dependencies is an important skill of the SCRUM team.

What is the task list?

After completion of the work package planning, the process list is created. It is a table of all work packages and contains essential information from the work package planning from which the scheduling is derived in the further course.

The work breakdown structure (WBS) does not yet have any information on the functional sequence (“technical” dependencies). The activity list helps here. In project management, it is a “bridge medium” between WBS and the schedule. The activity list is a table of activities in the project. Based on the activity list, the project manager can determine the start and end dates of the work packages.

What is the added value of the activity list?

After creating the task list, it can be estimated for the first time whether it is possible to achieve the project goal within the framework of the available resources. Now it is possible to add all costs and capacities that were considered necessary by the WP managers. However, it is not yet possible to draw conclusions about the sufficient availability of the necessary capacities, since normally there is no uniform utilization, but rather individual capacity peaks represent the problem. It is also possible to record which predecessors are necessary to start a work package.

The real added value is the task list, as a means of reducing the project duration, in which the core team with its expertise and the project manager identifies as many logical sequences as possible that can contribute to reducing the project duration. So a lazy use of the end-start sequence, because this is so convenient and easy to do, would cost the client project time and drive up project costs. Alternative sequences such as Beginning-Start help the project manager reduce the number of tasks on the critical path. This simplifies project control. The work package managers should not define the inputs for the sequence relationship in a quiet chamber, but communicate them to the core team (sub-project manager or project manager in the program), which then determines optimized sequences. The creation and discussion of the process list thus raises the potential for later optimization of the flow and schedule at an early stage.

Differentiation / forerunner to the schedule

From the sequence of the work packages it can be derived when which work package starts. Work packages that do not have a direct predecessor can start immediately. All others follow. An initial schedule can be derived from this. This, however, is not much more than an indication, since diverse framework conditions such as staff vacation, capacity limits of few available qualifications are not taken into account.

What is the task list in an agile environment?

Even in an agile environment, dependencies need to be identified and taken into account. Here, for example, SCRUM teams already take into account how dependencies between backlog items are represented in the overall backlog planning. The split of the backlog items can be done initially by the product owner, but should be validated by the entire agile team lastest during the initial sprint planning. Even within SCRUM teams, dependencies are constantly re-evaluated, since the continuous prioritization of user stories can possibly lead to additional identified dependencies. Splitting user stories without creating additional dependencies is an important skill of the SCRUM team. However, it should be taken into account that the user stories are not only split according to the technical paths, but that the functional questions are also taken into account. Otherwise, the agile approach will be counteracted. Because then an early and small-scale delivery of functions is no longer guaranteed. As already mentioned, this balancing act of splitting up is a core competence of the entire team.

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

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!