Working Group B: What principles are important in dealing with complexity?

[ian mack]

#16345

Up

0

::

Hi Team – I continue to be amazed and learning by the latest offerings from Stephen and Simon.

In terms of the initial comment by Simon relating to ‘recognising transitions when you are in them and then knowing how to incrementally grow through them’, my ‘learned’ experience (not ‘lived’, admittedly) suggests one must have bench strength or an available surge capacity under contract, based on the risk analysis for each phase. This is needed as much to deal with large emergent surprises (shame on us!) that introduced a need for some kind of transition, and that is frequently about more and/or differently skilled people. Alternatively, my ‘lived’ experience was to temporarily deploy people from other projects in my portfolio and at different project phases as bridges until we could get more people or contract for support into the challenged project.

I found Stephen’s paper absolutely fascinating. My experience was almost always related to military acquisitions of fleets of platforms for our Army and Navy. Thus, the one-off infrastructure project is somewhat new to me and this was a great education piece. I could have used this primer when I was a Base Commander in Halifax in the ‘90s!

In terms of Ottawa’s Light Rail Transit project (Phase One) inquiry report that I mentioned in December as a great case study, I think it was somewhat of a good example of what you discussed about the significant impacts of schedule slippage,. In that case, the construction work (tunneling under the City and station construction) were conducted on schedule until a geotechnical unknown (a huge sinkhole) introduced a significant schedule slip, with costs to recover that were all to the contractor’s account (estimated to be about $200M {Canadian} and largely being the reason for a one year delay). That said, there was much else done imprudently that the project would likely have produced the same unwelcome outcomes as it did, even without a sinkhole.

We had mentioned rolling wave planning in the paper we co-authored on complex project techniques, but that approach (planning in shorter stages) would likely be imprudent for many infrastructure projects as it would mean new or amended contracts for each phase with the related labour challenges. This approach could be problematic.

I guess you nailed it in the paper when you suggested that it means (1) setting expectations well with the Board(s), seniors and end-users (your ‘recognise that it can happen’ and ‘be prepared to deliberately reset … to avoid chaos’), (2) having contracts for production resources that are somewhat flexible so as  to accommodate these expectations (developed with front-end, joint and integrated black swan risk analysis), and (3) having enough capable people available with appropriate processes within the project execution team that are dedicated to the detection of the onsets of schedule slippage (as Simon emphasised in his comment) and rapid analysis of risks in general and slippage scenarios in particular, leading to optional courses of action – these perhaps supported by pre-agreed planning for short term losses of productivity as a result of slowing down other work while analysis occurs and a reset option is approved and re-resourced. If the initial expectations were properly shaped in a structured collaborative arrangement, one would hope to minimise the damage, which for me is part of the mindset needed for every complex project: a minimisation of the damage from the inevitable emergent issues so as to optimise the project outcomes.

Then, I was introduced to the power of AI in the ‘Chat GPT’ comment by Simon – wow! I imagined with great empathy the reaction of a project leader getting all those recommendations to pursue. That said, this led me to two comments; Firstly, the AI response is a lot about the ‘what’ should be done from a 10,000 foot view (perhaps somewhat triggered by words in the paper), but I wonder (and rather doubt) that there is a more granular AI offering on the ‘how’ to do the things that the notional consultant might recommend and in a way that is relevant to any selected project’s context. Secondly, emerging and powerful AI tools such as Chat GPT should perhaps be supported in partnerships with associations like ICCPM, ICEAA, Deloitte (who has analysed hundreds of projects to glean lessons and best practices) and others to provide ‘emerging practice’ enabling techniques for consideration. Somehow, I think that is where real consultants or mentors with ‘lived’ experience still have something to offer for a while longer. But I was gobsmacked by the Chat GPT response – perhaps we should ask about transitions …

Sincere thanks to both – Ian

[Simon Springate]

#16344

Up

0

::

Chat GPT is scary
Asked it to summarise your paper then asked “What would a consultant recommend in response? It replied:

Based on the information provided in the article, a consultant may recommend the following actions to prevent extreme schedule and cost overruns in large projects:

