Managing Projects in Trouble

Achieving Turnaround and Success

PMP, Ralph L. Kliem

• Publisher: Auerbach Publications
• Year: 2016
• eBook ISBN: 9781466508033
• Topic: Computer Science
• Subtopic: Project Management
• Index: Computer Science

Whether you use budget, schedule, quality, or other criteria, the statistics by think tanks, institutes, associations, and other trade organizations all point to one inescapable conclusion: your project has a greater chance of getting into trouble than staying out of it.Based on the lessons learned by the author during a quarter of a century of lea

1

Introduction

Think about this scenario. You’ve just been assigned as the project manager of a project that has the reputation of being an unmitigated disaster. Management does not want to cancel the project. So, the big question is, what do you do?

If you’re like most people, you’re standing still like a deer in the middle of the road and staring right into the headlights of an oncoming vehicle. The choices are to stay put or flee. Either way, the results are not good. Stay, and you become roadkill. Run away, and you may get hit by another oncoming vehicle in the other lane, fall off a cliff, or get eaten by wolves.

So, you are faced with a dilemma. Stay put or run? Many people decide to run. They take their chances by putting together a resume and hope for the best elsewhere. A few decide to stay put and face another existential decision: allow themselves to become victims or take action.

What would be your decision?

1.1 What You’ll Learn

In this book, you will learn to take action in a way that will increase the likelihood of success and minimize the possibility of failure for you and your project.

Specifically, you will be able to

• Recognize the symptoms of troubled projects.
• Make the necessary changes to turn around projects in trouble.
• Revisit a project’s vision, and develop a new or revised vision.
• Look at all the options to turn a project into reality.
• Choose the most appropriate option.
• Execute the new or revised vision.

1.2 The Odds Are Against You

The odds are high that you already have inherited or will inherit a project in trouble. The studies substantiating this fact are quite numerous and plentiful. That’s often because the conditions—despite the advancements in project management—are conducive to project failure.

Whether you use budget, schedule, quality, or some other criterion, the statistics by think tanks, institutes, associations, and other trade organizations all point to one inescapable conclusion: A project has a greater chance of getting into trouble than staying out of it.

The context of a project can be quite complicated. The interplay of a host of variables can influence a project’s outcome.

Strategic objectives, corporate values, team mores, management styles, policies, methods, tool availability, team member attitudes, and expertise are just a few of the contextual factors that can affect the state of a project.

Projects in general and project managers in particular face many pressures, too. These pressures can originate from various levels and organizations that a project must deal with throughout its life cycle. This includes politics, reviews and approvals, legal compliance, marketing environment, procurement sources, and much more.

On top of all that, projects must deal with issues on an increasingly larger scale in terms of size and complexity. These issues include outsourcing, virtual teaming, globalization, and compliance.

The conclusion? The chances of a project getting into trouble keep increasing. It seems every solution brings with it a greater level of complexity, which project managers will have to handle. With this greater level of complexity comes the correspondingly greater chances for projects and their project managers to get into trouble.

1.3 Symptoms To Look For

Despite the odds, many managers and project managers seem oblivious to the symptoms of troubled projects. These symptoms are quite ubiquitous and obvious, yet many choose to ignore and not address them.

1.3.1 Poorly Defined and Managed Scope and Requirements

It is amazing how many projects are initiated without an understanding of what it is all about. Instead, the project takes off like an airplane without a destination. Gradually, it evolves into something whose end result not even the key people understand. Ask a simple question such as, what are the project’s goals and objectives? What is in and out of scope? What are the specific requirements that the project must address? The chances are negligible that anyone will be able to give you a direct answer to such questions; in all probability, they will take umbrage at you for asking them such questions in the first place.

1.3.2 Lack of Involvement and Buy-In of Key Stakeholders

Many projects pop up out of nowhere. They are like atolls in the middle of the Pacific; they have very few, if any, “inhabitants”; they lie low, and nobody wants to go to them.

