Software Project Management: The Responsibility of Communicating Quality Trade-Offs
I don’t use the word deadline in polite company. Some projects have significant financial penalties for missing key dates, up to and including project failure, but it is rare that the coroner comes to put teams into body bags for missing a target.
That doesn’t mean dates aren’t important—just that missing a date should be a conscious decision by someone with the authority to accept the consequences.
Aspects of the Affordable Care Act are being rolled out in phases. One recent requirement was for larger employers to provide certain notifications to their employees, similar to the W-2 form provided for tax purposes. The notification was to be generated by my client’s payroll system, and they initiated a project to comply.
Unfortunately, as governments sometimes will, detailed requirements of how information was to be calculated in some special circumstances were slow to be finalized. My client uses a large commercial software package for payroll, and its vendor scrambled to provide a patch while the requirements were being finalized.
The updated payroll system arrived shortly before the government-imposed “deadline.” The project team tested the vendor code and found some errors, either in their data or in the vendor’s patch, but there was no time for resolution before the mandated notification date.
This compelled a choice. Should they:
- Do the production run and mail notifications on time when they knew some would be in error; or
- Delay the production run to resolve known quality issues, missing the mandated delivery date?
Either option was reasonable, and the team appropriately consulted with their executive team and legal department, who elected to take the first option. But that isn’t the end of the story.
A week after the imperfect notices were shipped, some executives were outraged at the quality. I don’t think the execs were being weasels; I think the project did everything by the book but perhaps failed to assure that the decision-makers were clearly aware of the implications and the potential scope of the problems.
There are several lessons to be learned here: Target dates are almost always negotiable. And when a date must be hit, the Zeroth Law of Quality tells us: “If a system doesn’t have to be reliable, it can meet any other objective.”
One key lesson in this particular instance is, when decision-makers agree to sacrifice quality in order to achieve a target date, make sure they clearly understand what is being traded away, what they will get, and the risks associated with their decisions.
Executives pay you to help them understand the decisions you ask them to make. The burden of communication rests with the project manager and team to assure the implications are understood and acknowledged.
In this case, I applaud the team for reaching out to the execs, and I think the decision reached was reasonable. But if an executive later says, “I didn’t fully realize the scope or impact,” the project manager should take note. The burden of communication lies with the party with the most to lose.
