Projects fail, and when they do there can be major consequences that no CIO wants to know about. But more common than the failed project is the "problem" project. In fact, some may argue that any project of significant scale is a problem project. I just took a look at the new book from Todd C. Williams entitled, "Rescue the Problem Project" that gets right at the heart of this issue.
Williams looks at all the phases of projects and takes on specific issues that are bound to create the problems we all want to avoid. The section I found most interesting centers around the concept of not letting a "problem project" become a dilemma by knowing the signs of a potentially hazardous problem. In his chapter, "Doing it Right the First Time: Avoiding Problems that Lead to Red Projects", Williams defines Red projects as, "a project is red when unanticipated and uncontrolled actions cause senior management to determine that it is performing insufficiently, based on agreed parameters."
The main goal is to keep any project being designated red from occurring. Williams advises that the most common issue with projects going red comes from not properly defining a project's initiation. Assuming that a project has already been approved, having cleared a number of hurdles in the enterprise and is now on the CIO's desk. This phrase is detrimental to the project, as it's the first point where problems begin to arise. As Williams puts it, "This process occurs long before the first phase of a project. It creates the seed for the project and provides input to the project team that will make it a reality. The first miscommunication can happen here, and it can set the project on a course for disaster."
That sounds like the point at which every problem project I've ever been involved in becomes trouble. Fortunately, there are ways that may lead to recovery. Williams suggests having a Guidance Team review the project. Williams says, "The problem is that these are initiatives rather than projects. Managers often fail to include the implementation professionals in these early meetings. To improve project inception, assemble a guidance team to participate in the business planning meetings and to provide oversight and monitoring throughout the project’s lifecycle."
The question seems to be at what point does an initiative become a project, and should there be different teams involved and at what stages. With the current trend toward multiple business units participating in IT initiatives it would seem that adding yet another set of oversight could further complicate things. What has your experience been with moving from initiatives to projects and keeping them from going Red?
Scott Koegler practiced IT as a CIO for 15 years. He also has more than 20 years experience as a technology journalist covering topics ranging from software and services through business strategy. He has written white papers and directed and published video interviews.
