The concept of DevOps is missing one really important thing

There’s a concept that’s building a buzz across all digital industries – you may’ve heard of it – it’s a little thing called DevOps. Someone (most probably a tester) decided to extend it and now you might even hear the #DevTestOps moniker being mentioned.

In the ultimate of undeserved acknowledgements, I even get a reference on Wikipedia’s DevOps page. It references this DevOps life-cycle diagram from an earlier post that I can take no credit for:

However, there is one really important chevron missing from the DevOps infinite loop above. Can you picture what it might be?

If I show you this time series below, does it help identify what’s missing from the DevOps infinite loop? I refer to the diagram below as The Tech-Debt Wreck
The increasing percentage of tech debt
If I give you a hint that it primarily relates to the grey band in the time series above, would that help?

Okay, okay. I’m sure you’ve guessed it already, but the big thing missing from the DevOps loop is pruning, or what I refer to as subtraction projects (others might call it re-factoring). Without pruning, the rapid release mantra of DevOps will take the digital world from t0 to t0+100 faster than at any time before in our history.

As a result, I’m advocating a variation on DevOps… or DevTestOps even… I want you to preach a revised version of the label – let’s start a movement called #DevTestPruneOps. Actually, the pruning should go at the start, before each dev / test cycle, but by calling it #PruneDevTestOps, I fear its lineage might get lost.

A summary of RPA uses in an OSS suite

This is the sixth and final post in a series about the four styles of RPA (Robotic Process Automation) in OSS.

Over the last few days, we’ve looked into the following styles of RPA used in OSS, their implementation approaches, pros / cons and the types of automation they’re best suited to:

  1. Automating repeatable tasks – using an algorithmic approach to completing regular, mundane tasks
  2. Streamlining processes / tasks – using an algorithmic approach to assist an operator during a process or as an alternate integration technique
  3. Predefined decision support – guiding operators through a complex decision process
  4. As part of a closed-loop system – that provides a learning, improving solution

RPA tools can significantly improve the usability of an OSS suite, especially for end-to-end processes that jump between different applications (in the many ways mentioned in the above links).

However, there can be a tendency to use the power of RPAs to “solve all problems” (see this article about automating bad processes). That can introduce a life-cycle of pain for operators and RPA admins alike. Like any OSS integration, we should look to keep the design as simple and streamlined as possible before embarking on implementation (subtraction projects).

RPA in OSS feedback loops

This is the fifth in a series about the four styles of RPA (Robotic Process Automation) in OSS.

The fourth of those styles is as part of a closed-loop system such as the one described here. Here’s a diagram from that link:
OSS / DSS feedback loop

This is the most valuable style of RPA because it represents a learning and improving system.

Note though that RPA tools only represent the DSS (Decision Support System) component of the closed-loop so they need to be supplemented with the other components. Also note that an RPA tool can only perform the DSS role in this loop if it can accept feedback (eg via an API) and modify its output in response. The RPA tool could then perform fully automated tasks (ie machine-to-machine) or semi-automated (Decision support for humans).

Setting up this type of solution can be far more challenging than the earlier styles of RPA use, but the results are potentially the most powerful too.

Almost any OSS process could be enhanced by this closed-loop model. It’s just a case of whether the benefits justify the effort. Broad examples include assurance (network health / performance), fulfilment / activations, operations, strategy, etc.

Using RPA as an alternate OSS integration

This is the third in a series about the four styles of RPA (Robotic Process Automation) in OSS.

The second of those styles is Streamlining processes / tasks by following an algorithmic approach to simplify processes for operators.

These can be particularly helpful during swivel-chair processes where multiple disparate systems are partially integrated but each needs the same data (ie reducing the amount of duplicated data entry between systems). As well as streamlining the process it also improves data consistency rates.

The most valuable aspect of this style of RPA is that it can minimise the amount of integration between systems, thus potentially reducing solution maintenance into the future. The RPA can even act as the integration technique where an API isn’t available or documentation isn’t available (think legacy systems here).

