Category: PM Methods

Extreme Scenarios and Pre-Mortems – Foresight Methods for Projects

7 min.

Summary

On October 20, Peter Kennedy of the Futures Strategy Group asked whether we need more extreme scenarios today. A few days earlier, Harvard Kennedy School’s Belfer Center had published a pre-mortem of a major AI-enabled catastrophe. Both methods start from a future nobody wants to plan for. My thesis is that in projects and strategy work we plan too close to the present, and that these two methods are a good antidote.

Why Now?

Kennedy describes a feeling many of us share. Reality seems to be overtaking even the most radical scenarios. Covid-19, political division, and now AI. The natural reaction is to hunker down, put off big decisions, and wait for things to settle.

His answer is clear. Things never really settle. In strategic planning, he calls prediction “a losing endeavor”. Beyond the very near term, the only prudent way to plan is to assume the future will be fundamentally different and will challenge your own operating model.

Almost at the same time, the Belfer Center took a different route. Instead of sketching many futures, the authors assumed a single, very dramatic one and asked backward how it could have happened.

Two methods, one common core. What’s behind them, and what can we as project and program managers take away?

What Is an Extreme Scenario?

By its own account, the Futures Strategy Group has worked with “alternative futures” for a quarter of a century. These aren’t probability calculations or single events. They’re fully developed stories about fundamentally different environments. They should be relevant and accessible, but also provocative.

Three rules from the piece strike me as especially useful for our work.

  • The scenario horizon lies well beyond the planning horizon. If an organization plans zero to five years ahead, FSG sets the scenarios ten years out or more.
  • Scenarios must be plausible and internally consistent. As a check, FSG sketches chronologies of invented events leading from today to the scenario.
  • Scenarios challenge not only assumptions about the future but also whether your own operating model still holds up.

According to Kennedy, the longer horizon frees people from the “tyranny of the present”. If you’re not tied to the timeline of current plans, you’re more willing to accept a truly different world.

An example from the piece shows how extreme this can get. In 2003, FSG wrote a scenario for the US Coast Guard in which a coronavirus originating in China kills ten million people worldwide. Covid-19 was still 16 years away. FSG itself stresses that prediction is never the goal. The value lies elsewhere. Kennedy argues that rehearsing several futures also prepares people for disruptions that never appeared in any scenario.

And now the real question of the piece. Do we need to deliberately stretch the boundaries of plausibility today to keep up with the pace of change? Kennedy sees a potentially big payoff. Broader and more resilient strategies, more agility, and a workforce that leans into the future.

Wild Cards and Stress Tests?

The discussion below the article, in which Kennedy himself takes part, is worth reading. Two suggestions from it are very practical.

Rodolfo Sabonge proposes keeping the core scenarios within a reasonable range and then stress-testing them with injected extreme shocks, much like central banks run their stress tests. Add clear early-warning indicators. And include extreme upside scenarios, not just threats. Extreme can also mean speed, when changes we expected over fifteen years arrive in two or three.

Charles Thomas writes that they occasionally do this already. The same extreme event is injected into all scenarios as a “wild card.” A powerful tool, he says, but tricky to get right.

My takeaway? Extreme doesn’t mean science fiction. Extreme means it hits our most cherished assumptions.

What Is a Pre-Mortem?

The idea comes from Gary Klein, who described it in Harvard Business Review in 2007. The team assumes the project it’s planning has already failed and comes up with plausible reasons why. The trick is psychological. People with doubts can voice them without being cast as naysayers.

The Belfer Center has now applied this method to a very serious subject. The October 15, 2026 paper by Stephen Casper and colleagues assumes that the first major AI-enabled terrorist event has already happened. “Major” is defined up front. At least 50 people killed or seriously injured, or at least one billion dollars in damage, based on thresholds in US laws on frontier AI.

From there, the authors work backward through the life cycle of an AI model. Five points where things can go wrong.

  1. How the dangerous capability is developed.
  2. How the model is deployed.
  3. How the capability is elicited.
  4. How safeguards fail.
  5. How detection fails.

At each point they ask which decision enabled the event and where it could have been interrupted. Their conclusion in short. Whether it comes to that depends largely on choices developers, distribution platforms, and governments are making today. The paper ends with nine falsifiable predictions and two explicitly hypothetical scenarios.

Speaking to the Harvard Gazette, Stephen Casper says they deliberately picked one of the more dramatic scenarios. The aim is to help prevent it or, if it does happen, to enable a faster and better-informed discussion afterward.

What interests me here is less the AI risk itself, important as it is. It’s the method. The threshold is defined in advance. The path backward is structured by phase. And the predictions are worded so they can be checked later.

What Can We Learn for Projects?

Quite a lot, in my opinion. We usually plan projects for their duration. Yet the benefits are often supposed to last many years beyond that. With its Momentum Model, ICB5 describes exactly this shift from “project delivered” to “value created.” I wrote about it in my post on the future of PM certification.

