Blog: Fixing Problem and High-Risk Projects

Dilbert's Boss' Visionary Leadership, Dilbert © September 9, 1999, United Feature Syndicate, Inc.

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.

CIO nameplate: Who should the CIO report to?

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.

Cousin Itt, from the Addams Family

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 scope of Rescue the Problem Project

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.

Page 8 of 12

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References

Sitemap