A while back I did some work for a company that prided itself on being a “process organization.”
One of directors was particularly remarkable. He was receiving an average of 130 pages a month related to problems in the production systems. That was after the issues had been filter through 1st level support, 2nd level support, the dev team, team leads and managers. You can imagine how many problems didn’t reach him.
I asked about defect metrics, but they didn’t have them. So I suggested some simple data gathering:
Draw a picture of all the programs and modules in the system and post on a wall
Each time there’s a production problem stick a color coded dot on the module – red for a crash bug, yellow for an issue with a workaround, blue for a data problem, etc.
I figured at the end of a week or so, he’d have a picture of the most error-prone modules, and could do some work to shore them up… Gradually the group could work its way out of crisis mode.
He didn’t like my idea. Instead, he pursued documenting the escalation process and wrote a thick requirements process document.
This manager, like any of the managers in this particular organization, believed if they had a defined process, all would be well. And they were rewarded for documenting processes, not for running an effective organization or producing good-enough software. There was useful common sense work going on in some pockets… but then someone would get hold of it and turn it into a rigid process with a 20 page checklist (really!). Which, of course, no one used.
In this company, the management process was the one that needed to be fixed. Process is not a substitute for talent, common sense, hard work, and good management. Which is one of the reasons I call this blog software (management) process improvement. Without improving management, defining “process” is sort of wasted.
I wonder if I’d written up the color dot data gathering in a 50 page document if he would have liked it better. 🙂
