Successful Service Launch

To the joy of delivery managers everywhere, media technology and agile development methodologies have reduced the need for hard launches and enabled lower risk approaches for the implementation of new services. But the requirement for ‘big bang’ launches hasn’t completely gone away. We explore some techniques to avoid getting burnt in the bang [blast] and enjoy a trouble-free transition to service.

As the media technology industry has become more ‘IT’ and less old school ‘ broadcast’ centric over the last 20 years the approach to project delivery has benefitted as much as the commoditisation of the technology.

An agile and incremental project implementation approach provides rapid benefits-realisation with low risk. An approach which elaborates on a base end-to-end capability, or a Minimum Viable Product (MVP) allows for hypotheses to be tested quickly and for requirements to emerge through an iterative delivery. In terms of outcomes, providing the overall vision for a project is well defined, there is no better approach.

With the increasing accessibility of cloud-based infrastructure, operators regularly plan projects based on an incremental service migration rather than ‘a launch’. In this context, transition to service is continuous and undisruptive. Blue Lucy are great proponents of incremental migrations and soft launches of new services. But there are inevitably cases, such as move to a new studio facility, where a ‘big bang’ launch is unavoidable.

BANG

The big bang transition to service can be terrifying for delivery managers, especially for established television services on which every freeze frame, wrong package and startled presenter will be noticed by a hawk-eyed audience of thousands.

Further pressure may come from immovable deadlines such as the date by which a building needs to be vacated or project sponsors who wish to see a timely return on investment.

Here’s some advice on how to avoid getting burned on the big day, and the period that follows.

Plan the Launch from the Outset

At the highest-level, break down a large project or programme into three logical and overlapping phases of:

• Define and Design (DD)
• Build and Deploy (BD)
• Training and Transition to Service (TTS)

All programmes are different but typically the phases are of approximately equally duration and cost. Each phase is also of equal importance and ‘robbing’ funds from the TTS phase during the earlier phases is a common mistake which should be avoided. New tools, which operators are unfamiliar with and cause error, will quickly negate a diligent design and build. Ring-fence, to use government parlance, the allocated budget in all phases. Tech is not more essential than training – the operation must come first.

Training and Operational Shakedown

The training plans should be developed early, immediately after the definition and design phase, during the build phase. A good starting point for this is to reuse the workflows defined during the design.

Training approach and materials should be contextual, operationally focused and framed on user journeys. Training should also be system focused, avoid breaking down the training by technology. A system may breakdown into specific technologies but the operation rarely follows the same pattern.

If possible operational training should take place on the new systems, as opposed to a specific training set-up, as this will assist in the system shakedown. The shakedown (which should shake out any bugs which weren’t captured in unit or integration testing) is most effective if it’s ‘as live’ – as it is in training and rehearsals.

Continually Monitor Status

In the weeks running up to a launch, the operational training, system testing and rehearsals will be a busy, and resource intensive, time. Project status monitoring through this period is best focused on the question of readiness: are the operational and technical teams ready? This warrants a checklist. As with many aspects of good project management, the checklist is just common sense with the skill residing in the assessment of the answers to those questions and any resulting action.

• Are new operational processes and workflows defined?
• Is there a common understanding amongst the operational teams of what the planned launch looks like?
• Is the technical solution to support the operation in place? Infrastructure installation complete? What is missing? When will it be available?
• Has workflow-based training been undertaken by operational teams on complete and integrated systems?
• Are any required operational workarounds or interim processes in place and reliable?
• Are the migration processes and roles and responsibilities fully defined?
• Is the technical and operational runbook (usually an intranet wiki) in place and up to date?
• Are external suppliers and internal technology departments ready for launch?
• Are software installations, including any bespoke developments or integrations, complete?
• Is testing, shakedown (as live operational testing) and loading complete?
• Are the plans for the migration from existing systems in place and robust?
• Have system failure and recovery scenarios been exercised?
• Have rollback or back-out scenarios been defined and exercised?

Deliver Sustaining, and Sustainable Services

The big bang launch is resource intensive and there is invariably a disproportionate focus on launch zero hour. The most experienced operational team will be deployed for the big day and the project delivery team will be on hand to deal with any teething troubles.

That’s great for the first day, but do ensure the resource plan extends for whatever period is necessary to transition to an operationally sustainable service. It is no co-incidence that most problems occur when the project team has disbanded a few weeks after an apparently successful launch.

We Aren’t Ready

There may be a compelling reason for a launch to occur before the checklist is sufficiently ticked off – i.e. before the operational teams are ready. This will need additional operational resource to sustain and complete the delivery. Completing an implementation on a live system is always protracted and therefore expensive. Good project governance will try and calculate the cost of overrun so that a balanced judgement can be made by sponsors on the GO/NOGO calls. Is a delay, if possible, less expensive than hitting an arbitrary deadline?

At Blue Lucy we prefer and advocate Softly, Softly but if Bang is what you need we are experienced enough to be flame retardant.