Onboarding outsiders as a new OSS business model

The majority of these new services [such as healthcare, content and media, autonomous vehicles, smart homes etc.] require partnerships and will be based on a platform business model where the customer is not aware of who is providing which part of the service and to be quite frankly honest, wont care. All as they will care about is the customer experience and the end-to-end delivery of their service that they have paid for. This is where the opportunity for the telco comes and we need to think beyond data!
Aaron Boasman-Patel
here on TM Forum Inform.

Are your OSS tools already integrating with third-party services?

Do your catalog / orchestration engines already call upon microservices from outside your organisation? Perhaps it’s something as simple as providing a content service bundled with a service provider’s standard bitpipe service. Perhaps it’s also bundled with an internal-facing analytics service or an outward-facing shopping cart service.

A telco isn’t going to want to (or be able to) provide all of these services but can use partnerships and catalog items to allow each unique customer to build the bundled offer they want.

This is where catalogs and microservices potentially represent a type of small-grid model. There are already many APIs from third-party providers and the catalog / orchestration tools already exist to support the model. For many telcos, it will take a slight mindset shift – to embrace partnerships (ie to discard the “not invented here” thinking); to allowing their many existing bit-pipe subscribers to sell and bill through the telco platform (embrace sell-through); to build platforms and processes to allow for simple certification and onboarding of third-parties.

If your current OSS isn’t already integrating with third-party services, is it on your roadmap? Then again, does it suit your proposed future business models?

It’s hard to do big things in a small way

it’s hard to do big things in a small way, so I suspect incumbents have more of an advantage than they do in most industries.”
Nic Brisbourne
.

The quote above came from a piece about the rise of ConstructTech (ie building houses via means such as 3D printing). However, it is equally true of the OSS industry.

Our OSS tend to be behemoths, or at least the ones I work on seem to be. They’ve been developed over many years and have millions of sunk person-hours invested in them. And they’ve been customised to each client’s business like vines wrapped around a pillar. This gives enormous incumbency power and acts as a barrier to smaller innovators having a big impact in the world of OSS.

Want an example of it being hard to do big things in a small way? Ever heard of ONAP? AT&T is a massive telco with revenues to match, committed to a more software-centric future, and has developed millions of lines of code yet it still needs the broader industry to help flesh out its vision for ONAP.

There are occasionally niche products developed but it’s definitely hard to do big things in a small way. The small grid analogy proposed earlier gives more room for the long tail of innovation, allowing smaller innovators to impact the larger ecosystem.

Write a comment below if you’d like to point out an outlier to this trend.

The two types of disruptive technologists

OSS is an industry that’s undergoing constant, and massive change. But it still hasn’t been disrupted in the modern sense of that term. It’s still waiting to have its Uber/AirBnB-moment, where the old way becomes almost obsoleted by the introduction of a new way. OSS is not just waiting, but primed for disruption.

It’s a massive industry in terms of revenues, but it’s still far from delivering everything that customers want/need. It’s potentially even holding back the large-scale service provider industry from being even more influential / efficient in the current digital communications world. Our recent OSS Call for Innovation spelled out the challenges and opportunities in detail.

Today we’ll talk about the two types of disruptive technologists – one that assists change and one that hinders.

The first disruptive technologist is a rare beast – they’re the innovators who create solutions that are distinctly different from anything else in the market, changing the market (for the better) in the process. As discussed in this recent post, most of the significant changes occurring to OSS have been extrinsic (from adjacent industries like IT or networking rather than OSS). We need more of these.

The second disruptive technologist is all too common – they’re the technologists whose actions disrupt an OSS implementation. They’re usually well-intended, but can get in the way of innovation in two main ways:
1) By not looking beyond incremental change to existing solutions
2) Halting momentum by creating and resolving a million “what if?” scenarios

Most of us probably fall into the second category more often than the first. We need to reverse that trend individually and collectively though don’t we?

