There is a signpost up ahead

recognizing and dealing with project warning signs

This article is copyrighted material and has been reproduced with the permission of Project Management Institute, Inc. Unauthorized reproduction of this material is strictly prohibited.

Introduction

In 1984, after spending fourteen years and $140 million dollars, RCA declared its Selecta Vision product a failure and abandoned the marketplace. Yet, throughout those fourteen years there were numerous and clear signs that warned the engineers at RCA that they had a failure on their hands. But they ignored them. As a result, they consumed fourteen years of engineering research and a staggering amount of money, time and money that could have been spent on other, more profitable, projects. What about your organization? Are you currently working on a project whose warning signs are being ignored? Do you even know what those warning signs are? In this presentation, I will discuss the nature of warning signs, and the five key categories of warning signs that successful companies use to help avoid failure. Moreover, I will discuss when to conduct project health checks, and what to do with the results of such reviews.

The Nature of Warning Signs

We see warning signs every day. They are all around us. “Wet paint,” “Road Ends in Water,” “Caution Radiation Area” (with that familiar radioactive logo),” “Fire Danger” (with a big picture of that American icon Smokey the Bear standing next to it). Such easily recognizable signs are common reminders that we need to be careful, we need to “watch out,” we need, in fact, to make a change in our current behavior or suffer the consequences of our actions. And, the earlier we heed their advice, the better off we’ll be because time is a resource when it comes to dealing with warning signs. Here’s an example.

I often ask an audience to identify the telltale signs of heart trouble. Most people respond by saying one or more of the following:

  • Numbness or pain in the left arm
  • A crushing or pressing sensation in the chest
  • Pains in the chest
  • Difficulty in breathing
  • Lightheadedness

And, they’re right. These are the classic symptoms of heart trouble. However, by the time an individual experiences these unfortunate symptoms, they should be calling “911” because they are in serious trouble. Although they are in fact warning signs, these signs come very late, and in too many cases they leave no time for action. The American Heart Association has found that the first sign of heart trouble for 33% of the people suffering such problems is instant death.

Signs of heart problems we should be looking for include any or all of the following:

  • High blood pressure
  • Increased “bad” cholesterol levels
  • Obesity
  • Smoking
  • Sedentary lifestyle
  • Family history of heart problems.

These, too, are warning signs, yet they are “early” warning signs because they provide us with the gift of time to change our behavior to affect our future. So it is with projects.

Many people say that the first sign of trouble with a project is scope change. I disagree. By the time the scope has changed, your well on your way down the inevitable slippery slope of scope creep. Yes, you can bring the project under control, but it’s a lot easier to make directional changes to a project standing on top of the slope and not when you’re sliding down it! For anyone who has ever been brave enough to strap on a pair of skis and look down at what appears to be a cliff knows that they must chose their direction at the top of the slope rather than simply proceed and try to pick the best path as they’re careening down the hill at 30 miles per hour (or what feels like 90 m.p.h.!).

In reality, the first sign of scope problems occurs when we realize that the requirements have not been well defined, that a project requirements document does not exist, that many or all of the project stakeholders have not been interviewed, or that the project has no business case. Lacking these aforementioned deliverables and actions, we are given a warning that problems can and probably will occur. Without an adequate scope document, the project becomes an amorphous mass of energy headed into the future, or in the words of jet pilots, all speed and no vector. Such a situation, I think you would agree, spells trouble.

Warning signs, then, are about the future, and the sooner you know about the future the more time you have to change it. So, how do you change the future? People have been trying for years, thousands of years in fact. Here are some examples: crystal balls, Ouija boards, Tarot cards, Palm reading, Psychic Friends Network, and many other questionable, albeit entertaining, methods. I’d be surprised if any of you reading this article right now would ever resort to using such quackery and pseudo-science, and if you would, please remind me never to have you run a project for me!

Here’s our quandary. If warning signs are about the future, and we cannot see the future, then how do project managers and organizations do it? How do they see their “project future”? The answer is simple: they look into their individual and collective pasts and attempt to estimate what problems they might encounter on their current project based on past, similar projects. It’s not foolproof but until someone comes along with the uncanny ability to actually see the future, and there have been many charlatans that have claimed to have that skill (Edgar Cayce, Karnack the Magnificent to name a couple), it’s the best method we mere mortals have.

Many of ESI’s clients have developed mechanisms to “help” their project managers avoid future problems. Such mechanisms manifest themselves in tools, procedures, or processes and come in a variety of names. Here are four I have encountered in my work:

  • Project health checks
  • Risk reviews
  • Project reviews
  • Project audits (my least favorite name)

