A critical gap that means most service platform (IMS/SDP) business cases keep failing

IMS (IP Multimedia Subsystem) continues to struggle in market acceptance for a variety of reasons.  Hugh Bradlow from Telstra did a good summary recently.  The SDP (Service Delivery Platform) through a lack of standardisation is becoming a vast architecture with multiple definitions.  Linking IMS and SDP would appear to be a sure-fire-way of killing any service platform business case.

In an IMS survey I did this year, two results of note are: an increase in uncertainty on whether IMS will be deployed, and deployment remains 2 years out for those planning IMS deployments.  In addition, some operators are bored and frustrated by the constant marketing on IMS and FMC (Fixed Mobile Convergence); they’re not being presented with a clear roadmap, rather they’re asked to ‘believe.’  There’s clearly a disconnect in the market.

Last year I built the IMS/NGN business case for an operator.  The NGN piece was relatively easy based upon operational savings, and accounted for the bulk of the investment.  However the service platform (IMS/SDP) business case proved difficult.  A critical gap in creating the case was the operator’s lack of a strategic services roadmap (SSR).  Within the operator the plan for services to be deployed that year was clear, but there was no stated plan in developing the customers experience over the next 2-4 years.

The SSR tends to fall into a gap between the CTO and CMO responsibilities.  The CTO focuses upon the platforms and technologies as enablers of general classes of services, while the CMO tends to focus upon operational matters to meet the current year’s targets.  The SSR is critical to the CTO because it defines the requirements the platforms and technologies must support, but the SSR must be driven from the customer facing side of the business.  The easiest answer is to make the accuracy and performance of the strategic services roadmap part of the CMO’s performance metrics.

But back to the IMS/NGN business case project.  In summary, we built a SSR, identifying which services the operator should brand versus what it should just enable, specific to the cultural and competitive environment of that operator.  For example, exposing their branded portal within communities (e.g. Facebook) as another route to market.  As a use case: why should people spend $1 gifting a picture onto a friend’s profile for their birthday, when they could spend that $1 on a cool ring-tone for them.  Creating the SSR is tough, and it’s not going to be right, but at least it’s a position from which the platform business case is easier to define.  And sets a timeline and prioritization on the capabilities within the platform, hence the operator can take an incremental approach to building their service platform, rather than defining a grand architecture and becoming a ‘prisoner of that architecture’.

I’ll be presenting more details on this experience at the SDP Asia 2007 conference in Singapore on the 26th-29th Nov.