CSPs’ Role in Multi-Stakeholder Telecom Projects

Recently, the U.S. Air Force announced that it is shutting down its next-generation, billion-dollar logistics management software project after its implementation was consistently stalled, and goals went unmet. This multi-stakeholder project started in 2005 and was designed to save billions of dollars by streamlining supply chain management and replacing more than 200 legacy IT systems and 500 interfaces. With such promising benefits, the decision to scrap this project raises more questions than answers: Why did it take so long, and so much money, to realise this project wasn’t going to pan out? What planning process was in place that allowed this to happen?

Drawing Parallels with Telecom and OSS Projects

Projects in the telecom industry have similar implementation challenges, especially because of the numerous stakeholders involved like network suppliers, OSS/BSS vendors, system integrators, VAS providers, in-house IT and various communications service provider (CSP) departments. Such a landscape of not just stakeholders but also systems and processes results in high complexity and risk, meaning there are many ways project execution can go wrong. For instance, individual vendors may promise more than they can deliver, system integrators might not take end-to-end responsibility, and CSPs could miss some important details. These gaps in ownerships, stakes, understandings, initiatives and interoperability create a snowball effect over time, leading to project delays that could mean disaster.

Insistence on Collective Responsibility

To help prevent this, it’s important for CSPs to be very knowledgeable about the big picture apart from being very detail oriented. Knowing the big picture ensures that the CSP can keep a firm grasp on the various parties engaged, and to what capacity, as well as each party’s weight and significance during the course of a project. On the other hand, being detail-oriented ensures that the CSP knows how to negotiate a meaningful, clear and unrelenting scope of work for each party. The scope of work distributed across different stakeholders should be collectively exhaustive and aspects like dependencies and engagement service level agreements (SLAs) should be very clearly stated and agreed upon in advance.
This can ensure that any conflicts of interest are alleviated, so vendors can act in the best interest of the project at hand to guarantee its collective success. Vendors like Comptel can play a very leading and helpful role in bringing different parties together to agree on a clearly documented scope at the very outset. This can involve details such as key objectives, success factors, project scheduling and budgeting, and risks.

Ensuring a Collaborative Project Roadmap

In my opinion, the CSP’s role in ensuring a collaborative project roadmap involving OSS/BSS vendors and system integrators is crucial. CSPs can define project execution models at the very outset and play an important role in overall project leadership and governance to ensure delivery within the constraints of budget, time and scope.
Furthermore, it is the CSP’s leadership alone that can contain the many simultaneous business-to-business relationships at any cost and without letting any party indulge in a game of blames. Success being the only ultimate benchmark, CSPs should trickle it down to all of its suppliers in unequivocal terms.