What if your OSS transformation is already outdated before your project even begins and you don’t even know it yet? There’s one overlooked step that separates forward-thinking OSS teams from those stuck in the past. It’s a step that, if not implemented, leaves teams destined to introduce insignificant, incremental changes to their OSS (at best) in the future rather than being truly transformational.
For some customers, we’ve found this one critical step to be the most impactful part of our OSS transformation process.
Some clients just quickly gloss over this step in the Project Vision Session, which forms part of our transformation process. Others have turned a one-day workshop into a week long exercise involving all of their senior leadership team.
The diagram below describes the very high-level view of our OSS transformation process. In fact, we don’t just use it on OSS transformations – we’ve used the same high-level steps on small consultancy projects to hundred million dollar infrastructure build projects. Each of the steps shown is broken down further into many additional steps but in this article we’ll focus on Step 1.1 – The Project Vision. We’ll go even deeper than that. We’ll focus most of our attention on one single component of the project vision step.
[If you’re interested, you might also like to look at this earlier article that provides additional detail about how we use this OSS transformation process to plan the resources and budget needed for an OSS transformation project. However, we do hope you’ll come back and read the rest of today’s article too of course.]
We normally allocate a full-day workshop with key project stakeholders for step 1.1, the Project Vision. Sometimes it takes less than the full day. Other times, it takes much more. Almost all of our projects are scope-of-work (not time and materials), which incentivises getting the steps done fast and efficiently to deliver clients their required outcomes as fast as possible. However, I do prefer it when clients take their time on this step as it’s a strong indicator into how invested they are in the transformation. It also gives us a much deeper perspective into the client’s thinking, challenges, constraints, objectives, desires and much more.
OSS aren’t just a technical transformation project. They’re business transformation projects facilitated by OSS, so it’s great when senior stakeholders and execs invest heavily into this phase.
Like all of our methodologies, we adapt this approach to each customer and refine our models over time. However, general outline of The Vision Session consists of the following:
We should also clarify our intent here. The Vision Statement we’re talking about here is slightly different from the typical 5 year plan you might be used to. The world of OSS is changing too fast to create a set-and-forget plan for the next 5 years. Instead, what we’re aiming for is for clients / stakeholders to cast their minds 5 years into the future and imagine what that world *might* look like. And therefore what does the OSS look like If you’re designing for an environment that’s vastly different than today. We won’t know exactly what it will look like, but we certainly can estimate by doing future scenario planning exercises (like these examples 1, 2, 3, 4).
Now, down to the nitty-gritty. This is the part that almost no OSS Transformation Teams perform.
Their minds are thinking about what the OSS will look like the day after it’s handed over to operations. I know this because I thought like this for many years.
But I’d like to encourage you to think differently. Since the OSS we create will (hopefully) still be in operation at least 5-10 years after go-live, we need to think about how they will still be relevant then. This means we have to project forward to what the environment *might* look like 5-10 years from now.
Reframing is about shifting perspective – moving away from short-term improvements and instead envisioning what an OSS should look like far into the future. The first step in this process is defining the long-term vision. OSS transformation teams must ask themselves: What will the industry landscape look like in a decade? What new technologies, business models, or regulatory changes could reshape how OSS operates? Without taking this forward-thinking approach, teams risk implementing what’s already in place yesterday / today and is therefore outdated before they’re even deployed.
Next, teams must challenge existing assumptions and limitations. This involves questioning why things are done a certain way and identifying legacy constraints that no longer serve a purpose. Are current architectures designed for flexibility and scalability? Will the OSS support emerging technologies like AI-driven automation, cloud-native architectures, or new customer engagement models? Are these technologies and techniques already showing signs of becoming usurped? By breaking free from current-state (outdated) thinking, teams can reframe their approach from maintaining the status quo to designing for the future.
Finally, aligning with business and technology evolution is critical. OSS doesn’t operate in isolation. It must support the client’s broader strategy. This means anticipating corporate shifts such as mergers and acquisitions (M&A), product diversification, ever-shrinking arbitrage opportunities or evolving go-to-market (GTM) models. A reframing exercise should involve key stakeholders who have a long-term vision for the company across business, IT and operations to ensure relevance and alignment.
The ideal outcome from this workshop is a future-state OSS vision that is strategically aligned, adaptable to change, and resilient against obsolescence – one that enables transformation the organisation rather than constraining it. You can never predict the future in this crazy world of OSS, but conducting scenario planning can allow you to project into a future of possibilities.
“No matter what future takes place, you are much more likely to be ready for it – and influential in it – if you have thought seriously about scenarios.”
Peter Schwartz
With technology changes such as AI proliferating quickly, the environments in which our OSS operate are evolving rapidly. It’s incumbent on us to design solutions that are set up to thrive in these future scenarios rather than being constrained by the worlds we’ve known from our past.
Hat-tips to:
We love doing The Passionate About OSS Podcast, but it’s been a loooong time between episodes. Too long. We love the conversations, but the
After working with countless OSS product teams over the years, we’ve noticed one universal truth: they’re all overloaded by huge backlogs of feature requests. But
Yesterday marked a an exciting milestone for the PAOSS business. We made our very first commission payment to an affiliate whose introduction led to a
Your OSS is either a catalyst for innovation or a roadblock to progress for your business. The same strategies that built your OSS might now
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
