by Kim H. Pries and Jon M. Quigley

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?

Scope Hope

The use of hope often starts at the beginning of the project. It is never too early to exercise the use of hope.  It begins 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 project manager that employs hope will take a team that is handed to him instead of identifying the resources needed.  Of course, as a project manager you have to make do with what the organization can provide, including team composition. However, that does not mean starting without trying to assemble the resources needed for a successful project.  The project manager will neglect resource procurement and take what they get rather than get (or ask for) what is needed for project success.

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 identification of the areas of responsibility, or better yet, they can all be responsible 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 they all are accountable – then none of them 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 information needed – without any work or coordination required.  For product development, this means product specifications are updated and automatically routed to the test group.

Estimating

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.

Contingencies

Again, 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 back up plans nor will we make sure the team is able to identify a symptom of a risk that has come to fruition.  With 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.

Project Execution and Control

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 called “…and here a miracle occurs.”

Communications and project status

Management may use doublespeak. It is not necessary to practice Hide / Obfuscate Project Errors (HOPE) project management to use this technique.  Using this technique makes it possible to down play the severity of a problem and the 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 brand as naysayers, hypercritical or just plain negative.  Their council 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.

Other ‘opportunities”

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.

Conclusion

The hope method of project management eliminates the need for activity from the project manager.  Hope project management is not a repeatable method that secures success.  We think it is better to be HOPE-less than to be HOPE-ful.  Hope should not be the first and certainly not the only action taken by the project manager.  Hope after all other actions and efforts to improve the situation are taken.  People often misunderstand the story of Pandora’s box: when the ills that afflict mankind flew from the box, only HOPE remained. We shudder.