Modeling the Climb to Launch for STB Delivery Projects

Continuing with my aim of sharing the tools I use (and come to value) in running my own projects, in this post I'd like to share a simple, yet powerful tool, that can be used for scenario planning a typical Set-Top-Box Product Launch, which I've come to term as "The Climb to Launch".

To understand what I'm about to present in this post, you should at least familiarize yourself with some preliminary info:

• Set-Top-Box (STB) Release Process
• Set-Top-Box Release Campaign Concepts
• Managing Quality in DTV Projects
• Architectural Components in a DTV System
• Typical Programme Structure for DTV Projects

The last mile of any DTV project is the STB Delivery Project. It is widely accepted practice to deliver the components of the system (a.k.a. Backend or Headend), the core infrastructure that provides essential services to the to STB, well in advance of initiating the formal Test/Integration/Release phase of the STB project. Some might argue this is all very well in theory, and in a complicated system when delivering a brand new feature like Video On-Demand, where the entire value-chain is impacted, one cannot avoid the big-bang Integration/Test approach. I maintain this is just a very lazy approach to programme management that should be avoided at all costs! But that's a topic for another post...

A STB Delivery Project Manager has to implement a plan taking into account all the inputs and resulting outputs. Although there is always variability in these projects, the variability reduces as we approach the end of your typical Development phase, and enter the Stabilisation phase of the project. 

We can therefore, quite easily quantify the planning variables involved in the STB Delivery Plan, and use these variables as inputs into producing an overall delivery plan, as I'll explain below.

The STB-Planning Model

Based on the Release Campaign Process outlined in earlier posts, the STB Delivery Plan needs to target specific milestones in the Climb to Launch. I call it the Climb to Launch because it is literally that: A tenuous climb by the entire project team, working through instabilities, performance issues and errors in functionality and user experience, that must all be fixed in order to Launch. The resulting Excel Tool implementing my model produces a Gantt View that takes the shape of Steps leading up to Launch Milestone, hence I've coined the term "Climb to Launch":

Output from Planning Model showing "The Climb to Launch"

Key Planning Variables for the STB Delivery Manager

Again, I'm not advocating that STB Delivery PM is easy and can be solved by using a simplified modeling tool in Excel! A STB PM adds value by having a keen appreciation for the various systems impacted, development & integration processes and most importantly building effective relationships with various teams and stakeholders. It is also important the Delivery PM is well equipped with relevant domain knowledge, can hold technical conversations with ease, as well as have the ability to prioritize issues, despite ambiguity, conflicts & uncertainty.

Planning is no less an important activity for a Delivery PM or even Programme Manager, but spending too much time maintaining a plan on paper, instead of active involvement in the shaping, driving and maintaining of focus - is another recipe for disaster. Having said that, at the high level though, essentially all STB projects follow typical patterns and involve the following key planning milestones or variables:

• Availability of the STB Target Hardware to the rest of the Core Development team
• There is only so much a development team can do on a typical reference development platform
• The sooner the target hardware is made available, the sooner SI can start stabilization
• Software components of STB must also be available, i.e. fully development, tested & certified - this is especially true for the STB Loader, less so for accompanying Drivers

• Availability of Target Hardware Drivers
• This is the foundation of the STB platform. It is generally expected practice that Drivers are delivered, as far as possible, independent from related Middleware components. As long as the interface specification is solid and stable, this development can happen in a parallel stream.
• STB SI team must verify and accept the Drivers are fit-for-purpose and can sustain ongoing Development & Integration

• STB User Interface Application Component Development Complete
• Applicable if there's any new EPG development happening, impacts STB SI timelines

• STB Middleware Component Development Complete
• Applicable if there's any new Middleware development happening, impacts STB SI timelines

• Number of Cycles for STB SI to Stabilize and recommend suitable build on Target Hardware
• Assuming your SI team operate in fixed time-boxed iterations, this variable is a useful timeline multiplier

• Headend Components Development Complete
• Generally, the real STB stabilization phase can only begin once a suitable Headend System is in place that supports the majority of use cases required from the STB product

• End-to-End SI Deployment of Headend to Live
• Milestone that is useful for tracking - useful for Programme Management, informative for STB Delivery PM

