Forum Replies Created
-
AuthorPosts
-
Up::0
Have read this book, which is a beaut. Recommended.
https://www.amazon.com.au/How-Big-Things-Get-Done/dp/1035018950/ref=asc_df_1035018950/?tag=googleshopdsk-22&linkCode=df0&hvadid=712259705004&hvpos=&hvnetw=g&hvrand=16058164612594418337&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9193273&hvtargid=pla-2196100620633&psc=1&mcid=d38a877c5a8e38a29b64f3988881abe9&gad_source=1Up::0As discussed today, I am in the midst of this excellent book, that I hope to write a review of, in terms of what we can apply to CPM. Not getting into Climate controversies in particular (its really just an example of a complex problem that Dr Curry’s thinking might be applied to), she explores the interaction of science, politics and risk governance, in uncertainty. My thinking is that if you expand “science” to include engineering, finance, economics and other disciplines that aspire to facts and truth, but have to grapple with uncertainty, her analysis has a lot to teach us in CPM.
“Climate Uncertainty and Risk: Rethinking Our Response” by Dr Judith Curry.
Up::0Colleagues, a copy of my webinar slides, as discussed. This was delivered to a Government and University of NSW sponsored symposium, “Project Government and Control Symposium” (PGCS). I put an ICCPM SIG ad in at the end. At slides 8 and 9 is the Jevons Paradox bit.
Attachments:
You must be logged in to view attached files.Up::0Thanks Davin, Ian and colleagues, for the productive few years. Hopefully we have helped some PMs. It was wonderful to learn from each other, throughout. “au revoir”, I suspect, rather than “goodbye”. :-)
Up::0Team, my apologies today. Duty has called, and I am unable to join. I’ll watch tye posts. Andrew
Up::0Ian, some great topics. My vote is for “The project management PM-related enablers (e.g. contracting, governance, collaboration, cost estimation, legal, HR, PA)”, with the vision that we produce an advisory paper on what may need to be demanded/negotiated with other disciplines, to be successful in managing complex projects. I think this would be a really useful product for ICCPM members.
Up::0Hi all, in reference to my action to develop the Webinar for November 2023, just to let you know that I have been in touch with the Office and the webinar program in booked until February, so it will be around that date.
Up::0Very interesting Tony. It is much the same in Australia – the Department’s work is IMHO often more akin to production management – nudging a “project” from station to station in a process. Not to trivialise this, though – it can be very tricky work. The substantive iron-triangle management is done by suppliers. There are exceptions to that, where Government Furnished [X] has to be ponied-up to the contractor, which can be significant projects in themselves (e.g. an available ship, a new facility, radios, etc). The Departmental work of integrating into a system-of-systems can also be substantial. Like Defence portfolios the world over, they are pretty diverse and its hard to generalise.
Up::0Team,
I have mentioned a few times, my hypothesis that the reason that rates of project failure remain constant – despite all the improvements – may be because the better the capability gets, the more demand is placed on it. There is, afterall, no shortage of demanding complex projects that need to be done in the world.
On this point, I discovered the Jevon’s Paradox (Jevons_paradox) , which sort of says the more efficient something becomes, the more it gets consumed, until it is rendered inefficient again. e.g freeway or broadband capacity.
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::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::0Team,
I will unfortunately be unable to join tomorrow session due to work duties. But I have read through the paper and I, too, am starting to become excited that we are on to something useful. Like polarities, once you start thinking about “transitions”, the examples are everywhere.Apropos, over the last week, I did an independent review of a large program, one tranche of which was Waterfall and another that was Agile. Goodness me! The Waterfall tranche had lost all baseline control and the original specification was completely overtaken by emergence. This was to a point, that a serious option was to abandon Waterfall and commit to Agile for the balance of the tranche. By that, I mean abandon the specification-driven approach and switch to a prioritised pursuit of value, for the remainder of the budget. (A big topic). I just offer it as yet another type of transition – when one methodology has to switch to another.
I look forward to the comments from the meeting tomorrow. Apologies that I can’t make it.
Andrew
-
AuthorPosts
