Primavera P6 contains a feature that I can take some responsibility for recommending. For those of you who do not know much of the history of Primavera P6, the legacy program - Primavera Project Planner - was introduced in 1983 by Primavera Systems.
And while we are going down memory lane, Microsoft Project was introduced the same year. Ask Netscape Navigator what it is like competing with Microsoft. (Netscape Navigator, for you youngsters, was the first great web browser, but Microsoft killed it by bundling Internet Explorer with Windows).
I also started my scheduling career in 1983, which seems like serendipity given that Primavera software would end up defining so much of my work. I have not spent nearly as much time using any other software program, and indeed, many of the earliest programs I learned are no longer around (Lotus Symphony, VisiCalc, IBM DisplayWrite, etc.)
But I digress. I started my scheduling career with Wagner-Hohns-Inglis, a construction consulting firm then headquartered in Mt. Holly, NJ. On the other side of the Delaware River is Bala Cynwyd, a town that only locals can pronounce correctly (hint: Ken Wood). WHI was offering Critical Path Method Scheduling long before any commercial scheduling software was available, using proprietary software running on mainframe computers.
I had studied CPM Scheduling in college using a program that ran on the university's mainframe computer. But in college our assignment was to build an initial schedule. During my job interview with WHI the scheduling manager asked me quite a few questions regarding my scheduling knowledge, and I had a few questions of my own, such as:
"How do you update a schedule?"
It seems rather obvious now, but I was not yet familiar with the function of the Data Date - a term not used in my college textbook. And I wasn't sure how actual dates get recorded. I was used to the schedule being "static" with a focus on getting the logic right.
WHI hired me in August 1983 and I was quickly thrown into the meat grinder. A consultant would typically build two or three initial schedules and perform ten or more updates every month. Each new initial schedule meant another schedule that had to updated, so the workload would build up pretty quickly.
My role in the beginning was to take over some of the monthly updates and to build parts of initial schedules - something we would call "fragnets" today. I would often create logic for the sitework activities, which were easy to differentiate from other work. This would also speed up development of the initial schedule.
To prepare me for my first update, the scheduling manager took me to a local project that our firm was scheduling. Besides just asking about progress I learned to inquire about potential problems. And with the Activity-On-Arrow diagramming method popular in those days, it was possible to do some quick manual calculations during the meeting to let everyone know if the end date of the project had changed.
Pretty soon I was attending quite a few update meetings on my own. And it didn't take very long for someone to throw me a curve ball. I was asking a subcontractor about one of his activities. He confirmed that it had started, so I asked for the actual start date. My next question was how much time he needed to finish the task. "Three days", he replied. Okay so far, until he added:
"But not the next three days."
The subcontractor was telling me that he did not plan to continue working on the activity. My boss had not warned me about this scenario. So I waited until I got back to the office to discuss the best approach for an interrupted activity. He advised me to leave only the number of days necessary to complete the task.
I understood the rationale. Artificially increasing the Remaining Duration to include days the contractor does not plan to work on the task obfuscates the real effort required to complete the task. And our client was typically the general contractor, who might not accept that the subcontractor is planning to ignore the work for several days.
There are clearly situations where an activity is interrupted because of unexpected events such as change orders, RFIs, and failure by other trades to perform in a timely manner. Identifying excusable delays is very important, especially when the project end date begins to slip. Our firm was very proactive with respect to time extension requests, again because our clients were mostly general contractors.
Nevertheless, work is sometimes interrupted for reasons that are less clear or even acceptable. Subcontractors might rob one project of workers because they are getting pressured to pick up the pace on other projects. Resources are finite. (I will never forget the kitchen supplier who gave the project manager a tour of his facility to demonstrate that the equipment was in production; it was all equipment for another client).
I would have preferred another solution. Leaving only the number of days required to complete the task did not accurately reflect the finish date for that activity. And if the activity was on the critical path, well, the project end date would not be right either. But the proprietary software we were using did not provide any means for interrupting an activity.
With the advent of personal computers in the early 1980s, WHI went looking for scheduling software that could run on desktop computers. As you can imagine, the proximity of Primavera Systems' headquarters was rather convenient. WHI did consider another early contender but quickly realized that Primavera Systems had the most advanced product.
Starting in 1986, WHI employees were encouraged to begin switching projects from the proprietary scheduling software to P3. This was a long process since our existing projects could not be converted to P3, so we ran projects using both programs all the way into the early 1980s.
Development of WHI's proprietary scheduling software had been frozen for several years and was rather rudimentary compared to P3. As a scheduler I really enjoyed the additional features in P3. But I still had the nagging concern about how to interrupt an activity - a feature lacking in P3 as well.
WHI had a close relationship with Primavera Systems, and not just because our offices were less than an hour apart. One of our employees became a beta tester for Primavera Systems. It was not unusual for WHI to reach out with ideas and suggestions. And Primavera Systems would listen, given our considerable experience scheduling projects.
So we asked: "could you give us a way to interrupt an activity so that everyone can see that progress has been halted? And Primavera Systems responded a few months later by introducing Suspend and Resume.
As you should know, once an actual start date is recorded, an activity can then be suspended. Days during the suspension period are not counted towards the At Completion duration, which gives a more accurate representation of how long it took to perform the task.
This P3 feature was carried over to P6. Oracle bought out Primavera Systems several years ago and has introduced many additional, useful, features. But I have a soft spot for Suspend and Resume. My wife has a patent for workflow software but this is my small contribution to scheduling software.
I have quite a few more stories about the early days of CPM Scheduling. To be resumed...
Postscript: a scheduling buddy of mine responded privately to my article. He explained that he never uses Suspend and Resume because he prefers to split the existing activity into new activities to demonstrate what work has been performed and what remains. In some situations an existing activity has been interrupted several times, so clearly Suspend and Resume will not suffice. But assuming we have just one interruption, Suspend and Resume is a much better approach. Why? Because introducing new Activity IDs means we can no longer baseline the project. The Activity IDs in the current schedule do not match up with Activity IDs in the older schedules.
I should also point out that if the work is being delayed by other parties then we should consider whether an "excusable" delay is occurring. Indeed, one of the first lessons I was taught during the 1980s was to as why the work has stopped. If the contractor is being forced to interrupt the work, I would prefer to split the existing activity and insert the delay in between. Suspend and Resume by itself does not prove who caused the delay, but it can be used as a temporary means to document the interruption until I can follow up with a more robust delay analysis.