Blog: Fixing Problem and High-Risk Projects

Multitasking Image How many times have you heard someone say men are poor at multitasking? Well, that is probably a good thing, since multitasking is horribly inefficient. When I first said this in a presentation, people were shocked and took exception to the statement. After a few studies on the subject (summarized in a Harvard Business Review article), people are listening and agreeing. This should be nothing new. Looking at some of the more common methods to reign in red projects—Agile and Critical Chain—one premise they share is dedicating resources.

In daily talks and presentations, I am often asked what the most common reasons are for project failures. I usually turn the question around and ask people what they think. It is a fun exercise and people list a mixture of symptoms and sources. As mentioned in the previous blog, one must drill past the symptoms and get down to the problem itself. It is my firm belief that most project problems are rooted in the people, however people are creatures of habit.

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.

Reading an article the other day, the author was lamenting on how Project Managers were under educated and needed to know more about earned values analysis, risk probability determination, finite schedule development and other tools that make a Project Manager great. She was arguing that certifications, like PMI's PMP® certification, needed to have more testing on those subjects.

The term 'Inception Phase' is often used to signify a project's beginning. Isn’t it really the birth? There are many similarities between a project's lifecycle and this familial analogy.

Inception happens much earlier with a glass of wine, maybe two. That first thought, “Hey, wouldn’t it be neat if we had a…” Complete the sentence to fit the situation. It is at this point that the ball gets rolling, so to speak, and someone decides to invest some time to explore the possibility of making something happen. The originator courts the business manager, selling the concept of the idea, until there is approval to move forward. Voilà! It is conceived. Someone commits to carry and nurture the project, allowing it to incubate and mature into a viable form that can properly benefit the organization as a final product. After the proper gestation, the project is born and has a team assigned. This is the transition that many methodologies errantly label inception.

Many companies have some form of a portfolio management group to manage their projects and their backlog. The projects they govern range from network pulls to new software development. However, most use only one methodology to run these projects. It may be waterfall, Agile, Critical Chain or some other process. This is analogous to having only one knife in the kitchen. Anyone that has cooked more than a few meals realizes that a table knife is insufficient for all your kitchen needs. It purees tomatoes, cuts meat poorly, fails at filleting fish and suffers as a steak knife. There are hundreds of knives, each designed to do some specific job. As with many jobs, some tools are better than others are for certain tasks.

"Technology... is a queer thing. It brings you great gifts with one hand, and it stabs you in the back with the other." This quote, delivered by C. P. Snow, is one we should all live by. Mr. Snow was a physicist, a novelist and a bit of philosopher. Technology brings about great benefits that many of our projects rely upon. We are using it right now. However, take pause to reflect on how technology is also our nemesis. It haunts our projects with its false promises and lures us into implementing superfluous functionality.

Yes, I am on that soapbox. Ensuring that maintainability and adaptability are part of a system is a "best practice," extensibility is not. To the extent that a highly structured system is extensible, that is the end of any commitment to building for the future.

Adding hooks and stubs for something that may not happen, confuses and clutters the design of the resulting system. Building and running prototypes wastes time. Making a system extensible adds significant undefined scope. The reason is that no one knows what the future will bring. Furthermore, how can it be tested if the systems it is interfacing with are not defined?

The other day a friend said that there were three reasons for project failure. I took exception and stated there were two. As I thought about it more, there is only one. People are at the root of all failures, everything else is a symptom. Let’s look at some common reasons.

The project is over constrained. People set the constraints. If they do not understand the project well enough to set the constraints, or listen to the people that are suggesting the constraints, then they are the problem.

Page 12 of 12

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References

Sitemap