Introduction | Project Goal | Project Sponsor | Project Manager | Project Benefits 
Project Plan & Status | Project Budget & Status | Project Organization | Project Resources
Project Steering Committee | Stakeholder Communication | Change Management
Project Technology | Conclusions and Recommendations

Yogi Schulz is a partner at Corvelle Consulting a company he founded. He holds a B. Comm. from the University of Calgary, is a member of CIPS and holds its ISP designation. He has presented at many conferences and writes for the Microsoft web site, Computing Canada and The Calgary Herald on IT management issues. He also appears on the CBC Wild Rose Forum. Corvelle Consulting specializes in assisting clients who are moving applications toward a web-based architecture. Yogi Schulz may be reached at YogiSchulz@corvelle.com. Corvelle Consulting may be viewed at www.corvelle.com.

Introduction

In this series of short descriptions, Yogi Schulz describes 12 signs of impending IT project doom that are visible months before catastrophe strikes. However, these signs are frequently missed or ignored. IT project failure can often be avoided if these fundamental signs are recognized and addressed. These signs relate to the fundamental characteristics of the project. They include Project Goal, Sponsor, Manager, Benefits, Plan & Status, Budget & Status, Organization, Resources, Steering Committee, Stakeholder Communication, Change Management and Technology.

For each of these 12 characteristics, Yogi describes both observations that lead to project catastrophe and observations that lead to project success. To address observations that lead to project catastrophe, he describes corrective actions that can turn impending doom into IT project success. So, if you are looking for a chance to bring that gnawing feeling of impending doom about an IT project out into the open in a constructive way, read on.

As Yogi says:

"Almost every month an IT trade magazine reports on yet another IT project that hasn't delivered to expectations. I am amazed that most people are genuinely stunned when an IT project crashes into the ditch. Often the signs of impending doom are visible months in advance; but we miss them. Frequently these failures can be avoided if a few fundamental factors had been candidly assessed and corrective action taken."

Learn to recognize common project success or failure factors when they occur in your project. If you aren't aware of common success or failure factors, you won't notice when they appear on your project. For example, if the project schedule is slipping a day or two each month, that may not be cause for concern. However, if the rate of slippage is increasing, you might end up a month behind schedule within a year. That slippage will definitely become a topic of great concern.

Build an understanding of corrective actions that work when a project failure factor looms. For each success or failure factor, we'll discuss corrective actions that can turn a looming failure factor into a success factor. For example, if the project schedule is slipping, the corrective action may be to jettison some scope or to re-assign a few tasks to others. Many factors can derail IT projects. Analysis of successful and failed projects reveals that the 12 factors described in this article are the most frequent contributors both to successful projects and to failed projects.

On unsuccessful projects, many of these factors were not recognized as important, not addressed, sloughed off as unimportant or swept aside as some administrative nicety that was seen as a distraction from "real" progress. For example, why build a project plan? That just consumes effort that is better applied to getting on with it. On successful projects, most of these factors were addressed. Typically how these factors will be addressed during the course of the project is described in the Project Charter document. For example, there's no point kicking off a project without a project sponsor in place who has credibility in the executive circle.

So, if you're a project manager looking for a chance to bring that feeling of doubt about the likelihood of success of your IT project out in a constructive way, take a moment to think about these factors. The factors are designed to uncover the specific type of difficulty your IT project may be experiencing. If you just say to the project sponsor: "I have this gnawing feeling that our project is not going well." That's an unhelpful comment. Worse, it communicates that you may not be a team player and that your negative views may undermine the project.

However, if you say to the project sponsor: "I believe that our project plan is weak in these areas. As a result we are most likely under-estimating a few risks. Here's my recommendation about how to fix the problem." Now you are impressing the project sponsor. Now you are providing early warning of a problem that could lead to disaster. You are providing ideas for how to fix the problem. Now the project sponsor will think: "I want to keep this guy around. He's a real team player who is adding value."

Based on these ideas, you should be able to better describe various project problems and craft solutions that will avert disaster. Read on for the 12 common project success or failure factors and how to fix them for project success.

Project Goal

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page