Oracle's P6 R8 – A Successful Operation, but Let's Make the Software Model How We Want to Do the Work
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.
I have found that software companies have made the tools more feature rich as a whole, with many of these either not applicable or undesirable for use in construction projects. Also wi...
Having to use activity manipulations to achieve a simple scheduling task seems counter to the general principals of good scheduling practice. It introduces additional opportunities for error and jeopardizes the reliability and stability of the critical path. It also creates additional activities for updating and reporting in an era when planner/schedulers and managers need to be more efficient to reduce cost and save time. this also introduces an added element of schedule risk, and for those in the EVM world another potential source of variances to report and control.
It seems that the software providers are shifting to support and respond to a different market, no longer seeing the construction industry as a unique and valued source of revenue. Choosing rather to make us "make do" with what they provide. the challenge is going to be how will this play out in practice, and what will happen when we have to bring these ill-fated schedules to the negotiations table when a project underperforms.
With respect to Dr. Plotnick's closing query, the best workaround for any software is to design the software to produce the required results. Although we in the construction user commu...
Messrs. Koppelman and Faris have been moving away from their original market for a long time. I happened to attend the users conference in Orlando when P3e was first announced. Users were very vocal about their displeasure with the "improvements" that were being described, which appeared to take the Primavera execs by surprise. There was a temporary retreat by Primavera but they eventually pressed ahead with a series of modifications that resulted in today's product.
As noted by Dr. Plotnick, P6 appears to be more aligned to the needs of non-construction customers. That has consequences which go beyond those listed in the original blog post. The more that Primavera, now Oracle, is successful in selling P6 to those customers, the more difficult life becomes for the engineers and constructors with whom they contract. Why? Because those customers want/need to impose their own WBS, resource IDs, codes, calendars, etc., on contractors so that the purity of their databases isn't sullied by the contractors' versions of those elements. That disrupts the contractors' ability to establish consistent means for organizing and managing their work, since each client has a different set of requirements that must be followed on their projects.
In fairness to Primavera, P6 is miles ahead of P3 in terms of multi-user operations. On large projects with multiple planners working in the same schedule, that is a huge advantage.
Since the current environment doesn't feature a contractor-friendly version of P6, it is important for companies and individual planners to understand how the software works. I have, as either witness or user, seen cases where P6 behaved in a very different fashion than expected. It wasn't until digging into some very obscure details that the reason for those unexpected results was discovered.
In real life, I see a lot more of the second example provided by Dr. Plotnick than I do of the third, regardless of software. While start-to-start or finish-to-finish relationships may be reasonable to use in limited cases, they can't be substituted for careful definition of the work that is to be performed. With good definition, it is usually possible to use finish-to-start relationships, with much better results.
Oracle-Primavera has provided more features, but implementing them successfully on large engineering and construction projects is a much greater challenge than advertised. This is espe...
Garbage-in, garbage-out. When you have a large number of players with a wide variety of scheduling experience (and quality), it is difficult to produce a schedule that produces reliable output for use in management decision making. For example, many project managers expect to be able to rely on total float values from the integrated schedule to denote criticality. With so many cooks in the kitchen, it can be difficult to maintain a schedule of high enough quality to produce consistently useful float values.
Oracle-Primavera has some continued work to do on the software side, and we as an industry have some continued work to do on personnel and practices. The software is giving us access to more information and more tools with which to process it, but we still need people that can recognize when the computer's answer is wrong, and why.
Mark C. Sanders, P.E.
