OSS Strategy – Planning a project

“It does not do to leave a live dragon out of your calculations, if you live near him.” J.R.R. Tolkien, The Hobbit In our case, the dragon is our OctopOSS. Where do we start when planning a new OSS project? Every OctopOSS is different.

Overall OSS Implementation Strategy

Like any other major infrastructure project, a program/project to build or transform an OSS requires a clearly defined strategy. Many factors within the CSP’s environment mean each strategy is completely unique. Therefore it is nigh on impossible to document a “best practice” OSS strategy that can be applied across all OSS projects. Impacting factors include:
  • Business model and associated competitive advantages. [You can find a great business model generation template here
  • Network technologies, reliability / availability and footprint
  • Service offerings
  • Sales model (eg re-seller, wholesale, retail)
  • Target customer type (eg residential, wholesale, corporate, etc)
  • Funding strategy and / or access to funds
  • Staffing levels and automations
  • In-house / Outsource / Partnership resource models
  • Legacy OSS and network environment
  • Change management (one of the most important but also most regularly forgotten factors)
And each of these factors needs to take into account the current situation and projected future situation. There could be unforseen scenarios such as mergers or partnerships, disruptive technologies and innumerable other situations that could impact the OSS roadmap. So whilst encouraging a 5-10 year strategy, there will also need to be flexibility in the planning. The strategy should aim to minimise change from rework (aka tech-debt) via enhancements rather than replacement. Naturally this requires adaptability, anticipation and vision.

High-level OSS Transformation Strategy

At the highest level, every transformation can be classified into four key facets:
  1. Current state – Capturing a technical, functional and organisational view of the current OSS suite. Also don’t forget to capture the terminology used by the project team to limit communication mis-matches. Terms like “services” can mean many different things to different people
  2. Desired future state – Capturing the future needs and objectives
  3. Identifying the Gap (between 1 and 2) – Across products, functionality, processes and people
  4. Roadmap of Implementation (to close the gap):
    1. Mapping applications, data models and interfaces in a staged progression to future state
    2. Mapping organisation and process changes
    3. Summarising with a sequence of tasks (ie the road-map)
To kick off Step 1 and 2 together, I generally start with stakeholder interviews (using a customised version of a base questionnaire).

Approach to capturing Current State Analysis

The current state analysis can incorporate factors such as:
  1. Client corporate environment – market the customer plays in, customer types, install base, network reach, offerings, strengths, objectives, Whale Curve, etc
  2. Current pain points and/or opportunities the project aims to overcome
  3. Overall architecture – of OSS and associated networks (active network, management network, corporate network, security, data centre, etc)
  4. Existing functionality / capability
  5. Service offerings – services carried by the network, for customers internal or external)
  6. Organisation structure and/or stakeholder map – of the overall organisation and the proposed project team (including delivery capability analysis)
  7. Other projects underway or planned (eg parallel transformation projects)
  8. Current Persona Mappings
  9. Current Process Maps
  10. Data – databases, data flows, data models, etc
  11. Volumetrics (eg device counts, user counts [incl. types of users], service counts, transaction volumes, etc)

Approach to capturing Desired Future State

The desired future state may include factors such as:
  1. Identify business objectives / benefits for the business (eg changes in strategic direction) and the project
  2. Business requirement capture
  3. Evaluation criteria (eg partnership, functional, commercial, process improvement, non-functional)
  4. Prioritisation criteria
  5. Benefit classification and acceptable quantification
  6. Market research / trends
  7. Strategy canvas (the factors / themes that are to be targeted)

Approach to documenting the Gap

For most OSS projects, there’s not just one gap but many. The Gap Analysis process involves identifying the gaps and evaluating precedence. Just because we can (technically), doesn’t mean we should, and doesn’t mean we can (due to constraints such as resourcing). The Gap Analysis may include factors such as:
  1. Gap identification
  2. Categorise possible solutions (eg networks / technologies, partnerships, training, resourcing, etc)
  3. Options analysis (comparing possible solutions against evaluation criteria / benchmarks)
  4. Resourcing / timeline / costing evaluation of options
  5. Recommendations

Approach to developing the Roadmap of Implementation

