In the recent years I have seen that the problem ‘works on my machine’ has changed into ‘looks ready-to-ship from here’
The good thing is that I do not have to fight with developers any more about errors, they have learned to see further from their own desk. Now the next step is the managers. And not the project manager himself, but his superiors.
It seems to me that the higher the office the more projects one needs to cover and fewer details can be handled.
I think the major reason for this is that developers, testers and project manager all know a lot about the state, risks and issues of the product, but the paperwork does not reflect all of that. Thus a supervising manager/stakeholder sees the wrong picture. Even if the weekly reports contain extra information, it seems to get lost in the process. Upper management (from my experience) seems to need very clear presentation of problems, and best if they were reported as errors. They seem to disregard what they have been told as vague and unmanageable if it is not written as error report. They seem to need something to point their finger at and say – it needs to be fixed. And more importantly, be able to show later that it clearly has been fixed.
The secondary reason for this is could be that the reported errors do not contain updated information about the product. Or the extra information is not given in the meetings. This is actually just what Micheal Bolton is talking about. Providing context to the errors, risks, and overall situation.
One way to fix this is to keep very clean picture of reported errors and stress the possible risks in meetings. The other way is to report the risks and issues also into the tracking system and hope you can manage that jungle to keep it legible. And always framing the issues to reflect their impact to the product/user/company/etc.
It comes down to the communication – how the errors are reported, problems are described, and information presented.