Blog: Fixing Problem and High-Risk Projects
The two most common project attributes that raise the red flag are cost and timeline problems. Both are easily measured and inextricable intertwined. As the timeline extends, there is a commensurate increase in cost; similarly, as cost goes up (usually from increased scope) the timeline increases. However, time is different. Benjamin Franklin said it best, "You may delay, but time will not." Work can stop work (controlling the burn rate) and extraneous features can be removed (decreasing the required work), but time marches on. We cannot control time. Although intuitively obvious, the concept seems to escape a large number of managers and executives.
The quickest way to get lost, in business or in your personal life, is failing to make decisions. Not knowing where you are headed increases stress and frustration. It would seem natural, then, that teams on projects beleaguered with indecisive management would be excited to have the logjam broken by a dynamic, decisive leader. Simply put, they are not. Every decision has its opponents and they are bound to be irritated, feeling they have lost prestige or stature. However, turning the decision into action requires a unified team. One of the best tools to accomplish this is to understand what impeded decision making and tactfully educating the team members on the source of the problem. This will garner their backing and improve their willingness to support the decision.
A couple months ago I asked the question, "Who should the CIO report to?" on the LinkedIn's CIO Magazine Forum. Surprisingly, over 100 people responded, so many that the group's moderator moved the discussion to the jobs section. Maybe they were tired of the attention this old, beat-up subject was getting. I surely did not think responses would be quite as passionate as they were. However, my interest lay in another area, not in the answers to the direct question, rather the reasoning behind them.
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.
The most common form of outsourcing is to hire resources through a staff augmentation firm. Staff augmentation firms, better known by their less polite nicknames of headhunters or pimps, provide anyone from project managers to developers and testers to fulfill a projects' temporarily needs. These firms match your requirements, based on level of experience in a skill or trade, or talent in dealing in specific situations such as overseas deployments, military contracts, etc., to the people in their database. The challenge remains in getting the correct person, who can ramp-up quickly and integrate into the team.
In a recent blog on stupid decisions, a reader asked about lessons learned processes. I had to defer the question since my reply would have been as long as the blog he was commenting on. So here we go: the entire class of retrospectives, postmortems, and lessons learned are a waste of time. Well, to be fair, I have never seen them work. They may have worked for others. Maybe the reason I never see them work is that I am involved only on disasters, you know, those projects everyone talks about for years to come, the ones people cannot get way from fast enough. Surely, the type of work I perform taints my experience.
The system integrator is the magical troupe that works with the customer and the software vendor to deliver a project's desired functionality. They cut through the vendor's promises while controlling the customer's expectations to create a successful deployment. Mike Krigsman refers to this triad as the Devil's Triangle; all three parties are culpable in the failure and share in the success. However, the system integrator is responsible for holding the three together to achieve successful delivery. The cornerstone to this relationship is a thoughtfully built contract.
The costs of failing projects are huge. Roger Sessions estimates the cost in the US alone to be $1 trillion annually. The impact, though, goes beyond monetary; it includes reputation, the organization's morale, consumption of resources, and missed opportunity by postponing other projects. Fortunately, there are also many unrealized benefits to glean from troubled projects. To reap those rewards, companies must adopt a culture to exploit failure and learn from it. More often than not, people just want to get the project behind them.
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.
More Info on Project Recovery
Rescue The Problem Project
- New PM Articles for the Week of November 9 – 15, The Practicing IT Project Manager, November 9, 2015
- The Argument for Disbanding Your PMO, Accellerated IT Success, Nov 13, 2015
- New PM Articles for the Week of September 28 – October 4, The Practicing IT Project Manager, October 4, 2015
- Episode 332: Project Sponsor Challenges and Solutions, PM Podcast, Cornelius Fichtner, September, 2015
- New PM Articles for the Week of December 1 – 7, The Practicing IT Project Manager, December 7, 2014
- How to buy Project Management Consulting Services: Service as a Product (SaaP), Guerrilla Project Management, Samad Aidane, December 2, 2014
- Episode 275: Your Project Statement of Work is Missing a Comma!, PM Podcast, Cornelius Fichtner, June 14, 2014
- State Invites 10 Firms To Shift Cover Oregon To The Federal Health Insurance Exchange, Oregonian, Portland, Nick Budnick, May 28, 2014
- Decision To Scrap Or Salvage Cover Oregon Health Insurance Exchange Poses Risks Either Way, Oregonian, Nick Budnick, Portland, April 9, 2014
- Cover Oregon Consultant: Fix For Health Insurance Exchange Could Take $40 Million, 21 Months, Oregonian, Nick Budnick, Portland, April 4, 2014
- Episode 205: Rescue The Problem Project, PM Podcast, Cornelius Fichtner, June, 2013
- Episode 206: How to Keep your Project out of Trouble, PM Podcast, Cornelius Fichtner, May, 2013
- How to identify, prevent, and recover from project failure, Accellerated IT Success,April 2, 2013
- Episode 260: The Seven Steps to Rescuing the Problem Project, PM Podcast, Cornelius Fichtner, January. 2014
- New PM Articles for the Week of August 6 – 12, The Practicing IT Project Manager, August 12, 2012
- New PM Articles for the Week of June 11 – 17, The Practicing IT Project Manager, June 17, 2012