Project Manager Is It Really A Crisis?
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?
Referenced articles:
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
5 thoughts on “Project Manager Is It Really A Crisis?”
Comments are closed.
More comments from around the web:
Andrea Herrmann • Yes, your are right. Some projects are doomed to failure from the beginning. The sad thing is that research and statistics show which are the project success factors and how projects should be planned in order to be successful. Nevertheless, the same errors are made again and again. Why?
My impression is that often the root problem is a distribution of responsibility. There is not one person who fully feels responsible for the project. Those who set up and plan the project, define the budgets etc will not be the same persons who will excute it. Those who define the project in the beginning, they get a rewards for winning the contract and then they leave and are no longer responsible. The sales persons are paid for the turnaround which they create, not for realistic cost estimations. 🙁
If you take over a badly planned project, what can you do? Not much! You can leave the company. Otherwise, you must do your best and then “suddenly” remark that the project has a crisis.
Bruce Benson • Andrea,
I recall where to get a decision we had to practically go the the president of a Fortune 50 company because no one individual was ultimately in charge of our large projects. Responsibility was spread out and when one manager tried to exercise leadership (make a decision or push folks towards a decision) the other managers would automatically resist. It was not that the decision would not have been a good one, only that managers didn’t want any one manager leading — as they saw that as making themselves not look good.
In the military we had the advantage that we always knew who was in charge. The hard part was often trying to get that commander to make a decision we felt was needed. Instead, too often, we had to just muddle along and do the best we could where a good clear decision would have made everything run much better.
Getting a company “organized” is often one of the key things that needs doing to help projects to succeed. Of course that does not appear to have anything to do with the “current project” when it is often the root cause of why the current project (and past projects) were/is struggling.
Thanks for the feedback.
Bruce
More comments from around the web:
Valentin-Tudor Mocanu • “Panic defect” effect could be expected rather in customer side and not in a professional development side. A good approach shall be risk-driven and main risks shall be detected EARLY in the project. There are specific methods in software development to realize a such approach.
Also, a good software PM/process approach shall identify quickly the root cause of the problems and that will offer the answer to “to be or not to be” in panic state. It is not only about defect rate, trends, etc that are observable issues on CONTROL, it is also about the root causes and built-in quality measures.
A PM that just perform monitoring and control and does not prevent is not a good-enough PM.
Bruce Benson • Valentin,
Agreed. Getting to the root cause and taking the time to understand the pattern of root causes (often inefficient management or technical habits) can help a team become very good in a very short period of time (as they learn and adjust).
Understanding root cause is essential in both fixing defects and in simply improving how things currently are done. If we don’t know what is causing the effects we observe, then changes to improve things can often be no different than making random changes with no purpose.
Good observation.
Comments from around the web:
Andrea Herrmann • For me, the difference between normal project problem and crisis is one of the following cases:
It´s a crisis when the problem can not be solved with the means and ressources that the project has. We need to apply to help from higher management.
It´s a crisis when the project is put in question. When we are no longer sure whether it makes sense to continue with the project or whether it would be better to stop it.
I now wonder whether these criteria are subjective or objective. I think that they are objective, but only good project managers use objective criteria for judging whether he needs help from outside or whether the project continues to make sense. Bad managers who do not use numbers for jduging the situation might react too late or create unnecessary panic.
Bruce Benson • Andrea,
Those are good thought provoking definitions. In the projects I’ve run, I’ve often had to go begging outside my project for help (temporary loan of an expert, purchase of extra equipment, etc.). While I could imagine an event that suddenly caused a project to be put into question (tsunami, earthquake, war, etc.) just about all my experience has been that a project that inevitably failed was pretty much “planned” that way at the beginning of the project.
Once we got organizations to plan realistic projects (e.g., use averages from past projects to size/estimate current projects) then existing project managers were successful with their projects. I don’t recall a well planned (i.e., using realistic estimates) project ever failing because a project manager poorly executed their project (ok, we have replaced project managers when they appeared to be struggling – as the project was too much for them. Poorly estimated/planned projects never improved with new project managers assigned).
Thanks for the feedback.