A Different Thought on Who Should Have the Final Say in Software Deployment

Most development shops are set up in such a way that once QA has signed off, then everything should be just fine. QA is usually active of the last phases in the IT Project Plan, and has one of the toughest jobs. However, I’ve seen some development companies leave the final call (if not joint final call with QA) with the Support Center, the group that handles customer calls and issues. One person who runs a call center says, “Every call that comes in is an indictment against the software.” His goal is to mitigate and minimize as many of these calls as possible. This is the group that is on the front lines, hears the angry customers, and is responsible for helping them solve their problems. Unfortunately, the solutions many times take the form of “workarounds” that may or may not ever fix the problem the proper way.

Why not let that support person be very involved, if not THE person that makes the call on whether a deployment is ready to be released, or whether it’s just about to be another product escape? Many times, QA is too sterile and removed from the true functionality of the software. Engineers are too close and can’t see the forest for the trees. A project manager just wants it out the door and the business analysts have forgotten about it at this point.

The person that runs the Support Center, however, is on the front line of supporting the software. It is their department’s metrics that are impacted by a bad software release. Metrics such as average hold times, call times, and ticket closure percentages can all get skewed quickly if the software is not performing up to standards. Let them say when they feel comfortable enough to let the software go and you might just end up with a better product.