Cleaning up logic when submitting a Recovery Baseline

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.

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!   

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.