Project Rescue and Recovery
Projects build in technical debt and maintenance groups remove it—if your organization has a maintenance group. Technical debt accrues in any product, whether or not it has a technical component. It is the result of taking shortcuts when building the product. Sometimes it is the result of not having enough time, on other occasions it is due to not having the right tools. Anything from the implementation of the software component to light fixture can have technical debt. Promises are made to correct it later, but later never comes.
A few weeks ago, I posted an article on five of the ten stupidest decisions management had done on troubled projects, as promised, here are the other five. Although these may all bring a little light hearted laughter, the goal is to educate in order to avoid repeat performances. We all have seen, and made, dumb decisions; finger pointing and blame will not improve the result. So, read on, enjoy and then share your experiences so we all learn more.
|Publisher:||American Management Association|
|Publication date||1st Ed. February 2003
2nd Ed. January 2009
3rd Ed. March 2015
As the title implies, this book discusses identifying and managing risks on projects. Although the book is written in a very generic manner, it has a decidedly high-tech flavor. This partly due to the fact that the author worked at Hewlett-Packard for twelve years.
Kendrick's coverage of risk, or more correctly uncertainty, is complete in a general sense focusing a majority of his discussion on risk in projects due to poor planning and change management processes. Two chapters of the book deal with quantifying risk, but the math is kept simple as he recommends using commercial products to the brunt of the work.
People routinely ask me the question, "What do you do when you find yourself on a project that is a hopeless failure?" It was raised again a few weeks ago in a Focus.com roundtable and then last week in an interview with Andy Kaufman. It only matters if the executives above the project are ignorant to how dire the situation is. It is tricky, trying to convince someone that they have a problem when they refuse to acknowledge the obvious—a tough and politically dangerous sell. The general consensus is "dust of the résumé." However, there is a logical approach to the problem—be logical.
Leadership is more than leading the people reporting to you. Too often, you need to lead people over which you lack any authority. The absence of hierarchical advantage adds a challenge, but is ideal training on how to deal with managers, customers, and difficult people. The key is making them feel the direction chosen is theirs. One of the best methods of doing this is storytelling.
"Why is it that when you get hired you are no longer the expert?" A chuckle rippled through the audience; however, the woman asking the question was serious. I turned the question back to the audience of director level managers, "Why is this the case?" There was silence. Finally, I proffered that it was management's lack of understanding the skills of the people working for them. "Who in your organization can you implicitly trust?" More silence. It is sad that organizations know so little about the people that they hired—the people on which they stake their company's future.
A few years ago, we had a run in with the healthcare industry. I think of it this way since is sounds like a run in with the law. Doctors are the law, or so they think. Do as they say, or else. The problem was that my wife, at 46, was having a heart attack and had a hidden... oops... I almost spoiled the story. Unbeknownst to me, Doctors rarely think about two things being wrong; they only work on one issue at a time. Those of us who live in project work realize this assumption can have grave consequences. What the doctors in this case needed was an anal-retentive, tenacious, asshole of a Project Manager whose objective was a successful project. As Gene Kranz so aptly said, "Failure is not an option," the product, service or end result of this project was a life—my wife's. However, I am getting ahead of myself. Let me take a few minutes to set the stage to show my mistakes and how years of project recovery experience helped. I will keep it brief.
In many years of recovering failing projects, I have found a few management actions whose rationale seem completely absurd. Regardless of my efforts, I am unable to understand or dissuade them from their decisions. These decisions either precipitate the failure or greatly exacerbate the project's dilemma. Regardless, due to management's level of shear desperation, they can only be classified as stupid decisions. If there were the Darwin awards for management, these would qualify.
Full implementation of agile project management requires a top-down approach. The differences in reporting, resource dedication, team structure, and customer relationship from traditional project management methodology requires buy-in at the highest level of the company. Educating superiors and customers on the benefits of agile project management is difficult, especially if they have a religious belief in classical project management style. Implementing a pilot project is the best way to quell their fears. Unfortunately, in a recovery this luxury is unavailable—the turn-around becomes the pilot.
From years of experience in recovering red projects, I estimate that only a third of all problems that affect red projects are actually on the project; the other two-thirds are in the surrounding organizations. Poor policies and procedures or lack of commitment by the customer, vendor, integrator, or organization overshadows problems on the project. Unfortunately, project managers do not have the authority, or even the influence, to address these issues. Their only course of action to complete the project successfully is to band-aid the problem. This must change if companies are going to quickly and accurately implement business initiatives.