Project Management Institute

Five lessons learned – from the memoirs of Wile E. Coyote

Introduction

How many of us are guilty? We stampede along chasing our projects at the speed of light driving them through execution. Our foreheads sweat profusely; our lungs gasping for the next breath. And, just as we see that light at the end of the tunnel, BAM! We find ourselves extracted from this chase only to be thrown into the next one—no time for lessons learned. No opportunity for post implementation reviews with the stakeholders. Project knowledge is not extracted and learned from. Our eyes are always focused on where we are going; never where we have been. We'd never consider driving our automobiles without rearview mirrors, and yet we seem to always drive our projects that way.

In a perfect world, we would do the kind of post-project assessment that we know we should. In theory, we recognize that it is the projects down the road that benefit from these lessons. So, why don't we execute lessons learned more often?

Time. It is legal tender in its own right. It's a time-to-market issue, we say. There's money to be made. We have no time to look back; we have another roadrunner to chase! Deeper still, many of us use the excuse of time to cover up the bigger excuse. Fear. Modern business doesn't always encourage shining the light on those dark, shadowy corners of our projects. Admitting to inadequacies of weak estimates, non-existent risk planning, and poor requirements gathering would be sabotage to our egos, our organizational self-image of invincibility.

But, our responsibility as project managers goes deeper than just the organizational lessons learned; it also needs to occur at the individual level. If we are truly to call ourselves professionals of the project management discipline we must be committed to taking a personal inventory of ourselves; we must consider our weaknesses and strengths before we can maximize that knowledge to benefit us on the next project.

And, since it's always easier to point the finger of evaluation at someone else, let's consider a project manager not unlike ourselves—Wile E. Coyote. Certainly, he had a clear goal—to catch the roadrunner. And, he undertook many projects to achieve this objective. All of them were miserable failures by most standards. We can learn from Wile E.‘s lessons. Let's take a look at a few things Wile E. might have written in his project memoirs as lessons learned and how we might find value for ourselves.

Lesson One

“Executing my projects without a risk plan is just too risky. Risk management protects the interests of my project as well as the financial impacts of failure to the business.”

It's startling to realize just how many projects are executed without risk plans. Perhaps this is one of the critical reasons that so few IT projects ever succeed. The interesting thing about risk management is this—in our individual lives we are excellent risk managers. How many of us would consider leaving our homes without the appropriate car, property, health, and life insurance? How often have we evaluated the risks of traffic when taking the highway versus the back roads? How many times have we considered the risk impact of indigestion when choosing the Grande Tex-Mex Burrito with extra jalapeno sauce over the Grilled Chicken Salad? We are planning for risk everyday of our lives.

And, then something happens as we leave our cars and buses each morning to enter the front door of our offices. Suddenly, the common sense of our personal lives doesn't always cross over into the territory of the professional arena. The common sense of good risk planning often waits there outside the front door until it's time for us to end the workday, and then we carry it home with us as we weigh again the risk of traffic jams and other such nefarious possibilities.

There's actually a reason, dare I say excuse, why risk planning gets forgotten in the project plan. It's because the customer never sets an expectation that would require us to do one. Our planning is driven less by what we know is right for the project and more by what our customers are looking at. Consider this. Generally, our customers are concerned with three basic questions:

“What am I getting, when do I get it, and how much is it going to cost me?”

These are the basis for what we know to be the triple constraints. We take the time to plan for these things because we know that the customer requires the answers to these questions. However, too many project teams have falsely believed that they have successfully completed project planning once the scope has been defined, the schedule built, and the costs estimated. As is so often the case, project planning stops here and project execution begins because it is believed the plan is complete. Do we truly have a robust plan? Probably not. And, the Coyote himself demonstrates this point brilliantly. Let's bring the theory of the triple constraints to bear on his projects and ask some questions.

1. Did he plan for scope, his deliverables in the project? Yes, he did. Whether it was a stick of dynamite under a pile of free birdseed or a biplane with a large, red rocket strapped to it, Coyote very much understood his scope, both the final deliverables he would need and those expendable deliverables that would help him create the final solution.

2. Did he plan for time? Absolutely. He always had a detailed schedule planned of how he would execute events just before the roadrunner's arrival.

3. And, did he plan for cost? We can only assume that to be the case since ACME seemed to stay in business for this one, dependable customer and his continuous stream of projects.

So, all could agree that Coyote had some sort of planning around scope, time and cost, but he forgot the critical protection that he would need to insure his plan could be successful. Risk management—anticipating uncertainty and planning for it. Sometimes, the uncertainty isn't all that uncertain, either. Take the example of Coyote's vendor, ACME. Their continuing poor quality didn't require brain surgery to figure out that choosing ACME again was a high risk to the project. Still, Coyote chose to stick his head in the sand.

It's perhaps one of the most difficult things that you will ask for as you work with your team in planning for the project. Most people shy away from looking at what could go wrong, more than happy to stick their heads in the sand and hope it goes away.“That's negative thinking,” one team member says. “We finally have a plan we can all live with so let's not mess with it,” chimes another. The list of excuses is endless.