• Implementing robust project risk assessment and modeling: The consultant may recommend organizations to take project risk analysis and modeling seriously and calibrate themselves to the point at which their contingency provisions are realistic and reliable, especially when the characteristics of their projects are reasonably consistent over time.
• Addressing the limitations of conventional risk modeling: The consultant may recommend organizations to adopt a more realistic approach to project risk assessment that takes into account the potential for extreme overruns and long right-hand tail distributions.
• Improving project management systems: The consultant may recommend organizations to improve the governance, management capability, estimating, planning, procurement, monitoring and control systems and processes provided to project teams, to eliminate the worst of the deficiencies that may lead to schedule failures.
• Account for potential productivity loss: The consultant may recommend the organizations to account for the potential productivity loss due to schedule slippage in the project schedule risk model, as a means to prevent the situation firefighting and loss of productivity that can lead to schedule failure

<li style=”text-align: left;”>Prioritizing transparency and communication: The consultant may recommend organizations to prioritize transparency and communication throughout the project to monitor and prevent disruptions, and have strong protocols in place to detect and mitigate issues as they arise.

Do they need us consultants any longer?  This ChatGPT is scary

[Simon Springate]

#16343

Up

0

::

I like this Stephen, only thing I would add to your 3 bullets is “detecting” that control is slipping away

In relation to risk using risk windows when known risks are likely to become real and then (thanks to slippage) you can see the windows starting to line up, that tells you that there is a building potential catastrophic event in your future – of course, an honest schedule would tell the same story but not perhaps the degree of risk exposure.

[Stephen Grey]

#16342

Up

0

::

First attempt to answer this vanished so I’m starting again. If a half finished reply pops up I’ll try to sort it out.

