Considerations on Project Execution

Abstract

Friday, September 28, 2007, was a sunny, warm day in autumn. The leaves were starting to turn from a luscious green to shades of yellow and bright red. That Friday had been defined as the milestone that completed the precisely scheduled development phase of a nonagile, stage-gated project. On this milestone, programmers were supposed to hand over their achievements to the test team. The project managers had been reporting a reassuring green status in their reports over the past weeks. Their good-looking PowerPoint charts had been passed up the management chain and inspired great confidence. The entire team was looking forward to a relaxing weekend, as the last weeks of the development phase had been extremely strenuous. In long hours, everyone had been rushing to complete the work that had been assigned to them. The developers had managed to check-in an incredible amount of last-minute code changes into the source control system. But there was one ugly detail: Many lines of code had been accumulated off-line and were now added to the main code stream just in time to meet the deadline of the milestone. The build stability decreased rapidly. Build breaks occurred more often, and even once the basic compiler errors were resolved, the product was still not installable. Just too much code had been added concurrently. Interfaces of components were out sync, and version conflicts had to be resolved. And worst of all: there had not been enough focus on testing. Especially the integration testing across the functional units had been gravely neglected. But in spite of these problems, on that particular Friday, the coding was complete, as scheduled and promised.