A health check is a formal examination assessing if an IT project is on track and under control, and serving as a valuable continuous improvement tool. The outcome is a project health report that proactively and impartially informs project stakeholders of the well-being of the initiative.
Too often, a project health check is only initiated once a project already is in trouble. But best-in-class organizations require health checks at several points during a project’s life cycle.
Creating the health report can be time-consuming, and it is typically not the responsibility of the project manager (PM). Instead, such reports should be produced by an independent party for the benefit of the project sponsor. I’ve seen health checks carried out effectively by a central Project Management Office, an internal auditor, or an external 3rd party.
I love Porsches. They always captured my attention as a child, and I told myself I’d own one someday. The sound, the quirky design, everything about them is perfect. One of my favorites is the 944, in production until 1991. It was a departure from Porsche’s typical design, so it isn’t terribly desirable to hardcore Porsche collectors. Some are listed for as low as $1,500—an attainable price point for me!
Recently, I went to check out a 944 for sale and priced on the low end. I found little things here and there that would require repair. After some research, I learned these small items would cost a significant amount of time, money and effort to fix, even if I did my own work.
The story was the same with other cars I saw in the same price range. One needed a timing belt replacement ($1,900 at a shop). Another needed a cooling system overhaul (between $1,100 and $1,600). Even discounting labor, the parts alone would completely blow my budget.
“This implementation is going nowhere fast and I am canceling it,” said the CIO.
I was in shock. In an IT career spanning decades I had never witnessed an executive make a decision as bold as this. But, truth be told, this particular implementation had already gone on for twice the allotted time and delivered nothing notable—beyond a very long list of open issues.
Still, I jumped in to defend the struggling project. I said we would be foolish to waste all the efforts made to date. I said the business case had a clear ROI. I said reputations, and possibly jobs, were on the line if the initiative was terminated.
An IT department’s most critical point of failure lies in its inability to cancel a dead-end project. Canceling a project can be a great move, but it is uncommon. (When was the last time you canceled an IT project?) All too often, IT departments waste significant time and money on a fruitless effort.
Let’s explore the major reasons why an IT project reaches an impasse. Knowing the reasons will help find an effective, yet low-risk path to fail fast and move forward.
The traditional vendor engagement model is flawed.
Technology initiatives are only getting more and more complex, time consuming and costly. Consequently, the risks associated with technology investments continue to pile up.
Complexity increases the number of weak links, prolonged timelines introduce changes to landscape and priorities, and budgets are inevitably blown by vendors that offer unrealistically low costs that they cannot later sustain. While some organizations may feel that the problem is the result of selecting the wrong vendor, the challenge may in fact be the typical vendor contract.
What are the root causes that lead some project teams to operate well, while others struggle? Underperforming project teams may result from a weak change management plan, lack of talent on the project team, or insufficient stakeholder support, among other factors.
In my view, all of these issues boil down to poor alignment.