A few years ago I tried exploring the development of complex phenomena in projects using a model of a feedback loop linking schedule slippage with behaviours and changes that can be expected to reduce efficiency (https://broadleaf.com.au/resource-material/extreme-project-schedule-over-run/). This was never intended as a realistic model of a real project, but it is instructive. It illustrates how disturbances can cascade through a project, growing from one area to wider and wider effects on the project as a whole.

The paper discusses the behavioural changes one sees in large projects that dissolve into chaos, or at least shift to a far less efficient mode of operation than was envisaged when the job was sanctioned. In brief, I postulated that:

• Small amounts of slippage are often absorbed without affecting major milestones or treated as a controlled baseline shift where the project carries on using the same practices with perhaps a modest one-off delay to the whole program. The original planning assumptions remain and working methods are essentially unchanged.
• Larger amounts of slippage stimulate a more intense response that often includes changing the sequence of tasks, changing working methods or adopting alternative components of a technical solution. Depending on the level of stress, or even panic and a need to be seen to be doing something, the implications of these changes might only be explored in a small region close to the work in which the crisis arose, overlooking wider implications. The knock-on disturbance to other work might not be seen until it manifests itself as another crisis somewhere else in the project. By this means, events that create slippage can cascade through a project if they are allowed to. Efficiency falls and the work takes longer than expected.
• Given enough isolated crises, each one all the time stimulating more, co-ordination can be lost. While work might not carry on becoming inefficient indefinitely, it can settle into a new stable condition that is no-where near as efficient as originally planned.

This is all set out with more discussion in the paper and illustrated with graphics.

What I took from the model, using it as a framework for my personal observations was:

• Nothing exotic or mysterious is required to explain a slide into chaos. Many appear to regard a general loss of control as and incomprehensible fact of life – “This just happens on very big projects … no matter how hard we try to tie them down”. This is akin to abdication of responsibility in the face of the mystical complexity.
• Project management teams rarely think very far through the knock-on effects of a disturbance in one part of a project to understand its ripple effect on the project as a whole. They might trace it through from one area to the overall milestones but not always consider the implications of resource demand, access to facilities and other ways in which the area causing immediate concern can affect others.
• As a result, awareness of the potential for a disturbance to spread and affect other parts of the work (mechanisms for this are discussed in the paper) is limited or absent. The immediate response is often to seek to pull the work back to the plan that has been disturbed, but rarely with as much rigour in the analysis and forecasting as when the job was first sanctioned. Restoring the initial shape of the project might not be feasible but it is seductive to the extent that problems with its feasibility might be resisted.
• When at last the full horror of a descent into chaos is realised, little short of a return to the original planning stage and a full reset offers a reliable return to order and few owners are willing to accept that.

Ian has spoken of the need to have competent specialists able to evaluate the impact of changes and advise senior managers. That fits well with these ideas. The faster project managers can understand the knock-on effects of changes or disturbances the more chance they have of maintaining control and, if not stopping it, dampening down the cascade. Early warning will push a project towards the robust end of the scale in Figure 18 and, conversely, limited foresight will push it towards the fragile end.

It seems to me that preparedness for disruption and willingness to accommodate it, assuming it cannot be prevented, should be considered a branch of contingency planning – not contingency plans for a single or specific source of disruption but measures to spot when control is slipping, and a cascade might be developing. This might go as far as agreeing conditions in which the project will be replanned to find the optimum way forward from wherever it has arrived.

Some businesses have a threshold setting on schedule performance, a level above the project manager’s KPI, that triggers a return to the Board or equivalent for investment (re)approval. It’s a coarse trigger and a lagging indicator, generally rendered even more so by the emotional resistance of all concerned to admitting things are bad enough to warrant such a drastic step.

So, at the end of all that the keys to handling projects that we cannot control perfectly seem to be:

1. Accepting that control might slip away
2. Understanding when it started to slip, and
3. Being prepared in advance to act on it.

#1 and #3 are human and social factors. #2 is more difficult, a technical and human factors assessment.

[Simon Springate]

#16336

Up

0

::

I like this Ian.  The transition aspect is a very interesting element.  Programs always start with small teams, even small mindsets (this is easy!), and stuff goes wrong as complexity emerges, understanding increases but the management organisation does not know how to transition until it reaches a ‘reset’ moment, normally involving a change of personnel.  Being able to recognise transitions when you are in it and then how to incrementally grow through them would be a great skill.
Although I wrote this relating to the whole project scope it applies to the understanding of risk just as much.

[ian mack]

#16335

Up

0

::

Team – I have tried to assess the aspects of the proposed new Working Group objective, which could be stated as follows:

The Question: How might practitioners mitigate the potential risks inherent in the many forms of transitions in complex projects with the aim of preserving project momentum in as seamless a way as possible?

The Desired Result: It is to ensure that the project execution team has everything needed to adapt to changing requirements in a manner which reduces the risks to post-transition enabling capabilities.

The Desired Product: A list of common transitions in complex projects, the triggers of such transitions, the attributes of such transitions, the related potential risks and the ways to mitigate such risks

Overarching Quote: The only constant is change; how we adapt to it and respond to it is a critical aspect of complex projects

Based on data mining of the transcript from the last Working Group meeting and a degree of preliminary analysis of the last meeting of the Working Group, this would lead to an initial short list of types of transitions (some of which have interdependent linkages) and sample questions to be answered:

1. Transition in Level of Complexity

Question: Is this a separate category, or is in actually inherent in all categories of potential disruptive transitions?

> Is such a transition  a challenge in terms of project execution teams, governance and/or other stakeholders (including those in industry within the project enterprise industry stakeholders perhaps) note being prepared for a step-up in complexity?

> Is the one trigger the change of project phases, which introduces a significant change in the nature or magnitude of complexity?

> Will the style of effective leadership change during and/or after the transition to enable adaptive behaviour by subordinates and/or superiors?

> Because of changes in complexity, might there be emergent risks as power dynamics change, and what might we expect to need to address if power is applied in ways which will disrupt project momentum?

> Whose responsibility is it to address such risks and how might they be mitigated?

2. Transition in required knowledge base

> Is it in terms of depth of existing knowledge, a change in sector specific domain knowledge, and either of (or both of) a planned loss of personnel or an unexpected loss of personnel with critical project knowledge?

> Does the next phase of the project require different knowledge?

> Who might be affected (e.g. the Project Leader/Manager, in the Project execution team, senior governance members and/or key industry leaders, the type of AI involved, or some combination of these?

> > Whose responsibility is it to address such risks and how might they be mitigated?

3. Transition in Project Leader/Manager

> Why might there be a transition (e.g. the 3-4 year standard rotation culture, a promotion, a change in necessary knowledge or skill sets for the next phase, a lack of HR motivations [bonus, governance dissonance or project redirect], or personal life change [sudden retirement for their or family reasons])?

> What might be the potential consequences if this risk is realised (e.g. project schedule slippage/reset, unrecoverable body of project journey knowledge, new vision [to achieve the outcomes required, to lead, to engage senior governance], and/or the challenge of rebuilding critical relationships)?

> Whose responsibility is it to address such risks and how might they be mitigated?

4. Transition assessment process at gates

> Aside from project outcomes and benefits, what sorts of project enabling capabilities should be assessed at gate reviews (e.g. continued availability and appropriateness of project leader/manager and/or execution team knowledge, staff skills & capacity for the next phase; potential scope change requirements in the next phase; expected level of available funding; potential for schedule changes; change in degree of expected complexity; stability of planned activities in the next phase; potential for changes in powerful/interested stakeholders; possible environmental condition changes in the next phase; appropriateness of the project enterprise’s organisational structure and unit locations for the next phase)?

> Whose responsibility is it to address such risks and how might they be mitigated?

5. The effect of power dynamics that can occur during transitions

> What could trigger a disruption in the relative stability of influence exerted by those with power (e.g. new project leader/manager or senior governance member [locally or internationally] with more or less lived experience amidst complexity or with the required sector specific domain knowledge that is otherwise absent, the emergence of a significant realized risk attracting new attention from previously satisfied powerful stakeholders, the transfer of funding control between client agents or to the Financial Officer)?

> Whose responsibility is it to address such risks and how might they be mitigated? Do the types of power in flux make a difference to the potential mitigation strategies?

Before closing,  I would add four additional comments:

> The issue of governance responsibility was raised in addressing transitions, in terms of the role they should play in mitigating the potential risks.

> There would appear to be a definition issue in terms of the needed continuing focus by governance on both of (1) broad non-project-specific organisational benefits realisation and (2) project deliverables. Experience indicates this to become an issue when the time between project launch and results is long [Note that the definitions for benefits and project deliverables are addressed in PMI’s PMBoK, and these collectively could be seen to define the primary set of ‘desirable project outcomes’]

> To state the obvious regarding almost all such transitions in enabling capabilities, the potential detrimental effects of disruption are almost always as much an opportunity as a risk because they are inflection points in the project journey that force clear-eyed reflection on the project writ large.

> I think that, once this list is further fleshed out and some of the additional questions raised are answered, some further analysis might reduce the task significantly (and thus the gravitas of the result) to perhaps no more than a short amendment in Annex B of our previous paper on complex project principles/considerations.

I offer this analysis for consideration leading up to the next meeting. And Happy New Year!   Ian

[Davin Shellshear]

#16334

Up

0

::

Thanks Ian

Being of slow mind, I went to the executive summary.

It almost reads like a specially prepared example of what not to do in a complex project, with 100% success in stuffing every step on the way.

If I can, I will go to the whole hog, but in the meantime, the executive summary makes good (scary) reading.

Cheers

Davin

[ian mack]

#16333

Up

0

::

Hello all from Snowy Canada – In the past month, a public Commission’s Final Report of OLRT Public Inquiry that reviewed Ottawa’s Light Rail Transit Phase One project. I have enclosed the link that should get you to a position to download the report. I regret to say that it is over 600 pages in length. And while there are chapters for conclusions and recommendations, the true story of a complex project that went from badly launched to worse  with the results many of us would expect is only apparent be reading the first 300 pages – and that is before the system commissioning and early years of unreliability are covered in the report. It is in my view a great case study for use as a teaching tool by those with experience in complex projects (in the first 300 pages, I have 26 pages of extracted report text and comments). We may choose to discuss, or not. However, I thought I would make it available for the hearty amongst us – I assure you that you will both laugh and cry if you make the effort. I would add that the project was launched over a decade ago as complex project techniques were rather nascent, and we all know that hindsight is 20/20. Nevertheless, it is quite a textbook case of the many things one could or should have done differently. Meanwhile, I continue to plod through all 600 pages in the hope of writing a focused paper sometime in 2023. In the meantime, I trust and pray that you are all enjoying a break.   Ian

Final report of OLRT Public Inquiry | Ottawa Light Rail Transit Commission (ottawalrtpublicinquiry.ca)

 

[Stephen Grey]

#16324

Up

0

::

Thank you Davin

A useful prompt for thinking in this area

I heard Warren’s talk. It was interesting as far as it went.

The idea that there is a small number of primary drivers in a system makes sense, so long as the system is described in reasonably high level terms. Too much granularity will probably cloud the connection and commonality of causes that make dominant factors visible.

[Davin Shellshear]

#16322

Up

0

::

Hi Stephen

Thank you for a well considered response.

For amusement, Warren Black recently (8th Dec 22) presented for the IRM working group on risk in complex projects, and he referred to the systems map by Sarkar and Kotler (attached) – you may well be aware of it as it has been doing the rounds for some time. Warren claims that in studying such a systems map, you will probably find 2 or 3 key issues that affect the matter you are concerned with. For example, he claims that study has shown that Profit Maximisation (rampant greed) and Poverty are the two key factors driving Climate Events/ Change, and that unless we can address these, we cannot successfully address climate events. Probably time to get off this world and find Planet B. I guess we could call climate change unintended unforeseen consequences of those two factors.

For your interest

Cheers

Davin

Attachments:

You must be logged in to view attached files.

[Stephen Grey]

#16321

Up

0

::

I assume you are referring to unforeseen unintended consequences. Any that might be unintended, as in we didn’t set out to make this happen, but can be imagined and foreseen would just fall under the general risk management heading – ‘We would prefer this didn’t happen but it might do’

I have occasionally thought around this area in relation to the so called unknown-unknowns

Two quick reactions

1. Anything that helps us deal with unforeseen unintended consequences of decisions we make concerning complexity will help us deal with surprises no matter what triggers them
2. As with the nebulous unknown-unknowns, we would be hard pressed to establish purposeful measures to address unforeseen unintended consequences of complex risk management as we won’t know what we are trying to address. In that case, the strategies Ian has discussed that make a management organisation light on its feet and responsive seem to be the best bet – adopt a disposition that will spot disturbances as they start to develop, ensure a well resourced analytical capability to determine how they might unfold and test out measures to maintain control. Ian mapped out several measures that can help management to understand what is going on before events overtake them.

[Rob McMartin]

#16320

Up

0

::

Hi Group,

I thought I would include something I have been thinking about and that is “Do we need to look at systems for dealing with “Unintended Consequences” of decisions on complexity.

Admittedly, it is the old how long is a piece of string but defining what to look for would go a long way to reducing any Unintended Consequences.

[ian mack]

#16301

Up

0

::

Thanks so much again Davin for the transcription – I fo one find these invaluable!

I am mining the key ideas/concepts around transition – so very rich a discussion. I will post my thoughts in due course for all to shoot at – well, if they get around to reading, it being the Festive Season and everyone else still employed. Holiday wishes to all, and blessings throughout 2023, from Ottawa Canada as the snow flies!

Ian

[Davin Shellshear]

#16300

Up

0

::

For those of you who are wondering how fill in the break till our next meeting, might I suggest some interesting reading around leadership and complexity – as leadership appears to be integral to the topic we are considering. The book is ‘Complexity and Leadership’, edited by Chauhan, K., Crewe, E., and Mowles, C. It was very recently published by Routledge.

Cheers

Davin

[Davin Shellshear]

#16298

Up

0

::

Hi Group B

Attached are my notes from our last meeting on 8th December.

Our next meeting is 19th January, so please consider what is the problem statement that defines the next topic we will work on. Please use the forum to post suggestions and progress our discussion over the intervening period.

Cheers and all the best over the Christmas period.

Davin Shellshear

Attachments:

You must be logged in to view attached files.

[Author]

Posts