Guest View: The HOPE Method
By Jon Quigley and Kim Pries
SDTimes.com, September 15, 2009 —
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.
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.
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
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.
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.”
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
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.
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.