SCRAPPY
PROJECT MANAGEMENT
Project
Management Dialogues with ATTITUDE!
by Kimberly M. Wiefling, M.S.
http://www.projectconnections.com/knowhow/columns/031506-wiefling.html
This Month's
Featured Noggin' Floggin': Fearless Project Leadership
If you are absolutely dependent on your paycheck to survive,
do yourself a favor, don't be a project leader! In most of the scrappy
high-tech organizations that I have worked in, the role of a project leader
cannot be successfully filled by anyone who can't put their job on the line in
the pursuit of doing The Right Thing. From the project kick-off, where the
project leader may not even be involved, to the attempted premature launch of a
less-than-ready-to-ship product, projects run a higgily-piggily route. This
real-world path rarely resembles the neat, tidy, well-defined process described
in the PMBOK®.
In order to deliver results in the challenging circumstances typical of many
business environments, project leaders must be absolutely committed to the
success of their projects and leading their team to that success. Frequently
they must execute this feat without any explicit support, sometimes with active
resistance, and occasionally in the absence of any evidence that the project is
indeed possible. This calls for leadership in the face of fearsome challenges.
It involves being willing to hold to a firm commitment to doing what it takes
to deliver the goods in the face of second-guessing and doubt from executives,
peers and even their own team. It requires the kind of resolve that can only
come from a commitment to something greater than your own safety and comfort,
something beyond "wage slavery." This calls for "Fearless Leadership."
The Biggest Fear
Most breakthrough projects have a fair degree of risk
associated with them. That's for good reason—they
haven't been done before, so success in not assured. In order to understand how
to lead teams on such projects you need to understand the number one reason
that most people resist taking on challenging goals: fear of failure. From the
According to research on high-tech product development projects, the proportion
of projects that are truly innovative relative to those that are incremental
extensions of past projects has shrunk dramatically in the past decade.
Unfortunately, if you aren't allowed to fail, you must be very careful what you
start. In fact, many companies have abandoned innovation entirely, choosing to
acquire innovation rather than attempting to produce it from within.
The
Innovating David vs. the Incremental Goliath?
A project team in a start-up company with no established
reputation, nothing to lose but a few years and a couple of million bucks, and
a fierce determination to risk everything to win or lose, is in a much better
position to innovate than a project team in a large company. Adrift on a sea of
budget cuts, schedule crunches and lukewarm executive sponsors determined not
to be left holding the bag on a failed project, large companies can sometimes
retreat into playing it safe.
And who can blame them?!!! Who in their right mind wants to champion upgrading
the robustness of a software platform for a product family when it won't
deliver new functionality obvious to the customer? It's just not that sexy to
be the advocate for a good, solid foundation. If you were going to put $100K
into fixing up your house which would you enjoy more: reinforcing the
foundation or putting in a brand new, state-of-the-art kitchen and remodeling
your bathrooms with Italian marble and slate? On the surface it is more
satisfying to just keep extending the current platform until it crashes and
burns, hopefully on the next guy's watch! It takes real commitment to the
greater good to take responsibility for building the foundation for future
success. Unfortunately most companies don't reward people for contributing to
the greater good; they reward them for achieving their own performance goals.
In the same vein, why should anyone take on the role of championing a product
in an emerging technology with a risky market future? Better to introduce yet
another revision to a marginally successful product.
In larger companies with dozens of projects there is little upside for taking
on high-risk projects, and there is most definitely a downside. Success is
quickly forgotten and any failure is remembered forever. One colleague of mine
in a very large company has had the stench of one failed project that he led
follow him for almost a decade. This failure has impeded his career progress
there, and he is now seriously considering going elsewhere instead of waiting
for all of the people who remember that incident to either retire or die. In
fact many people agreed that this project was huge, unwieldy and ill conceived
from the start, but this guy was the project manager; he took the fall for it,
and he's still paying a price.
Common Sense is Not
Common Practice
In small companies I have found that the greatest challenge
of project leadership can be more about being "The Only One": the
only person who really understands project management in the company. You see,
done well, project management seems like common sense to many people. So most
people think they have a good understanding of it even if they are not trained
or experienced in it. As the lone voice of project management in a small
company you may find yourself defending the basics to these PM back-seat
drivers on issues like setting priorities, having clear metrics of success, and
the need to hold design reviews and track action items. I recall one project
where I had laid out clear plans, schedules, assumptions, risks and possible
accelerators along with my conclusions to the CEO only to have him retort
"I don't buy it." That's it! No reason! No information about how his
assumptions and beliefs differed from mine. Nothing! Just "I don't buy
it." Alas, you can't enlighten the unconscious. Not long thereafter I
moved on to other, less futile challenges.
There is a discipline of project management that must be learned and practiced,
however many people think it's "just common sense." They have opinions
about how projects should be run, and will freely offer those opinions
unsolicited, and with great vigor! Often wrong but never in doubt, they believe
that their opinion is somehow on par with the blizzard of best practices and
evidence of what makes projects successful in thousands of companies. Certain
that "this company is different," they insist that common sense best
practices don't apply to them. And while they'd no more stand for you
micro-managing their part of the project than they'd agree to a diet consisting
solely of Metamucil, they don't view their resistance to basic project
management best practices as micro-managing your role.
Regardless of company size, executives seem united in their lack of
understanding of the interdependency of the quality, features, budget and
schedule of a project. Understandably driven by business needs to announce,
launch and ship products around certain market-driven dates, they often appear
to be unreasonable, or even irrational. A project leader may spend hours, days
or weeks creating a detailed project plan, including schedules, resources,
risks and mitigation, only to have an executive arbitrarily tell them to
"cut two months off of the schedule" without changing the scope or
adding resources. It's at this point that the difference between a professional
project manager and someone merely filling the position of a project
manager becomes clear.
The Fearless Project
Leader's Defining Moment
In my opinion, a fearless project leader who knows their
stuff and has created a sound basis of estimate for their project plan can win
this battle almost every time.
1. Assure that the team has overturned every stone in the planning phase and
done a thorough job in planning the project. This means explicitly
including risk and uncertainty into the plan, especially into the budget and
schedule if those items are critical to the project success. Planning is the
most often skipped phase of projects. It's a proven fact that, given a choice,
most people will under-plan ... or do no planning at
all. As project leader you must insist that your team devotes appropriate
attention to planning, looking at possible risks, and assessing the
opportunities for upside. Too often we think of all the ways that things can go
wrong but fail to explore what can go right. While single number estimates are
always wrong, stochastic estimation techniques and a healthy dose of both
negativity and possibility thinking should cover the bases between worst case,
most likely and best case. This provides a defendable position for the
inevitable (and appropriate!) executive push-back and subsequent negotiations.
2. You need an absolutely clear depiction of the plan being presented so
that it can be instantly understood by someone who has not spent hours creating
and pouring over it. In other words, simple enough for an executive who
spends 15 seconds looking at it to ascertain the critical few issues out of the
many found in any project. The best way I have found to accomplish this is to
have a one page simplified flow chart of the high-level project critical-chain
(critical-path and nearest neighbors most likely to compete for critical-path)
from start to finish. While MS Project is a handy tool to those who are
familiar with it, most executives won't take the time to understand the
intricacies of the interdependencies illustrated by its Gantt charts and PERT
charts. Although it's almost double the work, I find that a nice Visio diagram
showing the critical-path is easier to follow and worth its weight in gold when
having a dialogue with executives.
SCRAPPY TIP: Ornament the biggest risk areas to the project with clip
art such as a skull-and-crossbones, an ambulance or a
ticking time bomb. While you may be labeled a bit dramatic, these visuals help
draw attention to areas of greatest risk to the project.*
3. NEVER say NO. I make it a practice always to say "YES, that's
possible if . . ." and explain the interdependencies and impacts. For
example, if an executive insists that a project must be completed two months
earlier than the high-confidence estimated completion date, I might say
something like, "Sure, that's totally possible if you can tolerate a 70%
chance of missing that date, or if you add an additional QA shift during the
testing phase." They may balk at the requests that follow your "Yes,
if . . ." but at least you are now in a dialogue about how to jointly
accomplish the project goals rather than in an argument about whether or not it
can be done. It can ALWAYS be done, albeit with differing levels of risk,
failure and heroics.
Sometimes, as a result of executive push back, it makes sense to go away and
re-examine your plan to see if there are areas that were missed. However if you
have done #1 and #2 correctly you should be able to say with confidence:
"I totally understand the business need for what you are asking, and I
truly hope that we HAVE overlooked something in our planning that makes our
conclusions about completion date (or budget, or whatever the issue is . . .)
erroneous and overly pessimistic. Help us out here. What did we miss? (Motion
to your one page plan, with the skulls, ambulances and time bombs.) Help us
understand where our assumptions are incorrect."
Sensible, reasonable executives interested in fact-based decisions will offer
creative suggestions that may indeed point out what assumptions could be
changed in order to better achieve the goals. Other more nefarious executives
may show their true nature here with red-faced fist pounding, intimidation or
abdication of responsibility that leaves the burden squarely on the project
team. In the latter case, wage slaves must go off and "do their best"
until project failure is undeniable. (Unfortunately it is usually easier to
slip the schedule later in the project, rather than at the beginning when
everyone knows that the schedule is ridiculous but no one is allowed to admit
it.) For these unlucky souls, from this point on it is not so much a matter of
leading the project, but merely documenting its demise. Fearless project
leaders, on the other hand, will be able to stand their ground and insist on a
fact-based project plan, or take their skills elsewhere. Fearless project
leaders have the quiet confidence to assert that the business results must rest
on a sound basis of estimate, not wishing and hoping. In fact, this is the only
responsible way to conduct business in a project, and an absolute must for
anyone wishing to emerge with their integrity intact.
When All Else Fails
. . .
True,
sometimes reason doesn't prevail. My advice? When the horse is dead, get off!
Some projects aren't worthy of your fearless leadership. Move on to your next
great opportunity!