The dos and don’ts of delivering OSS/BSS quality

Both CSPs and OSS/BSS vendors must adopt behaviors to infuse quality into networks, systems and support. Quality has to be part of the job and work processes, not merely a metric that’s measured after the fact.

These are the dos:

• Establish a PMO that has budget, schedule and project authority.
• Help business units focus on the processes they want to optimize before discussing system and application requirements and solutions.
• Establish an enterprise-wide change-control function that includes every infrastructure, process and software change; require participation by every business unit; and include IT representation from development, administration, testing, quality assurance (QA), training, and support.
• Define rigid configuration-management procedures to ensure that everyone is working with the most current versions.
• Test, test, test, then test some more. Interface and interoperability testing ensure that the pieces fit while minimizing surprises.
• Decrease the time spent in meetings filling out status forms and conducting reviews; streamline the process, set time limits and make participation mandatory.

CIO Magazine reports that the cost to fix bugs discovered during unit testing is 10 times the cost when bugs are discovered during requirements review—which becomes 1,000 times when bugs make it to the phase of initial deployment. To put it another way, a problem that could be fixed for $10 if uncovered during requirements review costs $1,000 if reported by a customer, and that doesn’t include the loss of goodwill or the risk to your company’s reputation that can occur when your customers end up doing your interoperability testing for you.

These are the don’ts:

• Don’t force adherence to an unrealistic schedule. Give requirements definition and testing the time needed to make a project successful.
• Don’t begin coding until the requirements are clear and understood and agreed to by all.
• Don’t enable scope creep; changes cause problems for everybody. Adding functionality as a change late in the development process, rather than including it when requirements and specifications are created, can torpedo a project.
• Don’t reward behavior that abandons quality. Meeting a deadline with a poor product or saving the day with a last-minute fix that’s undocumented and untested undermines efforts to instill quality; though sometimes unavoidable, it shouldn’t be celebrated.
• Don’t insist on multiple, disconnected reviews and reports just so management stays informed. Streamline change-control functions and make meetings mandatory for every employee, including managers.
• Don’t leave your company’s business units in the dark. Changes to CRM, or customer relationship management, can affect marketing, and network changes can affect product development. Including all business units ensures transparency so that no one can say, “I had no idea ...”

The implementation of new or upgraded network and IT infrastructure or OSS/BSS solutions isn’t complete until it all works together. Interoperability and unit testing are too often minimized or skipped in favor of ramped-up scheduling, but delivering a product on time doesn’t guarantee customer satisfaction, and even if there are penalties associated with schedule delays, what’s the penalty for a solution that doesn’t work? Quality requires participation from the service provider, the infrastructure vendor and the OSS/BSS supplier in the areas of change management, requirements review, process definition, testing, and more in order to ensure a satisfactory result.