 |
How Many Things Can Go Wrong...
It is common that when I am called into fix a red project to have management assign all of the projects ills to one problem. As of yet, I have to see such a project. There are multitudes of problems deeply embedded in the organization and the project team to make a project truly crimson. Managers look at how the problems manifest themselves, skip diagnoses and assign blame. Prior to getting to the point of calling an outside party, they have tried to fix the issues by attacking these symptoms. This only makes matters worse and the project becomes a deeper shade of red.
|
The key to bringing a project back from red is the ability to distinguish the symptoms from the disease. This is very difficult for someone on or associated with the project. The patient are too involved, too attached and too emotional. They need a physician to review the complaints and develop a prognosis and treatment.
It is easy to blame symptoms they are most visible. Scope creep is a common one. However, scope creep is always only a symptom. One or more root causes are the real problem. It may be that the customer fails to understand what they really need. It is possible that Project Manager is allowing change to take place sans management or they are restricting the essential changes. The team could be slipping in new scope to meet the wishes of the customer and avoiding the processes. It may be a combination of any of these. This happens with waterfall and Agile methodologies. Ignoring the process creates havoc. Trying to solve the problem, however, without finding its root cause, will result in more frustration and ultimately failure.
Figure 1 provides an example of an actual project and the list of symptoms that people were claiming to be the root problems. In analysis, they all stemmed from four issues. Initially, scope creep was the base reason. Shortly into the project audit, however, it was obvious that there were two groups claiming to be the end user, each having different requirements. Without defining the end user, the sponsor was unable to prioritize the features. Even with a well-defined scope, the inexperienced team was unable to provide the infrastructure and features in a monolithic delivery—it was simply too complex. Without proper decision making, the authority to phase the project was unavailable and no one could push to remove the maintenance tasks from the project. It all looked like scope creep that is out of control.
As opposed to management's attempts to blame the project team, the problems were primarily outside the project team. Fixing the three problems outside the project and phasing the delivery solved the problems with the project. The corrective actions were put in place and a junior Project Manager completed the project.
Tags: 
IT Failure Project Management Leadership
 |
 |
 |
