IT productivity through project failure

All too often when projects fail, people are reassigned, project managers and key team members fall from favor, and the company quickly moves forward toward other new and important business initiatives.

This phenomenon, at least the “quickly moving forward” part, also often happens to a lesser degree when production systems fail, backup/restore procedures don’t work, security breaches occur and other bad things happen. In these cases, however, because they are ongoing activities, IT generally does an excellent job discovering the root cause of the issue and performing the needed corrective action.

Production groups then take the additional step of analyzing what organization and/or procedural factors allowed the issue to occur to prevent it from happening again.

This mainstay of organizational and procedural introspection should also be used more heavily when projects fail or fall short of the desired result. If you do, it can enhance your organizational awareness as to why the project environmentally failed, unrelated to the work performed by the project members. This increased knowledge can be captured by asking the following questions:

• Was the project team given the needed resources to complete the project?
• Was the project properly prioritized, thus having the ability to gain the needed information, approval, support and resources of those outside the team, but crucial to its success?
• Was the correct mix of technical and non-technical skills approved and included in the team’s original formation?
• Did the project stakeholders clearly articulate the projects goals and objectives?
• Did all project stakeholders have the same project vision and success criteria?
• Did the required project methodology (Waterfall, Agile, Six Sigma, etc.) properly position the project for success?
• Did project goals align with overall organizational goals? If not, what impact did it have on the project’s chance of success?
• Was there something in the corporate culture that doomed the project from the outset?
• Did corporate goals change during the duration of the project in a way that would adversely affect its outcome?

This concept of analyzing the project’s environment, not just the project team, raises two important questions:

1. How can this data be properly collected, analyzed and acted upon, given people’s egos, organizational politics, and other environmental factors?
2. If you can overcome the significant hurdles defined in the answer to question #1, how can it help enhance IT productivity and project success?

As for the first question, several things must be in place to properly analyze a project’s external environment. They include the following:

• Avoiding the temptation to simply blaming the project manager
• Senior management must be willing analyze their own actions and admit fault if it’s appropriate to do so.
• Senior management must create an environment that advocates transparency as a way to minimize future project risk, not a way to punish those involved in the project’s failure.
• Searching for the reasons behind project failure must be viewed as a "learning moment" for the company, not a witch hunt for the guilty.
• Openness and honesty is a mandatory company value.

As for the second question, reducing the risk of project failure, thus increasing the percentage of project success, has many organizational productivity advantages, some obvious some not, including the following:

• Reduces the cost of project restarts
• Reduces the lost opportunity cost related caused by project delay or failure
• Reduces employee attrition, forced by the project failure itself or caused by low team morale and/or professional embarrassment
• Gaining the business advantages caused by project success
• Organizational and individual employee willingness to take on additional projects due to a positive project environment
• Ability, as an organization, to stay competitive in today’s rapidly changing business and technological landscape

As a final thought, when a single IT project fails, it reduces the reputation of IT as a whole. This diminished standing can play out in many seeming unrelated ways, such as:

• Increased shadow IT
• Less involvement in SaaS based implementations
• Reduced seat at the digital transformation strategic planning table.

Your willingness to look beyond the PM when a project goes awry, may simultaneously show fairness to the project team and enhance your own stature within the firm.

This article is published as part of the IDG Contributor Network. Want to Join?