You may be asked at some point to take over a failing project. When joining a failing project, you will have to assess the people, processes, and tools. Today, I want to focus on processes.
When I join a failing project, the first thing I want to understand is whether the scope is clear? I look at the documented scope, but I also take time to understand what people believe the scope is. I frequently find there is a mismatch between what is expected and what is documented. At that point, we take the time to align on scope, clearly defining what is in scope as well as out of scope for the project.
When you have a failing project you are faced with the question of whether to perform project CPR or let it die. There are times when a project shouldn’t be resuscitated, even if it’s not failing.
I had a client that had spent $1.5 on an HCM implementation. They were faced with a product that wasn’t aligning to their needs and a software provider that wasn’t responding to the issues. As painful as a decision as it was, they decided to kill the project and go back out to market for a new solution.
When I once joined a project as a recovery consultant, the organization had already spent $10 million on a Salesforce implementation. Despite the amount of money invested, nothing was yet in production. It was one of the top three initiatives in the company. One of the first things I do during a project rescue is to understand the project org chart. As the team was walking me through it, they mentioned that we were to meet weekly with the sponsors. Sponsors? As in more than one? On this project, there were three, each from a different department.