Sharing insights

In vain have you acquired knowledge if you have not imparted it to others.”
Deuteronomy Rabbah
.

When implementing an OSS for a customer, I love getting hold of their real data because then their environment seems to become clearer. The more aspects of the data you investigate, the more the flower unfurls. The more their network, their services, their processes, their issues and so much more also become clearer.

Unfortunately it has only just dawned on me that as the implementation team, we have to do a better job of sharing these insights with key stakeholders and influencers within the customer. Implementation teams will usually have subject matter experts and sometimes data analysts to support the data migration team but most of the data they collate is for their own purpose of populating the OSS database to make sure their applications work well.

As the implementation team, shouldn’t we take a scientific approach to sharing the insights we’re gaining as we work our way through the data? Shouldn’t we share these gems of wisdom with all levels within the customer to inform them and excite them that this project is delivering great value to their organisation before they even receive the operational handover?

Afterall, isn’t that what our OSS tools are supposed to do – uncover the gems, not just collect reams of useless data? As experts in the systems we’re implementing, shouldn’t we be raising the knowledge bar for what the customer expects to gain from our systems even after their staff take over the reins?

I’m sad to say that up until now, I’ve never built “sharing insight” into the list of deliverables that the project team, and data team in particular, must develop. I do feel comfortable in saying that I’ve always tried to share insights with customers, I just have never written it in stone before.

There’s just one potential downside to this knowledge sharing and it may require great diplomacy. The data often reveals flaws or gaps in the way that the customer has operated, which can lead to embarrassment and a loss of face for the customer or its representatives. To implement broad-ranging organisational change via your OSS, you rely on maintaining strong relationships, working with many participants like the conductor of an orchestra. Loss of face can lead to loss of trust by some of those participants. Consider your approach carefully.

I once lost access to a customer’s whole network operations division (which we were highly reliant upon of course) because one of my colleagues publicly humiliated them for their network, which was unsophisticated in many ways. We never fully recovered during the ensuing two years of delivering that solution.

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

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

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.