• Number of days to time box STB SI Bug Fix / Release Cycle
• Length of SI release / bug fix cycles impact the timeline

• Number of days STB SI require to create a full stack build for further testing
• Necessary and useful to capture so that you don't underestimate the work involved by SI team in the initial bring up of the Software Stack. This doesn't happen by magic, and consumes time. 

• Number of Cycles to reserve for reaching First Major Milestone (Functionally Complete)
• For initial planning, and based on past projects - this is a variable that determines how long the initial stabilization phase is expected to take to hit the first real milestone of being fully Functionally Complete and ready for Closed-User-Group Testing

• Number of Cycles to reserve for reaching subsequent milestones, leading up to Wider Field Trials
• As above, similar penciling-in a slot to reserve for External Home User Testing

• Number of Cycles to allocate to Closed-User-Group (CUG) Testing
• As above - how long do we run the CUG stage for?

• Number of Cycles to allocate to Wider Field Trials (External Testing)
• As above - how long do we run the External Home Testing for?

• Earliest Indication of Launch Build Candidate
• Based on all the above, what then becomes the outlook for Product Launch?

The Modeling Tool - Example Use

Based on the above planning variables, the PM can model different scenarios. Typically one caters for Best Case, Worst Case and Most Likely scenarios. There is also the Three-Point Estimate technique that some PMs use to better quantify the estimates. I use this technique as guidance, but generally don't go down into the detail of mapping the probabilities of the different outcomes.

Suppose you were given a Programme to manage (but wasn't involved from the beginning) and the project itself has changed along the way to the latest Scenario. It's January 2010, almost a quarter way through the project, the business decides to change its mind: Brand new STB Hardware, New User Experience EPG, new Middleware and also new Headend. You're told that you need to deliver the project in 10 months, or else...

Clearly if you've been involved in STB projects as long as I have, you'll know immediately this project is a pipe dream. How do you report back to the Stakeholders, in a diplomatic way, that all the Stakeholders must be smoking something, or in La-La land, that they've never ran a Product Launch from the ground up on this scale before, and without any planning or analysis - you reject the deadline outright?? No matter how good your gut is, or hunch-base, you won't be taken seriously, unless you have some proof you've applied your mind to the scenarios, and things just don't add up.

But you don't have the luxury of time on your side to get into a detailed planning / analysis phase, with work breakdown estimations, etc. You need to summarize the plan at a high level, working through the various scenarios - this is where a tool comes in handy.

Below is a snapshot from the tool:

The Modeling tool

• Step 1: Input the dates / values for variables for the Tasks/Milestones offering the three Estimates: Best Case, Most Likely, Worst Case
• Step 2: Click on one of the Buttons to produce the Resulting Plan
• Step 3: Select the Variables you want to Fine Tune (using the + / - buttons)
• Step4: Repeat / Settle on an Acceptable View to Share with your Stakeholders

In the example project, you can work backwards with your deadline, adjust all the variables such that the plan meets the deadline - and the review the reality of achieving the plan with your stakeholders. You then sit with the primary stakeholders, along with the respective Project Managers to work through estimates that are more realistic. Use that as the baseline plan going forward.

The tool can also be used to summarize the key milestones, by automatically producing a milestones table:

Milestones Table Automatically Generated

Download the Tool Now!

Click on the above link to download a copy of the tool, please ensure you have Excel / Office 2010 or higher installed. As I use a Mac, the tool is best viewed on a Mac, preferably a 32 inch HD display. I will "port to Windows" when I have the time. Remember to enable Macros.

Concluding Remarks

This is a tool I keep in my own PM Toolbox. I use it as guidance to not only plan any new STB project, but also as a way of communicating not only to Stakeholders, but the entire Project Team, of the various scenarios and milestones we need to keep track of in achieving a successful Product Launch, on time or to realistically meet expectations. I have really made this into a generic tool only this year (2012), but again, the concepts and milestones are indeed common and applicable to any STB delivery project. I am hoping this could help some of the new PMs entering the DTV space, improving their ramp-up times.

Lastly, if you do take time to download and experiment with the tool, or even start using this in your own work, please get in touch, offering feedback as appropriate!