Rigidity, late-blooming requirements conflicts, triangular relationships and simple geography conspired to deliver half of what a major technology project promised. On this effort, it seemed, you could change everything but the way the team worked.
Project Yourself is an ongoing series that invites project professionals to share practical advice, personal insights and pet peeves based on their experiences in the field. Anonymity, if desired, is assured. To submit an article for consideration, contact the editor.
It should have been a cause for celebration. The Big New Controller (BNC) project, after slipping its schedule and busting its budget, had finally delivered hardware to the lab for performance testing. But the joy was short-lived: tests quickly determined the BNC was delivering barely half the performance it had promised — a bad sign for a project whose purpose was to improve performance. And there were rumors that the BNC development team had known it would fall far short of requirements.
It was time for some hard questions: How had the project fallen so short of its promises? What could be done now, given the company's dependence on this project? How could we prevent such problems in future projects? I was part of a group sent to find answers, and in the process I learned some important lessons about human nature, the