Managing problems can often require a lot more than knowledge of the problem itself. In particular, getting useful and timely responses from the people that want the problem solved can be the most difficult part of the task.
Consider the following actual series of events.
A.
Aasks person
Bto do the update.
Bhas built and installed the requested software.
Adistributes software and asks requester:
Please confirm that this software will meet your needs … (or let us know what problems it has).
Aasks help-desk:
We never did hear back from the requester. Can we mark it asdoneyet?
Is … behaving as it should now?
Sort of. [Reports run-time problem.] … wonder whether other things are not working so well. I might try downloading the source and compiling it myself.
A:
Are we all set for [May 1]?, who replies that the requester still hasn't responded.
Has … been tested and ready for [May 1]?
I've noticed that things aren't perfectly smooth on those computers. I am away this week but I'll look at it more closely next week.
The requester waited a total of less than one week for the work to be done, while the people working on the request have waited a total of nearly three months for responses from the requester.
When the software is finally required for production and it doesn't work right, guess who's going to be blamed for taking so long to complete the simple task?
And notice that even when information was given,
it was far too general to be useful:
things aren't perfectly smooth on these computers
.
What things?
Which computers?
And how aren't they smooth?
Clearly there is a lack of standards for who is responsible for what. In particular, the help desk could have done far more to ensure that useful and timely information was communicated to the people responsible for doing the work.