› Forums › Managing Risk in Complexity SIG
(MRC SIG) › Working Group B: What principles are important in dealing with complexity?
-
AuthorPosts
-
Up::0
Hi Team – Thanks for offering two interesting cases of project failure gentlemen. I think both are complex projects because I believe that all projects with multiple clients enter the realm of complexity. I would also offer a few amplifying thoughts.
Rob – In addition to multiple clients, I would suggest that R&D projects are almost always likely candidates for being tagged as complex projects because of the level of uncertainty – the degree of complexity influenced by whether the project is is foundational “R” or mostly “D”.
Stephen – As you imply, this is a case of multiple end-user group requirements (creep or poor initial requirements definition) that prematurely eat up all the funding. I think this is a common challenge wherever multiple clients are involved and especially in IT projects, which are indeed complex in nature. .
That said and remembering our current study on setting the definition for project success, had the multiple clients in either case have clearly defined success with end user input and then addressed by employing a pre-mortem analysis, there might have been mitigating strategies put in place to deal with either set of challenges at project launch – for example, by (1) finding common ground among the client requirements through better study of project scope, (2) paring down the client base at certain decision points when previously agreed thresholds in efficiency measures were met, with arrangements to address IP credits for follow-up investment by those opting out with ‘those left standing’, and (3) redefining the definition of project success at the predetermined decision points.
Finally, wherever there are multiple clients, I thing projects need to employ structured collaboration and extensive governance investment in the projects as they are launched to give them a fighting chance of being perceived as successful. Ian
Up::0Robert
Yes
In fact, multiple independent stakeholders with diverse priorities and the ability to influence the conduct of a project seems to me to be one of the clearest cases of complexity. Each stakeholder can make or demand adjustments to suit their objectives. These adjustments will affect other stakeholders, probably causing some of them to seek further adjustments. The adjustments don’t need to be very large for the scope and direction of a project to shift incrementally and ultimately move well away from its starting point.
Even if the stakeholders are constrained by change control, achieving consensus on decisions might bog the whole thing down.
I saw this on the TAFE student record project. A central project sought to engage all the TAFEs in procuring a single platform to hold and maintain student records.
For the benefit of the non-Australian members, TAFEs are Tertiary and Further Education colleges. Less academic that universities and offering everything from trade skills to hospitality, hairdressing, teaching, allied health, personal care, accounting and administration.
The core funding was to engage a contractor to specify, design and produce the platform based on consultation with the TAFEs and having regard to a myriad of existing hand made systems that used paper records, spreadsheets, small data bases, text files and other platforms to fulfill the function – all different from one TAFE to the next. Each TAFE not only had a different set of homemade tools, each TAFE’s systems were not integrated. They were an aggregate of half a dozen ad hoc responses to record keeping requirement that had emerged over many years in each organisation. The record keeping requirements of each TAFE differed (data base fields) and staff were not keen to relinquish their little bit of power.
Protracted decision making and reluctance in the TAFEs to fund the data gathering and cleansing required, a key planning assumption, led to the single pilot implementation exhausting the funding intended to kit out a couple of dozen organisations.
I think the pilot was declared a success and it all shut down. I didn’t hear much about it after that.
No real technical complexity, just basic data base design and implementation.
All to do with multiple independent stakeholders with differing priorities and the capacity to influence the direction and execution of the project.
Steve
Up::0A question for the group?
Could a program of work that has multiple funding sources constitute a complex program.
For example, I worked on a program a few years ago where multiple entities supplied funding for delivery of an R&D program. Due to the number of different public and private groups being involved all brought funds to the table to “buy in”.
After a few years, the Govt agencies started to suffer financial issues due to funding being diverted. This in turn led to delayed progress. Private groups picked up the financial load for a while, hoping for government funding to emerge. In fact, the funding was restored after a year, but became piecemeal. as the Govt bodies had funding withdrawn in other areas.
The project eventually turned into a legal bun fight when the Private companies declared they owned the IP, because they had supplied most of the money and had done most of the words.
The Financial Complexity, could be the heading for some of the uncertainty in programs in such areas as, bribery and corruption.
-
This reply was modified 1 month, 3 weeks ago by
Robert McMartin.
Up::0Team – There was a tremendous amount of useful information in the last meeting transcript that took me some time to pull out. I added that data to the previous information gleaned from our Working Group meetings on the subject of defining success for complex projects. I then did my best to capture these thoughts in a first draft of yet another paper (attached). It was no easy task, and you may object to its wordiness and length when you review it, among other things. Hopefully team members will have time to have a read before the next meeting. For consideration – Ian
Attachments:
You must be logged in to view attached files.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 am watching proceedings in the background but unable to rejoin the discussions
Looking after invalid relatives and working on a very interesting infrastructure project leave me little discretionary time
I’m sure the group will continue to turn out great stuff
My loss I’m afraid
Best wishes
Steve
Up::0UK Command Paper
We should remember the context:
- Secretary of State – exiting and retiring
- UK economic woes and debt burden
- Upcoming election next year
The Command Paper:
- is a lot of waffle & aspiration that only takes into account the realities of budgetary constraints by not including any details on programmes or inventory sizes
- re-recognises the importance of European collaboration
- does stress the importance of providing industry with long-term certainty, the value of iterative development, and the need for early engagement on strategic requirements.
My view is
The paper talks about increasing defence outputs within the current budgets – laudable – and yes, better Project Management would be useful to do this. However, critics would say the procurement issues run deeper than project management: e.g. AJAX armoured vehicle programme.
The government believes naively it has invested significantly in DE&S project management skills and that their competition policy has driven innovation e.g. T31e Programme etc
I agree that the Command Paper could and should have emphasised the tools (like Project management) that are needed to deliver better.
However, I see most of the real project management being done in industry. Defence Departments do budget management and only project manage the procurement process and only do a very little of the delivery process (e.g. Government Furnished Equipment etc).
We shall see what procurement processes are affected by the ideas within the Command Paper in due course. However, I have never seen Treasury wanting too much innovation… they always return to the economics of competition
I have done an analysis of the Command Paper for my business. In reality our concerns are not the project management skills of Defence. Industry/companies worries focus more on their policies, decision-making, heavy processes, risk transfer and indecision/change decision tendencies. The government have never achieved the ‘certainty for industry’ they talk about … because they are judged on politics/impact/change/etc…. and they train the MOD in ‘leadership’ which means change something …..
Up::0Hi Team – Rob, perhaps we can trigger Ton’y thoughts on why DE&S’s project management competency has escaped the latest review?
Team – I have mined the latest meeting transcript and tried to capture the many insights into a framework document (attached) for your review. With luck, I will see many of you at the ZOOM meeting next week. Ian
Attachments:
You must be logged in to view attached files.Up::0I read the UK report with great interest and I was struck by two things. While there was mention of Programme Management and Programme Managers there was no mention of project management or the competency of the people running the project/programmes.
As I was reading the report, I couldn’t help hearing Ian’s words on complex project governance almost on each paragraph.
The amazing levels of parallels between the UK MOD Procurement Group and the Australian CASG were unbelievable, I could have played Snap with the report, when comparing it to Australia.
Up::0David
Regret I’ve been busy travelling with work. I can’t make the 27th July either as touring Scotland.
Please let me know the next meeting date when available.
I’m keeping up with the notes.
Many thanks
Tony Graham
Up::0Hi Davin and thanks. I will try to get to this before week’s end (if lucky). Busy on a number of things, including the latest UK report on their ‘broken’ procurement system at the link below. Ian.
Up::0Hi Group B
Attached is the transcript of our last Group B meeting on 6 July 23. Lot of interesting thoughts emerged in that meeting.
Sorry for the delay in transcribing, I have been fully occupied in other work until now.
ICCPM have asked if Group B would be willing to to host a webinar in November on the work we are doing. I of course agreed and am now looking for a bunny to do it.
I thought the last meetings thoughts around honesty in business cases (owning up to disbenefits, minimising harm on complex projects, etc.) might be a really interesting topic, and we could fold in some of our earlier reports into the topic. What do you think.
See you next meeting on 27th July.
Cheers
Attachments:
You must be logged in to view attached files. -
This reply was modified 1 month, 3 weeks ago by
-
AuthorPosts
- You must be logged in to reply to this topic.