Would you like to nominate someone who stands out as being the first type of disruptive technologist and why?

What is your OSS answer : question ratio?

Experts know a lot…. obviously.
They have lots of answers… obviously.

There are lots of OSS experts. Combined, they know A LOT!!

Powerful indeed, but not sure if that’s what we need right now. I feel like we’re in a bit of an OSS innovation funk. The biggest improvements in OSS are coming from outside OSS – extrinsic improvement.

Where’s the intrinsic improvement coming from? Do we need someone to shake it up (do we need everyone to shake it up?)? Do we need new thinking to identify and create new patterns? To re-organise and revolutionise what the experts already know. Or do we need to ask the massive questions that re-frame the situation for the experts?

So, considering this funky moment in time, is the real expert the one who knows lots of answers… or the person who can catalyse change by asking the best mind-shift questions?

May I ask you – As an OSS expert, are you prouder of your answers…. or your questions?

To tackle that from a different angle – What is your answer : question ratio? Are you such an important expert that your day is so full of giving brilliant answers that you have no time left to ruminate and develop brilliant questions?

If so, can we take some of your answer time back and re-prioritise it please?

In the words of Socrates, “I cannot teach anybody anything, I can only make them think.

I found a way to save ten million dollars

Yesterday’s post about egos in OSS contained the following Dilbert cartoon:
Dilbert - I found a way to save a million dollars.
It reminded me of a story from many years ago.

I was working in a developing country, advising the board of a tier-one telco on the implementation of their first-ever OSS (they’d only ever operated their networks at NMS level previously). During the analysis phase I came across some data that showed an interesting opportunity for an innovation relating to their voice Points of Interconnect (PoI).

From a back-of-a-paper napkin analysis it seemed that a ~$50-100k investment could’ve resulted in an improvement to the company’s profit by at least $10M. I ran the concept, and the numbers, past their head of switching. His response was, “I think you’re right…. but I’m not going to recommend it.”

You could say that I was a little bewildered.

He then followed with, “You have to see this from my perspective. If I recommend this project and it succeeds, I receive no benefit. I’m not due for promotion for another two years at the earliest. I will barely receive any recognition at all, certainly no financial reward. The company receives all the benefits. But if the project fails, I will be put aside, passed over for any future promotions. It would be a career killer.”

He was right. I hadn’t seen it from his perspective… still not sure that I do, but as a consultant, I was only ever passing through their corporate culture rather than having a 4-5 decade career embedded within it.

It wasn’t within my OSS scope, but I quietly mentioned it to the board. They delegated the decision back to the head of switching. The project was not recommended to proceed, not even for further analysis.

It’s interesting the human factors that come into play when project investment is under evaluation isn’t it? What human factors have you seen influence purchasing decisions?

A deeper level of OSS connection,

Yesterday we talked about the cuckoo-bird analogy and how it was preventing telcos from building more valuable platforms on top of their capital-intensive network platforms. Thanks to Dean Bubley, it gave examples of how the most successful platform plays were platforms on platforms (eg Microsoft Office on Windows, iTunes on iOS, phones on physical networks, etc).

The telcos have found it difficult to build the second layer of platform on their data networks during the Internet age to keep the cuckoo chicks out of the nest.

Telcos are great at helping customers to make connections. OSS are great at establishing and maintaining those connections. But there’s a deeper level of connection waiting for us to support – helping the telcos’ customers to make valuable connections that they wouldn’t otherwise be able to make by themselves.

In the past, telcos provided yellow pages directories to help along these lines. The internet and social media have marginalised the value of this telco-owned asset in recent years.

But the telcos still own massive subscriber bases (within our OSS / BSS suites). How can our OSS / BSS facilitate a deeper level of connection, providing the telcos’ customers with valuable connections that they would not have otherwise made?

OSS that keep the cuckoos out of the nest

