Blog: Fixing Problem and High-Risk Projects

A Pretty Bar Graph

Businesses exist to make money. To improve operations they create various initiatives with promises of improving the bottom line. Projects, though, cost money. They do not make a profit. The dichotomy in a strapped economy to spend savings on projects to improve future profits usually results in the conservation of cash. Many an argument has been had over whether it is better to run improvement projects, burning precious cash and heading off the competition, or taking the traditional approach and wait for times with better cash flow. Subsequent to 2008's financial folly, it is well known that most companies sat on their reserves and waited. That action may have some unintended consequences that are in the midst of surfacing.

Picture of accountant

Few events start a project manager's day off worse than a yellow sticky note on his or her monitor saying, "The finance manager would like to talk to you." An email is equally as bad; however, the note at your desk means that someone actually hunted you down looking to talk about, you guessed it, finances. There must be some problem. Everyone knows the finance folks would never wander into project-land to invite you out for a friendly cup of coffee. You quickly review the project's finances. Everything seems in order. With a sigh, you contemplate whether you should walk over and see her or will a phone call be the least painful option? Yes, painful. Anytime the finance manager calls, there is going to be a lot of new work.

The Change U-Turn

Management comes up with great plans for sweeping change, it implements the plans, and three years later the organization has reverted to the way it was before the initiative. Changing to new breakthrough systems is hard; maintaining those processes and procedure is far more difficult. The reason progressive ideas can have a successful implementation only to have the organization regress to its prior state a few years later has its roots in societal practices and human nature.

Banging head on keyboard

It was a classical interview in all respects, except they kept asking, "Can you handle stress?" After while, I replied that on my last project gas mask training was a first-day requisite, meetings were routinely held in bomb shelters, there were written emergency evacuation plans, and uniformed men and women with M-16s were common sights on the city streets. That was stress. I should have known better. Stress comes from the unknown, the events in life for which we have no plans.

A speaker at a recent conference asked the well-dressed audience, "When is the best time to listen?" As with most presenters' questions, there was a host of blank stares, a few people rustled in their seats, and the remainder diverted their eyes to their laps as if a sudden important message had appeared on their notepad. After a pregnant pause the answer came, "When someone is talking." A relieved, yet embarrassed, chuckle rippled through the suit-clad audience. The advice is a good start; however, listening entails significantly more effort.

Picture of ducks facing off

As mentioned last week, alignment is of the utmost importance. Achieving alignment, at first glance, is easier when the supplier works for the same company as the customer, say an IT organization delivering a new application to a business unit. However, from my experience there is little difference. In fact, exploring a vendor's world, where access to the customer is inhibited, sheds significant light on techniques to improve the customer-supplier relationship. Classically, vendors must wait for a request (RFP or RFQ) before they can get access to the customer. Exploring ways of "fishing up stream," as an eloquent account manager friend of mine says, is critical in improving project success. To understand this we need to review a couple of case studies on vendor success and failure.

Picture of mise en place

I have always enjoyed cooking and rarely thought of it as a chore, let alone a project; however, when my wife became ill, I became the household chef and had to learn a new way to cook. Every evening was a project with varying degrees of success. Eventually making multi-course meals from scratch became easier. I used to joke that cooking Chinese food was two hours of chopping fresh vegetables and ten minutes with three blazing woks.

Cartoon on Risk

Risk is a risk in itself. It is risk for you if you dare bring it up. Have you ever identified the risk, in writing, that your boss' inherent inability to make decisions is going to sink the project? How about the company loss of market share will require laying off half the project team? Or, that the project manager has never had a successful project? These are CLMs (career limiting moves). Even mentioning such common risks as a company's inexperience in the project's domain is too risky to put in the risk register. It is as if management enjoys blissful ignorance and relishes the firefight that ensues. Cowboy mentality. Identifying risk, modeling mitigation plans, and compiling contingency are too boring compared to the thrill of disaster recovery.

Graphic Normal Estimation Distribution

Estimates are wrong if you cannot beat them half of the time; they are also wrong if you are not late half the time. Neither condition is one that should make management upset. In fact, matching that score is a great accomplishment. So how can people get so emotional about the statement? The answer is that people do not understand estimates and how they work. Through years of estimates being treated as quotes, we have been brainwashed into thinking our best effort is to meet the date, not better it. Heaven forbid if you are late. This lack of understanding is very evident by the number of blogs on the subject and some of their bewildering comments. The comments point out wildly different views. Some people think that Monte Carlo analysis gives you an estimate that has a 95% chance of being right and others believe that using Agile relieves people from having to make estimates entirely. Both of which are plainly not true.

schedule with Identified Padding

Why is it that tasks always seem to be late? No matter how much time we allot, there never seems to be enough to complete a task on time. There is one overreaching reason pervasive throughout the enterprise—poor time management. To accommodate the continual barrage of supposedly urgent tasks, we heavily pad estimates. Excessive padding triggers numerous negative work patterns. The extra time and over confidence in estimates allows people to accept other unrelated tasks, introduce low priority features, and strive for perfection. It is unfair, however, to saddle the individual with the entire problem; the work-place culture reinforces and rewards the behavior.

Page 2 of 4

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