Vendor Implementation

There comes a moment when you have to stop revving up the car and shove it into gear.”
David Mahoney

After engaging a vendor (or perhaps even an internal implementation team) to partner with your CSP, it is tempting to throw the OctopOSS over to them and expect them to deliver a bright, shiny new OSS with all the bells and whistles. Do this at your peril. They will deliver an OSS that they think you want or perhaps even what is easiest to deliver rather than what best fits your organisation’s needs. Remember that you are delegating, not abdicating responsibility for your OctopOSS. The CSP needs to lead, even if they delegate many of the implementation activities to the vendor.

There is no doubt that they will have great experience implementing their solutions, so you’ll seek to leverage this wealth of experience. However, you’ll also need to leverage the knowledge and experience of the CSP to deliver an outcome that suits their needs. You will best know the data, processes, networks, services, etc that you utilise on a daily basis and this is what will need to be modelled in the new OSS. Consider the analogy of a see-saw. It’s not a very fun game if only one team is involved. You need teams on both sides of the pivot for it to function.

The more involved your CSP gets during the implementation, the easier you will find the following tasks:

  • Understanding the applications you will use once they’re handed over into operations
  • Understanding the modelling of data to represent your network and services as well as having enough understanding of the applications to tweak the naming conventions and data modelling to better suit your mode of operation
  • Being able to confidently participate in User Acceptance Testing (UAT) and sign off with confidence that the solution will meet the needs of your CSP
  • Being able to communicate as peers with the vendor’s representatives to customise the solution to best meet your CSP’s needs
  • Being able to identify improvements and future possibilities for your CSP
  • Being able to identify risks / issues or areas where the vendor needs to improve

Steven Covey’s following Four Disciplines of Execution hold true for any OctopOSS implementation:

  1. Know the goal – The “players” on the combined vendor/CSP team all need to have a consistent understanding of the goal.
  2. Know what to do to achieve the goal – The players each have their own responsibilities to achieve in alignment with the overall goal. The player must also receive clear communications to understand and measure their responsibilities.
  3. Keep score – The players need to know where their team stands in relation to the goal at all times, as well as any variations required to re-align with the goal. A scoreboard provides a clear guide as to whether the team is leading or lagging. To continue the analogy, the count-down clock on the scoreboard is also an important guiding force to indicate how much time is left to play.
  4. Players are held accountable – All players are held accountable for their individual actions and results. A player who is not delivering to team objectives may require additional coaching or training. The players should know what things they can do this week to contribute towards lead measures and then be able to use the scoreboard to compare whether their actions have indeed contributed.

2 thoughts on “Vendor Implementation

  1. Hi,

    I’d like to get your thoughts on how to execute an OSS transformation program. As the OSS (or the OctopOSS as you put it) is made up of Fulfillment, Assurance and Inventory as major pillars / building blocks, it would be quite a big task implementing all these all at once.

    Should the program start with certain pillars first before others? Any dependencies that need to be accounted for?

  2. Hi Mikey,

    Brilliant question, thanks!

    It sure can be a big task implementing all these things at once. Not only is there the technical challenges, but there is also the organisational change that is often an even bigger challenge! (you can read more about that at

    But back to your question…
    Every situation is different, so there’s no one-size-fits-all answer (eg one organisation may have a business imperative to get inventory locked down and reconciling to prevent revenue leakage, another may have an OSS vendor that delivers all of these as part of core products [but it will still need lots of work to get it functioning as you need it], etc).

    But all things being equal, I would tend to take the following approach:
    1) As mentioned in the change management link above, you want to build momentum as quickly as possible and get the teams seeing visible progress as quickly as possible. I tend to do this by getting a base-level sand-pit environment set up to get people familiar with the product as it helps them see the future benefits as well as getting their head around what’s needed for the project and how it can be customised to suit the customer’s organisation
    2) Again to build momentum, and to follow the “smallest executable steps” approach, I tend to try to get a base level of assurance up and running first. For example, most alarm management tools support SNMP traps through compiling MIBs, so it can often be quite quick to get raw alarms into your alarm management system from your live network. That gets quick wins and excitement from the customer team. You can make all your refinements (eg alarm suppression, fault workflows, augmentation, etc) done later on
    3) Next quick win is collecting raw data for performance management, particularly if you have SNMP or XML-based performance counters available from your network. Just like alarm management, if you can get raw data into your performance manager, you’re showing exciting progress. Refinements such as thresholds, threshold crossing alarms, etc can be done later.
    4) Inventory and fulfilment are often much more complex, although basic services like IN (Intelligent network) services such as calling card provisioning can be relatively easy because resource checking is simpler or not required. But as a rule of thumb, most service / fulfilment functionality will rely on an accurate understanding of the inventory / resources that they will use. So, that means I’d normally tackle inventory before fulfilment
    5) There are two ways of tackling inventory – via data creation / migration or via discovery (or a combination of both I guess). I tend to prefer taking the discovery path because that’s going to be your long-term solution anyway (most likely) so you might as well build that rather than going with a temporary load first
    6) Then comes fulfilment, but noting that you’ve probably actually started the fulfilment planning stage much earlier… because you will need to understand the organisation, business unit structure, business processes / workflows, approvals, life-cycles, work orders / activities and so forth. This usually takes a significant effort to map into a new OSS. Fulfilment also tends to have the most complex automated provisioning unless the NMS / EMS / NEs that you’re writing to have advanced error checking and error handling functionality.

    There are many different dependencies, but again these are dependent on the tools, people and processes in each different situation. For example, some OSS are very data-driven, which means they need a lot of reference data loaded and cross-referenced before the system will function. But on the up-side, these systems also have a lot more cross-referencing which makes the analytics on them more powerful. Others are less dependent on data, making the inventory migration phase easier, but I don’t find them as insightful (or much harder to gather insights from).

    I’d also strongly suggest doing a risk analysis (

    Oh, and by the way, I always starting by mapping out a WBS first so that I can get a big-picture view of all the pieces of the project that I need to consider (

    Hope this helps! Best of luck with your OSS!

Leave a Reply

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