The cuckoo bird is infamous for laying its eggs in other birds’ nests. The young cuckoos grow much faster than the rightful occupants, forcing the other chicks out – if they haven’t already physically knocked the other eggs overboard. (See “brood parasitism”, here).
Analogies exist quite widely in technology – a faster-growing “tenant” sometimes pushes out the offspring of the host. Arguably Microsoft’s original Windows OS was an early “cuckoo platform” on top of IBM’s PC, removing much of IBM’s opportunity for selling additional software. 

In many ways, Internet access itself has outgrown its own host: telco-provided connectivity. Originally, fixed broadband (and the first iterations of 3G mobile broadband) were supposed to support a wide variety of telco-supplied services. Various “service delivery platforms” were conceived, including IMS, yet apart from ordinary operator telephony/VoIP and some IPTV, very little emerged as saleable services.

Instead, Internet access – which started using dial-up modems and normal phone lines before ADSL and cable and 3G/4G were deployed – has been the interloping bird which has thrived in the broadband nest instead of telcos’ own services. It’s interesting to go back and look at the 2000-era projections for walled-garden, non-Internet services.

The problem is that everyone wants to be a platform player. And when you’re building and scaling a new potential platform, it’s really hard to turn down a large and influential “anchor tenant”, even if you worry it might ultimately turn out to be a Trojan Horse (apologies for the mixed metaphor). You need the scale, the validation, and the draw for other developers and partners.

This is why the most successful platforms are always the one which have one of their own products as the key user. It reduces the cannibalisation risk. Office is the anchor tenant on Windows. iTunes, iMessage and the camera app are anchors on iOS. Amazon.com is the anchor tenant for AWS.

Unfortunately, the telecoms industry looks like it will have to learn a(nother) tough lesson or two about “cuckoo platforms”.”
Dean Bubley from Disruptive Wireless.

The link above provides some really interesting perspectives from Dean in relation to OTT business models and the challenges that telcos have faced in trying to build valuable platforms to sit on top of their capital-intensive network platforms. I really recommend having a read of the full article by clicking on the link.

I loosely equate this to the OSI stack where telcos own the L1 to L2 (L3 in many cases) platform, but haven’t been so successful at creating dominant platforms in the layers above that. That’s also why there are two distinct business model categories – the traditional CSP (Communications Service Provider) that services L1 to 2/3 and acts like a utility or REIT or the more competitive DSP (Digital Service Provider). One Telco group can have both by leveraging their trillion dollar treasure chest.

Traditional OSS service the CSP (as well as some of the aspects of the DSP model) but we probably need to create some innovative new concepts if we’re going to assist our telco customers to build DSP platforms and / or to keep the cuckoos out of the nest.

Raising the OSS horizon

With the holiday period looming for many of us, we will have the head-space to reflect – on the year(s) gone and to ponder the one(s) upcoming. I’d like to pose the rhetorical question, “What do you expect to reflect on?

It’s probably safe to say that a majority of OSS experts are engaged in delivery roles. Delivery roles tend to require great problem-solving skills. That’s one of the exciting aspects of being an OSS expert after all.

There’s one slight problem though. Delivery roles tend to have a focus on the immediacy of delivery, a short-term problem-solving horizon. This generates incremental improvements like new dashboards within an existing dashboard framework, refining processes, next release software upgrades, releasing new stuff that adds to the accumulation of tech-debt, etc, etc.

That’s great, highly talented, admirable work, often exactly what our customers are requesting, but not necessarily what our industry needs most.

We need the revolutionary, not the evolutionary. And that means raising our horizons – to identify and comprehend the bigger challenges and then solving those. That is the intent of the OSS Call for Innovation – to lift our vision to a more distant horizon.

When you reflect during this holiday period, how distant will your horizon be?

PS. Upon your own reflection, are there additional big challenges or exponential opportunities that should be captured in the OSS Call for Innovation?

What in OSS does nobody agree with you on?

Peter Thiel (co-founder of PayPal, Founders Fund and many other snippets in an impressive highlights reel) asks prospective entrepreneurs to tell him something they believe is true that nobody agrees with them about.

