When a project goes bad, it’s like getting sick. At first, you think it’s just allergies or you are a little under the weather. The symptoms mount and finally you accept the fact that you are really sick. The longer you wait, the sicker you get.
When a project starts going bad, we often ignore the symptoms. We are only a little behind schedule, but we will catch up. The code quality isn’t that great, but it will get better. Or, we are behind on our staffing plan, but we can hire more people in the next few weeks.
Here are five things to do when your project goes bad:
Sound the Alarm, Break the Glass
Contents
When there are serious issues, break the glass and pull the alarm. Often, a dramatic action is required to jolt the organization into recognizing that the project is in trouble.
Due to the ‘escalating commitment’ and ‘sunk cost fallacy’ phenomena, people and organizations continue to invest in bad decisions because they are emotionally committed. Recognizing a problem is an admission of failure.
Many organizations also foster the “hero culture.” In these situations, there are often executives who saved ‘the big project’ that succeeded against all odds. In these environments, breaking the glass is a dramatic and courageous act. But it needs to be done.
Accept That There is a Problem
After the alarm has sounded, everyone needs to accept that there is a problem. This is harder than it sounds. Often teams that are highly invested go through a version of Elizabeth Kübler-Ross’ five stages of grief: Denial, Anger, Bargaining, Depression, and Acceptance.
The project manager needs to help the team process the information and accept the situation. There are many strategies that can be employed. The best strategy often depends on the organization’s culture. Sometimes there is a need to stage an “intervention,” forcing the team to accept the problem. Other times overwhelming facts and data are needed to persuade the team. And sometimes it just takes time and perseverance.
Question the Assumptions
When planning a project, we make many assumptions. When a project goes bad, we should review and question these initial assumptions…
- Is the objective of the project still clear?
- Is the scope still aligned to the objective?
- Do we have the right resources?
- Are the planned durations still accurate?
During the reassessment, the team should be encouraged to challenge all current operating assumptions. Continuing the project without adjusting or resetting expectations and assumptions usually does not lead to success.
Sometimes the hardest assumption to question is whether we should even continue the project.
Don’t Call in the Cavalry, Call in Seal Team 6
There is often the desire to call in the cavalry and throw resources at the problem. Remember the lessons from the Mythical Man Month: “Adding manpower to a late software project makes it later.”
Don’t call the cavalry—call in Seal Team 6. A small, experienced project recovery team can provide the rigor, processes, and tools needed to stabilize the project and get it back on track. A large group of resources or even a small team that has not worked together before may increase the confusion.
Plan the Recovery, Day-by-Day
Once we have accepted the problem, we need to begin planning the recovery. Initially, the team will not be ready to re-plan the entire rest of the effort. Start with small, tactical steps. Plan out the actions that need to be accomplished in the first few weeks. Be specific about the tasks, assign owners, and review status and progress daily.
The initial recovery planning should focus on assessing the situation and defining a clear go-forward strategy. Once you have defined the new strategy you can begin re-planning the overall project schedule. Revising the project schedule should be done quickly, but should not be rushed.
Early in my career, I was the portfolio manager in a finance organization when I inherited an in-flight accounting project. We were building a new application using cutting-edge technologies with a new development team. The team had initially committed to a 9-month timeline.
Six months into the project, it was clear we were off-track. I tried to “break the glass.” The business sponsor and I went to our director and presented the issues. But the director was too invested in the project to accept our assessment. He said, “I’m sure it will be fine with the two of you involved.”
A few months later, there was a reorganization and we had a new director. The business sponsor and I presented the concerns to our new boss. The project was now past due without a realistic timeline. But we now had a leader who accepted the problem and was willing to take the strong action. We quickly took several steps:
- A combative development manager team was removed, which opened the way for collaboration between the teams;
- The new requirements management tool was abandoned because it was too complicated and unwieldy. We managed the remainder of the project using Microsoft Word and Excel ®.
- The original plan that the technology team would configure the accounting business rules was reversed, and a small team experienced in both accounting and technology was hired by the business to manage the configuration and acceptance testing processes.
The project eventually took two years to complete—15 months longer than the original estimate. Even though it was extremely over-budget and late, the application was successful, exceeded expectations, and was used to close the books for the next 10 years.
Sources:
Escalation of commitment – Wikipedia, the free encyclopedia. (n.d.). Retrieved May 8, 2015, from http://en.wikipedia.org/wiki/Escalation_of_commitment
Brooks, F. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley.
IT’s ‘Hero Culture’ Stunts Growth … (n.d.). Retrieved April 26, 2015, from http://www.computerworld.com/article/2558915/app-development/it-s–hero-culture–stunts-growth—-.html
Kübler-Ross model. (n.d.). Retrieved April 27, 2015, from http://en.wikipedia.org/wiki/Kübler-Ross_model
© 2015, Project Management Essentials, LLC