Letting Deadlines Slide (Under the Rug)

Two Decembers ago, Brianne inherited a 600 line schedule file from the previous contractor. Brianne was new to Schedule Management, and the team’s most junior member. Though the incumbent schedule spanned multiple subprojects over four years, the schedule was simple and required minimal upkeep. Every week, Brianne would solicit updates from the various team leads, marking tasks complete or adjusting finish dates as needed. 

A couple months into her new role, Brianne noticed something alarming. Over a dozen tasks were out of date. Tasks had due dates which were weeks old, yet were still not done. When Brianne reached out to team members for a new finish dates, they rebuffed her. 

Figure 1: Project Schedule as of March. Grey lines represent the baseline duration. Environment Automation and Business Case Writing (purple lines) are out of date because their finish dates were in February and they are still not complete.

This is normally a self-correcting problem. Team leads who don’t provide updates are tacitly admitting that nothing got done. The Schedule Manager simply slides overdue work and all dependent tasks to the right until progress is reported. Unfortunately, Brianne also encountered a serious dilemma with her client and her managers. 

Brianne’s client insisted that no dates on the schedule may change without prior written approval. Were Brianne asking to change the schedule baseline, this would be a perfectly reasonable Change Management request. However, few clients have authority to stop the inexorable march of time. 

Brianne’s boss, Kyle, capitulated to the client’s absurd demands. Kyle knew that their client was under scrutiny. In the client’s mind, reporting date shifts before the team had a chance to catch up would only inject unwanted micromanagement into the struggling project. Kyle told Brianne not to make drastic changes to how the schedule was managed. The previous contractor (fired for poor performance) did not shift dates without client approval, so Brianne should follow suit. Kyle promised that he would find an appropriate opportunity to raise the issue with the client down the road.

Months went by. Teams rarely reported progress so, Brianne made very few updates to the schedule file. Eventually, team leads neglected Brianne’s requests for status updates altogether. In August, the client added a new interface design and another 100 lines to the schedule, while keeping the original June 26thdeadline. The schedule was so out of date, no one could quantify whether the increased scope was doable. But everyone seemed sure that it was not. By November, over 10% of the schedule’s line items were incomplete and in the past! 

Figure 2: As of November, four headline activities and dozens of subtasks were out of date. Sweeping all incomplete work (purple) forward exposes that the project won’t complete until nine months after the deadline, at best.

No stakeholders, including the client, denied that there were serious delays impacting the project. But realizing one in ten tasks were overdue belies the problem’s severity. What’s not apparent from Figure 2 is just how many dependent tasks are being delayed, or how much work actually got done in a given week. Without an up-to-date schedule, neither the cause nor the impact of delays could be understood. Only Brianne, Kyle and a few others suspected how far off course the project had gone.

To understand how this project failure played out, it helps to consider two questions. First, what persuaded Kyle to ignore Brianne’s objections and side with the client? Consider what the schedule, represented to Kyle. Many reasons why the project was not going well were outside Kyle’s control. But the schedule file was a client deliverable which Kyle could control. If the schedule looked “good” to the client it would be ignored. If the schedule file did not look “good”, it would be one more cause for criticism from an already dissatisfied client. Everyone close to the project already knew that the work was running late and the client was upset. Kyle saw no reason to further aggravate the client by not heeding their wishes on a fairly trivial deliverable.

This raises the second question. What is the likely end-point of allowing schedule variances to be perpetually swept under the rug? The answer soon appeared.

In January, the client submitted a Cure Notice to Kyle and Brianne’s company. The team had ninety days to submit all outstanding deliverables as well as a plan for completing all work by the June 26th deadline. Corporate Leadership called an emergency meeting. While Leadership studied Brianne’s schedule, Kyle complained that the client had yet to provide many requirements and specifications which they had promised months ago. This he said, rendered the schedule with its obsolete dates useless. Unfortunately, Kyle wasn’t quite correct.

Figure 3: The official schedule of record, did not show the tasks which were behind or out of date.

Unlike Figure 2, the official schedule of record did not show which tasks were complete and which tasks were past due. If Kyle truthfully argued that his team still had too much work to do and that they were missing requirements, the contracts manager had grounds to disagree. The schedule shows that most of the work should be done by now, and that the requirements would have been given to Kyle’s team months ago. Kyle’s only counter-argument, that the client told him to not update the schedule, makes him and his team leads look incompetent.

Whether deliberate or not, the client left Kyle without a leg to stand on. The schedule, neglected for months in hopes of appeasing the client, had been wielded against him. The documented fact that the Brianne and Kyle’s point of contact told them not to change any dates no longer mattered. Nine weeks later, the client canceled the contract citing the company’s failure to perform.