Today I’m asking you the same question and would love to hear your answers:

What do you believe to be true in OSS that nobody else seems to agree with you on?

The exciting thing about OSS is that it has so much potential, so many opportunities to do things better. And that means so many opportunities to do things differently, to come at things from a different angle to everyone else.

After all, success comes from doing things differently.

5 principles for your OSS Innovation Lab

Corporate innovation is far more dependent on external collaboration and customer insight than having a ‘lab’.”
Andy Howard
in a fabulous LinkedIn post.

Like so many other industries, OSS is ripe for disruption through innovation. Andy Howard’s post provides a number of sobering statistics for any large OSS vendors thinking of embarking on an Innovation Lab journey as a way of triggering innovation. Andy quotes the New York Times as follows, “The last three years have seen Nordstrom, Microsoft, Disney, Target, Coca-Cola, British Airways and The New York Times either close or dramatically downsize their innovation labs. 90% of innovation labs are failing.”

He also proposes five principles for corporate innovation success (Andy’s comments are in italics, mine follow):

  1. People. Will taking people out of the business and placing them into a new department change their thinking? No way. Those successful in corporate innovation are more entrepreneurial and more customer-centered, and usually come from outside of the organisation.
    Are you identifying (and then leveraging) those with an entrepreneurial bent in your organisation?
  2. Commercial intent. Every innovation project requires a commercial forecast. To progress, a venture must demonstrate how it could ultimately generate at least €100 million in annual revenue from a market worth at least €1 billion, and promise higher profit margins than usual.
    The numbers quoted above come from Daimler’s (wildly successful) Innovation Lab. Have you noticed that they’ve set the bar high for their innovation teams? They’re seeking the moonshots, not the incremental change.
  3. Organisational architecture. Whether it’s an innovation lab or simply an innovation department, separating the innovation team from the rest of the business is important. While the team may be bound by the same organisational policies, separation has cultural benefits. The most critical separation is not in terms of physical space, but in the team’s roles and responsibilities. Having employees attempt to function in both an ‘innovation’ role and ‘business as usual’ role is counterproductive and confusing. Innovation is an exclusive job.
    I’m 50/50 on this one. Having a gemba / coal-face / BAU role provides a much better understanding of real customer challenges. However, having BAU responsibilities can detract from a focus on innovation. The question is how to find a balance that works.
  4. External collaboration. Working with consultants and customers from outside of the organisation has long been a contributor to corporate innovation success. Companies attempting a Silicon Valley-style ‘lone genius’ breakthrough are headed towards failure. P&G’s ‘Connect and Develop’ innovation model, designed to bring outside thinking together with P&G’s own teams, is attributed with helping to double the P&G share price within five years.
    Where do you source your external collaboration on OSS innovation? Dirty or clean consultants? Contractors? Training of staff? Delegating to vendors?
  5. Customer insight. Innovations solve real customer problems. Staying close to customers and getting out of the building is how customer problems are discovered.
    As indicated under point 3 above, how do you ensure your innovators are also deeply connected with the customer psyche? Getting the team out of the ivory tower and onto the customer site is a key here

Bill Gates’ two rules of OSS technology (plus one)

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”
Bill Gates
.

The pervading OSS business case paradigm is to seek cost-out by introducing automation that reduces head-count – Do more with less.

But it seems that’s the antithesis of how to look for cost reduction. It’s adding more complexity into a given system. Fundamentally, more complexity can not be the best approach to a cost-reduction strategy, right?

The cost-out paradigm should be built on reducing, not adding complexity – Let’s stop doing more that delivers less.

To add to Bill Gates’ two rules of technology, my third rule is that if you’re going to add technology (ie complexity), it should attempt to create growth opportunities, not seek to reduce costs.

Do you want dirty or clean OSS consulting?

