Countdown to Success

SUCCESS AS AN MVNO is based on a differentiated brand, unique data services and content, and the expectation of a lucrative customer segment. It is not surprising that in the excitement around MVNOs, which include prospects like Hustler and P. Diddy as well as heavyweights like Disney, we dont often hear mention of a more robust IT OSS infrastructure as a key enabler to long-term MVNO success. However, MVNO launch dates are as likely to be made and broken by technology components as by any other function.

This article outlines some of the key technology-focused lessons that help MVNOs reduce last-minute technology-related crises.

First off, dont delay in ramping up the technology crew. Technology can be a tremendous enabler or limiter of the ability to offer and bill for differentiated services and provide customer service. Therefore, involvement of critical and experienced technology resources early on is important to ensuring that decisions made at all aspects of the MVNO service offering incorporate an IT viewpoint about the ability of systems to support, augment, and streamline the objectives of the MVNO.

It is important to staff this function with the right people up front, prior to the finalization of MVNE and other technology partner contracts. While any cost-conscious MVNO may consider deferring the ramp-up of this team to as late as possible, this approach can have significant long-term costs. Once contracts have been finalized without experienced technology input, the ability to effectively dictate interim milestones, alignment of functionality delivery across partners, and key items like code, test case and other quality reviews is severely constrained.

Secondly, implement mature systems integration and partner management processes, metrics and audits. The management processes implemented by the MVNO leadership team should include the following key elements to allow the technology implementation of an MVNO to proceed to a timely, on-budget launch:


Project plan reviews are critical to ensure milestones are realistic, achievable, and dont delay critical project risks until just prior to launch. A hallmark of good planning is working with partner MVNEs to identify iterative targets for delivery of key milestones so that the launch date doesnt hinge on a handful of big bang code drops that could jeopardize the plan if any of these slipped.

Insight into partner completion against the plan is a key part

of assessing overall project health, in order to be able to make adjustments at the earliest possible point. At least a couple of hard and stressful course corrections, or worse, are to be expected.

Dont skimp on staffing the implementation and monitoring of these processes.

Even a fully outsourced hosting strategy requires an internal technology leadership and oversight function to ensure components delivered by partner MVNEs and other providers meet the customized requirements of your MVNO. This is equivalent to still needing an experienced general contractor to coordinate all functions of building a house or office building, even though all construction contractors are highly qualified.

The issue is that technology components invariably will have some integration incompatibilities. In order to overcome this, the MVNO must have an experienced technology program management team to guide the discussions of which partners must flex to support integration to other components. Without a small team of technologists who are directly tied to the success criteria of the MVNO, the discussions between partner MVNEs concerning integration and other scope and functionality issues are at risk of deviating from the MVNOs objectives.

Manage vendors.

Monthly cross-partner meetings, moderated by the MVNO technology leadership group, are a valuable practice for getting the leadership of the different MVNEs and technology suppliers into the same room to address the issues du jour.


The execution phase of implementing the technology of an MVNO infrastructure generally will lie mostly within the domain of MVNEs and technology partners, which will implement or customize their solutions for the MVNO. However, here are some key best practices that provide the glue between various hosted or turnkey MVNE and vendor solutions:

Dont underestimate connectivity.

There is significant planning, tracking and escalation required to support the connectivity required to deliver an integrated MVNO IT platform across multiple disparate MVNE data centers. This set of tasks needs to be accounted for early enough to ensure that development, test, staging and production connections are up and running.

The help desk function is key

to supporting triage of issues that will span partner environments, connectivity and code bases. It may seem that partners should own this function. However, the optimal approach is to have the MVNO drive and monitor the resolution of any customerimpacting technology platform issues so that all customer service issues are known to, and resolvable by, the MVNO. This is especially vital in any cross-partner environment, where the human inclination to search for the root of the problem in the other partners domains will surface. The help desk ideally should be brought up during the execution stage, so it can be validated and operational during testing.


Testing is one of the most critical functions for the MVNO technology team. Solutions developed or customized by partner MVNEs and other technology providers must be evaluated for interoperability, robustness, ease of use and seamless customer experience. Here are some key lessons learned around this pivotal stage in the process:

Engage an independent, MVNO quality assurance team

