In late July, the Secretary of the Department had a surprise announcement. The Government was authorizing an emergency economic relief program for qualifying Americans, and the application would be available online the day after Labor Day. The web development and application development teams, recognizing they had five weeks to make good the Secretary’s promise, scrambled heroically. One motivation above all others drove the development teams’ efforts: this would not become a calamity like the initial launch of Healthcare.gov. They would make the September 4th deadline.
Three weeks later, in mid-August, the project management team was reviewing the relief program’s project dashboard report. By this point in the rushed project, two things were evident from the trenches. First, the two development teams would release something on September 4th. They would keep the Secretary’s word. Second, the teams would need at least another three weeks to fully complete the project. A second release would be necessary in late September.
Neither the limited release, nor the delay of the project’s completion was a surprise. Even before the customer ordered new requirements and functionality mid-project, the business owner and developers knew there was too much work and too little time. The very first status report declared the project “yellow”, meaning the project was at risk of finishing up to thirty days late.
This afternoon’s meeting was the first group review of the briefing deck since the scope change, and one change to the briefing deck, made behind the scenes, was immediately obvious. The project status indicator was green (on time) rather than yellow (minor delay). Why had the change been made? The editor justified the change based on confirmation that the relief application would be up and running September 4th as promised. Mission accomplished! However, the green status indicates the project completion date, not the end of the release. Even charitably claiming that bug fixes are part of continuing operations (something not even the development team tried to claim) the project must still recognize that not all functionality will be ready by September 4th. So, the team made a second edit.
By extending the project finish date to the end of September, the management team had rescued the project from minor lateness, extended the project’s planned period of performance and implicitly signed someone up to work on Sunday, September 30th. Not a bad day’s work on an Agile software development project.
In every project, there are tasks that are late, and there are tasks that are late that matter. Meeting the September 4th deadline in some capacity clearly mattered. Just as obviously, closing out all other work by September 4th was a deadline that did not matter. Why for the sake of appearances, did a green status have to be kept? Part of the answer is that the project team had no change management process to access and approve scope changes. The other motivator is a real or perceived fear that reporting delays leads to punishment.
Getting project teams in the habit of admitting when small things run late, and quantifying the impact is excellent crisis management practice and a productive trust building mechanism. If a project team gets good at recognizing and addressing small bad news, they will be far more prepared to handle the big crises.
Like crisis management, moving goalposts is also a learned skill which improves with practice. Teams that practice moving the goalposts are more likely to attempt that solution first, even when that strategy is not feasible, not necessary, or ethically dubious.