The User Acceptance Test (UAT) is a critical component of any IT implementation. The goal of a UAT is to validate if a system or solution will meet the needs of business users in their operational environment.
The outcome of this phase sends the project down one of two paths. If all goes well, the project moves on to the Go Live phase. If it’s a flop, the project faces many challenges ahead, the Go Live timeframe is at risk, and the credibility of the project with the business may be tarnished. Obviously, the stakeholders want the UAT to go well. So how do you secure a win?
Let’s explore the 10 key ingredients of a successful UAT. We’ve seen this recipe work across a wide variety of IT projects.
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.