Forum Replies Created
-
AuthorPosts
-
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:
- Accepting that control might slip away
- Understanding when it started to slip, and
- 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.
Up::0Thank 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.
Up::0I 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
- 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
- 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.
Up::1I am still extremely interested in this working group
Just can’t fit much into a current upsurge of work and domestic issues that demand a lot of my time
This article illustrates how ‘white lies’ can add to the confusion on really big projects
Up::0I have been unable to attend the last two meetings so I might be off the pace a bit but the sense I had emerging from the conversation, and from Ian’s recounts of his experience, was that with a truly complex project it is advisable to essentially design your own approach to suit the job
That is not to say start from scratch but rather to assemble all the artifacts, tools, procedures and management structures we all know with appropriate tailoring and shifts of emphasis to give the work the best chance of success
Up::0This is not meant to be provocative, rather to explore a little – what is the purpose of a “life cycle”
I have a sense that the term is used often without thought, as if you have to have one even though its purpose, and how well it fulfills that, is not clear
If we knew what we wanted the structure to do it would be easier to answer the question
Up::0Very disappointed to have to say I can’t make it tomorrow
Large proposal to complete
I’ll have to retire soon so I can spend more time in meetings of professional societies :)
in reply to: Question for the Brains Trust #15818Up::0Ian
I wasn’t very clear about what I meant
The smearing I was referring to is not something I have seen in initial governance structures established at the beginning of a project but rather unavoidable revisiting of priorities, major design decisions, casting aside pieces of work and undertaking rework, which usually leads to dramatic reactions from those who, however naively, assumed the pattern established at the outset would persist. They might have expected slippage and a cost hit or two but not having to discard positions they thought were nailed down.
I expect we have all seen that and framing it in the way I have is not the only option. It can also be characterised as a loss of control and a descent into chaos.
Certainly in the software sector, I have seen the entire basis of a project change during its life as technological changes presented new options and stakeholder interactions proved even more challenging that anyone had imagined they could be: e.g. the project that barely completed its pilot implementation within its budget let alone the 17 operational sites where it was supposed to be installed; or, the project that delivered a big defence procurement support system that was packed up and placed in storage by the client without being used because it was out of date in a world where inexpensive PC systems had emerged to fulfill the same role. Their purpose was recast in the language and decisions of the client and contractors every few weeks as the true level of the challenge became clear and everything from consultation to threats of legal action failed to provide a magical solution.
The big disasters are dramatic and cancellation and restarting might be the best option in such cases. Smaller examples are quite common though. Switching horses mid stream to take advantage of a more attractive system component, acknowledging that the inputs we were planning to use from an earlier project are so late we will have to build them ourselves, accepting that the scale of the planned scope is impractical so we will curtail it.
My Utopian view is that such things cannot always be avoided and it makes more sense, as well as encouraging a more constructive reaction to maintaining progress is to accept that they will happen and be prepared to rework priorities, designs and built components as a matter of course.
I think this is covered by Ian’s concept of “there is no bad new, no good news, only news”
None of this is new I think
Talking of stages being smeared out is perhaps just a way to say that the rigid framework of many project stage models is unrealistic when dealing with serious complexity
Steve
in reply to: Question for the Brains Trust #15810Up::0Rob
I reckon that a complex project in which a lot of features might be fluid and change over time sees the stages smeared out and overlapping to a greater extent than in a linear project
Early analysis and decision making might have to be revisited, some work might be redone, some products or deliverables might be closed out while others are being worked on
All because you cannot bank on early decisions and work remaining optimal until the nominal end
Steve
Up::0This is a little off topic
It might spark a thought though
During our meeting yesterday, Daniel Kahneman was mentioned in relation to decision making
His ideas open up many avenues of thought, one of which, Thinking Fast and Slow, is set out in this talk he gave a few years ago through the Long Now Foundation – https://youtu.be/gmjgZF2HEwI
Paraphrasing their self description, the Long Now Foundation is a nonprofit intended to foster long-term thinking. They encourage imagination at the timescale of civilization (click on the first down arrow on their home page and then scroll down) — the next and last 10,000 years — a timespan they call the long now. A small part of this is to designate dates in a 10,000 year frame, 02022 being the year we are in.
You can see more of their work in the web site that hosts the video, such as The Clock of the Long Now, an immense mechanical monument, installed in a mountain, designed to keep accurate time for the next 10,000 years.
Their oblique viewpoint attracts a lot of interesting speakers. One of my favourites is Lera Boroditsky’s talk on How Language Shapes Thought, which shows how much we are bound into the way we have been taught to see and describe the world – https://youtu.be/I64RtGofPW8
Up::0I’m hoping to join in tomorrow – subject to how my jaw feels after having a tooth removed
In the meantime, I put together the attached diagram to help me make sense of the principles
I overlooked the top cover point that Ian raised recently but that fairly clearly fits in with governance and resourcing I think
I’m not proposing this as a WG product but I found it helped me grasp the dozen or so items that might be regarded as all connected to one another equally strongly
To see if I could expose a structure that made sense to me I considered which items require or benefit strongly from others
In broad terms, that’s the flow down the page
I am not so interested in the resultant diagram as in being able to think about the whole system sensibly and possible begin to ask: Where does a newcomer start?
Attachments:
You must be logged in to view attached files.Up::1I agree
All the other points or considerations can be framed in terms of general complexity management principles – adopting multiple viewpoints, deferring locking down anything you can, remaining open to change …
-
AuthorPosts
