Social Icons

Friday 28 March 2014

Spitting in the Soup: Part Two - On the hook.

Spitting in the Soup - part 2 - On the Hook

As a small boy, growing up in rural Nottinghamshire, a highlight of my week would be a trip to the local newsagents to buy another six-penny pack of American Civil War cards. Each wax-papered pack would contain about five random cards from a series of maybe 200 in total, plus a nominal one inch square of bright pink bubble gum. 

Amongst our gang of local village boys, by far the most treasured card was one depicting a poor Confederate soldier helplessly impaled through his torso on a huge angled wooden stake. He had a ghastly agonised expression on his face and blood seeping from an enormous chest wound. By any standards it was a horrific sight, unless of course you were aged seven. Nowadays, I often think back to that picture when I encounter those CIOs of telecom operators who are struggling to come to terms with their own uncomfortable predicaments. Not so much "on the hook" as "on the spike".



To understand the CIO's predicament, I should explain that a telecom BSS solution plays a similar role within a large telecoms organisation to that of the vital organs in the human body - say the heart, liver, and lungs. So, unfortunately when dealing with some vendors, once that BSS solution has been installed and implemented (of itself a major challenge), the operator is effectively "on the hook" to that BSS vendor, and as helpless as that poor Confederate soldier. Up until final implementation and cut-over from any previous system, there may still be a small window of opportunity to escape from the vendor's clutches (see Spitting in the Soup part 1). 

Painful but true

Once the new system has "gone live", and the project celebration party bunting has been taken down, the operator gradually becomes aware of some pretty unsettling home truths:

  • The vendor's A team, whose experience and skills were so valuable during the implementation project will gradually drift away to other higher priority (for the vendor) projects/clients, being replaced by inexperienced youngsters, whose industry training the operator seems to be unwittingly paying for.
  • The exciting vendor strategic road-map that was so key in convincing the sceptics on the system selection committee to originally choose that particular path from the various available options, drops from sight as though it had never actually existed. Any attempt to engage the vendor in a discussion about it is met with either a blank expression or hysterical laughter.
  • As the operator introduces new products and lines of business with corresponding new system requirements, the cost of such incremental system changes goes through the roof, and software is delivered late and with numerous bugs. Support levels deteriorate continuously. There is no other source for the software changes or software support, so the operator has literally nowhere to go. 
  • The vendor acquires another BSS business, and announces that the newly acquired company's application software will form the centre-piece of its exciting (for them maybe) new roadmap. The solution that the operator has just spent millions implementing is effectively relegated to legacy status with massively reduced R&D funding.

Sadly for our industry, these kind of post-implementation disappointments have become the rule rather than the exception in recent years. In most "normal" economic market models, vendors delivering poor levels of software, service, and value for money would quickly be driven out and replaced by vendors with better offerings. 

We don't have much choice with who we pick... 

Unfortunately, in the BSS market two powerful forces combine to create a stifling inertia that prevents the development of an efficient market. Firstly there are the enormous barriers to entry that face potential entrants into the BSS industry. BSS applications have increased massively in their complexity as operators have launched new lines of business, with so-called triple-play and quad-play operators now offering complex bundles of telecoms services. 

The expertise required to design and develop such applications is such that there are probably no more than a handful of businesses worldwide attempting to create new applications for the industry, despite analysts estimating the annual market size as being in excess of 15 billion dollars. (Gartner 2011 IRCM Magic Quadrant)    

Secondly, the costs of switching BSS solution are so high, and the negative business impact of switching so great - requiring the business to freeze itself for a year or more, that operators generally have little option, but to grin and bear it.  

So what is our disillusioned and disappointed CIO to do in such circumstances? The real secret of survival for CIOs is to ensure that such scenarios simply do not arise in the first place, with the key issue being that of vendor selection. In fact I would go so far as to say the secret of success here is in not just finding the right vendor, but in finding a vendor with the right people. Ultimately it is the vendor's service delivery team that you will be hugely reliant on, not their corporate image, stock exchange listing, plush executive offices, or extravagant entertaining.


So what is a CIO to do?


So to finish, here are a couple of free tips for anyone thinking of entering the minefield that is buying a new BSS:

Make sure that you meet the vendor staff who will be responsible for implementing your system. Get hold of their CVs and get references from their previous client projects. Make a careful note of their names (the good ones), and ensure that the project staffing list forms part of your implementation contract. Make this a show-stopping contractual point, and do NOT back down.

Negotiate tough, but fair service levels that are clear and measurable. Insist on contract terms that will require the vendor to meet the estimated cost of you having to replace their system in the event that service levels are repeatedly breached, or as an alternative, that will trigger the automatic release of the application source code from escrow. You don't really want to have to exercise either of these options, but they should both help to keep the vendor in line. 

In my next article, I will explore why "small IS beautiful" as far as BSS vendors is concerned, and why there are so few of us around.



1 comments :