Every project is different, so every Implementation Roadmap is different. I start almost every assignment with a WBS (Work Breakdown Structure) chart, whether the project involves planning from requirements capture, ongoing operations or any part in between. Attached are sample WBS for various situations here on Passionate About OSS. These show the various factors that can be considered depending on your project. The visual nature of the WBS allows a reader to quickly visualise all the constituent parts of the OctopOSS and how they all hang together. It also allows various members of the team to brainstorm their ideas and ensure all major components are covered. The use of colour-coding of the WBS elements assists with the delegation of tasks to the various members of the implementation team. If the WBS model doesn’t work for you and the samples (see link above) don’t provide the details you’re after, you could utilise a framework like TM Forum’s Frameworx (eTOM, SID, TAM) or TOGAF to help. There are many other resources describing each of these, but you can find more info on TOGAF here and Frameworx here. And one other key call-out – consider developing an OSS Road-itecture rather than a Roadmap or an Architecture. It articulates not just an end-state, but the interim states that your project may need to progress through to reach completion. Waterfall vs Agile Implementation Having worked with Waterfall and Agile (and perhaps even Wagile) delivery approaches, I prefer Agile because of the more modular breakdown of work that tends to follow (with too many caveats to detail here!). Agile objectives – Speed, flexibility, modularity and using prototyping to give users early involvement – are attributes that every OSS implementation should ascribe to. The merits of the Agile approach extend to capturing requirements (user stories) and working through the finer details of an evolving OSS implementation (scrum). However, concentration on the minutae can divert attention from the guiding vision of a project…. unless there is a visionary leading the development. As mentioned above, the key to getting best value from Agile is in the breakdown of work. More specifically, identifying a breakdown of work that creates modularity and reduces the multitude of dependencies present in OSS projects. Click on the link for details, but see the two diagrams below for a high-level view of work breakdown approaches. Traditional delivery schedules have been built around big-bang / waterfall approaches like below. Big-bang OSS delivery The diagram below shows an alternate, more Agile, breakdown. Incremental OSS work breakdown Thrashing OctopOSS projects are all-encompassing and easily side-tracked. One of the reasons they can be diverted is due to large numbers of people providing their opinions on the wants and needs of the final solution. To overcome this problem, I’m an advocate of thrashing hard and thrashing early, allowing all major and minor stakeholders to contribute their desired outcomes, but then leaving a very small team to architect a solution that they believe is the best fit of all desired outcomes. This trusted team must be left alone after thrashing has occured and allowed to represent the needs of the entire organisation. Many OctopOSS projects fail due to in-flight changes that get out of control. The trusted team must also be tasked with refraining from all but the most necessary of in-flight changes if possible. The KISS principle Keep It Simple Stupid! Don’t get distracted by the “nice to haves” and “wish-list.” OSS products have many features or can be heavily customised to do many tasks that add minimal value to an organisation. But just because you can, doesn’t mean you should. Wherever possible:
  • Use out of the box functionality rather than heavy customisation
  • Focus on simplifying the actions that are most important to your organisation (eg adding customer services, responding quickly to alarms, etc)
  • Seek quick-wins, delivering project phases that are quicker and easier to develop momentum for project sponsors. Examples include rolling out alarm or performance management before flow-through provisioning because it is generally much easier to present alarm lists quite quickly from standard applications with minimal customisation
  • Consider the life-cycle costs of adding customisations, including increased difficulty in performing standard upgrades and ongoing regression test load increases.
Architecture Roadmap When building a roadmap, I look to analyse the current application / interface situation using my OSS Interface Assessment Tool, then build a current-state application diagram using my OSS Roadmap Tool. When aligned with future objectives, I find that the visual representation of the OSS topology helps to identify gaps that we can target with products and / or integration effort. When trying to describe architectures, process flows and data flows, it can often lead to spaghetti diagrams. There’s just too much complexity to adequately capture. As such, I find the Paint-the-fence analogy to be helpful to describe general flows. It also helps to identify which system should be data master and which systems should sub-ordinate off them.

Additional Considerations

With regards to architecture / implementation, the following high-level considerations are required: Please see the links above to blog entries that cover each of these questions in more detail and the pros/cons of each approach.