Change is a fact of business life. The move to 5G, Gigabit fibre, and broadband satellite systems is prompting considerable change in the service provider market. New product offerings – in the form of SD-WAN, IoT, Cloud or network-plus services such as security – all involve change and potentially the deployment of new support systems.
But system change remains problematic for many service providers and their customers.
A small change is akin to a pebble being dropped into a large pond – a few small ripples but no real impact. Change introduced as part of a project is like a stone being put into a goldfish bowl. The bigger the project, the bigger the stone.
Done well the water level rises, and the goldfish (aka the customer) benefits from a new feature. Done not so well, water splashes over the sides and the goldfish is disturbed. Done badly and the stone can crack the bowl, spill the water onto the floor and leave the goldfish distressed. Done really badly the bowl (aka the business) breaks.
Much has been done to raise the professional standard of project management, but the failure rate on big projects remains stubbornly high. In my experience there are two potential methods to reducing the risk of failure (ie cost or time overrun, or failure to deliver what is wanted).
I would not recommend the first method, but I have seen it adopted by an enterprising CIO who was proud of his team’s 100% project success rate. When a project reached the end of its budget or time limit, whatever was ready was handed over. When the business complained, a new project was established to address the issues.
Simple. Brilliant even. But of no value to the business.
The second method involves using experienced project professionals to carry out an impartial review and the CEO acting upon these findings. Why the CEO? Well it’s not uncommon for projects to be delayed because one or more areas of the business do not believe in the project and provide little support for it. The CEO is needed to ensure all areas commit.
Most organisations have a process to manage the implementation of system change into production. A couple of years ago I was working with a UK-based CSP that had a well-structured change management process. Change requests were submitted and had to be approved before details (including risk and impact assessment) were circulated prior to a change steering group review and final approval.
Whilst this was textbook stuff there were some underlying issues:
- There was a high volume of change and no one was looking at what was driving it. A series of changes could, for instance, indicate that one or more core systems needed replacing.
- The ecosystem was not fully understood, therefore impact assessments in some instances were flawed. Over the years I’ve carried out dozens of IT function reviews and most, as was the case with this CSP’s IT function, had a list of systems they supported that differed from the list of systems business users stated they were using.
- Processes were not fully understood. One of the most common issues, based on due diligence reviews of over two hundred projects, is that not all processes are documented and the interaction between processes and systems is often unclear. As was the case with the billing replacement project at this CSP. The net result can range from customers and internal users being unable to perform certain tasks, to financial reports being wrong.
Managing the change process is important, but so too is a periodic review to ensure change is relevant and that impact assessment is based on a solid understanding of the ecosystem and business processes. Getting the basics right is key to companies seeking to be operationally and cost-efficient while delivering a good customer experience.