Sins and redemption: IT project recovery in focus

I talk with many enterprise buyers, system integrators, CIOs, and software vendors about why IT projects are so notoriously difficult to get right. In the end, two observations astound me:

• The very structure of economic and political interests often drives IT failure
• Enterprise buyers frequently exhibit poor judgment and denial when constructing their projects. Worse, the folks who most need advice are typically the least likely to accept it. 

These problems are part of the business environment in which organizations deliver IT projects -- they lie outside the project itself. For this reason, successful IT delivery requires a deep connection to the broader business. To be effective, this connection should take the form of collaboration between lines of business and IT. Success in IT requires cultivating greater cooperation between the technology delivery parts of an organization and the business units that consume technology to improve operations.

Author and consultant, Todd C. Williams, is a top authority making IT projects successful. His book, Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure offers a definitive and comprehensive look at fixing problem IT projects. Given the depth of Todd's experience, I asked him to write a guest post for this blog. Find Todd on Twitter under the name @BackFromRed and read his blog at http://ecaminc.com.

Also read: The IT failures blame game (part 2) CIO analysis: Defining IT project 'success' and 'failure' 7 tips to safely kill zombie projects  12 characteristics of doomed projectsNew techniques for saving failed projects Rescuing software trainwrecks, without sacrificing goats

I am grateful to Todd for writing the guest post that follows.

=============================

SINS AND REDEMPTION: IT PROJECT RECOVERY IN FOCUS

In business, we often struggle with the concept of experiential learning, and so repeat the same antics that get our projects into trouble time after time. If we really learned from our mistakes, ERP implementations would be far easier and more successful.

The issue is that we have failed to structure business to learn from our mistakes. Especially in the information technology world, we need to develop a culture that allows us to find the root cause of problems as they occur and fix them at that time.

Until more organizations cultivate a stronger learning culture, project recovery will remain an important tool in the fight to interrupt IT failure.

Realization

Before we can proceed down the path of recovery, we must admit the existence of a problem. Pride, ego, emotion, denial, and inertia bias our view of the situation.  Project managers believe they can correct the problems. Executives try to help by assigning additional tasks, new processes to follow, numerous spreadsheets to complete and daily reports to distribute.  Eventually, the customer becomes aware of the situation and they go to the steering committee demanding action.  The latter gets action. The resulting scramble to appease the customer, however, does little to solve problems while only addressing symptoms.

Addressing the problem with logic

The solution is a methodical, calm approach of auditing the project's current state, analyzing the options to make it successful, negotiating a new approach, and implementing the new plans.

Project audits acquire data to drive the project rescue.  Like the well-accustomed financial audit, this phase is an objective and nonjudgmental exercise to gather data, in which we take few, if any, actions. Increased communication and cutting the chaos are the improvements that usually result.

The second step is analyzing the information, identifying the root causes of problems, and formulating a recovery plan.  The most critical point is associating problems with their sources so the originating failure may be addressed and fixed. Correcting problems at their root eliminates them from affecting this and other future projects.  Unfortunately, in the mayhem and haste of fixing most projects, this essential step is sacrificed. The result is a failure to learn from our mistakes.

The new project plan

The recovered project's plan is necessarily different from the original.  Something on the project must change, time has been lost and money spent, one or both are over budget; otherwise, the project would not in the red.  Stakeholders will need to approve the changes.  Therefore, the third step of the recovery process is negotiation and approval of the new plan.  Without a thorough understanding of the problems, identifying the root causes, and developing plans to address them, it is fruitless attempting to convince anyone that the new solution is any better than the original.

With negotiation complete, the root causes can be addressed and the new plans executed. Addressing the root causes first makes the project run like any successful project.

Create a new rescue project

Thinking of the recovery as a project itself requires that you understand and obtain stakeholder agreement on the rescue's deliverables. Hence, there are three projects in every rescue effort.  The recovery project is sandwiched between two other projects -- the failing project and the new successful project.  The recovery process generates multiple corrective actions that will predicate the new successful project.  The benefit of properly addressing a failed project is the deliverable of the recovery project-corrective actions.  Properly applying these corrective actions solves the problems so it will not reoccur on this and follow-on projects.

Experience shows that most problems have little to do with the internals of the project itself.  The most common are related to the organizations that are responsible for the project.  How the project was conceived, its size and complexity, inadequate managerial support, the organization's lack of discipline, or its policies and procedures are by far the most critical in dooming a project. These problems need to be fixed in the organization, rather than in the project.

To understand the depth to which you must go, to identify and solve root causes, let's look at a common issue for system integrators. Integration projects often get into trouble because the assigned people are lacking the skills to adequately do the work.

There are two solutions to this problem: 1) train team members to acquire the required skills, or 2) replace them with appropriately trained resources.  Besides the cost involve, this does not solve the problem. During the audit, the recovery manager must ask, "Why are the resources missing these skills?"  It is surely not the individual's fault.  A combination of policies generates this problem. System Integrators must keep their staff billable, therefore they have policies to use internal resources prior to bringing in outside help, they normally do not have policies about training staff on the technologies required to fulfill their strategic roadmap.  The training must be part of overhead or factored into the time and cost of the project.  As a result they bid a lower price, trying to complete the project with deficient resources, and the project suffers.

Learn and improve

Organizations excel when their projects are successful.  To turn the project failures into continued success, we need to take a deliberate, methodical approach to project rescue. Look beyond the reaction to Band-Aid the project in an effort to get to rapid completion and focus on solving the root causes. This requires a new attitude.

To achieve success with IT projects foster a culture that adapts and changes how we conduct business, dismantle organizational silos, and use each failure to generate new ways of thinking.  By doing this, every failure becomes a gold mine that improves our organization.

=============================

I am grateful to Todd C. Williams for writing this guest post.

Photo from Istockphoto and process drawing from Todd Williams.