Building schedules for complex projects is challenging. While the results are never perfect, credible schedules are a useful communication and coordination device. Incredible schedules, on the other hand, are a dangerous waste of time and energy that damage a project manager’s credibility and cost an enterprise a fortune.
The massive legacy system to be replaced had evolved over 40 years into a maintenance nightmare. It was held together with bubble gum and string by a cadre of gray-haired COBOL programmers who were retiring and dying at an alarming rate. The procurement to replace the system was fraught, delayed by bureaucracy, and a protested award.
When the half-billion-dollar contract was finally signed, the fixed-price, fixed end date project was expected to take five years. There was a project manager (PM) on the client-side responsible for coordinating user interactions among multiple departments and subject matter experts, and a PMr on the system integrator’s side managing a team of about 200 developers and staff. The PMs worked together as best they could, looking out for their employers’ respective interests and trying to minimize needless conflict.
I was on the client-side in a project oversight role—I was a guard rail. My job was to call shenanigans promptly if the client PM screwed up. When I had concerns about how things were progressing, I would raise them with her privately. If she addressed them appropriately, that was that—nothing to report. The PM was experienced and well-intentioned, and we had an “arm’s distance” collegial relationship. The project was big and scary, and I think she appreciated having another senior PM to bounce ideas off of.
The vendor PM identified some preparatory work that was clearly needed and busied her staff with that for the first few months while she and her project office developed a detailed schedule for the bulk of the project. When it was presented to the client PM, she called me—concerned. She suspected that the vendor’s proposed schedule was extremely aggressive and unsustainable, but she couldn’t be sure. If she agreed to the proposed schedule, she was concerned that it made resource demands of her staff that she couldn’t sustain. She thought the vendor was playing “Schedule Chicken”. “Chicken” is a stupid game that teenagers play with bicycles (or cars for the really stupid ones) in which two opponents drive straight toward one another threatening a head-on collision, and the first one to swerve is “chicken” and loses. Schedule Chicken is when two “partners” know a schedule isn’t credible, but neither wants to be the first one to admit it. In fixed-price systems integration contracts, the first one to blink has to pay for the change order to accommodate the delay that is their fault (because they blinked).
Schedule basics are familiar to most project managers: identify tasks; determine dependencies; develop effort and duration estimates; commit arithmetic to identify the critical path(s), and assign resources. What rookie project managers don’t realize is that the resulting schedule, even when built with care, is extremely unlikely to match future reality. There are several reasons for this—tasks missing from the schedule and poor estimates being the most commonly understood—but if you are a math nerd, there are actually some mathematical and structural issues that make a traditionally constructed schedule nearly impossible to execute, even if there are a few missing tasks and the estimates are reasonable.
Fortunately, I’m a math nerd. I had recently procured a Schedule Risk Assessment (SRA) tool and was curious about what it might say about the proposed schedule. An SRA takes a well-formed schedule[1] as input and uses Monte Carlo simulations or similar math tricks to calculate a probability distribution of the end date. Essentially it simulates doing the project a bunch of times using a randomized distribution for each task duration and is derived from three-point estimates instead of just assuming that the “most likely duration” for each task is correct. The result is a histogram that shows how likely a given end date is based upon the simulation.
I suggested to the client PM that we work with the vendor PM to run the simulation and see what it revealed. She scheduled a meeting for the next day, and I was curious about what would result. I arrived at the project site expecting to have an intimate meeting with the two PMs to review the schedule. I was surprised to find that the vendor had sent a team of schedulers to do a dog and pony show presenting their scheduling process. The vendor’s schedule lead opened with a 20-minute presentation about their rigorous approach. Without me mentioning it, they volunteered that the schedule was well-formed and that every task was represented by three-point estimates that had been carefully reviewed and vetted by senior team members. When he finished, he asked if there were any questions, convinced that everyone in the audience would be so dazzled by his knowledge and rigor that there could be none.
“That sounds like a thorough process,” I said. “I’d like to get a copy of that schedule because I recently acquired a Schedule Risk Analysis tool, and what you are saying is that your well-formed schedule is already cleaned up and ready for analysis. I look forward to processing your schedule and sharing the results with you. Please send the schedule data to me at this address.” I handed the stone-faced presenter my business card, and the meeting ended.
That afternoon while awaiting the scheduling data, my phone rang. It was the client's PM. “Payson,” she said, “I owe you lunch. The vendor just ‘discovered some issues’ with their schedule and have asked for a change order to delay the project six months.”
Thus ends a true story (details somewhat obscured to protect confidentiality) of how simple Schedule Risk Analysis saved between $50M and $100M USD in a single day by threatening to provide a useful way to visualize schedule risk and assess whether or not a proposed schedule was “credible”.
[1] “Well-formed schedule” is a term of art in scheduling, which (oversimplifying) means that all tasks in the schedule have at least one predecessor, at least one successor, is “floating” (they aren’t hardcoded to a date), and have a three-point estimate. More info on three-point estimates here:https://www.techwell.com/techwell-insights/2020/05/3-questions-easier-less-stressful-project-estimates