Applied to project and strategy work, I see seven starting points.

  • Choose a scenario horizon longer than the project itself. The question isn’t whether the project finishes on time, but whether its result still holds up in ten years.
  • Run a pre-mortem before kick-off or before a major steering committee decision. The project has failed. Why?
  • Structure the path backward by phase, as the Belfer Center does, and ask for each phase where you could have stepped in.
  • Define up front what “failure” means. Without a threshold, everyone ends up discussing a different problem.
  • Inject one wild card into every plan variant instead of writing a separate disaster scenario.
  • Define early-warning indicators for each scenario and track them in the status report.
  • Play through the extremely good scenario, too. Sudden success can overwhelm a project just as much.

I have only used pre-mortems indirectly so far. In a current software development project, I will use exactly this approach for strategically supported AI discussions.

If you know reverse brainstorming, often called the headstand method in German-speaking countries, much of this will look familiar. Both flip the question toward failure. The difference lies in tense, purpose, and output.

  • Reverse brainstorming asks, “How do we make this project fail?” It’s a creativity technique. The negative ideas are flipped back around and turned into solution ideas.
  • The pre-mortem says, “The project has failed. Why?” The failure has already happened and is explained backward. It’s a risk technique. The result is a set of risks, warning signs, and points where you can step in.

An everyday picture. Reverse brainstorming asks how we could thoroughly ruin a dinner party, and derives from that what really matters. The pre-mortem imagines the guests have already left disappointed and asks what went wrong.

One point matters most to me. Both methods depend on dissent being welcome. In the discussion, Kennedy adds that extreme scenarios also weaken the influence of those who have seen it all. And then: “There are no experts on the future.” That’s a leadership task, not a question of method.

Where Are the Limits?

Of course, these methods aren’t a cure-all either.

  • Scenarios are not forecasts. Selling the coronavirus example as a hit misses the point. FSG says so itself.
  • Extreme scenarios can paralyze. Kennedy describes clients who already feel immobilized by constant disruption. If an organization’s hair is on fire right now, he says he actually advises against scenario work.
  • Extreme has to be tailored, as Charles Thomas stresses in the discussion. A scenario that doesn’t affect anyone in the room remains a thought experiment.
  • A pre-mortem is only as good as the willingness to hear uncomfortable answers. Without psychological safety, it ends up as a list of the usual suspects.

What Does This Mean for the Coming Years?

From here on, this is my assessment, not an established development.

If AI agents become team members, as I described in Project Manager in 2036, and prepare more and more of the planning work, our contribution shifts. Away from building the plan, toward questioning its assumptions. Scenarios and pre-mortems are made for exactly that.

The Belfer paper also shows that risks arise in chains of decisions. Who makes which decision, and where it can be interrupted, is a governance question. It belongs in steering committees, not just in risk registers.

And the point about speed from the FSG discussion stays with me. Maybe the extreme thing about the future isn’t the event itself, but that it arrives sooner than expected.

Kennedy closes with Louis Pasteur. Chance favors the prepared mind.

Which scenario would you never put in front of your steering committee? And why that one?

Feel free to subscribe to my free newsletter.

Sources

Big Picture in Project Management

2 min.

Summary

A Big Picture is a visual representation of a project that makes its context, challenges, and key elements immediately graspable. It is especially valuable when developed in a workshop with a small, interdisciplinary team—without striving for perfection, but with a playful mindset. The Big Picture serves as a communication tool, promotes shared understanding, and helps reduce complexity. It can be refined as the project progresses and provides a foundation for stakeholder communication.

Why create a Big Picture?

Projects are often complex and full of uncertainties. A Big Picture helps make the essential aspects tangible:

  • Deliverables and scope: What belongs to the project? What is deliberately excluded?
  • Stakeholders: Who is involved, who is affected?
  • Milestones and phases: Which steps are planned, which dates are critical?
  • Risks and constraints: Which external factors influence the project?

By visualizing these elements, misunderstandings are avoided and everyone works from the start with a shared baseline.

Practical application

Identifying deliverables

In a fictional project to build a wind turbine, it quickly becomes clear that not only the main asset (e.g., a construction site) but also additional components such as permits, safety measures, and possibly even preliminary work (e.g., ordnance clearance) are relevant.
The key question is: What is in scope and what is not? For example, an access road might be left out due to time constraints — but this must be communicated early to those affected to avoid later conflicts.

Involving stakeholders

Projects do not exist in a vacuum. Authorities, residents, external service providers, and internal teams all have different expectations. A Big Picture makes visible:

  • Who is the client?
  • Who assumes which responsibility?
  • Which permits are required?
    Early involvement of all relevant parties helps reduce later delays.

Phase planning and milestones

Not every project is suitable for agile methods. In this example, a classic waterfall model was chosen because clear approval processes and fixed deadlines set the framework. A rough phase plan might include:

  • Planning phase (outline concept with costs, schedule, organization)
  • Implementation phase (detailed concepts, execution, procurement)
  • Approval and acceptance phase
  • Project closure

Clear milestones are crucial — such as the release for implementation or the final handover date.

Challenges and risks

External factors such as legal requirements (e.g., reforestation obligations) or historical legacies (e.g., unexploded ordnance) can influence the project’s course. These should be noted early in the Big Picture to prevent unpleasant surprises later on.

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