Project managers who give in to the team's tendency to avoid risk planning rely on good luck—that's not enough. The absence of solid risk planning results in constant fire fighting and an abundance of open items outstanding on your project's issues log. Project managers have an obligation to make the appropriate expectation for risk planning.

It's problem enough to get others to buy into the idea of donning the black thinking caps to plan for risk at the beginning of a project, it's more difficult to instill the expectation to the team that risk planning happens throughout the project life. That's important. Stated again:

Risk planning must occur throughout the project life—at the beginning, during execution, and through to completion.

A risk plan should never be created and then put on a shelf where it collects dust. Risks are dynamic entities requiring a project team to engage in risk management dynamically. Take the time to consider how much protection you are providing to your own project plans.

Lesson Two

“Project failure—it's not personal. Or, is it?”

Most project managers would agree with the analogy of an invisible umbilical cord attached between themselves and their projects. Sometimes it is difficult to distinguish where we stop and where our projects start. It becomes who we are. Because of this, we tend to see a relationship between our own self-worth (how we value ourselves) and our project's self-worth (how our project is viewed in terms of success and importance).

For the Coyote there was complete separation of self-worth and project-worth. The only advantage this separation provided him was that he never let project failure keep him from trying again. He was the model of persistence. And, he never allowed disaster to affect his opinion of himself. This extreme may have made him diligent, however, it also made him too tolerant of possible project failure.

At the other end of the spectrum is the project manager whose self-worth is too dependent upon the project-worth. If the project is succeeding, his opinion of himself improves. If the project is struggling, so is his ego. It's easy to fall into this mindset. When projects become too personal then fear sets in. Fear can become too strong of an influence in decisions and actions throughout the course of the project. It injures the ability to:

1. Communicate the bad news that needs to be told

2. Remove emotion from the facts when problems arise

3. Interact with the team objectively

4. Objectively evaluate the continuing alignment of project and corporate strategy

5. Consistently provide support to project stakeholders

6. Maintain flexibility and resilience in the face of change

7. Expedite decisions for the project

Neither extreme serves the needs of the project. Instead, a balance must be found between the two. Understanding that though there can be some connection between the success of a project and how it relates to your success as a project manager, some things are completely out of your control. Finding a healthy interdependence between self-worth and project-worth is critical if we are going to make the tough decisions and communicate honestly with other stakeholders in the project.

Lesson Three

“Not reacting to change in a prompt, consistent manner only finds me in the shadow of a falling boulder. I need to set better expectations for responding to change and implement procedure consistently.”

Change. It's a fact of life. Organizations who want to survive for the long haul understand that they must stay fluid and responsive to change. Projects themselves exist for the sole purpose of bringing about change helping organizations become more productive, efficient, and competitive. Projects are vehicles for change. And, projects are influenced by change. As the project manager, it is important to be aware of this and what it means as we do our jobs.

When aligned correctly, projects come together to complete larger programs. These larger programs fulfill strategic initiatives put into place to keep an organization headed in the right direction—to arrive to its vision. Whether the project is to assist in creating a new product, improving customer service, or staying in alignment with governmental regulations—all projects exist for a good greater than its own.

Because the speed of change in business is so rapid in today's world, a project that began in alignment with corporate strategy always has the possibility of becoming inappropriate, unnecessary, or lower on the totem pole of priority. Good project management understands this and always evaluates that alignment. It certainly doesn't foster job security in the short term, however one role of a PM is to stay in tune with not just the project goals but also the corporate good and how we serve it.

In Coyote's case, we can parallel the corporate vision to his overall goal—survival. For him, survival was satisfied though a strategy called catching dinner. Though at one time “Project Roadrunner” may have been in alignment with this need to eat, this ongoing program of implementing one project plan after another began to fall away from the strategy. The program became more about winning and less about eating. And, perhaps another project could have been undertaken to achieve a satisfying meal.

Even as we are watching the changes outside of the project to ensure that we are staying aligned we are watching those changes that are occurring within the project. People changes, changes to schedule, changes to budget, changes to vendor relationships. And, then there is the dreaded change all project managers face— scope change. Our challenge as we maneuver through this change is to understand that it is a natural circumstance of projects and maintain an amount of flexibility within those changes.

It can be difficult to accept change within the project plan after blood, sweat, and tears have been lost over preparing it. We don't like to change the way we envisioned it should be back when we first began meeting as a team to discuss how to do the job. Yet, project plans are living, breathing entities. It is in their nature to evolve as time goes on.

In particular, scope change is one of the most difficult of changes that a project manager must face. Most people cringe at the mention of it. For project managers, we first must accept the fact that projects, as change devices, encourage our clients to consider new or additional changes, and thus scope change occurs.

Second, though we must be flexible about how we view change, we must have structure in terms of how we implement change. A structured, documented process for scope change must be introduced to the customer at the beginning of the project. And, it must be used consistently and diligently throughout the entire course of the project if scope change is to be managed for the good of the customer. For Coyote, scope creep became a financial and schedule disaster. For us, it can be just as costly. So, project managers must:

