Can a failing software engineering project be rescued?

Our previous post looked at how projects have failed over the last 25 years and the minor increase in the success rate from 16% to 29%. That is still abysmally low. What if your project is failing – can it be rescued?

Asking this question is the first and most important step. The only way to know is step back from the growing carnage and assess the situation. It may be clear or you may be too close to the situation and need to have an independent party do the assessment.

Regardless, the later in the project life cycle this happens the harder it will be but not as hard as waiting even longer.

A Project Management Institute (PMI) Report detailed a detailed five step plan. It begins with defining the charter which will determine the assessment approach and make sure there is a clear understanding of the history of the project from all perspectives. One of the key questions to answer will be whether the recovery should take place or not. If it does, the assessment will end with a new schedule with a new project plan.

A more recent 2017 PMI report sheds light on the factors of successful projects today. It found that having an “actively engaged executive sponsor is the top driver of projects meeting their original goals and business intent”. What if there is an actively engaged executive sponsor, you perhaps, and it’s still failing.

Are Agile processes in place? If so, you’ve covered the two key factors. It may be the team. That’s not something anyone wants to consider but it must be done during the assessment. It’s easy to think that any developer can do any software project. But many developers  have expertise in a limited scope and aren’t aware of new technologies. Can they learn? Probably, but it will have to be on the project. This is good for them to learn but it could be at the expense of the project success.

Irina Abramson, co-founder of Speed & Function, says that rescuing a project can be done but that  it requires “proven processes and proven people”. The keys are:

1. Project Owner
2. High level adoption of Agile methodology
3. Dedicated and early QA testing
4. Risk Management
5. A strong team

A Project Owner will coordinate scope, budget and client expectations, and will prevent overage and misunderstandings:

1. Highly responsive and collaborative.
2. Properly set expectations about scope, budget and timelines.
3. Track scope and budget on a daily basis.
4. Successfully fill the shoes of Agile Product Owner or Scrum Master, depending on project team layout and other circumstances.

Agile methodology is the process answer because it ensures that:

1. Client is involved in the project every step of the way, with daily Scrum meetings and weekly demos. This way you’d have no surprises when it’s time for release because you have been with engineers non-stop, are familiar with the application and they’ve already implemented all of your high-priority requests.
2. Time-boxing delivery: you can’t have endless user acceptance testing (UAT)
3. Full transparency for what’s happening on the engineering side
4. Complete visibility for what’s happening in every aspect of the project
5. If budget is limited, simplify scope to reduce risks

Dedicated and early QA testing would have prevented bugs from reaching production.

Risk Management facilitates adjustment of either scope, budget or timeline to ensure the high-priority items can be delivered regardless. .

A strong team ensures the best outcome: you can’t afford mediocrity in software engineering. .

It’s important to have the tools to put this all together. For example, Speed & Function uses a project management tool that they have customized for use with Agile projects.

Recovering failing projects is not easy but it can have a happy ending.

We welcome your comments.