› Forums › Managing Risk in Complexity SIG
(MRC SIG) › Working Group B: What principles are important in dealing with complexity?
-
AuthorPosts
-
Up::0
While I wouldn’t recommend the necessity of scar tissue upon one’s back for the one to qualify as professional, we older peoples, performed project management when there were two kinds of project managers, unemployed and soon to be unemployed project managers.
The fact is our project failures (well at least mine) were based around a number of issues, no support, no procedures, no training and no policies. One of the reasons I became a PMO Manager instead of going to Director or Senior role was to ensure that no PM went through what I had to go through.
I remember when I was coming through the industry and what I had to go through. Now I tell all PMs working for me, as long as you don’t lie to me (and I will know), no project manager fails. It is on me for not seeing the problems they were facing, either no training, no support, no policy, or no procedure. The organisation fails the project manager, not the project manager failing the organisation.
Of course, projects have evolved and we are still using old methodologies (FFS Gantt charts were invented in 1910), we need new methodologies for Complex projects (and Complex Adaptive System projects). While we have made a good start, I don’t know if what we have done can be stitched into a methodology we could use to measure and run complex projects. We know what to look for, but we are, in my opinion, still missing that je nais se qua.
Up::0Love the quote. Depressingly true
I attended a discussion with Stephen Denning many years ago discussing storytelling techniques in the business place (cross over to Ian’s reference to stories today).
He held that if you tell a negative story (describing a mistake), listeners store that specific bad experience away and vow not to do the same. However, if you tell a positive story the listeners map the scenario to their own situation and think – ‘I want some of that’, they take a broad view.
Should your experience contain a minimum number of cock-ups to qualify as a professional? doesn’t sound like a positive story!
Stephen Denning – The Leaders Guide to Story Telling & Squirrel Inc.
Up::0Yesterday I talked to a company called Octant AI about a tool they are building, it was very interesting and I hope to take them further. But a comment was made ‘how does experience help you spot trends’ – the answer being, of course, experience. You have lived long enough to know when something is ‘off’.
Then it was related to AI, with regard to the narrow dataset the AI is using to determine trends that occur and then relating that to new data to create a percentage likelihood of that trend reoccurring (Montecarlo-ish).
So that is how AI will supplement/supplant human experience – of course, in a time frame that is not going to trouble most of us.
And this made me think, what changes people’s model? What qualifies you as ‘experienced’ most importantly, how do I break out of the profitable but very boring scenario of telling clients the same answer I have been telling clients for decades?
What really is the non-engineering, non-process answer to successfully wrangling any complex project (the current paper is a good-enough answer) we need the next step – communication.
OK – enough deep thought for a morning, back to reviewing a clients Project Execution plan
Up::0Brain’s trust,
In thinking about this morning’s (evening for some) discussions about where next. It occurred to me, we have concentrated on a number of items over the last few years, especially about complex project management, but one thing that strikes me, is that as PMs we have been there and done that, but where is the biggest frustration when dealing with complexity and from my experience is that senior executives, boards, etc often have no understanding (or want to), about what we are talking about.
Not every board member is an idiot, some of them are very savvy individuals with experience, but in our world (complexity) they have no understanding, maybe this is where we need to concentrate our visions. How do we engage with Senior Executives/Board Members, so they understand.
Personally, I feel that there need to be a Chief Project Officer in any organisation that deals with large scale construction/manufacturing/infrastructure or complexity.
Just a thought.
Up::0Team,
As mentioned today, the Inland Rail Project Independent Review report is at this link. On risk, it is incredibly poor (both the project and the review)
Up::0First, I am sorry that I have commitments on Thursday morning that will prevent me from joinng you
Second, a quick comment on Simon’s bullet points
The first one “What is it (Transition)” goes to the issue I have raised a few times and on which Davin has kindly sent me some papers, which I have not yet been able to read
Transitions arising from and visible in tangible features of a project are very important and can have profound consequences
I don’t think I am alone in having seen transitions in the mood of a project team that cannot be seen immediately in the usual metrics and KPIs that senior managers like to see when they are trying to assess the health of a project
A project whose personnel become convinced they have failed, looses faith in their ability to meet key milestones and becomes disengaged – why bother, we are doomed anyway but I need the job so I’ll hang on – is one scenario that I think can arise from complexity because every attempt to fix things throws up unintended consequences that make life worse and there is no clear vision of the long term
Another pathological scenario is where middle managers look first to protect their own reputation no matter how badly it affects the job as a whole, transitioning from being members of a team to being street fighters protecting their patch
Yet another is where every decision is made with a short term focus and everyone is frenetic, looking at immediate consequences with no strategic vision – don’t bother me with details, just tell me what to do tomorrow
Spotting projects that are slipping into these conditions and assisting them might be even more challenging than dealing with tangible transitions, as important as they are
So, if we can, I would like to leave the door open to exploring transitions in greater depth and diversity
Steve
Up::0Hi all: Thanks to a client going through a painful, predictable but unanticipated ‘transition’ plus taking a four-week holiday I have been out of the loop.
Having reviewed the document I am really impressed with how much of the discussion has been embedded. To me it is new material, something which is often implied but not directly talked about (or taught). Therefore this paper is very important to get published.
I think we need to review how it is best assembled: I suggest
– What is it (Transition)
– How do you see one – early, if possible
– How do you prevent it from becoming an issue – much of the document has great material on this point
– How do you fix it when it happens (and you didn’t spot it early) – the norm!
– What not to do! again, I love the sections of the document that covers this. Many actions are taken in the hope of ‘any action is better than nothing’ but this points out what a mistake that approach is.Of course, I should wade in to help with the edit (:-))
Talk tomorrow. Simon
Up::0Morning all,
In reviewing the Transition document (well done Ian), I realised we have missed a common transition which is schedule slippage, or changes in scheduled tasks, or activities. For example, a scheduler notices that a work package is either larger than initially planned, or there is interdependencies, or interrelationships that had not prior been picked up. This of course is reflected in the resource plans, or work force planning.
Up::0Morning all,
In reviewing the Transition document (well done Ian), I realised we have missed a common transition which is schedule slippage, or changes in scheduled tasks, or activities. For example, a scheduler notices that a work package is either larger than initially planned, or there is interdependencies, or interrelationships that had not prior been picked up. This of course is reflected in the resource plans, or work force planning.
Up::0Team – I have amended the paper on Transitions for what I think is the last time. The changes since the last version are in red print. Please note that:
– Annex A only includes one example, is that acceptable or do we need to add one or more others?
– In Annex B, I have split the examples into two groups: Common Triggers and Transitions; and Less Common Triggers and Transitions. In hindsight, perhaps we should (1) just leave them all as “common”, and/or (2) move some between the two groupings. Thoughts?
– Also, I may have missed some names of people who contributed at the meeting in December that I missed – if so, please speak up.
I hope to see you all in a week or so, though I think Australia just had a time change so I may miss you all completely… – Ian
Attachments:
You must be logged in to view attached files.Up::0Ian, nice job.
In reference to the Agile comment: Apologies if I have missed a discussion on that, but I would offer a few comments……
I think there would be plenty who would disagree with the statement that “use of agile techniques before delivery of outcomes (rarely effective until the in-service lifecycle phase)” is inappropriate.
As it happens, I have just completed several significant reviews of what I would describe as “Agile inside Waterfall” and am assisting a major Government client with this problem, so its topical!
In terms of “transitions”, coincidentally I have been looking at 3 separate projects where, actually against all contracts and project control, developers and users have flipped from waterfall to agile. Typically, this is at the point where the approved iron triangle (cost/schedule/scope) is blown, the product becomes horribly delayed, and desperate uses calling for “just something”, so developers start ignoring the waterfall plan and delivering value as early as possible. It can be quite political, actually, because if an employers directs the scarce developer talent to get back to waterfall, they just resign. A bit of Boomer vs Zoomer, as well. :-)
One of the issues is that waterfall is perceived as simply to slow, such that reality gets inside the OODA-loop. By the time the requirements analysis is done (if that is even possible), the market approached, contracts negotiated, development done, testing done, etc, the requirements are obsolete, interfaces have changed, technology has changed, the system-of-systems has changed, etc.
From my own experience, I do agree that Agile tends to work better where there is v1.0 of a product, that already addresses many of the essential compliance requirements best addressed by Waterfall. Obviously best for software products, although there are many experiments in hardware too, especially systems-of-systems. However, I have also seen it work well on ab initio developments, so our statement may be prejudicial.
So, I think the point about transitioning from one methodology to another it a good one, but maybe we should pull-back from the skepticism about Agile – there will be a variety of experiences on this.
Up::0Hi Andrew,
Yes the meeting is running normally
ICCPM ADMIN is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://us06web.zoom.us/j/89707644924?pwd=cTB6TVd6bXFydjVXajlLOWJyckJ3dz09
Meeting ID: 897 0764 4924
Passcode: 690949
One tap mobile
Cheers
Davin
-
AuthorPosts
- You must be logged in to reply to this topic.