Adaptive broadcast systems engineering

In the last two Transition to Digital newsletters, traditional and contemporary engineering process management methods were discussed. Using a capability matrix model to assess process efficiency implies a traditional waterfall project methodology. Each step is clearly defined and completed before the next step begins; this is an essentially linear process. Any major change in requirements or unanticipated delays can wreck the project schedule.

On the other side of the spectrum, agile programming (AP) methods address the reality of rapidly changing user requirements inherent in software development. Yet in this apparent chaos, there is a clearly defined set of principles and practices that are comprehensively adhered to. The key to the agile methodology is short, iterative design cycles, star team members and continuous communication with the client.

Design, construction and commissioning of contemporary broadcast media infrastructures obviously contains tasks and challenges that are best addressed with either of these two apparently diametrically opposed project management techniques. But, blindly following one rigidly defined method for every project will not work best under all circumstances.

The challenge of integrating digital systems

Envision the current integrated digital broadcast infrastructure design scenario as that of a small waterfall, or rapids, following the course of the riverbed, but with the individual molecules of water each following their own varied path.

Prior to networked, IT-based production, broadcast systems were divided by functionality and stood alone. Now, they are all integrated over an IT infrastructure, requiring systems to rely on each other, and to a strong and adaptable infrastructure.

A natural selection

Upon analysis, the design of a digital broadcast infrastructure can be logically divided into areas where either the traditional waterfall or AP method is the best fit. For example, the SDI distribution network is a stable technology, and a long-term investment. Any error in design or implementation will be difficult to correct later. Once installed, the system will only require expansion, not a complete redesign. This is an area where the waterfall design process is a natural fit.

The evolution to 3Gb/s transmission can be considered a design iteration, and though not as short as weeks or months, could be considered from an AP point of view. How will going to 3Gb/s impact the entire production and broadcast operation; how can this be leveraged to improve efficiency? The Six Sigma process seems most applicable here.

Or, if a team is designing a media asset management application, every new audio or video codec requires a new software module. As users get acquainted with the GUI, in all likelihood, they will suggest new features that need to be incorporated. An AP project management process fits best here. As the project management team traverses the “rapids,” contingency plans can be put in place that take an agile approach in response to changing requirements. In other words, plan ahead for change.

AP can be applied to a hardware-based project as well. For instance, monitors may be needed for a control room, and the rapid improvements in monitor technology combined with dropping prices will likely result in a selected model being eclipsed by a later design. So, it may be best to practice just-in-time procurement, taking into account order delivery lead time. But there is a risk in that if delivery is late, your control room may be completed and waiting for the monitors.

In general, waterfall techniques fit best with platform, infrastructure projects while agile methods work well with features. This roughly follows a hardware/software system division.

To make the adaptive approach work, broadcasters and engineers must stay ahead of the technology curve. Participation in technical community standards activity, attendance at conferences where emerging technology is discussed and a dialog with vendors about new features will enable an organization to better judge what will be available in the future, and how to stay adaptable enough to benefit from it.

A combined methodology

Can two such disparate project management methods be reconciled in modern broadcast engineering, selecting the best of each? Just as IT and traditional video engineering are producing a new technical discipline of media system engineering, so too can traditional waterfall project management and AP techniques forge a new project management methodology.

In fact, this is exactly what media system engineering requires for integrated technology systems to be successfully and robustly designed, deployed, commissioned and maintained. By appropriately applying the processes of both paradigms, an adaptive model can be applied to engineering broadcast media systems.

Determining what parts of a project should be managed by waterfall techniques and which lend themselves to agile methods will not always be easy. Risk management is always a part of good project management and can help with the decision of which methodology to use where. Applying risk evaluation can instill organizational confidence in an adaptive approach to broadcast media systems engineering.

A scenario

Consider this scenario: a broadcaster has decided to consolidate all its graphics resources into one centralized location. This includes a SAN, GFX render farm, SDI routing to multiple displays and new workstations and applications — a multimillion-dollar project that will take nine months to design, construct and commission.

When the design begins, the project scope requires that the GFX produced will only be used in broadcast programming. The budget and schedule is approved, equipment is specified and construction scheduled. Three months elapse and everything is on target and on budget.

The organization also maintains a Web site and has moved into mobile/handheld repurposed content delivery. Executive marketing management has decided that consistency of GFX images across all delivery channels will ensure brand awareness among consumers. They are faced with two options: develop an independent GFX production process for each channel or transcode and reformat GFX for each channel on the fly.

Management communicates to engineering that one GFX process should support all channels, and because a new GFX workspace and infrastructure project is underway, it should be adapted to meet the new multiplatform delivery requirements. There is also one more constraint — the project schedule and budget cannot be altered.

This is exactly the scenario that calls for both waterfall and agile project management. If a systems engineering department follows a formalized design and implementation process, they are now faced with abandoning this ordered methodology and will use ad-hoc procedures to get the job done. If agile broadcast system engineering is practiced, however, the engineers could successfully respond to the change in project requirements while designing a solid foundation infrastructure.

Additional Reading

Extreme Programming and the Capability Maturity Model, Ron Jeffries
http://www.xprogramming.com/xpmag/xp_and_cmm.htm

CMM –Compliant XP, Alan S. Koch
http://www.askprocess.com/Articles/CMM-XP.pdf

Extreme Programming from a CMM Perspective, Mark C. Paulk
www.sei.cmu.edu/publications/articles/paulk/xp-from-a-cmm-perspective.html

CMMI and the Balance of Discipline and Agility, Barry Boehm
www.dtic.mil/ndia/2002cmmi/boehm.pdf