Fearless Project Leadership

airplanedog.jpgIf 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 US to Eastern Europe to Japan, I have found that the fear of failure dwarfs the dreams, hopes and aspirations of people around the world and at all levels in the organization. This ubiquitous fear of failure causes individuals to take refuge in incremental thinking and the safety of nebulous, ill-defined commitments to which they can’t possibly be held accountable. The result? Creeping Incrementalism.

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 which 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!

Facebooktwitterredditpinterestlinkedinmailby feather

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.