Regardless of the name that is given, the purpose of each of these is to allow the project manager, team members, and others to take a quick look at the project to see how things are going, in short, to see if things are “on track.” Such an approach is akin to scanning the dashboard in your car while driving, or an instrument panel in a jet’s cockpit, or the dials and levers in the control room of a nuclear power plant (get the picture?) to make sure things are in control, and that there’s nothing in the “red zone.” Let’s take a closer look at the concept of a Project Health Check, my favorite name for identifying and dealing with warning signs.

Project Health Checks

Following, I will discuss the three areas of importance as regards this increasingly popular and proven approach:

  • What warning signs do we look for?
  • How should we conduct the “exam”?
  • What do we do with the results?

What warning signs do we look for?

There are many, many lists of warning signs available to project managers. If you do a search on “project warning signs” on your favorite search engine, you’ll find numerous and myriad approaches to the topic. One of the best sites I encountered was from the Tasmanian government (2003). It’s loaded with interesting information.

I assert that we have more than enough information on project warning signs to create a list that would go to the moon and back. It’s not the quantity of the items on the list; it’s the quality of what’s on the list that makes the difference. What we really need is how we should approach warning signs based on our project, organization, and customer. Sure, reading others’ list of warning signs can help us, but the best list of signs is the one we create ourselves for our specific needs.

Below I list five broad categories of warning signs to help you get started to create your own list. I have chosen these five because they are common across a number of ESI’s clients who are very successful in using health checks to ferret out problems. As such, these five categories represent the best of what the best do. You now have the beginning of a very solid set of warning signs to look for. These categories are:

  • Project control
  • Compliance
  • Business case validation
  • Risk issues
  • The “Human” factor

I will discuss each one briefly.

Project Control

Our clients are constantly looking at the schedule, cost, quality, and resource usage of their projects. It’s classic project management and it is indeed important. But in my mind it’s only the tip of the project “iceberg.” When your sponsor asks you how much money has been spent, they’re asking you about the past. Yes, the past. It’s money that’s been spent. You can’t change that fact. Notwithstanding George Santayana’s oft-quoted stanza, knowing what you’ve spent is really not that good of a warning sign because it’s historical information. Although this information is useful, what is more important is what we will spend in the next day, week, or month. In other words what is the project’s “burn rate”? This is the concept of the early warning sign I discussed earlier. If we know the burn rate we can estimate what our costs will be, and we can change that by making certain resource decisions now to create, or at least shape, our future.

Thinking of it from another perspective, let’s return to the iceberg as an example. The flow of an iceberg is predicated on two physical forces: wind and current. And we all learned by the fourth grade that there’s more ice under the water than above it; therefore, current will have more affect on the movement of an iceberg than the wind. In our project, knowing what we spent is the wind, but knowing what we will spend is the current. Therefore, it’s what you don’t see that is really moving your project.

Compliance

Project managers worldwide are an independent group of people. They like to give orders not take them. Consequently, they don’t like being told what to do or how to do it. That’s why many organizations struggle when introducing a project management methodology. Yet, we know that certain practices will have a beneficial affect on our project, and we also know that we need a consistent approach to practicing project management across an organization. Otherwise, everyone will be going off in his or her own direction and doing what he or she thinks is best. That’s a crapshoot. If you want to gamble go to Las Vegas.

If you’re a two-person shop doing web development and living in a cool loft in Soho, you don’t need a methodology. If, on the other hand, you are Rene Speitel, Vice President of the Worldwide Engagement PMO for HP Services (and one of ESI’s long term clients), with thousands of projects underway at any one time, you know that a methodology is extremely important because a methodology:

  • Promotes consistency across all geographies
  • Embodies best practices which helps PMs in their work
  • Improves productivity and efficiency of the project managers and the organization as a whole
  • Improves communication because everyone is speaking the same “language”

Designing, developing and implementing a project management methodology is a significant investment of an organization’s time and resources. The organization has a right to receive a return on that investment. Asking questions concerning the use of the methodology is an extremely important part of health checks and companies such as HP Services do it because they want to ensure that their project managers are using the best practices that HP has learned over many years of experience. In fact, by doing so, HP Services is ensuring that their clients’ are getting the best level of project management available. Does your company do that?

Validating the business case

Projects are done for many reasons. Here are some examples:

  • Increase customer satisfaction
  • Enhance efficiencies
  • Avoid costs
  • Increase revenue
  • Bring new products to market

