In our Fractional CTO™ practice we often help distressed software development teams in the middle of a struggling project, or right after one has failed. Regardless of the size of the organization or project, the failures are usually caused by tensions between the definition of the end result and the process by which the team attempts to accomplish it.
In this series we will explore our approach to identifying and addressing project failures in the hopes of enabling you to capitalize on our lessons learned. We break the process into four steps; identify the failure scenario, assess the indicators of project risk, identify the root causes, and then formulate a remedy.
Step 1: Identify the failure scenario
Every new situation requires us to first identify the type of project “failure” the client perceives they are dealing with. We want to identify themes in order to build team consensus and understanding of the issues from a strategic point of view. Later we will create an action plan to resolve the issues. Typically, project challenges fall into any of the four categories described below. If you have ever struggled with a software project these categories may sound familiar.
There are many reasons why a project may feel like it is sucking money. So when it becomes clear management views the project as an endless stream of unplanned costs we focus on that. This could be a lack of cost controls, poor project management or software quality and practices, or a variety of other challenges in the SDLC that we will try to identify in a later stage of investigation. Usually this can lead to other serious problems and significantly erode trust and communication and force bad choices. For instance, you don’t want to throw good money after bad but replacing the team or changing the project goals may make things worse. It’s important to get to the root of the problem quickly before this high burn rate leaves you with no good options. When this happens project termination, or abandonment is often the result.
Unending scope creep
The project requirements continually change resulting in a seemingly never-ending project with more and more features but no sense of completion. In some cases there may be no releases, just a steady stream of new requirements. A variation on this is a sense that the software isn’t “perfect” so it is either never released or the release is never considered worthy due to constant tweaking. This could be due to poor quality in any stage of the Software Development Life Cycle (SDLC) combined with unrealistic expectations. There is simply no clear strategy for calling the project “done”.
Over the course of these projects Management will often ask “Why can’t we ever ship anything?” or “This seems simple, why can’t we finish it?” It is common to hear the development team in these situations complain that, “Every time we show Management/The Customer our progress they change what they want.”
The result will often be that Management becomes frustrated with the lack of a released product and out of control costs. Meanwhile this endless drip of requirements can lead to low development team morale since they want to feel accomplished. What’s worse, this deterioration of morale can lead to a lack of project commitment since the team will feel like they can’t finish anything and that feeling slowly becomes the accepted cultural norm.
The team finally hits their milestones but the project is not viewed as worthwhile upon completion. The perception may be the overall costs were too high, “nobody” is finding the new features helpful, it’s possible the original intent and need has been forgotten. Even worse, the resources, who are now burned out, could have been better utilized. As technical leaders ourselves it hurts to recognize the tremendous amount of energy and creativity that went into a project which when finally completed no longer represents core business value. We find this more often in non-agile projects, however even projects utilizing tight iterations can suffer from this disconnect when there is a lack of real product ownership and an uncommitted team that doesn’t challenge weak requirements or focus on consistently delivering value.
When a project fails it may end up getting turned off, resources reallocated or let go. For a small company this could be the end. For a larger company it could be the end of a strategic vision or it could be wasted money followed by a reboot with a different team or approach. Abandonment is the result of not identifying the signs of a project at risk and taking action soon enough. The mistake many companies make with this type of result is they don’t learn enough from it. Taking the time to really do a detailed and constructive analysis of what happened can be invaluable, in fact, in the long run it could be more valuable than the promise of the original project. If an organization learns sufficient lessons from their mistakes they can become a stronger and more effective organization. So while this may be the worst of all outcomes for a project it doesn’t have to be a complete waste for the company.
There are of course many types of failures but these four general scenarios cover the majority of situations we help to unwind and improve. They are also in the back of our mind whenever we are helping to launch new project initiatives as serious risks to avoid. Understanding where the project stands and having the team come to consensus is the first step in fixing the problem or avoiding it in the future. In the next installment we will examine some of the underlying indicators that help us clue in where the issues are percolating so we can later hone in and address them. These key issues are also important areas for new teams to learn to avoid and address quickly so their project doesn’t end up in one of the failure scenarios.
If you have any war stories and observations on this topic we would love to hear from you. By sharing our experience we can all improve our process and deliver high-quality solutions.