Critical Path Walker

This is a story about the mainframe era and project scheduling software.

Several years before receiving the Quad Cities assignment in 1994, I was working overseas. The timeframe was 1990. Only some employees had computer screens on their work desks. File folders were in their heyday.

It was Saturday. Perfect weather. The windows were open. I was all alone. Aussies do not normally work weekends especially the management staff at Garden Island Dockyard. Weekends were very quiet and I could focus. The only noise I heard was the occasional cannon shot for weekend sailboat races in the harbor.

This is when I could be creative and do risky things. As a scheduling consultant, I was technically not a programmer but quite capable of using PSDI scheduling software (called P/2). In the previous weeks, I taught myself COBOL (with some help from IT staff). The neat thing about COBOL is that it is very similar to P/2 – and similar to speaking English. 

The hardest thing about P/2 is that you must type up commands and wait for the results to come back. You make one change in the schedule critical path and everything gets recalculated. The best way to find any "errors" in the schedule is to get a network plot to show the critical path which can take some time to print out and quite challenging to follow all the logic ties. [ I wish I had one to show you ]

It seemed to me I could write a program to show the predecessors and successors of one activity on a computer screen by making fake boxes. 3 boxes on the left, 1 in the middle, and 3 on the right all connected with logic ties.

I would start the program by entering the center activity. This would show 3 activity predecessors and 3 successors. The objective is to discover what was pushing the project finish. There are several possible drivers (e.g., logic ties, lags, constraints, progress, activity calendar, duration, resource leveling).

Typically, there will be one primary driver of the activity you entered. I built activity boxes using keyboard characters - dash, slash, and vertical line. I displayed the top 3 drivers (based on total float) on the left side. Then, by hitting a PF Key on the mainframe keyboard, everything should shift to the right which is walking backward on the critical path. This was the plan anyway.

The thing is, if I made a coding mistake, I could put the program in a loop and then not be sure what happens to the mainframe. Anyway, I hit the PF8 key and the screen redisplayed so fast I almost fell out of my chair. I looked around the room and there was no one to share my excitement with. It worked! The Aussies would say “gobsmacked.”

The beauty of this on-screen display is that a non-scheduler could operate it, with minimal effort, and understand what he was seeing. A new run would be made once fixes were made and the process could be repeated.

A few years later, I visited a nuclear power plant where I had the chance to re-create this program. Timeframe: 1994

In a nuclear plant P&S department, there is a Senior Reactor Operator who is assigned to the department for the outage and acts as the subject matter expert (SME). He has the final say on schedule validation. Schedulers gather information like newspaper reporters and submit “fragnets.” The master scheduler puts it all together, but it is the SME who provides final approval of the outage schedule.

PSDI later became MRO and created Maximo. IBM then bought MRO and the Maximo product. In any case, I am not sure this feature, the critical path walker, has been replicated yet today. The software designers may not understand the significance. Sometimes when legacy systems get replaced in the name of progress, features get lost.