For example, it is amazing how many projects exist under the assumption that “if you build it they will come.” Take a typical large project involving millions of dollars. Ask a simple question such as “Who is the customer?” and don’t be surprised if you get a perplexed look or incoherent mumbling. Granted, sometimes projects are so complex that there are many different types of customers. But customers must be identified, to give you an idea of whose needs you need to satisfy so as to be able to define them. Sometimes, to add another level of complexity and confusion, the person or organization you think is the customer is not really the customer, and the real answer emerges after the product or service has been delivered and, frequently, not in a positive way.

Now take this line of thinking one step further, and you’ll likely find that the people or organizations you thought were interested in the project are, in truth, not interested. They may have attended meetings, but the reality is that they are socialites who are everyone’s favorite houseguests; nobody knows why they show up at meetings. Or they claim they represent a key stakeholder but have absolutely no substantive background about the person or organization they represent.

1.3.3 Lack of Detail and Realism in the Project Plan

Many projects in trouble have a plan, or something that existing participants call a plan. More often than not, the plan has a few milestones with a sizable percentage of them marked TBD, To Be Determined. Coupled with this is a lack of detail or realistic analysis of how the milestone was determined other than some high-level executive or manager licking the tip of his or her finger and plucking a milestone date out of midair. Just about everyone shakes their heads like bobbleheads with the hope that the project will or that they can find another opportunity elsewhere.

Often, the history and assumptions behind the schedule are known only to a few. If some people leave, then what often happens is that the schedule either gets ignored or it does not give a true picture of what is happening; either way, the schedule is of no use to anyone.

1.3.4 Negative Conflicts Among Team Members and Poor Morale

One of the key signs of projects in trouble is the dynamics among the team members and their relationships with other stakeholders. In just about any project facing difficulties—whatever the reasons—the quality of the relationships is key. Just a few toxic relationships can affect the entire performance of a project, have harmful effects on people and, consequently, degrade the overall results achieved.

Toxic personalities and their relationships with others are perhaps the most difficult part of turning around a project in trouble. Too many of them are allowed to continue out of fear, denial, and legal concerns. Yet, it is often more costly to not deal with these personalities and their relationships than to take them head-on.

Their impact is undeniable. These people inhibit thinking and communications. Morale sinks. Teaming fails. Sabotage can occur, and anger may lurk below the surface, waiting to erupt at any moment.

It is certain that the most significant contributors to poor project performance are related to this scenario. Constrained resources, compressed schedules, shifting priorities, and countless other situations may cause conflict, but they are just enablers that toxic personalities capitalize on. The history of projects is replete with examples in which constrained resources and compressed timetables seemed insurmountable and yet the teams still succeeded. History is also replete with project teams that enjoyed every conceivable advantage, but where toxic team members and relationships contributed immensely to project failure.

1.3.5 Ill-Defined Assumptions and Expectations

Assumptions are nothing more than facts assumed to be real or imagined. Expectations are what people assume will be the results of their efforts. Amazingly, projects large and small alike operate on assumptions and expectations that few people even question, document, or articulate. Many projects get into trouble because key stakeholders never question their assumptions or the expectations of others. Instead, many projects chug along with everyone thinking that everything is fine until something “hits the fan”—and it isn’t air. For example, few projects start off with a listing of assumptions that serve as the basis for making key decisions and developing plans. Few project managers make any effort to identify success criteria for the customer. The result is often high rework and recovery costs, which not only increase overhead costs but also eat up the managerial gains anticipated for the project in the first place.

There are many reasons why projects proceed without a common understanding, let alone questioning of expectations. Some people simply go along with the flow. Others prefer to operate in a veil of ignorance. Still others are there for their paycheck. Others just want to avoid the pain of asking about it in the first place. After a while, the assumptions and expectations are treated as a given until the very end, when the results of the projects demonstrate that the assumptions were incorrect and the expectations (if they exist at all) are unrealistic.

