Chaos, complexity, and CPM

Hi Dennis

This is similar to another current discussion on the topic "If you can't measure it - you can't manage it".

In my experience management ignore the programme in whatever degree of detail it is presented.

It forms expensive site office wall paper - chaos ensues.

Best regards

Mike Testro

Mike:

Thanks, I will look for the other thread.  Managers will use what works.  They cannot be faulted for ignoring that which does not provide timely, useful information.

Other thread is from several months ago:  http://www.planningplanet.com/forums/planning-scheduling-programming-discussion/544736/if-you-can%E2%80%99t-measure-it-you-can%E2%80%99t-manage-it

"The current thinking is that with greater detail/complexity, project managers/controllers/schedulers gain greater control."

Greater detail allows for more granular scheduling and more objective progress reporting.  Objective progress data is much better for driving decisions (ie. managing) than subjective data.  This only works when an organization has procedures in place to effect updates timely and completely. 

Greater detail doesn't necessarily correlate with greater complexity.

As I see it, Chaos Theory really only applies here to the effect that:

1. more data input = more opportunity for data errors
2. more schedule data = greater havoc for soft logic rework in the face of schedule non-compliance

With proper scope and sceduling reviews, you can mitigate the former.  With proper scheduling practices (minimizing soft logic), you can mitigate the latter.

We built our ATC software to handle a high level of detail for turnarounds (refinery shutdowns / maintenance projects).  We have found the greater clarity of a granular schedule and objectivity of progress reporting to be essential to managing the beasts.  YMMV

Bernard:

Thanks for responding, though I don't think either of us understands chaos theory and its (mis) application to project controls.

Chaos: When the present determines the future, but the approximate present does not approximately determine the future.

For me, it goes to trying to understand the system rather than rigidly modeling expected outcomes (overly detailed schedules).  I expect the plan to go awry, and see aggragation as a possible remedy.  Soft Logic does not eliminate detail, in fact it may incorporate more detail, it just does not put that detail in the schedule.  

I am toying with the concept of applying Soft Logic to turnarounds (STO in your parlance). My thinking is to use the Work Order (WO) as the work package and go into no greater detail than this work package on the schedule.  The Work Order would be fully disassembled and become part of a flat file or database.  The WBS would be geographic (construction-centric) instead of the more common function oriented (Operations-centric) and go only down to the Work Order. All engineering would be by WO, as well as any procurement.  The schedule would be resouce loaded again by WO and aggragated according to the WBS.

I would welcome your insights as to the feasibility of this approach. 

BTW: Your company seems to have some nice tools.  I need to get better aquainted with them.