Rebooting Failed IT Projects: The Power of Technical Project Remediation

Like mediation, remediation is supposed to help both sides understand where they are and where to get to. However, in technical project remediation it is much more hands on as the focus is on getting a solution delivered. Someone doing remediation work has to be a deeply skilled technologist as really what you’re asking is another technical delivery firm to come in and help get the project over the line.

There are limitless reasons as to why a project is failing, but generally there are “themes” of problems that occur. The project could have been incorrectly specified. There could have been insufficient technical resources deployed or – to be balanced – the customer may not have put enough of the right people at the disposal of the supplier. The customer may have changed their objectives mid-process (or had their objectives changed for them by outside factors). The testing processes may have failed and too many critical faults have crept in.

It’s also important to realise when in the process you get to a point where the need for remediation is identified. It happens very late on in the project. There needs to be enough time, frankly, for one of the parties to get “pissed off”. No one is Googling for commercial litigation lawyers a short way into the project – someone has to be getting embarrassed and/or resentful about the progress. Once you get to that point, it’s legitimately hard to work together, even if you want to.

All in all, the principle of technical project remediation is to reboot the project when trust has evaporated between customer and supplier by inviting in an independent, fresh technical expert to come in and help both parties get the system delivered so all that time you spent on the project isn’t wasted.

By Matthew Reynolds