Previously, I had trumpeted a slowdown in defect removal and that had gotten the project development team to crank back up their efforts. The other thing that happened during this same time was that my boss decided to “help” me out. While I was talking about the overall rate of defect removal (which had to balance the overall rate of defect arrival) he decided to trumpet a particular class of defects. These defects were known as “panic” defects where the product just up and died while in use. The “panic” was a complete failure of the product and because of it other development and testing activities would often be blocked until the panic defect was found and removed.
This would have been great help, except the panics in the product were in the normal range. We had panics, and it would be nice not to have any, but the panics were no more and no less than we normally had at this point in time in the project. This indicated that while we had work to do, we were still on track for removing sufficient defects to ship the product on time, if we kept the overall repair rate up where it needed to be.
However, the alarm trumpeting panics — since it was from my boss — alerted the bosses of the development managers. These bosses decided to crack the whip on working panics and hence set it as a priority. Recall, I had been trumpeting — based on hard data — that the overall rate of defect removal had slowed down and needed to pick back up. Well, these other bosses began to berate me for putting out conflicting priorities and I needed to follow what my boss was now saying and not to confuse people with other direction!
Sheesh. Ok, how do I handle this? I do tell my boss that while we always need to stay focused on panics, that the panics are still doing OK. We need to keep them working on all defects or else, even with panics eliminated, we would have too much functionality that still didn’t work and hence would not be able to ship the product on time.
My boss appeared confused with my position. “No, no” he says “we have to get those panics down. Push them to focus first on the panics!” Now, we have my boss a more senior and very experience manager trying to drive the effort by “this sounds right” and not by the available data. The good news was my original trumpeting of “pick up the pace” was still having an effect, so thank goodness for open communications and not the old fashion hierarchical controlled communications. The arguments on “panics” vs “all defects” turned out to be more a political game that helped the development managers save face (“Bruce, you and your boss are saying different things!”) for letting the overall pace slip and not realizing they had done so.
In any large project there are always things that are going wrong. As project managers we need to be on top of such things and help them get resolved, but we need to recognize the difference between normal problems and a real crisis. While experience will help in this regard, we also need to keep measuring and trending how things are going. This ensures we react to the real problems and not run off on a wild goose chase trumpeting issues that our folks will take care of in the normal course of doing their jobs.
Do you have examples of declared “crisis” that were not real huge issues but you had to spend significant time on them anyway?
Project Managers Are We Managing Or Are We Theorizing?
Are We Project Managing Or Sending In The Clowns?
Knowing Your Project Management Average Is Powerful!
Project Managers, Maybe We Should Ignore Our Boss
Do We Manage Projects By Intuition or by Methodology?
Visibility – The Fifth Project Planning Secret
Defect Reports Are Your Best Friend!
How To Project Manage People Who Are Smarter Than You