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 still not done. When Brianne reached out to team members for new finish dates, they rebuffed her.
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 status requests altogether. In August, the client added a new interface design and another 100 lines to the schedule, while keeping the original June 26th deadline. 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 was incomplete and in the past!
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.
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 should have been given to Kyle’s team months ago. Kyle’s only counterargument, 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 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.
Questions to Consider
- What may have been motivating Brianne and Kyle’s client contacts not to act as honest brokers during the project? Which schedule stakeholders had the highest commitment to the schedule’s success?
- Imagine you are in Brianne, Kyle or one of the developers’ shoes after the project’s demise. In a new job interview, how would you explain the project’s outcome and your contribution? Is this experience a detriment to Brianne’s resume?