1.3.6 Lack of People with the Necessary Attributes

Many projects in trouble have people with the necessary skills. Other projects have people who lack the necessary hard and soft skills.

Some people may have all the hard skills, for example, programming or data modeling expertise, but lack the soft ones to do the job, for example, effective listening, looking at different perspectives, etc. Or a person can have great soft skills but lack the expertise to do the necessary technical work to get the job done efficiently and effectively.

Of course, nobody is perfect, though many people think they are. A mismatch in skills—for example, a person on a critical path failing to perform up to expectations for whatever reason—can have devastating consequences for the overall performance of a project. It can also be devastating for the individual.

It is interesting to note that hard skills seem to have more relevance in the selection of people on a project team. Perhaps this is because the hard skills are more tangible, whereas the soft skills are less so. Many projects are in trouble, however, not because of a dearth of hard skills but soft skills. This is especially the case with technical projects where hard skills are necessary to accomplish the tangible work. Yet, many studies reveal that most of these projects fail not because of issues related to expertise in hard skills but with soft ones.

Hard versus soft skills aside, most projects in trouble have skills-related issues. Often, the prerequisite skills are not identified or are identified too late in the life cycle or the work breakdown structure or the responsibility assignment matrix is missing or incomplete. The incompleteness or lack of these two items is directly linked to the inability to determine what skills are necessary to start, continue, or conclude a project.

1.3.7 Failure to Identify or Deal with Risks

In many projects in trouble, risks are not addressed or, if they are, they are addressed at a high level. Most projects face risks, some of which are more challenging and critical than others. Some projects operate on the assumption—real or imagined—that everything will work out. The reality is that few projects ever work out as planned, especially if no effort is made to identify risks and, more importantly, take action to deal with them. Even if people recognize that risks exist, some may succumb to institutional or peer pressure to deny their existence. The failure to identify or deal with them may be the result of politics or groupthink. Whatever the cause, ignoring risks of all magnitude makes projects vulnerable to failure, perhaps not immediately but eventually. This failure to identify risks, in fact, may not surface during a project’s life cycle but may do so much later during the product life cycle; this may be reflected, for example, in substantial maintenance costs.

People responsible for projects in trouble may have identified risks but elected to do nothing about them. The risks may appear at first rather inconsequential but later pop up as significant risks. The danger here is that failure to address a risk early makes it much more difficult to do so later on. That’s because rework and costs will be greater, and any action may be too late.

A concomitant to not addressing risks is not to do so adequately up front. Instead, a band-aid approach is applied when a tourniquet is needed. This approach is fine if ongoing monitoring of risks and their mitigation occurs. However, projects in trouble often suffer from inadequate monitoring.

1.3.8 Too Many Dependencies

This symptom of projects in trouble is frequently overlooked. Projects often take on a life of their own, operating as though they are independent. The reality is that these projects often depend on the effectiveness of other organizations and projects for resources and deliverables. Projects in trouble frequently overlook these dependencies, assuming instead that they can operate independently. But no project is an island. Holding such a false belief is similar to inhabitants on an atoll believing tsunamis can’t affect them.

For projects in trouble, these risks often are not cited in their assumptions or issues. Partly, the rationale is the feeling that nothing can be done about them and partly because there is an unrealistic belief that the project can be salvaged even under the most dreadful circumstances. Regardless of the reason, the failure to recognize external dependencies can lead to a feeling of invulnerability, in turn, leading to trouble if and when something does happen.

All of these symptoms manifest the...

Table of contents

• Cover
• Half Title
• Series Page
• Title Page
• Copyright Page
• Contents
• List of Figures
• Dedication
• Preface
• 1 Introduction
• 2 Energize
• 3 Envision
• 4 Explore
• 5 Evaluate
• 6 Execute
• 7 Final Thoughts
• Glossary
• Bibliography
• Index