The original management consultant was Frederick Taylor, who prided himself in having discovered the “one best way” which would be delivered by “first-class men”. These assumptions, made in 1911, are still dominant today. Best practice is today’s “one best way” and recruiters, HR and hiring managers spend months and months searching for today’s “first-class men”.

I call this type of consulting clean because the assumptions allow the consultant to avoid dirty work or negative feedback. The model is “proven” best practice. Thus, if the model fails, it is not the consultants’ fault – rather it’s that the organisation doesn’t have the “first-class employees” who can deliver the expected outcome. You just have to find those that can. Then everything will be hunky dory.

All responsibility and accountability are abdicated downwards to HR and hiring managers. A very clean solution for everybody but them.

It’s also clean because it can be presented in a shiny manner – lots of colourful slide-decks promising a beautiful outcome – rational, logical, predictable, ordered, manageable. Clean. In today’s world of digital work, the best practice model is a new platform transforming everything you do into a shiny, pixelated reality. Cleaner than ever.

The images drawn by clean consultants are compelling. The client gets a clearly defined vision of a future state backed up by evidence of its efficacy.

But it’s far too often a dud. Things are ignored. The complex differences between the client and the other companies the model has been used on. The differences in size, in market, in demographic, in industry. None matter – because the one best way model is just that – one best way. It will work everywhere for everyone. As long as they keep doing it right and can find the right people to do it.

The dirty consultant has a problem that the clean consultant doesn’t have. It’s a big problem. He doesn’t have an immediate answer for the complex problem vexing the client. He has no flashy best practice model he strongly believes in. No shiny slide deck that outlines a defined future state.

It’s a difficult sell.

What he does have is a research process. A way of finding out what is actually causing the organisational problems. Why and how the espoused culture is different from organisational reality. Why and how the supposed best practice solution is producing stressed out anxiety or cynical apathy.

This process is underpinned by a fundamentally different perspective on the world of work. Context is everything. There is no solution that can fit every company all of the time. But there’s always a solution for the problem. It just has to be discovered.

The dirty consultant enters an organisation ready and willing to uncover the dirty reasons for the organisation not performing. This involved two processes – (1) working out where the inefficiencies and absurdities are, and (2) finding out who knows how to solve them.”

The text above all comes from this LinkedIn post by Dr Richard Claydon. It’s also the longest quote I’ve used in nearly 2000 posts here on PAOSS. I’ve copied such a great swathe of it because it articulates a message that is important for OSS.

There is no “best practice.” There is no single way. There are no cookie-cutter consulting solutions. There are too many variants at play. Every OSS has massive local context. They all have a local context that is far bigger than any consultant can bring to bear.

They all need dirty consulting – assignments where the consultant doesn’t go into the job knowing the answers, acknowledging that they don’t have the same local, highly important context of those who are at gemba every day, at the coal-face every day.

There is no magic-square best-fit OSS solution for a given customer. There should be no domino-effect selection of OSS (ie the big-dog service provider in the region has chosen product X after a long product evaluation so therefore all the others should choose X too). There is no perfect, clean answer to all OSS problems.

Having said that, we should definitely seek elements of repeatability – using repeatable decision frameworks to guide the dirty consulting process, to find solutions that really do fit, to find where repeatable processes will actually make a difference for a given customer.

So if the local context is so important, why even use a consultant?

It’s a consultant’s role to be a connector – to connect people, ideas, technologies, concepts, organisations – to help a customer make valuable connections they would otherwise not be able to make.

These connections often come from the ability to combine the big-picture concepts of clean consulting with the contextual methods of dirty consulting. There’s a place for both, but it’s the dirty consulting that provides the all-important connection to gemba. If an OSS consultant doesn’t have a dirty-consulting background, an ability to frame from a knowledge of gemba, I wonder whether the big-picture concepts can ever be workable?

What are your experiences working with clean consultants (vs dirty consultants) in OSS?

The biggest moonshot facing OSS today

