Unfortunately, our quality control processes didn’t fare so well. We did get sufficient testing resources for the first rollout, but a couple of process owners only delivered under protest. For you see, they believed that testing of their processes — even user acceptance testing (UAT) — was not their job. To put it another way, they did not hold themselves accountable to ensure that the technical solution conformed to their processes’ requirements.
This personal shortcoming — an unwillingness to be accountable — triggered a chain of events that put the program right back in a hole:
- Because it wasn’t their “real” job, some process owners did not create their own user acceptance tests. They simply copied the tests the developers used for unit or integration testing. Therefore, UAT did not provide an independent verification of the system’s fitness for use; it simply confirmed the results of the first test.
- This approach also allowed process gaps to persist. Missing functionality that would have been caught with test plans that ensured process coverage went unnoticed.
- Resources for testing were provided only grudgingly and were often second-rate. They often did not know enough about system and process to run the scripts, never mind verify the solution or notice process gaps.
To say it was a challenging cutover and start-up would be an understatement. Yawning process gaps remained open because they had never been tested. For sure, we had a stack of deliverable acceptance documents, all formally signed off. What we didn’t have was a process that was enabled and fit for use. One example:
- Documents remained stuck in limbo for weeks after go live, all because a key approval workflow scenario had not even been developed.
- And because it hadn’t been developed, the developers hadn’t created and executed a test script.
- And because the process owners were so focused on doing only their “real” job, they missed a gap that made us do business by hand for nearly two months.