Turning around falling projects
One of the most sought after topics for project managers is how to deal with failing projects or even how to turn them around. When industry figures show a variation of 59%–94% of projects failing, it is easy to see why so many seek this information.
In my typical style, this paper will not be full of theories or textbook options. Instead, it will be an introspective look into actual experiences and a telling of true lessons learned. I made a name for myself at Fortune 100 companies for my ability to quickly analyze, understand, and put plans in motion to turn around failing projects. Some of the stories will include:
- Dealing with difficult sponsors
- Dealing with an unresponsive and unsupportive direct manager
- Turning around software development as well as IT Services projects
- Dealing with ethical/moral issues
This paper will also discuss some of my personal failures in trying to bring a project back to life. As in every situation, there are times when a project will simply fail. The paper will also discuss some of the difficult lessons I learned in some of the most trying times of my career.
The statistics are staggering. The propensity for project failure is enormous. The general accepted failure rates range from as low as 59% to an unbelievable 94% of projects failing to meet their goals. When studying project failure, the survey questions try to determine if the project met the desired scope, timeframe, or met all of the requirements that the project set out to complete. However, these all take on new meanings when you consider something Rob Thomsett says in his book Radical Project Management:
“Projects fail because of context, not because of content” (Thomsett, 2002, p. 37).
If this statement is correct, then a large part, if not the entire 59% to 94%, of projects failed because of the improper setting of expectations. They may have delivered the contents of the project but failed to deliver on the expectations of time and cost. This drastically changes the landscape of the meaning of project failure. Now, pair Rob's definition with PMI's belief that a poor project schedule or inadequate budget is the direct result of poor project management, and project failure rests on project manager's shoulders.
It is usually assumed that a project is being run in the first place by a trained project manager. However, most of the time, someone is managing a project along with their other duties. In this paper, we'll consider how to turn around a project that is failing, no matter what the reason for the failure.
How to Spot a Project that Is on Its Way Down
The first task in turning around a failing project is to learn how to recognize when a project is failing. In many cases, you need to start with the first step of the classic 12-step process with the first step being identifying that there is a problem. Although there are many reasons that projects may fail, there are some key indicators that projects are on the way down:
- Poor project planning or no plan at all. It has been said that a failure to plan is a plan for failure. If you do not prepare for problems, they will surely derail you and your project.
- Disagreement on project requirements. A lack of good documentation of requirements or receiving different answers from different team members about the goals of the project muddies the waters and
- Lack of team involvement. Sponsors, stakeholders, or team members are not involved in team activities or are not responding to inquiries about the project. When people are not involved in the project it has no real life.
- Lack of a clearly defined end. Have you ever had a project last a year and every time you ask how much longer will the project last, the answer is just another two to three weeks? Failing to set a clear end point means a project will never end and if it never ends, it can never truly succeed.
- Unrealistic Demands. If I said I needed you to rebuild the Eiffel Tower from the ground up for $30 in three weeks with five seven-year-old children as laborers, you would laugh. As ridiculous as this may sound, real demands as ridiculous as this have been set for projects. A project with demands that can never be met is sure to fail.
- Failure to stop or plan again. Anytime a new project manager is assigned to a project, one of the first things that they want to do is to stop the project and assess where they are in the plan or re-plan in lieu of having a written plan. A team that responds by saying they are almost finished or they are too busy to plan is a clear sign of a project on the way down. Every team needs to be able to stop and rethink the project's plan.
These are all general theories and a search of the Internet will bring up many sites that have early warning signs, causes for failure, or theories as to why projects fail. The funny thing is that project managers seem to make the same mistakes over and over. The whole point of a project management process and profession is to continually improve. However, the reasons for project failure still continue to remain the same. Unfortunately, unless the way the projects are being planned or how the expectations are being set changes, the results of the project are unlikely to change.
Someone Isn't Being Heard
One common reason for project failure is that communication has fallen apart and someone is not being heard. Consider the following example:
A project manager was assigned to a support project that had no project management structure. The project was consistently not meeting the customer's expectations and senior management wanted a plan to improve customer satisfaction. The project manager started to investigate the root causes of the satisfaction issues. She met with the team as a whole and then individually. As she met with the team members, the issues were becoming quite clear. The causes of the customer satisfaction issues had already been identified by the team and they attempted to put action plans in place to rectify the problems. The project manager investigated the options that the team had put together and saw that they were quite viable. She compiled the information into a presentation and scheduled a meeting with her senior management. She outlined the options and asked for a decision from senior management as to which option they agreed with. They chose an option and she implemented the plan. There was an immediate improvement in the timeliness of customer service which in turn led to an improvement in customer satisfaction. As the improvements continued for the next couple of weeks, senior management brought the project manager in to thank her for a job well done. They asked how she came up with the options she presented. “I didn't,” she replied. “The team developed the options. All I did was examine them for viability and present them to you.” The senior management team was in disbelief. They wondered why the team hadn't presented the options to them before this. The project manager replied, “They may have not understood the best way to present the information to you or how to approach you with their ideas. But it was their ideas all along.”
There are many reasons why the team may not have been able to communicate their options to the management in this example. Teams can develop behaviors based on small insignificant events. At one point, a senior manager could have said “no” too abruptly and demoralized a team member. That team member then begins to have the attitude that senior management doesn't care or will not listen to them. A few episodes of that and groupthink can set in.
According to www.dictionary.com, groupthink is defined as:
The act or practice of reasoning or decision-making by a group, especially when characterized by uncritical acceptance or conformity to prevailing points of view.
Decision making by a group (especially in a manner that discourages creativity or individual responsibility).
For a very serious example, groupthink was the cause of the Challenger Space Shuttle disaster. This is no small statement. Groupthink was the ultimate cause of one of the worst space tragedies in our time. When the analysis of the disaster was complete, it was determined that the O-rings of the rocket booster were the cause of the explosion. An engineer at the company that manufactured the O-rings had warned senior management that when the weather drops below a certain temperature, the integrity of the O-rings is compromised. The engineer asked for more time from senior management to be certain. The panel that was formed to uncover the reasons for the Challenger disaster found some startling information. Originally, the company that made the O-rings recommended that the Challenger should cancel the launch until the temperature rose above 53 degrees, which was not expected to occur for several days. NASA has already cancelled the launch a few times and was under enormous political and societal pressure. NASA applied pressure to the engineering company. Fearing the loss of future revenue and backlash from causing another delay, the engineering company began to question its own data and began to rationalize their decision. The engineering company asked for five minutes to discuss the situation. During the five minutes that the company was isolated, enormous pressure was put on the engineer about his data and analysis. The question for the company became whether to choose safety and possible loss of revenue or risk and future revenue. Inevitably, the pressure to conform outweighed the right decision. When the engineering company called NASA back, they recommended that the Challenger should launch. The official findings of the panel stated that the technical malfunction was the O-rings but the cause of the disaster was groupthink.
When anyone in management stops listening to their team members disaster can strike at any time. When a project is failing, first look to the communication. Over 90% of a project manager's job is to communicate. Whether it is documentation, meetings, one-on-one conversation, or phone calls, all are forms of communications. When you refer to the list of key indicators, communication is central part of all of the items. When communications stop, people stop being heard. When team members are not being heard, project failure is sure to follow. So what do you recommend to open communication? How do we prevent these kinds of failures?
When It's Wrong, It's Wrong
There are times when a project manager is assigned to turn around a failing project that simply can't be saved. There are some project managers who feel that project cancellation is a negative thing. Although stopping a project before completion or cancelling a project that is bound for failure can seem negative, they are great positives for many companies. Why continue to labor on a project that has dragged on and on with no end in sight and a myriad of problems? Why start a project that has many of the factors that will cause a project to fail?
A development project was six months behind schedule, $300,000 over budget, and the client was growing increasingly concerned over the investment in the project. A project manager was assigned to assess the project progress and create a new plan that would reset the expectations of the client. The project manager first asked to see all of the documentation for the project. For a software development project, some of the key documents are the scope of work, functional specification, and use cases. The team pointed to a collection of over 100 binders of information along the wall. The first thing that the project manager noticed was that a team of developers were developing code for the project, but not one of them had one of the 100 binders open to refer to the specifications. The project, from a scope standpoint, was a relatively simple application. While it was not unheard of, the project manager was concerned about why an application that seemed simple would need 100 binders of documentation. Also, if it was complex enough to warrant that level of documentation, why were the developers not using it?
The answers became quite clear. The project was sold incorrectly. The sales person that sold the deal was compensated on one type of technology but not on another type. He sold it as one type of technology, when actually the project required another. Instead of gracefully backing away from the project, the team tried to make a square peg fit into a round hole. When it didn't fit, they wrote reams of documentation to shave, chip away at, or otherwise force the square peg through. Upon realizing this, the project manager called his senior management and asked to stop the project. The project was wrong. It didn't matter if they could eventually get the square peg in the hole, the project should have never been sold in the first place. The project manager called for the stoppage of the project.
After some convincing, senior management eventually agreed and a long battle ensued. In the end, the project manager's company lost a tremendous amount of money and face. However, if they had continued down the path they were on, the customer would have bought a highly customized, over-worked, and diamond encrusted square peg that fits one type of round hole. Should the customer ever change their mind, the project would have had to have been redone. The closing of the project was painful, but it should never have been begun in the first place. Greed took over and the sales person saw dollar signs that he could not pass up. However, when it is wrong, it is wrong.
It Is What It Is
This paper does not imply that if the project manager says it, senior management will do it. This is not always the case. Sometimes, you have to adopt the attitude of “It is what it is” and report appropriately. You must understand that even with the best plans, options, arguments, and facts, senior management still may not do what is being requested. They may continue down a wrong path. In these cases, proper project management can still be followed and the truth will eventually come out.
A project was failing and a new project manager was assigned. This was the fourth project manager assigned to the project. This project manager had a reputation of being able to turn around the impossible and senior management was getting tired of the lack of progress on the project. The new project manager assessed the situation and developed a plan. The team had told him that the progress of the project was extremely slow due to the working conditions. They were developing software with their client was in one state, the server that they were developing on was in another state, and they were located in a third state. There were three developers all trying to get to one server. If one developer made a mistake, it would corrupt the development environment and it would also lose the work that the other developers were completing. This was happening often. The team stated that they felt that they would get at least a 75% productivity boost if the server could be located where they were or at least if an interim server could be located with the development staff that would communicate with the server in the other state. It made perfect sense to the project manager. The project manager presented the options to the senior manager who was acting as the internal sponsor on the project. The senior manager immediately shot down the idea. No explanation was given. The senior manager then demanded the new project manager come up with a new plan and a new schedule for completion and get back to him immediately.
The project manager went back to the team somewhat dejected, but continued to do the work. He sat with the project team and received new estimates on how long the project would take to complete. However, the project manager had to account for the corruption issues that were occurring in the development environment. This extended the project much further than the senior manager had originally anticipated. When presented with this information, the senior manager said, “No way! We are going to change our whole development methodology! We have a client call in 30 minutes. I will handle this!” The senior manager then took over the customer call. He told the customer that the team had decided that the customer's input and changes were the delay to the project and that they would be changing the development methodology. The new methodology will not allow the client to see the project until it was completely finished and it would be complete in three months.
The team estimated six months and changing the methodology would extend that estimate even further. The project team was just committed by the senior manager to do twice the work planned in half the time estimated to do the original work.
The project manager re-estimated the project and showed that the new mandates were not possible under the current environment with the current development staff. They either needed more resources or to have the server located with the team. Again, the senior manager rebuffed the project manager and declared that the project manager was the fourth project manager on this project, and he could get a fifth if the project manager didn't comply with his demands. The project manager knew that he was fighting a losing battle, but continued to do everything possible to try to bring the project in line. A project review meeting was called with the senior manager and his boss. The project manager tried on several occasions to work out the differences out with the senior manager before the call. He called and left voicemails for the senior manager. The senior manager would call the team leader who would be sitting right next to the project manager. The senior manager would ask the team leader what the project manager wanted. When the team leader said he was unsure but the project manager was right next to him, the senior manager said he would call the project manager right back. He never called the project manager.
The call with the senior manager and his boss was an unbelievable event. When they all were on the phone, the project manager outlined the issues that he saw with the project. The senior manager acted surprised. He said things like, “I'm really disappointed with you. I had assumed you would bring issues like these to my attention.” He then went on to lecture the project manager about proper project management techniques and how the project manager needed to communicate better. The project manager was stunned. He had been bringing these things to his attention and was either berated, ignored, or belittled by the senior manager every time. The call ended. The project manager felt alone, confused, and at risk of losing his job. He then employed the “is what it is” attitude. He came to a decision that if he was at risk of his losing job, he would lose his job on his terms. He called the senior manager's boss and shared with him all of the documented occurrences. The key point was that the project had four project managers and all were failing. What hasn't changed was the internal leadership or the development staff.
At the end of the call, the senior manager was taken off of the project. The project manager then began to report to the senior manager's boss for project progress. There was still tremendous damage to the customer relationship, the team morale, and the confidence of the project manager throughout the ordeal, but at least the major road block to project success had been removed.
This story proves that even if the right theories and fundamentals are followed, a lack of or poor quality of the executive leadership can still cause a project to fail. Even though the project manager was putting together plans and trying to turn the project around, the senior manager was taking the project off course. The moral of the story is to stick to the fundamentals. When faced with a situation where you can't change the way the project is being handled:
- Focus on identifying the problem,
- Assess the impact,
- Create options, and
- Get buy-in to those options to deal with project issues (even if the option means you have to replace a senior manager).
A central theme to project management is a cycle between project phases. There are five distinct phases in project management:
- Controlling, and
Initiation and closing stand alone. Planning, executing, and controlling are cyclical processes that continue throughout the life of the project. The four points previously listed are the steps that complete the cycle.
How to Assess the Current Situation and Create an Action Plan that Works
One of the key reasons a projects can fail is due to the decline of communication. This also leads to the team members not being heard. Therefore, the best way to assess the current situation is to establish and meet the needs of the team. For instance, a project manager was assigned to turn around a failing software development project that had only two developers. When she arrived on site and introduced herself, the first developer was quite rude and announced, “I will not work an ounce of overtime for you. Just so you know.” The second developer said, “I'll work all of the overtime you want, as long as you pay me.” Taken aback, the project manager continued with her introductions. She felt a bit awkward, but she did not judge the team right away. The project had been failing. The team was demoralized and she was a new authority figure.
Her first order of business was to assess the situation. The project was behind schedule. She found it peculiar that the project was behind and a developer was declaring that he would not work overtime. All projects are different, but a standard process to turn around a project is:
- Stop the current progress and begin a re-planning effort.
- Determine the progress made to date and estimate the work and durations remaining.
- Determine impact to the other project management plans (cost, schedule, risk, communications, etc.)
- Re-publish the plan and reset expectations.
There are many variations to those steps, but in essence that is what is required to begin to turn around a failing project. If step three is surprising, understand from a project management standpoint, a project management plan consists of much more than just a schedule. To read more about the various plans, refer to A Guide to the Project Management Body of Knowledge (PMBOK® Guide) that is issued by the Project Management Institute (PMI).
The project manager followed the first two steps and understood the level of effort required to complete the project. However, she still needed to understand how to most effectively divide the tasks. She needed to understand why the first developer was against overtime. She asked the developer. He stated that he had been working so many hours and had performed so much overtime, yet the project was still behind schedule. His experience was that no matter how much overtime he put in, he still would never finish in the timeframe allotted. She understood that he was not motivated by money, but by quality of life. Therefore, she put together a plan. She talked through the estimates that she had just received from him. She questioned and ensured that the estimates in terms of hours to complete the work were accurate. She then put together this thought:
“I will make a deal with you. I promise that I will not schedule more tasks than will fill an eight-hour day for you based on the estimates that you have given me. If you finish early, go ahead and go home early. I will pay you for eight hours. However, if it takes you more than eight hours, then I need you to stay here until you are finished. Fair?”
The developer quickly agreed. To be fair, she offered the same deal to the other developer. The second developer declined. He wanted as much overtime as possible. Now she had a better understanding of the developers. She then looked at her plan and developed her critical path. The critical path for a project consists of tasks, which if delayed, would cause the project to end late. In a project, not all tasks are on the critical path. For instance, if you are building a house, pouring the foundation, building the frame, and finishing the house are all on the critical path. Installing the mailbox, while important, isn't really dependent on the house itself completing, therefore it is not on the critical path. If a project manager wants to complete a project early, they look first to shortening the duration of a task on the critical path.
Understanding this methodology, she chose to place developer two, the one that would work overtime, on all critical path tasks. Developer one was scheduled to as many non-critical path tasks as possible. The end result was a project that finished three weeks prior to the end date and a project that was successfully turned around.
How to Set Expectations Properly in the Beginning to Stop the Project from Failing in the First Place
Expectations become the key to project success. If the project is going to fail more often because of the context of the project and not the content of the project, then great project management means properly setting expectations. This is not an easy task. In fact, it will take great change from how most businesses are run. There may be many obstacles, however, if the current way of doing things is best, why do most people, and namely 59–94% of people think that projects fail? When turning around failing projects, or making them successful in the first place, it all starts with proper planning. Planning then becomes the foundation to build the expectations.
Morris, R. (2008). Project management that works! AMACOM.
Thomsett, R. (2002). Radical project management. Upper Saddle River, NJ: Prentice Hall PTR.
© 2009, Rick A. Morris
Originally published as a part of 2008 PMI Global Congress Proceedings – Orlando, FL
Hurricane Katrina decimated thousands of buildings in New Orleans, Louisiana, USA, in 2005, including a U.S. Department of Veterans Affairs (VA) medical facility that served approximately 40,000…
Federal Project and Program Management Community of Practice (FedPM CoP) – How Sharing Best Practices Can Lead to Success
Recognizing the value of a community focused on project practice capability and how such a community could help improve the performance of departments across the U.S. federal government, the leaders…
Developing a Project Management Office in the Department of Energy, Energy Information Administration
This case example, a supplement to the report, PMIAA: Strengthening the Government Delivery Foundation, highlights project and program management capability building within The U.S. Energy…
Commissioned and supported with research from PMI, MIT’s Consortium for Engineering Program Management, and others, this report distills how many government agencies have been leading (and continue…