Telstra IT transformation woes

I was about to write some more about the networked society but this article by Michael Sainsbury caught my eye: Telstra trauma as tranformation costs mount.

This is a sad, but all to common, tale of a large organisation that desperately needs to update its core systems, and to integrate the various acquisitions over the years into a single system. And, like most telco disasters, this one is centred around a billing system, which necessarily also includes customer information management systems. It is getting hard to keep count of the billing system disasters that unfold with monotonous regularity.

For Telstra the problem is a myriad of different systems billing and customer management systems that have evolved or been acquired over many years. The goal is to get them all onto a single system to achieve vast savings and make it easier to move staff around without retraining them. Some of my sources have told hilarious stories of the arcane, arbitrary  and mysterious nature of some of the billing systems over the years.

Mr Trujillo appears to have trod the road followed by so many previous leaders of large companies:

  1. announce large and expensive transformative IT program;
  2. bring in a bunch of consultants to run it;
  3. sideline the internal staff who have a clue about some of the actual challenges in implementing such an ambitious program;
  4. completely underestimate the scale and complexity of the task embarked upon;
  5. not chunk up delivery into bite sized pieces so that failures and problems are minimised in their impact;
  6. fail to understand the appropriate level of governance required to ensure effective delivery;
  7. and, resign and leave the country before the program is completed.

According to Sainsbury, the essential next phase of any large enterprise project disaster is already underway – i.e. run for cover and blame people who’ve left for the entire problem:

The Australian understands a number of the candidates are now trying to distance themselves from Mr Trujillo’s management-consultant-led program and have highlighted a range of areas in which the transformation is over budget, over time and not meeting its targets.

This is not a problem to be taken lightly for one of Australia’s most significant corporations. The impact of this program’s failure will translate into pain for shareholders, as Sainsbury notes:

The biggest problem for the company is the IT overhaul, the centrepiece of which is a problematic new billing and customer service platform.

It is now well behind schedule and over budget … and this will delay Mr Trujillo’s promise of improved earnings.

It is very frustrating to see the same drama played out over and over again in different companies. It is especially exasperating when there exists an enormous body of knowledge about how to run successful projects. It’s always worth checking out Michael Krigsman on the topic of IT project failures and how to avoid them.

Psychology of why reuse fails – courtesy of GeekAndPoke

This amusing cartoon by Geek and Poke captures one of the important reasons why so much of our planned software reuse fails. Thus projects often fail to achieve the economy of scale benefits from the business case.

Within companies there is often little trust between departments and an unwillingness to rely upon things that other people have built.

The real question is how can we overcome this problem so as to achieve the benefits of shared resources and reuse?

The first step in resolving the problem for any organisation is recognition that this kind of problem exists. The next step is to bring the issue out into the open.

Often there are war stories within the business that explain how or why the lack of trust has evolved. It is important to uncover these reasons. Once things are out in the open they can be managed.

My rule of thumb for problems with technology projects is that about 70% of the problems are in our heads (us being all the people involved in the project), while the other 30% of problems are logistical (e.g. stuff takes longer to do than planned; or stuff gets delivered late).

Very rarely are the problems actually about the technology in and of itself. More often the problems that appear to be technical result from hidden issues with people that remain un-addressed, or architectural problems that lead to the selection of inappropriate hardware or software.

By Carruthers via Aide-mémoire
http://w.sharethis.com/widget/?tabs=web%2Cemail&charset=utf-8&services=facebook%2Cdigg%2Cstumbleupon%2Cdelicious%2Creddit%2Cblinklist%2Cnewsvine%2Cfurl%2Ctailrank%2Cmagnolia&style=rotate&publisher=91b467b0-fcb3-4e42-95e0-1f04ad0c9be9