› Forums › Managing Risk in Complexity SIG
(MRC SIG) › Working Group B: What principles are important in dealing with complexity?
-
AuthorPosts
-
Up::0
Hi 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
Up::0Morning everyone,
I was doing some research on Project Complexity for an upcoming presentation and found this on Wikipedia. Some interesting information.
Up::0Team – I have once again updated the initial version of our tranisitons paper based on the discussion at the last meeting. That included the introduction of an Annex B which tries to spek to the common triggers and transitions we have identified to date. Note in that Annex that I have not finished my work, as I wanted to get the next draft of the paper out for you all to review (if time allowed) before our meeting next week.
As promised, I have red highlighted the changes made in the paper.
I hope to see you all soon. Ian
Attachments:
You must be logged in to view attached files.Up::0Hi Rob, I use Dragon Dictate to talk into the computer. I listen to what is said and then talk it into a docx document. Edit as I go because talk never translates directly into the written word, and then normally do a final edit to clean up the glaring English glitches. Takes about 8 hours to do each meeting.
Cheers
Davin
-
AuthorPosts
- You must be logged in to reply to this topic.