Project Recovery in IT through Electroshocks

Project recovery in IT is an activity that companies occasionally undertake when the situation calls for it. It usually happens when the quality, cost, and schedule goals of the project are clearly at risk, or when the project governance no longer has the trust of the company's IT management. In this post, we will look at the reasons behind project recovery, how it is carried out, and its characteristics. Finally, we will conclude with a more philosophical point, where I will present the project manager's point of view, having been in both positions - recovery officer and recoveree - during my career.

What leads a company to initiate project recovery

We often refer to the famous triangle of performance in IT project management. It includes the three objectives of any IT project:

  • Quality (scope)
  • Budget (cost)
  • Schedule.

The project manager sets up the activities that enable the achievement of these objectives. This notably includes governance activities on various levels: scope, risks, issues, etc. Depending on the size of the organization, the IT project portfolio is also managed at a slightly higher level. A certain number of key performance indicators are monitored for each of the projects. Projects that are subject to recovery are those that have been in the red for several consecutive weeks on many indicators. For example, a project for which major cost overruns are anticipated and in which the client relationship has fallen into an abyss, a recovery will be initiated. This can all be summed up quite simply: the IT management no longer has confidence in the project manager and the governance, and a course correction is necessary!

What types of projects can be recovered?

Project recovery can apply to all types of projects: any application project, for example the implementation of an ERP, e-commerce projects, etc. Web and mobile projects are also subject to recovery. Let's not forget that the main trigger is that the achievement of the objectives is jeopardized.

The recovery process

The recovery of a project typically takes place in three phases. Here's a brief overview.

Pre-intervention

During the pre-intervention, the mandate and context are introduced to the new governance (the new project manager). This is often a stage where many corridor discussions take place, as well as secret meetings. A specific action plan to be implemented is agreed upon. The pre-intervention phase is relatively short, from one to two weeks. Maybe a little more for major projects.

Intervention

During the intervention, the execution of the action plan begins. Usually, the project manager is thanked, replaced or transferred. Several members of the project team (IT staff or business lines) may also be replaced or thanked. The new project manager presents himself to the team and announces his colours by presenting his governance approach and the mechanisms put in place. Typically, strict scope control measures are announced and implemented. The intervention phase is also short, we're talking about two weeks at most.

Stabilization

During this phase, the actions determined in the plan have mostly been implemented, and the project is then continued with the new mechanisms put in place during the recovery. This phase lasts as long as the project is in progress.

Recovery, above all an exceptional measure!

Recovery is primarily an exceptional measure. Normally, governance mechanisms should trigger corrective actions well before we find ourselves in recovery. Indeed, it is during reviews of IT project portfolios that alarm signals should normally be triggered. Most of the recovery cases I have seen were initiated following a situation where the project was not on the radar for a long time. A glimpse of the reasons explaining this:

  • Limited initial budget.
  • Project considered non-strategic.
  • Manager not paying enough attention to his files.
  • The company has other priorities considered more important.

And what about the IT project manager in all this?

During my career, I have had to carry out the recovery of some projects, but the opposite has also happened to me: I was told that another project manager was going to take my place. This is often a very difficult announcement to receive, so how do we live with this situation? To cope with such a situation, you must first seek to identify the shortcomings in our management and the root causes of the situation in which we found ourselves. We will come up with a list of possible causes. A number will be directly related to management shortcomings, but we will also realize that several factors were probably completely out of our control: difficult client, mentality that IT is there to take and execute orders, limited availability of business resources, poor communication between several stakeholders, etc. Acceptance of the situation comes from the realization that:

  • We had shortcomings as a project manager and we know how to avoid them in the future.
  • We changed the governance of the project to better manage factors considered out-of-control. We have simply put in place a person who is a better fit for the position.
The most important thing is not to take it personally. We will become a better project manager when we become aware of our shortcomings and know how to improve for the future.

Conclusion

As you may have noticed, IT project recovery is a one-off activity that is carried out when necessary. It aims to get a project back on track, so that the company can reap the expected benefits, or at least part of them. Of course, there is a technical aspect to recoveries, but in my opinion, the most important thing for the manager caught in the middle of the recovery is to learn from it and turn the page. Otherwise, he could carry some scars for the rest of his career and be vulnerable…

Other references

I invite you to consult the following sources, they have been particularly useful to me in my reflection before writing this post.

This article was written by the founder of Brome Conseil, Simon Chamberland. Working in the field of information technology since 1995, he has twenty years of experience in information technology and management. Note that this article was first published on the blog of the firm Brome Conseil.