How a Creative Risk Response Saved the Day

How is it that with the thousands of risks that come our way on IT projects, we can almost always guarantee that the User Acceptance Test (UAT) process will consistently yield risk events? In fact, on my large projects, the first threats I would enter into the risk register were that UAT may start late, may delay implementation, and would probably uncover more software defects than anticipated.

Two and one-half years into one such project, we actually entered UAT on time. So, scratch that risk event. However, as we began to execute our 6000+ test scripts, we began to document hundreds (eventually thousands) of software defects.

To mitigate the risk of missing the implementation date, the IT provider pulled out all stops. Developers worked overtime to turn fixes around in record time. Our UAT testers retested the fixes diligently, as they continued with their regular test scripts.

One month prior to implementation we still had several hundred outstanding defects. The probability of not making the implementation date was updated to 100%. This was the major triggering condition to implement the response plan for this risk. The major project sponsor was alerted and became very anxious about missing the date. However, she was not willing to implement the system while there were still several hundred outstanding defects.

“So what’s the big deal?” you may ask. So you’re a month late. So what?

Well, I’ll tell you. We were rolling the system out in waves. This required just-in-time training, just-in-time infrastructure buildout, and just-in-time project staff reductions. Delaying even one month would have resulted in exorbitant costs and disruptions, as we would have had to renegotiate training facility contracts, hardware deployment contracts, and start dates for staff moving on to their next projects.

My personal goal as oversight for the project was to implement on time. I hate missing dates. While I understood and respected the sponsor’s concerns about the quality of the system given the number of outstanding defects, my own deep experience in these types of projects suggested that the number of defects was not indicative of system quality. I suspected that we could implement on schedule, even with this large number.

I arranged a meeting with the project sponsor and the IT provider’s Application Development Manager. We analyzed each outstanding defect and classified it according to its potential effect on the system if we were to implement without it being fixed. After 2½ days, we arrived at exactly 100 defects that needed to be remediated before we could confidently implement the system. Not that the hundreds of other outstanding defects did not need to be fixed; however, they were deemed not to have a detrimental effect on system functionality.

There was one sticking point among the 100 defects to be fixed. One of the major data exchanges proved to be stubbornly difficult to get right. True to form, one week prior to implementation, at the point where we needed to freeze the code for deployment into production, only one of the 100 defects remained. And it was in regard to the data exchange.

The project sponsor felt that she could not in good conscience sign off on the user acceptance to allow the system to be implemented. One defect! One functional area to be finalized!

I huddled with the IT provider’s Project Manager, and suddenly it occurred to us. While the data exchange functionality was an absolute requirement for the system at initial rollout, it was not scheduled to run in production until the end of the first month of production. That meant we had 30 additional calendar days to fix and test the data exchange, even if we went live on schedule.

We documented the risk with high probability and high impact. Our new risk response plan assumed an on-time implementation, and therefore put the highest priority on fixing and testing the data exchange in 30 days. To her credit, our normally risk-averse project sponsor agreed.

The happy result: we implemented on schedule while completing the testing of the data exchange well in advance of when it was required to run in production. A major win!

My major incentive for writing these articles in parallel to the PMBOK® Guide’s bias towards the process aspects of project management is to focus Project Managers on the equal importance of the people aspects of project management. In this real-life example, had we just stuck to process, we would have had a perfectly documented risk event with a risk response that would probably have allowed implementation to be delayed. However, by paying attention to the people aspects of project management, which included understanding the personality and risk-averse nature of our major sponsor, we applied several creative solutions to mitigating the risk event. As a result, we delivered the project successfully against multiple odds, on time, within budget, with requisite quality, and to the satisfaction of our end-users.

Project management is about people as well as process.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.