It was right there in black-and-white. I ought to know. I wrote the language in the Request for Proposal.
It had been approved by the client. The IT providers had responded with this in mind. They had priced their offers based on the client taking responsibility for this major project task.
The task: user acceptance testing.
It only made sense. The client staff on the project must test the system as eventual end-users of the system. Only they could determine whether the system was ready to implement into the field.
As I reviewed the project plan in my capacity in the Project Management Office, I saw the user acceptance test task looming on the horizon. It had been documented as a project risk (based on past project experience). But no one was talking about it. An owner had not yet been assigned. The risk of the client not being ready to test was not being discussed in the weekly status meetings.
True, it was still nine months out, but from my experience it would take that long just to prepare the test scripts.
Who was monitoring this risk? How had it slipped through the cracks?
I suspected that the IT provider was heads down working towards its own completion of coding and System Integration Test and had not looked that far ahead. I also suspected that the client, unfamiliar with project work, was relying on the IT provider to guide them to their next responsibility. Nine months may have seemed like an eternity away, and no one was watching given more immediate pressing matters.
Not wanting my client to be caught unprepared to begin testing on the day the code was turned over to them, I took matters into my own hands. I approached the primary stakeholder and alerted her to the demanding task that her team was responsible to accomplish. I walked through the preparation activities that they would have to complete before they even put a finger to the keyboard to run the first test.
I explained the rigor of developing test case scenarios, of breaking them down into test scripts with expected results. The need for her staff to learn how to run the test scripts on an unfamiliar system. The requirement to document the test results and write up defects. The understanding of how to retest scripts when the defects were fixed and returned to the client staff. The need to understand the full functioning of this massive system so that they could coordinate batch cycles along with the online data creation.
It seemed so overwhelming. And with only nine months to go.
I then presented her with a preliminary plan and recommended a person on her team who I felt would be the ideal lead for the client side of the testing process. This was a person who had shown an affinity to systems work. It was no time to stand on seniority. She agreed.
Looooooong story short, the acceptance testing was a success, beyond even my expectations. It was thorough. It covered the entirety of the system. Defects were well documented. Test results were reported accurately and timely. Stakeholders were kept apprised of progress.
This is a prime example of a very real risk that suddenly sprang from obscurity to prominence. At no time should a risk be documented without assigning an owner. If a risk appears in the risk register it requires a periodic review.
These are the people aspects of project management that with a little focus and attention lead to project success.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.