to perform testing across all parts of the project. This ensures the biases and objectives of the testing team are aligned with the MVNOs objectives. Ensure this team has requirements to work with that support the definition of substantive test cases that match MVNO acceptance criteria.

Focus early on assuring a smooth final testing effort.

Dont fall into the dangerous trap of shrinking the quality assurance window as individual development items slip.

Instead, identify components of cross-platform functionality that approach a semblance of end-to-end functionality and manage toward timely completion and entry into testing of as many of these components as possible in order to facilitate early identification and correction of defects.

Focus on end-to-end tests

that span the customer experience and MVNO support tasks that are required across platforms. The keys for effective testing given the inevitable constraints during launch mode is to avoid extensively duplicating the partner component tests, and to focus on the cross-partner integration tests that in many cases will be tested the first time by your MVNO test team.

Validate testing plans

for various testing phases to ensure the vendor testing plans line up with or exceed your MVNO quality standards, timelines and reporting needs.

Evaluate vendor component test plans

and ensure the MVNO has insight into the defects found by MVNE partners as they test their individual solutions. This is critical, especially for a multitenant MVNE solution. MVNOs may have contractual gating criteria in place that govern when a release by a MVNE partner can proceed into production, based on how many high-severity defects exist. This, of course, can pose a strategic risk to any new MVNO. Other customers of a MVNE could delay a release critical to your launch because an enhancement specific to them still has more than the allowed number of gating defects.

Actively manage integration testing.

Integration tests are one of the most crucial elements in ensuring an MVNOs success. The best way to gain insight into potential problems is to structure partner agreements so they align development of specific functions, and support integration as each function is ready. The more risky alternative is to have partners do their development in silos and integrate at the end. The objective of early integration testing is to expose issues soon enough to allow adequate time to address these within launch timeline constraints.

Realistically, one cant expect to align all development across the program. However, identifying the key value propositions and the highest risk components, and organizing around the integration of these components, can reduce integration challenges close to launch. Given the potential for interpartner contention and fingerpointing, the integration function is one that will require active management from the MVNO technology team.

Use acceptance testing to assess final launch readiness.

A substantial period of time should be dedicated to acceptance tests. These should include the full range of MVNO stakeholders, from CSRs to friendly customers (usually MVNO staff) to the help desk. The acceptance test phase is a critical component of shaking out the production environments, ordering, activation, billing and care processes, application, environment and connectivity support processes, as well as escalation paths. Acceptance testing should not replace, or even shorten, the prior quality assurance process managed by the MVNO test team. Finally, only when acceptance tests clearly indicate that all key issues have been resolved, should the MVNO proceed to a market launch.

Of course, stakeholder expectations within any MVNO must be managed closely, recognizing that if the quest for IT perfection is not tempered by a healthy dose of pragmatism, launch could be delayed indefinitely. A good mantra for assessing launch readiness is to not address all defects, but to focus on ironing out the customerimpacting wrinkles you wouldnt want Walter Mossberg from the Wall Street Journal to experience when he tries out your service.

Track completion of tests, defects logged, fix rates for the component test, integration test and end-to-end test phases.

Monitoring testing progress is a key component of monitoring project health and positioning yourself for early triage of emerging problems. Items to watch out for include:

  • Component code quality issues that may signal a lack of readiness for launch.
  • Long partner lead times in adhering to SLAs for defect correction could indicate resource issues that may significantly slow mission-critical code fixes if the need were to arise.
  • Unavailability of key system functionality may require an adjustment of marketing materials for regulatory reasons.
  • Inability to support certain distribution channels may require an adjustment of handset orders, call center and help desk sizing, and financial plans.

A set of testing dashboards that track defects by partner and severity, as well as defect aging and closure rates can provide critical insights into potential risk areas that call for additional attention or efforts.

Fleming Schutrumpf is a principal consultant with BoldTech Systems Inc., a 10- year-old international consulting firm with a focus on rapid delivery of telecom BSS/OSS functionality using agile methodologies. Schutrumpf focuses on program management of large, mission- critical projects, and recently helped launch a major MVNO. You can contact him at

BoldTech Systems Inc.

Leave a comment

Your email address will not be published. Required fields are marked *

The ID is: 70975