In many corporations today, and in particular the IT industry, projects are not getting approved unless they can prove that there will be a substantial return on investment (by however way the ROI is determined in an organization). Simply stated, there’s not enough money to go around to support all projects; therefore, organizations are taking a much harder look at which projects will have the best return to the corporation. Those are the projects that get funded; however, they don’t stop the scrutiny at that point. After a project is launched they continually check to determine if the project will meet its business case objectives.

This laser-like focus on project benefits means that the business case is being validated during project execution. No longer is it enough to build a business case for a project, complete the project, and then check to see if the project achieved its objectives. Rather, the best corporations are looking at benefits management during project execution and killing those projects that won’t make their investment objectives. But killing projects is hard, and in some organizations downright impossible as was the case with the RCA Selecta Vision. Here’s a brief, and tortured, history of this project.

1970—RCA announces that it will develop the Selecta Vision player. Experts in the field questioned the use of videodisk technology.

1977—RCA launches the first prototype even after all its competitors have abandoned videodisk research citing the quality and increasing popularity of VCRs.

1980—RCA introduces the Selecta Vision to tepid consumer response.

1984—RCA abandons the product citing poor sales.

You might be asking yourself “What were they thinking?” Why did the engineers and managers of RCA press forward in the face of all the warning signs to develop and launch this product? According to Isabelle Royer, in her interesting article “Why Bad Projects are Hard to Kill” (2003), it was because of a “collective belief system” at RCA. The engineers were so convinced that they had a successful product they were incapable of processing any information to the contrary. Succinctly stated, they fell in love with their project. As we all know, love is blind!

Had the Selecta Vision project had been subject to regular and rigorous health checks, and had those health checks included a focus on business case validation conducted by people not related to the project, RCA might have been spared the staggering losses it incurred. What’s going on in your company right now? Are you working on your company’s version of the Selecta Vision?

Risk Issues

To many of our clients, project management is risk management and vice versa; there’s no difference between the two. Accordingly, their health checks always include a focus on project risk. They look at the following for each project under review:

  • Risk management process
  • Risk management plan
  • Top ten risks
  • Issue management practices

As I mentioned earlier, many of ESI’s clients call their process of evaluation Risk Reviews; that’s how important the topic is with them.

The “Human” Factor

Project management is a team sport. In the classic description of project management, the project manager perceives himself much like Ptolemy perceived the earth, to wit: the center of the-project-universe. Accordingly, the project manager needs to be concerned about the relationships between and among the various project stakeholders. Without solid working relationships between and among those players, the project’s chances of success is questionable.

Therefore, the successful project manager will always keep his/her pulse on the relationships in the project. In any health check, those relationships need to be evaluated to ensure that the team is headed in the right direction and that the appropriate stakeholders are being kept informed. Project health checks look at how the team is functioning, if the sponsor remains committed, if the client is satisfied with the team’s work, and any other human factor that could adversely impact the project.

The issue for project managers is to remain constantly alert for any possible disruption of the relationships. This can be difficult for a person whose normal inclination is to be “task based” not “relationship oriented” as so many project managers tend to be. Relationships of any kind, whether they be personal or professional need constant nurturing and the good project managers know that and devote a significant amount of time to it.

Now that we know what to look for, here are some ideas for conducting the health checks.

Conducting the “exam”

For small projects the project manager, along with the team, should conduct the exam. And, actually, this is quite simple because I have noticed through the years that the good project managers conduct these exams 24 hours a day, seven days a week in their heads! They’re always looking out for what could go wrong. The value however, in conducting an “official” health check is two-fold. First, no matter how good or experienced a project manager is, the old and trusted concept of “two heads are better than one” certainly applies to this process. There is no way that any project manager can think of all the issues all the time. Therefore, the team members are crucial to the process of uncovering issues with the project. Second, if you do something in your head, you’re bound to miss an important point. By formalizing the process using checklists and or other documentation ensures that you’re covering all bases.

Project managers tend to become very passionate and emotionally invested in their projects. For large projects, with a great deal of money at stake, as well as the reputation of the project manager, it is important that an impartial review be conducted. One of the greatest assets a project manager brings to the job is a “can do” attitude. Project managers tend to be action leaders. As such, their view of the world tends to be that they can and will accomplish the goal laid out for them. The downside of this enviable trait is that they sometimes can’t recognize when things are going badly, or they do not appreciate just how bad things really are. They are convinced that with a little extra effort the job can get done. And, most of the time they’re right; however, as in the case of the Selecta Vision project, they produced the product; sadly, the product was not something that people wanted.

