Case study: How a major broadcaster managed the risks of a switch from cable TV to streaming

I worked as a program and risk consultant on a major digital transformation project. It involved working with a broadcast organisation to replace traditional cable TV with a streaming service.

My role was to guide this initiative, which involved navigating through different project management methodologies, managing change and mitigating risks across onsite and off shore teams.

NAVIGATING AN AMBITIOUS PROJECT

When I joined the program, it was clear that this wasn’t just about launching a new app. It was about transforming the entire way millions of people consumed television.

The project was ambitious, involving both the creation of a user-friendly app and the streaming service. The excitement was high, but so were the risks.

Early on, I identified several key risks. Change management was at the top of the list.

Transitioning users from a familiar cable TV setup to a new streaming platform was a massive shift, and if not handled correctly, it could lead to significant customer churn.

“The stakes were high – any technical failures could lead to dissatisfaction and damage to the brand’s reputation.”

Program management was another major challenge, especially given the mixed methodologies we were dealing with. While a waterfall approach is a linear approach where each phase is completed in turn, an agile approach sees the team work simultaneously on different phases.

Parts of this project, such as infrastructure development, were being managed using a traditional waterfall approach, while the app development and user interface were being handled in an agile environment. This amalgamation added complexity to coordination and risk management.

Finally, there was risk management itself. The stakes were high – any technical failures could lead to dissatisfaction and damage to the brand’s reputation.

My role was to ensure that these risks were identified early and managed effectively throughout the program.

ADAPTING TO EVOLVING RISKS

As the program progressed, some risks evolved in ways that required cross-functional coordination.

Vendor reliability became a significant issue in the waterfall environment. We were dependent on third-party providers for key components of the infrastructure, and when one vendor failed to meet a critical deadline, it threatened to derail the entire schedule.

In response, I advised the team to activate contingency plans, bringing in backup vendors and reallocating resources to mitigate the impact.

In the agile environment, timeline delays began to creep in as technical challenges mounted. While the team was able to adapt quickly to changing requirements, the constant evolution of the product meant that some features took longer to develop than anticipated.

I worked with the agile team to prioritise the most critical features, ensuring that we stayed on track for our planned release date.

Throughout the program, market demand was a constant concern. In a rapidly changing market, we needed to ensure that our product remained competitive.

Midway through the program, we realised that new competitors were launching similar services, forcing us to reconsider our feature set. The agile team was able to pivot quickly, adding new features to stay competitive, while the waterfall team worked on ensuring that the backend could support these new capabilities.

MANAGING VENDOR RELIABILITY

We were heavily reliant on a third-party vendor to deliver a critical component of the infrastructure — specifically, the content delivery network (CDN) that was essential for streaming video to millions of users.

The vendor had a strong reputation, and we had conducted due diligence, but as the program advanced, it became clear that they were struggling to meet our deadlines.

This risk had been identified early on, but its full impact wasn’t felt until we were deep into the program, with only weeks to go before a key launch date.

When the vendor missed a critical delivery deadline, it immediately put our timeline at risk. Recognising the severity of the situation, we convened an emergency meeting with the onsite and off shore teams, as well as the vendor.

“To minimise the impact on the overall project, we reallocated resources from non-critical areas to focus on the integration of the new vendor’s solution”

After assessing the extent of the delay and its potential impact on the project timeline, it became clear that the vendor would not be able to meet the revised deadlines without compromising quality — a risk we could not take.

Fortunately, we had anticipated the possibility of such a scenario and had developed contingency plans early in the project. These plans included identifying alternative vendors who could step in if needed.

We immediately reached out to an alternative vendor we had vetted earlier in the project. This vendor had the capability to deliver the necessary CDN services, but at a slightly higher cost and with a tight timeline.

We negotiated an expedited delivery schedule and began the transition process. Then, to minimise the impact on the overall project, we reallocated resources from non-critical areas to focus on the integration of the new vendor’s solution. This included bringing in additional technical expertise to ensure the integration process went smoothly.

We also initiated parallel testing with the new vendor’s solution to ensure that it met all performance and reliability standards and throughout this process, we kept all key stakeholders informed, including senior management and key external stakeholders.

COORDINATING WATERFALL AND AGILE TEAMS

One of the most significant challenges was managing risks across both waterfall and agile environments.

The infrastructure and backend development were being handled using a waterfall approach, where plans were more rigid, and risks had to be anticipated and mitigated early in the process. The app development and user interface were managed in an agile environment, which was more flexible but required constant adaptation to evolving requirements and risks.

I implemented a dual-track risk management strategy. For the waterfall teams, we conducted thorough upfront risk identification and assessments, focusing on areas like technical feasibility, vendor reliability and integration challenges. For the agile teams, I introduced iterative risk reviews as part of the sprint retrospectives.

This allowed us to identify emerging risks quickly and adjust our strategies accordingly. I also facilitated regular cross-team communication to ensure that any changes in the agile development process were aligned with the more structured waterfall approach.

BALANCING USER EXPECTATIONS

The risk in this transition was losing customers who were either resistant to change or who found the new platform difficult to use. Managing this while ensuring a smooth user experience was critical.

I worked with the change management team to develop a comprehensive strategy, creating detailed, user-friendly guides, videos and interactive 2D and 3D animated stories to help users transition.

“The risk in this transition was losing customers”

We implemented early beta testing with users to gather feedback on the platform’s usability. We also maintained transparent communication with users throughout the transition, highlighting the benefits of the new platform and addressing any concerns promptly.

By focusing on user training, iterative improvements and clear communication, we were able to manage the transition effectively and retain the company’s customer base.

WHAT I WOULD HAVE DONE DIFFERENTLY

I would have engaged with alternative vendors much earlier in the program with the support of the supply chain department, even running parallel pilot tests with them to ensure they were ready to step in if needed.

I also would have done more frequent and granular risk assessments.

Given the scale and complexity of the program, the initial risk identification and assessment were broad and focused on the most significant risks. However, as the program evolved, new risks emerged that we hadn’t fully anticipated in the early stages.

“It’s crucial that communication is not just regular but also timely and efficient.”

I would have implemented more frequent and granular risk identification and assessment, particularly at critical project milestones.

Other lessons include deeper integration of user feedback into risk management to ensure that the user perspective is always considered in risk management decisions and enhanced crossteam communication protocols.

It’s crucial that communication is not just regular but also timely and efficient.

Yasir Masood is a program and risk consultant for small and capital projects for GleeYM.