We have all been there. That challenging moment when a project shifts from Yellow to Red, carrying the association of bad to worse, as well as the understanding that tensions can be high. As project managers, our job in these scenarios is to do what we can to get the project back under control. This was the case with a project I was recently a part of where the reality of the situation was the project was not just red, it was very red. Two years behind schedule color red, to be exact. 

Thankfully for my future career, I was not the cause of the issues with the project. At the time I was engaged, the client had pushed their way through two years of continually changing circumstances, which had created the latency. The project goal was to implement an enterprise case management system, and my role specifically was to serve as the project manager overseeing user acceptance testing (UAT) of that system. 

Typically, this part of a project runs relatively smoothly and allows end-users to engage with a new system before it goes live for the entire organization. In the case of this project, however, UAT came with its own complications that I had to work around and create new solutions to new problems.

With any UAT program, it’s good to have a set of business and technical requirements to test and track failures in the system for everyone from experienced users to newbies. Unfortunately for me, the previous vendor handling project management did not capture either. This meant I was essentially creating testing scripts blind; I had no idea what success was supposed to look like for these end-users. To make matters worse, my timeline for testing this system with 8-10 business groups was only three weeks.

Certainly challenging. Not impossible, though. Utilizing agile methodologies, we created a plan that would allow us to test and apply lessons learned as we went through each sprint. This meant that our test plans would get more and more granular as testing went on. From a scheduling perspective, we could stack the schedule with the easier testing groups first. 

The first week of testing was a little rough, but ultimately successful. We cut down on the number of submitted issues by having both a project manager and IT subject matter experts in the rooms while each group was testing.

Behind the scenes, the client’s main IT/Programming group was working issues in real-time almost around the clock, which significantly improved the project status as well. We completed UAT as successfully as we could, and we were finally ready for go-live. Or so we thought. 

Two events occurred for which we could never have planned. First was the COVID outbreak. The second was that the vendor who owns the system we had just finished testing, was conducting a cloud storage migration for its platform. This meant we would now have to conduct UAT for a second time, and due to the pandemic, we would have to run it remotely. This created absolute chaos amongst the backdrop of workforces going remote and reinventing their business processes, so our end-user stakeholders were less than pleased. This also affected the go-live timeline and the data conversion that would need to occur between the old and new system. 

This project was truly a project management challenge for me and has been one of the most difficult projects I have been privileged to work on to date. I was able to take away a few things as well and learn from the challenges this project presented,  where I often felt reminded of one of my favorite books “Man’s Search for Meaning” by Victor Frankl.

  1. Have a “what if” plan that can account for things like an entire workforce migrating to remote/telework. If COVID-19 has taught me anything, it is that people and organizations are very capable of working remotely and tailoring your project management style accordingly can result in an increase of productivity. 
  2. As it relates to this horror story, we would have greatly benefitted from up-front transparency regarding the hosting migration the system provider was planning to undertake. When running technology implementation projects in the future, I will be sure to try to get as much information about future changes to the system we are implementing so I can plan a project accordingly. This can be valuable information when drafting Service Level Agreements or task orders since you can build in a plan at the start of a project rather than during or at the back end. 
  3. The end users know the system better than you think. We continually learned new functionality and issues while we conducted testing from the very folks testing the system. Leaning on these people as well as project stakeholders can create a better project ecosystem, especially when end users feel like they have an impact on the system they are adopting. 
  4. Sometimes, and very rarely, things just go wrong that are entirely out of anyone’s control. Myself and my team were certainly not expecting a global pandemic that would result in months of remote work, and the only thing anyone can really do in that scenario is roll with the punches. 

The last point specifically is what reminded me of Victor Frankl, who made the argument that the only real possession anyone of us truly own, is our choice to react to a situation. This project was, unfortunately, a project full of reaction and as Project Managers, our role is to react in the best way possible for the client.