(^162) 97 Things Every Project Manager Should Know
The Fallacy of Status
Udi Dahan
Haifa, Israel
AFTER A SUCCESSFUl FIRST PRojECT, I confidently embarked on my sec-
ond. This was a larger project, it was more strategic to my employer, and I
would manage a multidisciplinary team of people. I was sure that the skills that
had served me the first time around wouldn’t fail. Interestingly enough, it was
my trust in my team’s status reports that was my eventual undoing.
About two months into the project, my infrastructure team lead confessed, “It
turns out some of the architectural assumptions we made were unfounded.”
However, he assured me that, “We’ll be back on track by the end of the month.”
Despite his reassurances and the contingency buffers I had in place, I couldn’t
dismiss the sense that something was wrong.
At the end of the month, I followed up with the same team lead. He showed
me how the refactoring work had been completed on schedule and how the
developers were all set to hit their targets for the coming month. When I sat
down with my integration team lead, she notified me that everything looked
good from her vantage point, too. Modules were complying with their speci-
fications, each had been sufficiently tested, and all the multiple layers of the
architecture tested stable enough for the first integration.
After a slightly bumpy first integration (as many of them are) and a regular
quality assurance cycle, I was astounded to discover that almost every use case
had critical bugs in it. We were almost 5 months into the 15-month schedule,
but nowhere near a third done with our project work.