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.

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.

Maintenance does not belong in projects. Combining the two violates the definition of a project, mixes deliverables with opposing triple constraints, and sets the stage for scope creep. Maintenance needs to be performed by a dedicated group that can quickly implement changes. Project teams should focus on completing enhancements that will provide additional value to the customer.