Question for the Brains Trust

[Stephen Grey]

#15818

Up

0

::

Ian

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

[Davin Shellshear]

#15817

Up

0

::

Hi Ian

I should have been clearer about the diagram. The diagram is based on a model developed by my compatriots for a infrastructure  alliance. I am not sure where the IP is now as one of the key people has died and his company sold to another member.

We were working an a methodology for assessing complexity in projects, and recognised that the complexity profile would vary at each stage of the project. We included looking at the cultural (behavioural) risk profile at each stage since the people involved could change through the project stages. Risk management for all projects starts at the beginning of the project and is an ongoing process across the whole project. The behavioural risk processes is separate and looks at the alignment of the group profile for the management and leadership tiers of the project against their particular objectives. It is based on behavioural predispositions which emerge from worldviews, and as we all know, this is a significant source of emergence in projects. The inclusion of  Complexity/ Risk assessment has not yet been put into practice, but is based on a similar process conducted during the procurement process.

So there was a lot not explained – apologies

I will be unable to attend the next Group B meeting as I will be in New Zealand without my computer.

Cheers

Davin

There is a lot of detail not included as we did not provide microscopes with diagrams.

[ian mack]

#15816

Up

0

::

Thanks Davin. It is an interesting document, which I could add to the discussion I will draft for Annex B – who has the IP for this diagram, your company?

Of course, it seems to me to be somewhat simplified and stylised, as it does not seem to portray a degree of emergence (typically high in complex projects)? I am more used to budget approval in each phase. As well, risk assessment (of complex and non-complex work) would be integrated and run continuously from project launch to close-out in an advanced risk treatment system. And I am more accustomed to risk-assessed plans (with the related/resulting confidence-based budgets and schedules) being much more focused on reaching goals ‘en route’ to Gates. My preference is also to delay as long as possible into production (and never before design is complete) the less risky/converged higher confidence establishment of schedule to delivery and budget. But then, by the time one introduces that degree of granularity, the diagram would be illegible, unless it was broken into each phase perhaps.

Just musing – again, my thanks. Ian

[Davin Shellshear]

#15814

Up

0

::

Hi All,

Attached is a diagram we used in the past to link complexity assessment and project gates

FYI

Cheers

Davin

Attachments:

You must be logged in to view attached files.

[ian mack]

#15811

Up

0

::

 

Hi Stephen – An interesting interpretation. In my experience, project management organisational processes usually have solid gates to control phases until you enter contract, which means that one is controlled to be in one phase or another – though backsliding is possible and I have lived through one such case. However once in contract (where the work really happens), there were always overlaps and backslides, with ‘hard reviews’ in need of becoming ‘soft’ by allowing some work to get advanced while emergent risks create laggards – this to maintain progress that will keep paying subcontractors so as to keep their teams in place. This is as close as I have seen to ‘smeared’ stages. And this also means many contract amendments if they were of a traditional inflexible design to start. Hopefully that makes sense.  Ian

[Stephen Grey]

#15810

Up

0

::

Rob

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

[ian mack]

#15804

Up

0

::

Hi Rob and thanks for expanding. My own experience was that emergence typically occurred within each phase (only once we were forced back to the beginning), and it is why ‘wave planning’ (an equivalent perhaps to your ‘agile phase’) as a project complexity response technique to planning, scheduling and delayed commitments to cost and schedule for a specific scope is so important.

I could support your approach by better integrating emergence in all phases (except close-out) and saying that the phases are:

– Initiation, understanding that as you add to the stakeholder identification list, it could impact the definition of success. As well, you may need to reset business needs based on changing internal capacity and capability availability

– Planning should be front-end-loaded for detail, with an expectation of additional detailed short-term and long-term planning going forward

– Execution & Monitor/Control (my preference not to separate these) will need to further plan to meet the next goal and thus re-plan the longer term, with the ever-present possibility of having to return to the redefinition of project success in Initiation

– Close-Out

 

Were it up to me, I would prefer to lay out the potential impacts of complexity for each project phase as follows:

– Initiation – As part of establishing the project’s business needs, preliminary stakeholder identification and alignment on project success criteria throughout the life cycle, the following should be included in complex projects: one must determine if there are projects aspects that could be complex, and if so start to establish complexity techniques – this necessary early on with complex projects as it could affect  the definition of project success and it may be needed in setting stakeholder expectations with respect to the possibility or even realization of emergence from Day Two.

– Planning – In addition to planning what tasks the team needs to perform (tasks, actions, timelines, and the resources for the project execution team), one needs to establish all of the project’s systems which in complex must include tailored systems to best deal with complexity such as wave planning itself. As you discover more information, you will have to adjust your past planning due to emergence which will introduce more back-and-forth approvals for all manner of things from governance, throughout the planning, execution and monitoring & control phases.

– Execution and Monitoring & Control – I have addressed these two PMBoK phases together because I never liked their separation. Here my experience amplifies ‘the implementation of plans’ to include developing and then supporting a Request for Proposals, evaluating bids, negotiating & awarding one or more contracts and resetting as necessary to engage with contractors to monitor contractor performance and to respond to emerging concerns to minimise harmful impacts to a project’s successful delivery. As I think you have seen, my experience has been that there is much emergence in this activity with lots of related schedule slippage and project crises – in one case resulting in project cancellation after years of work to get to a contract awaiting approval before the client ‘pulled the plug’ and the project was terminated. (The back story needs to remain confidential – regrets)

Either way, the phases do not change amidst complexity – you likely will have to revisit them and then re-plan often. And, perhaps this is a question/subject we should add to Annex B in the paper, after discussion within our Group?

For consideration – Ian

[Rob McMartin]

#15802

Up

0

::

Morning Ian,

My thoughts were more along the line, we have the 5 Phases, as you described, but what do we do when we get emergence in the project.  The only way to deal with it is to re-evaluate the entire process, before attempting to deal with the complexity.  To continue on with the execution phase when we have emergence through the project would potentially be project suicide, as you need to understand all the issues before attempting to move on, so possibly the phases become :Initiation,  Planning, Execution (replan, modify, re execute) , Monitor/Control and Close-Out, and this is for emergence, while a complex project will certainly require more detailed Initiation and Planning prior to Execution, or do we need to incorporate an Agile phase within the existing phases.

Hope my thoughts are clear enough.

 

Rob

[Rob McMartin]

#15801

Up

0

::

Morning Ian,

My thoughts were more along the line, we have the 5 Phases, as you described, but what do we do when we get emergence in the project.  The only way to deal with it is to re-evaluate the entire process, before attempting to deal with the complexity.  To continue on with the execution phase when we have emergence through the project would potentially be project suicide, as you need to understand all the issues before attempting to move on, so possibly the phases become :Initiation,  Planning, Execution (replan, modify, re execute) , Monitor/Control and Close-Out, and this is for emergence, while a complex project will certainly require more detailed Initiation and Planning prior to Execution, or do we need to incorporate an Agile phase within the existing phases.

Hope my thoughts are clear enough.

 

Rob

[ian mack]

#15798

Up

0

::

Hi Rob – I must admit that I have seen the project life cycle defined in different organizations in so many ways. I have no difficulty with any framework, rather what matters in complexity is what has to get done. After a bit of reflection, I think what matters in complex projects is the extra effort at the front end around the requirements definition, the preparation for launch and the unique aspects of planning (in particular, who will do what, using what techniques and when – plus scheduling). Whether it is PMI’s 8-phase approach or the typical 5-phases (Initiation, Planning, Execution, Monitor/Control and close-Out), I care less about the semantics. But I may be missing your point. A few words then to  people thinking – Ian

[Author]

Posts