Oracle Primavera’s P6 R8 release in November 2010 may generally be considered a successful operation. It is a shame the patient died.
CPM was developed in 1956 to assist in the problem of bringing the maximum resources to bear on reducing the time it may take to shut down, revamp, and restart a chemical process line at Du Pont’s production facility.
Each hour the line was shut down represented a loss of revenue. If while executing a carefully prepared schedule, some new issue was discovered, such as corrosion in a pipe which was planned to be used from the old configuration, recalculation of the bar-chart was found to take an average of 40% of the initial scheduling effort.
The solution was to map a pure logic plan of the thought processes used to prepare a bar-chart, and let a computer calculate the schedule. Changing the plan to account for unforeseen conditions and changes could be done quickly; recalculation by the computer even more quickly.
The purpose of the entire operation was to speed completion of the work modeled.
Over the years, new features and benefits have been added to CPM software, notably the ability to report past progress to upper management, and the ability to track resource usage across the many projects of any one enterprise. And now given a holistic viewpoint, an enterprise may utilize portfolio resource allocation that may slow any one project (resulting in less than optimum profit) but speed enough other projects to offset this loss and actually improve corporate profits.
After all, even at the 1956 Du Pont facility, resources were not unlimited and had there been the desire to revamp two lines at the same time, a master plan involving both would probably be preferred to separate schedules.
But the world of construction does not work that way.
Should a contractor on project “A” pull resources to support work on project “B” to maximize the contractor’s profits, it is likely the contractor will be terminated from “A”, the owner will contact the surety to take over, and the contractor will be legally enjoined from removing equipment from the site.
Projects in the worlds of manufacturing, aerospace and defense typically move ahead at the whim of one owner. Projects in the world of construction move ahead based upon collaboration and an enforceable contract between two or more “owners.” Here we cannot rob Peter to pay Paul. (Note the term does apply to two construction projects, Cathedrals of St. Peter and St. Paul, one delayed to speed the completion of the other).
What does all this have to do with Oracle Primavera’s P6 Enterprise Project Portfolio Management, Release 8?
With all of the advantages of P6 R8 browser deployment, we do expect it to take over the last remnants of older legacy systems. This new software series no longer supports the construction norm of “interruptible duration” and only supports the manufacturing norm of “continuous duration”.
And this means that the goal of controlled resource usage will always trump early completion of a project, be that of construction or that of getting a product “first to market.” (Had the Betamax manufacturing plants been ramped up and brought to market only a few months earlier, the term “VCR” would be unknown.)
Let’s look at a simple logic diagram.
Activity A of 10 days duration, is followed by Activity B of 15 days duration, and Activity C of 10 days work, but note Activity C cannot be complete until 5 days after Activity B is complete. Activity D, of 5 days duration follows B and C. Activity E, of 20 days duration, can start when 50% of Activity C is complete. Activity F, of 5 days duration, follows Activities D and E.
Although not perfectly modeled, this logic plan and calculated schedule may be depicted below:
The manager of boilermakers is now happy. She will get her maximum of productivity (which will be reported to her boss) from her crew. Of course she will be looking over the weekly (or daily) updates to see if Activity B is on schedule, and if there is any delay expected, will further delay deployment of her crew, delaying the project even further.
If it looks like Activity B will be finished early, what do you think the chances of an early deployment? Is two weeks additional downtime for the process line going to be noticed by upper management? Some may lament that “it used to be done faster” but we can see, right from the computer generated schedule, this is the best we can expect.
Complaining may be fun, but does not get the job done. What can we do as professional planner/schedulers to work within the constraints placed by our software?
First, we should note whether our software supports interruptible durations. Assuming not, we should convert all FF lags into FS by splitting the impacted activity into two parts, explicitly stating the scope of the portion that cannot be completed until the “predecessor” is complete.
Do not take “NO” for an answer – make up your own scope description if required (“That portion which cannot be completed before B is completed”).
This, of course, does not solve all of the issues raised, but is one way to start. I’d like to hear from readers of this blog other ideas for work-arounds to make the software better model how we want to do the work, and not dictate how work should be performed.