1. Accept that change will always exist.

2. Remain flexible to change.

3. Remain structured in how he evaluates and implements change.

Lesson Four

“The obvious may not always be the answer. Too often I made the false assumption that my expertise was flawless.”

The Coyote had a very good opinion of himself, and it was somewhat justified. He was extremely creative, bright to a fault, and dedicated to his task. This level of intelligence and skill gave him significant advantages over the average Joe-coyote, right? In fact, it may have hindered him. It's very easy to become so much the authority that we allow that expertise to lure us into a cocoon of perception about the way things are. If the world was made up of only one person, this cocoon could be a productive place. However, in the world our project exists in, there are many more influences. The cocoon is dangerous.

There is a story of a group of engineers who were called to the scene of a large truck that had attempted to drive under a bridge where there was no clearance. The truck had become wedged under the bridge creating a major traffic backup. For a considerable amount of time the engineers struggled with ways to clear the truck. Brainstorming proceeded, but none of the engineers could come up with a remedy that would be expedient. Traffic continued to build on the road as there was no way to route the cars around the truck.

A five-year-old girl who sat in the backseat of her parents’ car watched the situation ahead in anticipation. She was on her way to a carnival and becoming more impatient. She rolled down the window of her door and leaned out to yell to the engineers. Only one of the engineers took any notice of her. He walked over to her and asked her what she had said. She repeated the suggestion. “Why don't you try letting the air out of the tires?” It worked. And, the advice came from a little girl who didn't have the “expertise” to fix the problem.

Too often, our own perception can keep us from seeing opportunities and ideas from different angles, from larger perspectives. One of our responsibilities as a project manager is to seek evaluation of our choices and those of the team. This can come in the form of outside consulting, benchmarking, and even the simple critical eye of someone else in your organization who may have a more objective view of your project.

In the case of the Coyote, perhaps a peer review from average Joe-coyote would have provided him with a more effective way to achieve his dinner. The lesson for us as project managers is to seek out the advice of other project managers, peers we trust, to review what we've planned and implemented and to bring a critical eye not just to how the project is being executed but also to how we are executing our role as the project manager.

Lesson Five

“I am persistent fellow committed to never doing the same wrong thing twice, but maybe I need to take a formal approach to reviewing my success and failure.”

In the book Who Moved My Cheese the authors illustrate that people have a tendency to expect that the same actions will produce something different. We all have heard the joke that the definition of insanity is doing the same thing over and over while each time expecting a different result. We could say that the Coyote was smart enough to learn from design flaws and try something new. If only he could have learned to approach his lessons learned more formally. If only we all could only learn to do a better job of that.

Reflection is a necessary part of learning, and our responsibility is to set an expectation for project lessons learned and to execute capturing this information. Additionally, we must be committed to a review of ourselves as project managers so we can continue to grow and mature in our discipline. We must regularly evaluate the job that we are doing and how we might improve our knowledge, implementation of sound methodology, and interpersonal skills.

It's easy to fall prey to the standard arguments that there isn't enough time, there's too much on our plate, or it is inconvenient. All these are probably true statements for most of us as project managers. Yet, the most successful, creative individuals commit to a process of self-evaluation and continuing development.

Lessons learned for the project manager happens throughout the project life as well as at the end of the project. I encourage you to consider your strengths and weaknesses yourself. Additionally, ask for the input of two or three others you have worked with who will provide you honest feedback.

Some good questions to consider asking yourself and others are:

1. What are my strengths/weaknesses as I did my job in this phase/project?

2. What accomplishment am I most proud of?

3. What situation presented the greatest challenge to me?

4. Did I manage the project in an integrated way (e.g., did I manage time, cost, quality, scope, risk, communications, procurement, and human resources in a way that served the project)?

5. What skill do I need to improve?

6. Where do I need to improve my knowledge?

7. Did I perform equally well in terms of people and performance? Which area is my weaker area? What can I do to improve?

Acknowledge yourself for what you do well. Then, take inventory of what you don't and put together a plan of action for how you will incorporate changes to strengthen you. Develop a set of goals to make improvements as you move to the next phase or on to the next project. Review your goals to make sure you are staying on track. Project management is a rewarding discipline—one that requires us to be diligent and committed to continual growth as a professional. It is through this growth that we can be a strong force for the projects that we serve.

LOONEY TUNES characters, names and all related indicia are trademarks of Warner Bros. ©2000

References and Suggested Reading

Harrington, H. James, Darly R. Conner, and Nicholas L. Horney. 2000. Project Change Management. New York. McGraw-Hill.

Johnson, Spencer. 1998. Who Moved My Cheese? New York: G.P. Putnam's Sons.

Lientz, Bennet P., and Kathryn P. Pea. 1998. Project Management for the 21st Century, 2nd Edition. San Diego, CA. Academic Press.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA

Advertisement

Advertisement

Related Content

Advertisement