The Best Way to Communicate Project Quality Concerns
I was consulting for a company that retained a vendor to build a message switch. Management decided the existing vendor was the safest and fastest way to get the new technology. It was sound reasoning, but it didn’t work out as planned.
The vendor, a small company, was seriously overextended. To compensate, they brought on several less qualified staff and turned them loose on my client. The client’s technical team was not happy; they saw that the vendor staff were not tall enough for the ride.
The vendor was building a specialized communications manager that guaranteed delivery of messages across external interfaces. It also allowed message priority to drive sequencing during peak load. I reviewed the detailed design for the product, and it was terrible. There were obvious flaws in the way message priorities were handled: High-priority messages could be delayed to assure delivery of lower-priority messages, and there were places in the logic where system failure would result in message loss. When I asked about the flaws, the vendor team didn’t seem to understand my questions.
When I consulted with the client tech team, they told me to save my breath. They had tried to raise these concerns with the CIO and had been shut down. I brought the issues to him myself, and he seemed quite surprised. I asked what he had heard from his own technical team, and he said, “It may have been somewhere in here,” fishing a twelve-page report from his inbox.
The report had little preamble other than to explain that the tech team had concerns about the quality of vendor performance and work products. What followed was a numbered list of “issues” that went on for a dozen pages. There was no indication of severity or priority. The entire first page listed what seemed to be trivial complaints about performance and deliverables.
To be fair, the major issues were in the report, but they were buried deep and framed in very technical language. I also need to point out that the CIO was a good manager but not a nerdy “propeller-head” likely to understand subtle concerns about low-level queue handling and scheduler priority logic, particularly if the problems were shrouded in computer science jargon.
I tried to coach the technical team about prioritizing their findings and presenting them in language assessable to executives, but it was too late. Their disgust at identifying the problems and having their concerns disregarded had encouraged them to apply for jobs elsewhere.
The vendor solution took longer to implement than advertised because of time required to address issues with the design. The executive was disappointed in himself for failing to understand the significance of the staff report, and for losing promising staff as a consequence.
My takeaway from this encounter is to remind technical people that busy executives need you to help them focus on the biggest issues. Accomplish this by prioritizing findings to point out the most significant concerns and presenting them in appropriate language. It is a good instinct to be thorough, but you must always consider your audience.
