IT productivity through project failure
This post was first published in my “Driving IT Productivity” column on CIO.com and has been updated from its original form. 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 [...]