Planning Outages in P6

• Use of artificial constraints to move outages is wrong unless there is a real date constraint. Very frequently some preferential logic must be used but you shall never use constraints or preferential logic whenever there is a way in your software to handle true logic. Substituting resource dependencies with soft links instead of using resource leveling is bad practice. 

• Suppose your work consist of work on one hundred towers or sub-stations and you can work outage on three of them at the same time. The work will take about 8 months.  If you need to do it in 4 months you can increase the resources as to be able to work on six towers at the same time. 

• Any three towers can be worked at first outage. There is no dependencies but resource limitations and this is how you shall model it.  If for some reason work in any tower must be delayed the next in order of priority will take its place without this requiring a re-work on logic. If after some time some outages have been stopped due to bad weather and you start falling behind it might be necessary to increase the number of towers you can work at the same time or another shift might be allowed to work another outage during the week. If using resource leveling the adjustments are easy on the other hand if using soft links it can be chaotic. The following figure shows a way to model this scenario without without having to recur to false logic.

• Under resource leveling longest path is flawed, even if you substitute resource dependencies with soft links the logic is not static and therefore a flawed model. In addition not always longest path is the most critical. I do not mean to say there is no use for longest path computations but that its use is misunderstood. 
• The idea of always a single longest critical path is not valid in the presence of multiple calendars, resource constraining, date constraints(some of which are contractual and very real), out-of-sequence progress and other functionalities not available when CPM was born over 50 years ago. 
• I used calendars to drive start of pre-outage activities for Mondays while outages to be on Saturday.  What most people said about calendars is correct same as the recommendation to avoid drawing your schedule as if a bar chart using date constraints. 
• I used different software but P6 shall be able to handle this without any problem. 

first i don't recommend to use contraints to indicate outages.

I always use an outage calendar that shows the outage(s) duration as a work days and all other days as nonwork.

to adjust the critical path you will have to revisit the pre-outage activities to revise the durations and logic, see if  it's possible to use FS instead of paralel logic also check if the durations are enough.

and if everything is okay sometimes i extend the durations to adjust the critical path and make it look like the longest path.

Hi John

I solved this problem by putting the outage work as the only "working" period in a non working calendar.

This project was a start up and linkage of a new sub station in central london and the only time sections of the grid could be switched of was for 90 minutes from 21:00 hours on a Friday night.

So my calendar had this work pattern for every week - if you missed the slot then wait for next week.

I am not sure that P6 is subtle enough to replicate this work pattern - P3 certainly wasn't - so you may have to resort to Asta PowerProject.

Best regards

Mike Testro