By having an independent review the organization will mitigate this “can do” spirit, and the associated rosy picture scenarios such individuals tend to describe, by having people who have no emotional stake in the outcome review the progress of the project. One client of ESI’s conducts such independent reviews where the central question is always “should we kill this project?” They have a fail-fast mentality because their projects are so long and so expensive that they want to ensure they’re investing in the product with the best ROI. The next time you conduct a review, start with the question “should we kill this project”? I’m sure a few eyebrows around the conference room table (or cube) will be raised. Many organizations would be much better off if they asked this question more frequently.

As regards the timing of health checks there are two basic approaches used by our clients: a schedule- driven system and an event-driven model. In a schedule-driven model, the health check is conducted according to a set schedule. So, for example, large projects are reviewed quarterly whereby smaller projects are done monthly. An event-driven schedule is usually done for large projects that take more than a year to complete. In my experience, certain product development projects are reviewed using this approach. An event could be anything that is of particular importance to the organization; however, an event is typically defined as the beginning or end of a major project phase.

I favor a schedule-driven approach. They tend to be done more frequently, and everyone knows exactly when the review is to be conducted. Events, or major milestones in large projects are oftentimes many months apart. A lot can go wrong in that time period, and as odd as it sounds, it is not altogether clear in certain circumstances when the event actually occurs. It’s easy to schedule reviews based on a calendar. After all, a date certain is a date certain. The same cannot be said for an event. Regardless of which approach you use, the key is to conduct the exam when you say you’re going to. Consistency is imperative. People will know you’re serious about the business if you follow through on your own dictates.

What do we do with the results?

Any health checks, whether it is for a small or large project results in two things: findings and action items. This is very valuable information that must be distributed to interested parties. But who are those parties? Here’s a list of people that need to receive this information:

  • Project Manager
  • Team members
  • Sponsor
  • Steering committee
  • Product portfolio committee

This might sound very logical to you. However, oftentimes, our sense of pride, or fear of failure (or being perceived as a failure), will cause project managers or sponsors to limit the distribution of the findings. In Eastern cultures the term is “save face;” in Western cultures we’re concerned with not being embarrassed or humiliated. I’m not suggesting that the findings from a health check should be put in a press release and distributed to the world! I’ve managed plenty of projects myself and I sure would not have wanted that to happen. However, this information does need to be reported to someone of accountability outside the team. We all need and benefit from the type of “reality check” such a process promotes.

As regards the findings and the action items, it is the action items that need our foremost attention. After all, the findings are a statement of the past, and we cannot change that. The action items on the other hand, provide us with an opportunity to change our future. Accordingly these items must get logged into the project system, added to the WBS and project schedule, assigned to a responsible party, and tracked. If these steps are not done the value of the health check is severely diminished. Additionally, these action items form the first agenda item on the subsequent health check.

Final Thoughts

A system of identifying and acting upon early warning signs is as crucial to successful project management as understanding how to build a WBS or negotiate for team members. Yet, in too many instances organizations have not formalized this critical activity, or otherwise rely on the individual to develop his or her own process. Look at your current project: do you have a series of warning signs that you’re looking for? Are they early warning signs? Are you reviewing your project with others on a regular basis? If you cannot answer yes to all these questions, you are not maximizing the value of your team members, and you are certainly not engaging in a process found valuable by some of the best practitioners of project management with whom we work at ESI. If you’re in the business of managing projects, why not bring to bear the best methods available? After all, your success, and the success of your organization, depends on it.

Project Management - Tasmanian State Government. Retrieved from: http://www.projectmanagement.tas.gov.au/

Royer, I. (2003, February) Why bad projects are hard to kill, Harvard Business Review, 81(2), 48-57.

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 PMI® Global Congress 2003 – North America
Baltimore, Maryland, USA ● 20-23 September 2003

Advertisement

Advertisement

Related Content

  • PM Network

    Rookie Revelations member content locked

    PM Network asks the project management community to share their mistakes made at the beginning of their careers.

  • PM Network

    Interior Motives member content locked

    By Wenger, Fred Project managers are accustomed to looking outside their projects for risks—at competitors, clients, suppliers, the economy, even the weather. But experience has taught me that all projects face a…

  • PM Network

    New Digs member content locked

    By Waity, C. J. Ore deposits are hardly the only factor project leaders use to determine future mining sites in Latin America. Everything from geopolitical turmoil to local labor markets can impact a mining…

  • PM Network

    Past Is Prologue member content locked

    By Hendershot, Steve Organizations can't escape the past when they pump money into tech upgrades. Before they start rolling out cool new tech, project teams need to identify and mitigate the risk of putting fancy new…

  • PM Network

    Bank Breach member content locked

    Dankse Bank A/S came under scrutiny for failing to prevent suspected money laundering at its Estonian branch, and a shelved IT project may be to blame.

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.