Transformational Change

A revolution is a struggle to the death between the future and the past.”
Fidel Castro

In yesterday’s blog, we discussed the air-traffic controller analogy for incremental change to your OSS via the use of projects. Today we talk of transformational change.

Transformation has appeared in the Telco vernacular as a guiding vision of a future business state that is remarkably different from the current state (plus the plan to implement that future state of course). However, I see it as more a revolutionary change than a transformational change because there needs to be acknowledgement that we have to have destruction to make room for a more positive creation.

With virtualisation starting to establish a position of strength amongst network vendors and CSPs, I can envisage a period of revolutionary change to CSP networks upon us that will subsequently be mirrored by revolutionary OSS change projects.

As with transformation projects of the past, it will be relatively easy to build new OSS to manage the new network technologies in parallel to the remaining legacy OSS. This is not so much a transformation but a supplementary change. Supplementary change makes the B/OSS environment more problematic because it now has even more systems to manage as well as more data and interfaces to synchronise. Time to Market (TTM) of any prospective new services is also compromised.

A truly transformational project first requires a revolution – out with the old, in with the new. The old has to be attacked first in a war of Ruthless Simplification. Once completed, this then allows a simpler, stronger foundation on which to build the new. Ruthless Simplification also needs to be enforced on the new solutions as well.

Having worked on a Transformation project of immense proportions ($1B+), my strongest take-aways were:

  1. The overall vision wasn’t clear or simple
  2. There was negligible destruction of legacy. In fact the new systems were forced to integrate into legacy systems, making them even harder to remove in future
  3. The new build wasn’t simple enough. The program was broken into projects, many with designers who proved their capabilities through complexity rather than simplicity
  4. The relationship between integrator and CSP was far from symbiotic

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.