Scheduling Turnaround execution

Question

In my plant we are scheduling a 5 week turnaround during which we will execute >$10M in upgrades and repairs while the plant is down. We will be using scheduling software to coordinate projects for execution of the turn around portfolio including building interdependencies of steps between projects (e.g. scaffold built for one project that can be used on another should not be torn down until both projects have gone past needing it).

Once this schedule is built my manager would like it committed to paper as a static item and for us to use paper rather than software to track progress during execution. My gut tells me that this creates risk but he is arguing that the administrative overhead around tracking 1000+ activities outweighs the benefits gained. His thinking is that through good communication between trades and contractors any jobs that risk turning into critical path will be caught.

For something like this where a large portfolio is being executed simultaneously, what is the strongest argument for use of software to track completion of activities in a complex environment?

Answer 1

Your OP reads as if his assumption is he can maintain talent size for project controls that is consistent with the use of current technology while performing the activities of project control before we had our current technology. I think your best argument is to show him the number of calculations that need to be made that our current tools do for us manually and, that do to this calculation in a precise and accurate way EVERY SINGLE TIME THE SCHEDULE IS UPDATED with actuals, you will need to increase staff probably five fold, maybe more. Or, you will manage this contract without those calculations made which is not managing the project at all.

Imagine doing the forward and backward pass calculations on thousands of lines weekly to determine the change in critical path. Without doing that, it is impossible to really know your critical path(s). I have only done those calculations for exams, for like seven work packages, and rarely have I not made a mistake on simple math. For thousands of lines? Forget it.

Here's an analogy that might help. Before our current software that enables us to write documents, like MSWord, our grandfathers used dictation and typing pools. His expectation of avoiding our PM technologies is exactly like asking our current workforce to produce our documents we have to produce today with the old typewriter but without those typing pools of secretaries or whatever they were called then. Our output would grind to a halt.

Answer 2

For something like this where a large portfolio is being executed simultaneously, what is the strongest argument for use of software to track completion of activities in a complex environment?

Risk management. Every component of this portfolio has schedule risk (because everything has schedule risk). The cost of updating a paper schedule is much higher than the cost of updating the schedule in software.

he is arguing that the administrative overhead around tracking 1000+ activities outweighs the benefits gained. His thinking is that through good communication between trades and contractors any jobs that risk turning into critical path will be caught.

This isn't really a software vs paper question, then. This is a "track detailed progress against the schedule or don't track detailed progress against the schedule" question. The paper is a tool to enforce the choice of not tracking progress against the schedule, because it would be almost impossible.

So again, the best argument is risk management. Not tracking detailed progress against the schedule is a risk that escalates as the project proceeds.

I wonder whether the software you are using would permit tracking at a less detailed level than scheduling. Could you track progress against only the rollups? It sounds as if that is what he really wants to do, but it has turned into a paper vs software argument.

If your manager refuses to mitigate this risk by doing the detailed tracking, then push to mitigate the risk by building additional slack time into the schedule.