Guest View

When you step onto an airplane, you hope it will not crash. You, as a passenger, have no control over what happens during the flight. Statistics indicate flying is relatively safe, which is due to vehicle mechanics, pilot training and competence, flight crew and tower teamwork, and substantial planning.

Purchasing a lottery ticket or a spin on a roulette wheel is all about luck and hope, with little possibility of influencing the outcome. Sure, it is possible to purchase more lottery tickets or to buy more spots on the wheel for another spin, but the outcome is only incrementally improved. Why, then, do we so often see the HOPE method used in software project management?

The use of HOPE often starts at the beginning of the project, with Hurriedly Overlooked Project Extent (HOPE). The project manager will not know exactly what is to be delivered or how to go about doing it. The project manager will spend little time asking questions of the customer, never qualifying what is to be delivered or what constitutes good quality for the deliverable item. At best, any discussion will be around the very highest of levels of abstraction. We hope we got the full scope. This will have an impact when we estimate the project.

After the project manager spends his modicum of time understanding the targets of the project, he will transfer this knowledge to the project team. The HOPE project manager takes the team that is handed to him instead of identifying the resources needed.

Expectation HOPE
Once the team is assembled, the HOPE practitioner will let the project team magically know the demands upon them via Halfhearted Orientation to Project Expectations (HOPE). Here we neglect to identify of the areas of responsibility for delivering the project. The PM will not spend time identifying what constitutes success or how the team member contributions will be measured—no need for a resource allocation matrix or some other way of defining team roles. If all are accountable, then none are accountable.

With HOPE, there is no need for communications plans or project reviews. These just cloud the air like a bad odor. With HOPE, those key communications channels are self-identifying and develop on their own. People or groups of people depending upon information from other parts of the project get the needed information, without any work or coordination required.

Estimation HOPE
With Highly Optimistic Project Estimation (HOPE), there is no need to review how other projects were executed in the past. With HOPE, we do not have to go through the due diligence of developing a schedule based on past performance. We can eliminate duration estimates from the team and get them from our individual expert or line manager, or better still, the project manager should set the durations. We can treat the duration estimates as a single-point source, no matter how much risk is associated with the task or how the task impacts subsequent, dependent tasks. It is best not to even recognize dependencies.

Contingency HOPE
Hands-Off Prevention Effort (HOPE) comes to the rescue. With HOPE, we can take only a cursory look at the risks and impediments to the project success. We may identify some very high-level catastrophic risks. However, these risks may not be very probable.

We will not generate backup plans nor will we make sure the team is able to identify a symptom of a risk that has come to fruition. Wearing our HOPE armor, we can sit on our fannies until heavy-duty effort is required to solve the problem.

We will not respond when a team member brings a risk our way. We will summarily dismiss the input as rumors or hearsay. We choose to be reactive instead of understanding what could go wrong and develop a plan for handling the risk should it come to bear.

Control HOPE
The application of Hope Other People Excel (HOPE) to project execution and control typically begins with the previously mentioned abdication or deferment of responsibility. Hope relies upon the project team to deliver. The project manager becomes a hermit in a remote office and only emerges when there is pressure from the project team or from upper management.

There will be few, if any, project reviews or project team meetings, and the ones that do occur will usually be the result of ignoring a small problem until it becomes a fiasco. Generally, we mark our schedule (if we have a schedule) with a line item labeled “…and here a miracle occurs.”

Communication HOPE
Management may use doublespeak. It is not necessary to practice Hide/Obfuscate Project Errors (HOPE) project management to use this technique. This technique makes it possible to downplay the severity of a problem and ignore its root cause. It is hard to say if this is a function of self-preservation or if this is indeed an overly optimistic perspective. However, in this mode, problems will not be called problems but, rather, “challenges” or “opportunities.”

When a problem is spoken of, it will be due to a non-team member getting frustrated or an unpredictable risk coming to fruition (“we could never have foreseen such a condition happening to our project.”). Those who earlier predicted an issue would come to fruition we will branded as naysayers, hypercritical or just plain negative. Their counsel having been disregarded, when the risk comes to pass, the people who tried to alert the project manager will sarcastically say, “If only somebody could have predicted this.” We choose instead to rationalize away those things that are amiss by management spin.

Opportunity HOPE
We can employ the Hands-Off Prevention Effort (HOPE) to eliminate tracking of metrics and avoid monitoring the project-development schedule. We can delay actions with Hard Options Put at the End (HOPE), so that we don’t have to deal with anything until it grows like an ugly cancer, potentially killing the host. And, of course, we have Heartless and Obstinate Personnel Ecosystem (HOPE), driving employee apathy, resistance and interpersonal futility. Our entire team works in a Half-Optimized Project Environment (HOPE), redolent with procrastination, misunderstandings and blundering.

Concluding HOPE
The HOPE method of project management eliminates the need for activity from the project manager. But HOPE project management is not a repeatable method to secure success. We think it's better to be HOPE-less than to be HOPE-ful. People often misunderstand the story of Pandora’s Box: When the ills that afflict mankind flew from the box, only HOPE remained. We shudder.

Jon M. Quigley and Kim H. Pries are principals with Value Transformation LLC, a product development training and cost improvement organization. They are presently working on two books to be published in 2010. The first book is on SCRUM project management, and the second on product testing.

Guest View: The HOPE Method

By Jon Quigley and Kim Pries