Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Cleaning up logic when submitting a Recovery Baseline

4 replies [Last post]
Greg Paulson
User offline. Last seen 49 weeks 14 hours ago. Offline
Joined: 15 Jun 2018
Posts: 30
Groups: None

Hello,

A year and a half into our project, we finally have an approved baseline and are being allowed to submit a Recovery Schedule that will reflect the actual planned sequence of the work.  We have not been able to submit any monthly updates, other than to status the baseline as of the data date we will be using for the Recovery Schedule.

While considering various recovery scenarios, I developed a simplified schedule to expedite implementing revisions and reviewing the outcome.  Now that we've decided upon our recovery plan, it is time to revise the original Baseline to match the new plan.

The Baseline has 4,000 activities and 10,300 relationships.  An inordinant number of those relationships redundant or incorrect logic ties. (I inherited this schedule).  

In making modifications, I instinctually began "cleaning up" the logic to remove some of these superflous and confusing logic ties, as I normally would if I were preparing a Basline Schedule.  But about a week into this process, I suddenly realized the tremendous amount of work that might be required if I have to explain each and every logic change to the schedule reviewer.

Do you think it would be easier to simplify the schedule to make it less cumbersome, hoping that the Recovery Schedule will be reviewed on whole as one would review a new Baseline Schedule?

Or, would it be easier to go back and add the deleted logic back in, live with the overly complicated logic, and try to only remove the invalid ties that could potentially affect successors somewhere down the road?

I am preparing an agenda to go over this and many other aspects of the schedule, but wanted to pose this particular question to the Planning Planet community as well.

Thanks!

Greg

PS. I've read through AACE's RP 54r-07 Recovery Scheduling, which is helpful, but does not speak directly to the issue of "cleaning up" logic.

Replies

Zoltan Palffy
User offline. Last seen 3 days 20 hours ago. Offline
Joined: 13 Jul 2009
Posts: 3089
Groups: None

if you give me your email address I can send you info on redundant logic and how to remove it using sdk and excel if you do not have Acumen.

Tom Boyle
User offline. Last seen 4 days 15 hours ago. Offline
Joined: 28 Nov 2006
Posts: 304
Groups: None

I like Trevor's response.

"Redundant logic" may be a red flag.  The definition of "redundant" logic is not fixed for everyone, with non-FS relationships, lags, and leads adding confusion.  For far too many schedulers, unfortunately, "redundant" means any logic beyond the minimum necessary to get some acceptable early dates.  For them, detailing the technologically-required, but (initially) non-driving relationships is wasted effort and therefore "redundant."  [To be sure, there is some professional judgement involved in establishing how much logic in a schedule is "enough."  My own bias is more or less, "when in doubt, leave it in."]

If you have access to Acumen Fuse, then you can easily find, report (to the reviewer), and remedy any truly redundant logic (e.g. A<>C when A<>B<>C exists.)  Though the resulting impact to the schedule dates is (by definition) zero, the process may improve your subsequent scheduling effort while building credibility with the reviewer.

The fact that you have a "Baseline" schedule approval, first progress update, and invitation for a recovery schedule all happening concurrently 18-months into the project implies a heap of trouble.  I can only presume that by now the issues and/or incompetence (on both sides) that have brought you here have been cleaned up, and there's a new spirit of cooperation.  Under these circumstances, If I were the Owner's consultant - and the Contract did not explicitly mandate a different approach - I would view a "Recovery Schedule" (along with the more-important, and governing, written Schedule Recovery Plan) as a 1-time opportunity to correct a bunch of errors and get the project back on track.  The details of the redundant or incorrect logic ties in the prior schedule are not relevant.  Consequently, I would lean toward giving wide leeway to "clean-up" the logic from the Recovery-Data-Date forward, with the focus being on the end result - i.e. Baseline Rev 1.

If that presumption is wrong, however, and you expect to be second-guessed at every turn, then I would suggest fully cataloging all 10,300 original relationships, coding and/or flagging each as remove, replace, or retain and with a reason coded for the first two flags.  You could do this in Excel or in a third-party tool like Logic League. Yuck!   

 

 

 

 

Trevor Rabey
User offline. Last seen 1 year 18 weeks ago. Offline
Joined: 29 Nov 2005
Posts: 530
Groups: None

Greg, your situation is indeed unenviable. If you are going to get assistance anywhere, this is the place. Others may be able to give better advice than me, but I will give it a shot. Generally, I don't consider whether predecessor links are redundant or unnecessary, only whether they are true or not. If a task has half a dozen predecessors, and let's say that they are all FS0, only one of them will be the one that finishes latest and determines the earliest start date of the task. But the others are still all true, and as the plan is updated and re-scheduled maybe one of the others will become the one that finishes latest, so there is still a good reason to keep them there. I would rather have more than needed, than risk missing one. So your priority is to remove any that are definitely not true. I would also remove any that have negative lag, or at least remove the negative lag, which is my least favourite thing. I would also make sure than every task has at least one FS0 predecessor and at least one FS0 successor. After that, the SFs and FFs can probably go. The SSs can probably stay, but try and remove any positive lag from them, if any, and this usually requires breaking tasks into finer detail so that an SS with lag can be replaced by FS0. After that, remove obviously excessive unnecessaries but don't overdo it.

What you call a "Recovery Schedule" is simply the new best plan going forward, all previous plans being now superseded/obsolete/abandoned/irrelevant. It is basically starting from scratch but having perhaps something to start with to build on.

The approved baseline must by now barely resemble your current intentions, even if it does show the intentions from 18 months ago.

I don't think you need to be able to explain each and every change, except to say that the changes were necessary because what was there in the approved baseline was wrong and/or genuinely unnecessary, and the changes are to correct them and improve the overall clarity. What you are doing is a good idea, whether the reviewer buys into it or not, but I haven't met him so I can't say whether he has the sense to let you do what needs to be done.

Greg Paulson
User offline. Last seen 49 weeks 14 hours ago. Offline
Joined: 15 Jun 2018
Posts: 30
Groups: None

After reading through some posts regarding "redundant logic" I would like to clarify that the logic I have been deleting is leftover from the initial schedule development and absolutely unnecessary. 

Removing these unnecessary links has made it simpler when resequencing because I can clearly see what is driving and I don't have to resequence multilpe redundant links.

However, the previous posts indicate that many see this as an unnecessary and potentially dangerous practice.

That in mind, I'm now very curious to see how the community weighs in on removing redundancies when submitting a Recovery Schedule.

Seeing as I've already removed approximately a hundred blatant redundancies, my hope is that the consensus is that removing these is a good idea.  Otherwise, I've got some back tracking to do!

Thanks again,

Greg