When we have a big OSS transformation to undertake, we tend to start with the use cases / requirements, work our way through the technical solution and build up an implementation plan before delivering it (yes, I’ve heavily reduced the real number of steps there!).
However, we sometimes overlook the organisational change management part. That’s the process of getting the customer’s organisation aligned to assist with the transformation, not to mention being fully skilled up to accept handover into operations. I’ve seen OSS projects that were nearly perfect technically, but ultimately doomed because the customer wasn’t ready to accept handover. Seasoned OSS veterans probably already have plans in place for handling organisational change through stakeholder management, training, testing, thorough handover-to-ops processes, etc. You can find some hints on the Free Stuff pages here on PAOSS.
In addition, long-time readers here on PAOSS have probably already seen a few posts about organisational management, but there’s a new gotcha that I’d like to add to the mix today – the changing operating model. This one is often overlooked. The changes made in a next-gen OSS can often have profound changes on the to-be organisation chart. Roles and responsibilities that used to be clearly defined now become blurred and obsoleted by the new solution.
This is particularly true for modern delivery models where cloud, virtualisation, as-a-service, etc change the dynamic. Demarcation points between IT, operations, networks, marketing, products, third-party suppliers, etc can need complete reconsideration. The most challenging part about understanding the re-mapping of operating models is that we often can’t even predict what they will be until we start using the new solution and refining our processes in-flight. We can start with a RACI and a bunch of “what if?” assumptions / scenarios to capture new operational mappings, but you can almost bet that it will need ongoing refinement.
Earlier this week, I was lucky enough to be introduced to a talented RAN automation expert. He’s one of Australia’s foremost, hands-on, experts on SON
I was listening to a group of telco experts on a podcast the other day. As they were talking, I kept picturing the image of
Earlier in the year, we wrote a series of articles about the chasm that exists between OSS/BSS buyers and sellers (pt1, pt2, pt3, pt4, pt5, pt6). “The chasm” is
Actually, maybe a few related questions. As you’ve seen from recent articles such as this, I’m increasingly interested in the cross-over worlds of comms and
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.
4 Responses
What if we built OSS and IT systems around people’s willingness to change instead of against corporate goals and metrics? Would the corporation be worst off at the end?
Brilliant question Roland! The answer probably has more facets than a brilliant-cut diamond – different within each organisation and changing over time.
For examples: if only workarounds to problems that were driving operators crazy were implemented, then it would be much easier to make an implementation happen and get accepted; If operators all had conflicting opinions then gridlock would be reached or only the smallest of changes could ever get through and no exponential improvements could be delivered; If network and IT groups were caught in a political war then…??? 🙂
It would be a fascinating study to analyse the success (or otherwise) of all the different projects across all the different OSS and see the results wouldn’t it? I wonder whether the OSS with no system change, but process-based workarounds, might actually be the most efficient (but do us all out of jobs)???
What are your thoughts Roland?
What I meant to say is that we all get caught in requirements definitions (which are often features in disguise) and feature descriptions. What if we started by asking the question “What do you want to change?” and try to steer clear of answers “I want this feature or implement this process”, but foster answers like “I want to get rid of this work item” and even “I do not want change because I am afraid of becoming irrelevant”. The problem is that very few people are trained like that, and certainly not in the engineering professions. And it is not the CIO/CTO alone that can deal with it.
So true Roland! One of the first dictums of stakeholder management is if you involve a person in a change, you’re more likely to get their support to make the change than if you thrust change upon them. But in OSS we tend to thrust rather than ask 🙂