Having spent much of the last 20 years talking to operators, there are constants in big transformation projects. Here are my top ten tips for successful IT transformations.
1) Before you start, make sure you have the resources (people and documentation) to get into the old systems. Too often the people who knew the old systems have left!
“The system was in no way table driven, and to change anything meant brave expeditions into the code itself.”
CTO, Mobile Operator, Asia Pacific
2) Without a Board Level sponsor, do not start. You need authority to cut through the politics.
“The CEO was on the steering committee and therefore the team had decision making abilities at the highest level.”
CIO, Major US carrier
3) Get as much of the business involved as possible, but maintain control.
“A bigger opportunity was missed – to work with Marketing and other areas of the business in the rationalisation process. Better, more relevant products could have been designed and launched.”
VP, Billing, European operator
4) RFPs – are a pain and some think irrelevant in such a fast moving environment. But they provide clarity, a check-list and foster honesty. They are a necessary evil.
“All RFPs stink, frankly, but I have yet to find a better process for sorting out the best supplier fit for the business. The more specific an RFP is the clearer the answers will be.”
VP of IT, North American Carrier
5) When selecting which system to consolidate on to, design a functionality matrix, and be clinical about which systems meet the criteria.
“Experienced heads when you are in the middle of a merger or a migration are like gold dust.”
Billing Manager, Mobile Operator, Europe
6) The most difficult part of a transformation is parity, maintaining business as usual in the midst of massive disruption.
“You should never underestimate the amount of the effort involved. The advice is to work out the worst case in terms of effort – and then add 50%.”
Veteran IT Chief, North American Carrier
7) The thing that most operators wish they had spent more time doing – testing. Test, test, then test again.
“The aim should be to migrate as little of the old complexity as possible.”
IT Director, Triple Play Operator, North America
8) Communication: brand the project, communicate what you are doing with the business. Explain the disruption, sell the benefits and people will be on your side.
“The business probably does not understand the business potential of the new systems anyway.”
Billing Strategy Manager, Quad Play Operator, UK
9) Do not expect to get to one system. You will get to three or four and then investment and resources will find more urgent projects. One system is not a realistic goal. Several iterations of a system is a better one. It will have the same benefits – licensing, training, maintenance. Aim for different iterations along business lines – consumer, SME, corporate.
“Software will not fit your requirements completely – it never has and probably never will.”
Head of Billing and Payments, Wholesale Carrier, Europe
10) And finally – the most difficult thing?
“The most difficult thing in a billing conversion – based on 25 years experience of doing this – is getting people off old ideas and selling the idea to the business. Technology is the easy part. The funny thing is that IT ends up selling business agility to the business.”
VP of IT, North American Carrier
Hi, we are also in the process of transformation from legacy billing system to new here in India. This transformation is at very large scale because it needs to take care of entire postpaid base of abt 12 million. The additional complexity to it is concept of circleso where each circle is one complete business entity in itself. Hence this could be considered as migration of billing systems of 23 countries into one unified strong billing system across all.
I’d add one tip: Do not change what is working.
Sometimes you just have to live with some legacy systems and employ different strategies (e.g., adjunct billing) to complement these systems. Many times the benefits of a transformation project are overestimated (due to politics, pride, you name it) and they just become a major headache for the CSP and a gigantic money pit.
Employing a comprehensive assessment to understand what your systems do and what the business demands – understanding the business before you commit to a technology solution – is an essential and often overlooked step on many transformation projects.
Absolutely right Ed, thanks. Actually another quote I didn’t use this time was ‘never, ever, ever, attempt to change the bill format in the middle of a major transformation.’ But yes, it is about internal disruption….
If I may…by “parity” I think one point is that it’s pretty easy to go through a transformation and end up with something which is less effective than what you had prior to the transformation. I also think we’re talking about avoiding business disruption; even a bill format change can disrupt the business. But you are absolutely right Geoff; carrying flaws from the old to the new environment is not only a cause of failure, it is a mark of failure. No one wants to be the CIO who has to tell the Board that $100 million later the company is no better off – or worse off – than it was before.
Alex
Good list I can see it on Letterman next week.
However I’m not totally clear what you mean by “Parity” in 6) above. Certainly the end customer should not see a massive change and in fact should be blissfully unaware that a billing system has changed. At same time “a need for internal parity” I believe is one of the primary causes of IT project failure. A Transformation project should not just be about technology (or driven by technology) but rather needs to be part of a business change. I don’t know how many times I’ve heard a customer say “but this is how I did it in our old system and I need your system to do it exactly the same way”.
This in turn relates to your point one above which I think needs to be strengthened in that it need sot be more than “sponsor” but an active participant with authority to say when the company has to change versus the new software being customized to fit old ways.
In terms of “hardest things” the parallel run and explaining to a customer that just because their old calculator thinks 2+2 = 4.5 doesn’t mean their new calculator should ignore that basic rules of math and accounting. In other words parallel runs often turn up as many errors in the old system as in the new system.
And we won’t even get into data migration of data that has been 2 or 3 transformations in the past already.