Moonshot thinking is about making something 10x better. This forces you to throw away the existing assumptions and create something bold and new. Reality will eat into your 10x. At the end of the process it may only be 2x, but that’s still amazing.”
Brian Jansen
‘s Book Summary: “Bold: How To Go Big, Create Wealth, and Impact the World,” by Peter Diamandis & Steven Kotler.

I think the biggest moonshot facing OSS today is the design and implementation of an architecture that allows other moonshots to happen.

Take a moment to reflect on that…

As of today, our OSS tend to be complex, entangled beasts, governed by the chess-board analogy. The entanglement is so profound that we tend to only do small, incremental charges. Moving a single piece on the chess-board takes soooo much planning to avoid negative consequences. lt’s the reason that some of our high-profile OSS probably still contain chunks of code that were written in the 1990’s or 2000’s.

In the world of OSS, the 10x moonshot comes with a risk of delivering -5x not just the 2x mentioned in the quote above.

Having said that, I’m all for a good moonshot project. It might take just one disentanglement moonshot to allow 1000 subsequent moonshots to fire! A disentanglement moonshot like the small-grid approach described here.

Avoiding the OSS honey trap

Regardless of whose estimates you read, OSS is a multi billion industry. However, based on the relatively infrequent signing of new vendor deals, it’s safe to say that only a very small percentage of those billions are ever “in play.”

In other words, OSS tend to be very sticky, in part because they’re so difficult to forklift out and replace. Some vendors play his situation extremely well, with low install costs but with strategies such as “land and expand,” “so sue us” and “that will be a variation.” These honey pots hide the real cost of ownership.

Cloud IT architectures such as containerisation and microservices can provide a level of modularity and instant replaceability between products (ie competition). When combined with a Minimum Viable Product mindset rather than complex, entwining customisations, you can seek to engineer a lower lock-in solution.

The aim is to ensure that products (and vendors) stay in-situ for long periods based on merit (ie partnership strength, functionality, valuable outcomes, mutual benefit, etc) rather than lock-in.

Are we measuring OSS at the wrong end?

I have a really simple philosophical question to pose of you today – Are we measuring our OSS at the wrong end?
It seems that a vast majority of our OSS measurement is at the input end of a process rather than at the output.

Just a few examples:

  • Financial predictions in a business cases vs Return on Invested Capital (ROIC) of that project
  • Implementation costs vs lifetime ownership implication costs
  • Revenues vs profitability (of products, services, workflows, activities, etc)
  • OSS costs vs enablement of service and/or monetisation of assets (ie operationalising assets such as network equipment via service activation)
  • OSS incidents raised (or even resolved) vs insurance on brand value (ie prevention of negative word-of-mouth caused by network / service outages)

In each of these cases, it’s much easier to measure the inputs. However, the output measurements portray a far more powerful message don’t you think?

Building an OSS piggybank with scoreboard pressure

“The gameplan tells what you want to happen, but the scoreboard tells what is happening.”
John C Maxwell

Over the years, I’ve found it interesting that most of the organisations I’ve consulted to have significant hurdles for a new OSS to jump through to get funded (the gameplan), but rarely spend much time on the results (the scoreboard)… apart from the burndown of capital during the implementation project.

From one perspective, that’s great for OSS implementers. With less accountability, we can move straight on to the next implementation and not have to justify whether our projects are worth the investment. It allows us to focus on justifying whether we’ve done a technically brilliant implementation instead.

However, from the other perspective, we’re short-changing ourselves if we’re not proving the value of our projects. We’re not building up the credits in the sponsor bank ahead of the inevitable withdrawals (ie when one of our OSS projects goes over time, budget or functionality is reduced to bring in time/budget). It’s the lack of credits that make sponsors skeptical of any OSS investment value and force the aforementioned jumping through hoops.

One of our OSS‘s primary functions is to collect and process data – to be the central nervous system for our organisations. We have the data to build the scoreboards. Perhaps we just don’t apply enough creativity to proving the enormous value of what our OSS are facilitating.

Do you ever consider whether you’re on the left or right side of this ledger / scoreboard?