A career without OSS

Have you ever noticed that the biographies of almost every successful person contains the chapter(s) where everything goes disastrously? It seems inevitable that there are periods in our careers where things don’t go right, no matter how successful you are.

Interestingly my least successful project was also one that had only a very small OSS component to it. It was one of the triggers to starting PAOSS.com. PAOSS was a way to remain connected to OSS outside the demands of that day job.

That project may’ve been less successful, but it certainly wasn’t short on handing me lessons. It wasn’t the lack of OSS in that day job that made it less successful. I’ve done other telco projects that have given very different, valuable insights on OSS without being directly related to OSS.

I’ve recently had a number of job offers that have looked quite exciting. They’ve made me re-think whether I’d be better at my “art” (with PAOSS as the vehicle) if it wasn’t also my main career arc.

Derek Sivers has an interesting take on this here, “Do something for love, and something for money. Don’t try to make one thing satisfy your entire life. In practice, then, each half of your life becomes a remedy for the other. You get paid and get stability for part of your day, but then need creative time for expression.”

Contrary to Derek’s suggestion, do you combine your art with your job? If OSS is your job, what is your art?

Are your OSS better today than they were 5 years ago?

Are your OSS better today than they were 5 years ago?
(or 10, 15, 20 years depending on how long you’ve been in the industry) 

Your immediate reaction to this question is probably going to be, “Yes!” After all, you and your peers have put so much effort into your OSS in the last 5 years. They have to be better right?

On the basis of effort, our OSS are definitely more capable… but let me ask again, “Are they better?”

How do they stack up on key metrics such as:

  1. Do they need less staff to run / maintain
  2. Do they allow products to be released more quickly to market
  3. Do they allow customer services to be ready for service (RFS) faster
  4. Are mean times to repair (MTTR) faster when there’s a problem in the network
  5. Are bills more accurate (and need less intervention across all of the parties that contribute)
  6. Are there less fall-outs (eg customer activations that get lost in the ether)
  7. Are we better at delivering (or maintaining) OSS on budget
  8. Are your CAPEX and OPEX budgets lower
  9. Are our front-office staff (eg retail, contact centres, etc) able to give better outcomes for customers via our OSS/BSS
  10. Are our average truck-rolls per activation lower
  11. Are the insights we’re identifying generating longer-run competitive advantages
  12. etc, etc

Maybe it’s the rose-coloured glasses, but my answer to the initial question when framed against these key metrics is, “Probably not,” but with a couple of caveats.

Our OSS are certainly far more complicated. The bubble in which we operate is far more complicated (ie network types, product offerings, technology options, contact channels, more touchpoints, etc). This means more variants for our OSS / BSS to handle. In addition, we’ve added a lot more functionality (ie complexity of our own).

Comparison of metrics will vary greatly across different OSS operators – some for the better, some worse. Maybe I’m just working on projects that are more challenging now than I was 5, 10, 15 years ago.

Do you have the data to confirm / deny that your OSS is better than in years past?

PS. Oh, and one last call-out. You’ll notice that the metrics above tend to be cross-silo. I have no doubt that individual OSS products have improved in terms of functionality, usability, processing speeds, etc. But what about our end-to-end workflows through our OSS/BSS suite of products?

The unfair OSS advantage

My wife and I attended a Christmas party over the weekend and on the trip home we discussed customer service. In particular we were discussing the customer service training she’d had, as well as the culture of customer service reinforcement she’d experienced via leaders and peers in her industry. She doesn’t work in ICT or OSS (obviously?).

In our industry, we talk the customer experience talk via metrics like NPS (Net Promoter Score). However, I don’t recall ever working with a company that provided customer service training or had a strong culture of reinforcing customer service behaviours. Some might claim that it’s just an unwritten rule / expectation.

Conversely, some players in our industry go the opposite way and appear to have the mentality of trying to screw over their customers. Their customers know it and don’t like it but are locked in for any number of reasons.

As OSS implementers, the more consistent trend seems to be a culture of technical perfection. I know I’ve dropped the ball on customer service in the past by putting the technical solution ahead of the customer. I feel bad about that on reflection.

Perhaps what we don’t realise is that we’re missing out on an unfair advantage.

As Seth Godin states in this blog, “Here’s a sign I’ve never seen hanging in a corporate office, a mechanic’s garage or a politician’s headquarters:
WE HAVE AN UNFAIR ADVANTAGE:
We care more.

It’s easy to promise and difficult to do. But if you did it, it would work. More than any other skill or attitude, this is what keeps me (and people like me) coming back
.”

Could it be a real differentiator in our fragmented market?

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

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?

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?

An uncommon list of OSS books

Since reading the first book on this list, I’ve become a very avid and wide-ranging reader. The seeds sown by the book list below have immensely helped enrich the content you see here on the PAOSS blog and other PAOSS content.

You’ll begin to notice a very curious thing about this list though. There are only two books in the entire list that are actually about OSS. I have many OSS books in my library, but most struggle for relevance beyond the author’s frame of reference – they have been written from the specific technical experiences of the author, which are rarely transferable to other OSS. Either the technologies are now out of date and/or the details / terminologies were pertinent only to that OSS time and place. It’s one of the reasons that PAOSS content is specifically intended to abstract from technology and deliver insights, methodologies, processes and frameworks that have a broader relevance and greater longevity (hopefully).

The remaining books in the list have not been written with OSS in mind but definitely provide insights and perspectives that are transferable to the challenges we face in the OSS industry. In no particular order (except the first being the first…)

Rich Dad, Poor DadRich Dad, Poor Dad
by Sharon L. Lechter Robert T. Kiyosaki
This was the book that changed it all for me. Whilst its intent is to educate on personal finance, the effect it had was to lift my eyes beyond the purely technical. Like 95%+ of people in our industry, I had previously only ever focused on delivering the best technical solution I could with the assumption that this would deliver a great customer outcome. I now know that the challenges we face are far  bigger than that!
Insanely Simple: The Obsession That Drives Apple's SuccessInsanely Simple: The Obsession That Drives Apple’s Success
by Ken Segall
The greatest OSS (but non-OSS) book I’ve read. The first half of this book in particular delivers powerful examples of simplification at all levels of an organisation as experienced by an advertising executive working alongside Steve Jobs at Apple. The OSS and communications industry need more people who are able to wield the simple stick like Steve did.
ReworkRework
by Jason Fried, David Heinemeier Hansson
These gentlemen have built a strong business around the Basecamp project management suite of tools. In Rework, just like their blog at 37signals, they provide brilliant contrarian insights into how to run a software business… Or any business for that matter. Efficiency and simplicity are the mantra ahead of the Red-Bull fuelled heroics spouted by many organisations in the software industry. One of my all-time favourite business books.
Enchantment: The Art of Changing Hearts, Minds, and ActionsEnchantment: The Art of Changing Hearts, Minds, and Actions
by Guy Kawasaki
Guy defines enchantment as, “the process of delighting people with a product, service, organisation or idea. The outcome of enchantment is voluntary and long-lasting support that is mutually beneficial.” If there was ever an industry that was in need of enchantment, it is the OSS industry right now.
Rain: What a Paperboy Learned About BusinessRain: What a Paperboy Learned About Business
by Jeffrey J. Fox
An easy to digest story about a boy with a paper-route learning the key tenets of rainmaking, the ability to delight customers and make sales (and projects) happen.
The Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any AudienceThe Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any Audience
by Carmine Gallo
There are two acronyms that pervade in the OSS / telco / tech industry; DBA (Death by Acronym) and DBP (Death by Powerpoint). This book provides some stunning insights into how to make a compelling presentation on your latest OSS project.
Killing Giants: 10 Strategies to Topple the Goliath in Your IndustryKilling Giants: 10 Strategies to Topple the Goliath in Your Industry
by Stephen Denny
There are a number of goliath incumbents in our industry. However, I suspect that most of the required disruption is coming from the Davids of our industry, despite the burning platforms at the goliaths. Interesting reading for a different perspective on innovation and change.
Jack Welch & The G.E. Way: Management Insights and Leadership Secrets of the Legendary CEOJack Welch & The G.E. Way: Management Insights and Leadership Secrets of the Legendary CEO
by Robert Slater
This book describes a number of key strategies for how Jack Welch pared back the weighty bureaucracy of General Electric upon his ascension to CEO. I suspect our industry needs similarly brutal change leadership to thrive into the future
The Best Service is No Service: How to Liberate Your Customers from Customer Service, Keep Them Happy, and Control CostsThe Best Service is No Service: How to Liberate Your Customers from Customer Service, Keep Them Happy, and Control Costs
by Bill Price, David Jaffe
There is a distinct difference between the customer service models of the typical communications service provider (CSP) and digital service providers (DSP) like Google, Facebook, Amazon, et al. Most CSPs can only wish for the level of customer self-service that the DSPs enjoy. I was working on a project for a customer-facing business unit of a CSP whilst reading this book and the parallels were almost scary.
Essentialism: The Disciplined Pursuit of LessEssentialism: The Disciplined Pursuit of Less
by Greg McKeown
Think: Less but better. A motto for our industry, one individual at a time.
Anything You Want: 40 Lessons for a New Kind of EntrepreneurAnything You Want: 40 Lessons for a New Kind of Entrepreneur
by Derek Sivers
Derek Sivers was a professional musician before starting his own business, one that helped sell the CDs of the long tail of the music industry, musicians overlooked by the big labels. This might sound barely relevant to the OSS industry but there is an uncommon clarity in the way that Sivers views businesses, customers and delivery. Many of his thoughts really struck a chord with me (bad pun intended).
Brick by Brick: How LEGO Rewrote the Rules of Innovation and Conquered the Global Toy IndustryBrick by Brick: How LEGO Rewrote the Rules of Innovation and Conquered the Global Toy Industry
by David Robertson, Bill Breen
Bespoke creativity took this icon of childrens’ toys to the brink of bankruptcy. Perhaps counter-intuitively, paring it back to the basic building blocks (another bad pun) allowed creativity and profitability to thrive at Lego.
Principles: Life and WorkPrinciples: Life and Work
by Ray Dalio
Built around the principles that Ray Dalio codified at his company, Bridgewater Associates. Many of his principles of team and culture seem like common sense, but helpfully compiled into a single volume. Not all OSS teams have these principles mastered.
Blue Ocean Strategy, Expanded Edition: How to Create Uncontested Market Space and Make the Competition IrrelevantBlue Ocean Strategy, Expanded Edition: How to Create Uncontested Market Space and Make the Competition Irrelevant
by W. Chan Kim, Renée Mauborgne
This book provides frameworks for shifting an organisation out of fragmented, highly competitive markets (bloody red oceans) into a unique market segment (blue oceans). I’ve even added some of the concepts in this book into a framework that helps my clients plot differentiated strategic roadmaps and product evaluations.
Leading ChangeLeading Change
by John P. Kotter
OSS projects are challenging to implement. Through harsh experience, I’ve learnt that even technically perfect implementations are prone to fail if the organisational change effort hasn’t been managed well. Whilst there are newer change management methodologies available, I still find that Kotter’s 8 steps provide a valuable framework for building OSS change management strategies around.
Everything Is Negotiable: How to Get the Best Deal Every TimeEverything Is Negotiable: How to Get the Best Deal Every Time
by Gavin Kennedy
Introduces some fascinating negotiation tactics such as “The Mother Hubbard” (ie the cupboard is bare). There is more negotiation required in OSS than I first gave it credit for.
Endless Referrals: Network Your Everyday Contacts into SalesEndless Referrals: Network Your Everyday Contacts into Sales
by Bob Burg
In the early days of my career, I’d gone from one project to the next, with my head down focusing on delivery. This book opened my eyes to the value of staying in touch with past colleagues and adding value to my network. The results have surprised me so I recommend this book’s teachings to anyone who is purely tech-focused.
The Idea Factory: Bell Labs and the Great Age of American InnovationThe Idea Factory: Bell Labs and the Great Age of American Innovation
by Jon Gertner
Put simply, this is probably the most inspiring book I’ve read in relation to the communications industry. The groundbreaking innovations (including OSS) that were developed within R&D powerhouses like Bell Labs during the 1900’s are staggering and something that we can barely even aspire to today. It’s no coincidence that the OSS Call for Innovation references this book
nullLinchpin: Are You Indispensable?
by Seth Godin
A call to action to become a linchpin, someone who delivers in territory where there is no map / rule-book, someone who inspires those around them. OSS needs more linchpins.
Made to Stick: Why Some Ideas Survive and Others DieMade to Stick: Why Some Ideas Survive and Others Die
by Chip Heath, Dan Heath
The term “stickiness” was popularised by Malcolm Gladwell in “The Tipping Point.” This book borrows the term and looks to explain why an idea or concept remains sticky. OSS tend to be so sticky, in many cases to the detriment of the customer experience, but our industry is also in desperate need for powerfully sticky new ideas and approaches.
The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About ItThe E-Myth Revisited: Why Most Small Businesses Don’t Work and What to Do About It
by Michael E. Gerber
The ideas in this book are based on growing small businesses, but there are certainly take-aways for OSS. The biggest for me is the need for repeatability. We need to codify and systematise if we are to refine and improve.
Purple Cow, New Edition: Transform Your Business by Being RemarkablePurple Cow, New Edition: Transform Your Business by Being Remarkable
by Seth Godin
In a cluttered or fragmented marketplace, like OSS, it is difficult to stand out from all other suppliers. Seth Godin introduces the concept of the purple cow – when you’re on a long trip in the countryside, seeing lots of brown or black cows soon gets boring, but if you saw a purple cow, you’d immediately take notice. This book provides the impetus to make your products stand out and drive word of mouth rather than having to differentiate via your marketing.
Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True InspirationCreativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration
by Ed Catmull, Amy Wallace
From the creative brilliance of Pixar Studios comes this book of how to cultivate inspired creativity. My biggest take-away was the amount of time and money Pixar spends on upgrading its hardware and software platforms between films…. unlike some of our OSS that are still rooted in tech from the 1990s.
The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New RichThe 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich
by Timothy Ferriss
Starts off strongly but drops away rapidly in the second half IMHO. The words of a friend of mine aptly paraphrase what Tim Ferris talks about in this book, “Only do what only you can do.” Prioritise your efforts on what make you truly unique and use other efficiency tools and/or engage others to do the rest
OSS Essentials: Support System Solutions for Service ProvidersOSS Essentials: Support System Solutions for Service Providers
by Kornel Terplan
Finally, a book that’s actually about OSS. Whilst covering some obsolete technologies, this is one of the very few OSS books that retains a longevity of relevance (it was published in 2001)
Million Dollar Consulting: The Professional's Guide to Growing a Practice, Fifth EditionMillion Dollar Consulting: The Professional’s Guide to Growing a Practice, Fifth Edition
by Alan Weiss
Alan Weiss has the ability to cut through the waffle that’s offered in many consultancy how-to manuals. He provides insightful and often contrarian advice that will make you a more professional consultant, no matter what area of expertise you cover.
Mastering your OSS: Operational Support System Implementation Tips and TechniquesMastering your OSS: Operational Support System Implementation Tips and Techniques
by Ryan Jeffery
This is the best OSS book that I’ve written (so far), but with new material in the pipeline, watch this space for even better publications. It provides the frameworks, processes, insights and recommendations that will help guide you through the myriad of challenges, technical or otherwise, that you will face in the world of OSS.
Power Listening: Mastering the Most Critical Business Skill of AllPower Listening: Mastering the Most Critical Business Skill of All
by Bernard T. Ferrari
Bernard Ferrari advises the use of the Pareto Principle to listening. In other words, spending 80% of the time listening and only 20% talking. It’s such an important trait for all technical resources, yet perhaps somewhat uncommon unfortunately. As the “hired gun,” there is a tendency to start firing from both barrels verbally as soon as you meet with the customer. But the most insightful insights are the ones that are understandable to the customer. They have to be relevant in terminology, desired outcomes, roles/responsibilities, respective capabilities, etc, etc. You only get that context from Power Listening.
The Click Moment: Seizing Opportunity in an Unpredictable WorldThe Click Moment: Seizing Opportunity in an Unpredictable World
by Frans Johansson
Johansson also introduces the concept of the “smallest executable step” as a mechanism for harnessing the apparent randomness of our modern, rapidly changing world. He suggests that we make many small bets rather than one massive bet as a means of improving success rates. OSS are complex systems so any small deviation makes predictions of completion time, resources and cost difficult. As implementers, it’s our job to remove as much complexity as possible
 Harder Than I Thought: Adventures of a Twenty-First Century LeaderHarder Than I Thought: Adventures of a Twenty-First Century Leader
by Robert D. Austin, Richard L. Nolan
More than anything else, one paragraph has stuck with me from this guide to project change leadership, “….once you start a company transformation, it’s like a stampede. If you try to lead from the front, you get trampled; if you try to lead from the back, you have no impact. Best to lead from the side by carefully nudging and turning the stampede to avoid everyone going over the cliff.”
Waging War on Complexity Costs: Reshape Your Cost Structure, Free Up Cash Flows and Boost Productivity by Attacking Process, Product and Organizational ComplexityWaging War on Complexity Costs: Reshape Your Cost Structure, Free Up Cash Flows and Boost Productivity by Attacking Process, Product and Organizational Complexity
by Stephen A. Wilson, Andrei Perumal.
Amongst other things, this book introduces the concept of The Whale Curve, a model that breaks products into the profitable or the cannibalistic.
Cryptocurrency: How Bitcoin and Digital Money are Challenging the Global Economic OrderCryptocurrency: How Bitcoin and Digital Money are Challenging the Global Economic Order
by Paul Vigna, Michael J. Casey
You may (or may not) be interested in cryptocurrencies right now, but this book provides brilliant context for two concepts that are likely to have a big impact on future OSS – blockchains and smart contracts.

What have I missed? What should I be adding to my reading list? Alternatively, which books on the list do you think I’ve over-rated?

Your OSS – asset or liability?

An asset is something that puts money into your pocket every month. A liability takes money out.

Based on those very simple terms, is your OSS an asset or a liability? If a liability, does it aspire to be an asset? By that, I mean are you actively doing stuff to make it profitable in its own right, or are you happy to just apportion the cost of your OSS out across the “asset” business units every month?

The diagram below shows what is known as The Whale Curve. It provides a graph of the relative profitability of each product in your product mix. Both are generating revenues, but assets are on the left, liabilities on the right.
The Whale Curve

Can your OSS even be plotted on this graph or is it just dragging all the products down by cost apportionment?

Even if you are unable to productise your OSS, one simple mindset shift changes OSS asset perception – talk in business outcomes or results, never in deliverables or functionalities.

For example, a business outcome is,”our new OSS allows us to activate customer services (and turn on revenue) 5 days faster than our competitors (on average).” The same thing stated in functionality-speak is, “Our new OSS uses machine learning to automate the customer design and build process.”

One link in an OSS chain reaction

Have you ever experienced an event where you realised that you’d spent the previous 10+ years doing something wrong (or at least incomplete)?

I had one such experience last Friday during a presentation by Roger Gibson, a Partner at Infosys Consulting.

Now you all know that I’m a passionate spruiker of change management on OSS projects, mainly because one of the biggest reasons for OSS failure is the lack of CM. You may’ve even noticed a recent article here on PAOSS relating to the techniques we can use to influence change.

My entirely random guess is that about 95% of people in OSS focus primarily on the technical aspects of what’s being implemented, leaving only 5% who’ve grasped the significance of influencing change. My lightbulb moment on Friday came in realising that there’s actually also a 1% group (to be honest, it’s probably far less than 1%).

As an external consultant on most projects, I’ve generally figured that client representatives have far greater tenure and more ability to influence change within their organisation than me. My modus operandi has been to create change strategies and persuade the project team (plus key stakeholders) to start change initiatives as early as possible.

In effect, I’ve been delegating change responsibility. l now realise that’s not going far enough. It is MY responsibility to light the fire under every project I work on – to initiate the chain reaction.

Do you agree that it’s also YOUR responsibility to light the fire under every project you work on?
To quote Wayne Dyer, “It’s never crowded along the extra mile.”

The PAOSS Call for Innovation has been released

I’ve been promising to release an OSS Call for Innovation, a manifesto of what OSS can become – a manifesto that also describes areas where exponential improvements are just waiting to happen .

It can be found here:
http://passionateaboutoss.com/oss-call-for-innovation/
And you’ll also notice that it’s a new top-level menu item here on PAOSS.

Each time I’ve released one of these vision-statement style reports in the past, I’ve been pleasantly surprised to find that some of the visions are already being worked on by someone in the industry.

Are there any visions that I’ve overlooked? I’d love to see your comments on the page and spread the word on all the amazing innovations that you’re working on and/or dreaming about.

Do we actually need less intellectual giants?

Have you ever noticed that almost every person who works in OSS is extremely clever?
No?

They may not know the stuff that you know or even talk in the same terminologies that you and your peers use, but chances are they also know lots of stuff that you don’t.

OSS sets a very high bar. I’ve been lucky enough to cross into many different industries as a consultant. I’d have to say that there are more geniuses per capita in OSS than in any other industry / sector I’ve worked in.

So why then are so many of our OSS a shambles?

Is it groupthink? Do we need more diversity of thinking? Do we actually need less intellectual giants to create pragmatic, mere-mortal solutions?

Our current approach appears to be flawed. Perhaps Project Platypus gives us on alternate framework?

Actually, I don’t think we need less intellectual giants. But I do think we need our intellectual giants to have a greater diversity of experiences.

The OSS Think Big juxtaposition

I recently saw the advertisement below:

I’ve clipped only the last 10 seconds because that was the part that struck me. The ad is for BHP*, one of the world’s largest miners. The mining industry thinks in long-term projects because it takes many years to deliver results – for exploration, planning, approvals, for the infrastructure to be built and operationalised, etc.

Mining is “only” the process of pulling natural resources out of the ground, but despite all our complexities, mining projects tend to be far more complex than for OSS. The decade-long duration of projects means that technologies that were originally included in plans frequently become obsolete mid-flight and have to be re-planned. That means major contracts also need to be obsoleted and re-planned mid-flight. Work-force management has a completely different scale than for OSS.

Mining thinks in time-frames of decades. OSS transformations are planned in time-frames of years. OSS delivery, especially Agile deliveries, often only think in quarters (or much, much less).

In OSS, do we really Think Big?

But there’s a twist on this question. In the rare cases when we do think big, are we constraining ourselves by then following into the “deliver big” mindset too? In OSS, I’ve always felt that we deliver most efficiently when very small numbers of very clever people group together.

So there’s the juxtaposition with the clip above – Think Big… Think Small.

When you’re thinking of OSS roadmaps, what’s your thinking time-frame?

* For disclosure, I’m not an investor in BHP to my knowledge, but perhaps my super fund is.

OSS brand building with the simple stick

Today’s consumers want to get the best prices, but offering your brand at a discount can undermine profits and threaten viability. Smart brands utilize strategies to create and sustain a meaningful difference that helps consumers justify spending more.”
Nigel Hollis
, in his PoV on branding.

I once read a statistic that at one point Apple owned 6.5% of the total handset market, but accounted for 75% of the entire industry’s operating profit. Now that’s a premium brand!

Whilst some in the OSS industry may claim their brand is the strongest, none come close to having the fanatic customer base that Apple has built. This makes me ponder what it would take to create a truly premium OSS brand.

People buy a premium brand for the enjoyment it brings them, either in the experience, the status, the prestige, the satisfaction of having a need met efficiently and probably many other variants on these reasons.

Three questions for you:

  1. For how many customers is the OSS buying experience an enjoyable one?
  2. For how many customers is the implementation / integration experience an enjoyable one?
  3. For how many customers is the user experience an enjoyable one?

Actual customer experiences in relation to the questions above might be 1) Confusing, 2) Arduous and 3) Unintuitive.

I’m going to take a completely contrarian view because the status quo clearly isn’t working. This contrarian view focuses squarely on simplicity. It seems that our developers are always building new functionality. However, most of the OSS functionality that users will ever need has already been around for decades. Rather than new functionality, how about a focus on making old functionality vastly more simple?

Rather than with Engineers, how about beating OSS with the simple stick by engaging marketers, designers, artists, stylists – the creatives – to improve the three experiences above?

Use cases for architectural smoke-tests

I often leverage use-case design and touch-point mapping through the stack to ensure that all of the use-cases can be turned into user-journeys, process journeys and data journeys. This process can pick up the high-level flows, but more importantly, the high-level gaps in your theoretical stack.”

Yesterday’s blog discussed the use of use cases to test a new OSS architecture. TM Forum’s eTOM is the go-to model for process mapping for OSS / BSS. Their process maps define multi-level standards (in terms of granularity of process mapping) to promote a level of process repeatability across the industry. Their clickable model allows you to drill down through the layers of interest to you (note that this is available for members only though).

In terms of quick smoke-testing an OSS stack though, I tend to use a simpler list of use cases for an 80/20 coverage:

  • Service qualification (SQ)
  • Adding new customers
  • New customer orders (order handling)
  • Changes to orders (adds / moves / changes / deletes / suspends / resumes)
  • Logging an incident
  • Running a report
  • Creating a new product (for sale to customers)
  • Tracking network health (which may include tracking of faults, performance, traffic engineering, QoS analysis, etc)
  • Performing network intelligence (viewing inventory, capacity, tracing paths, sites, etc)
  • Performing service intelligence (viewing service health, utilised resources, SLA threshold analysis, etc)
  • Extracting configurations (eg network, device, product, customer or service configs)
  • Tracking customer interactions (and all internal / external events that may impact customer experience such as site visits, bills, etc)
  • Running reports (of all sorts)
  • Data imports
  • Data exports
  • Performing an enquiry (by a customer, for the purpose of sales, service health, parameters, etc)
  • Bill creation

There are many more that may be required depending on what your OSS stack needs to deliver, but hopefully this is a starting point to help your own smoke tests.

Use-case driven OSS architecture

When it comes to designing a multi-vendor (sometimes also referred to as best-of-breed) OSS architecture stack, there is never a truer saying than, “the devil is in the detail.”

Oftentimes, it’s just not feasible to design every interface / integration / data-flow traversing a theoretical OSS stack (eg pre-contract award, whilst building a business case, etc). That level of detail is developed during detailed design or perhaps tech-spikes in the Agile world.

In this interim state, I often leverage use-case design and touch-point mapping through the stack to ensure that all of the use-cases can be turned into user-journeys, process journeys and data journeys. This process can pick up the high-level flows, but more importantly, the high-level gaps in your theoretical stack.

Can you define why OSS projects are so challenging?

Answer. Change creates incompetence.

Whether on the vendor/integrator side, the customer side or along the strategic advisor line, OSS projects bring about constant change; massive change.

I’ve often wondered why I can feel so incompetent in the world of OSS, even though I know more about it than (probably) any other topic.

The answer has just dawned on me, as per above – change creates incompetence. There is so much change happening on so many levels within OSS that every one of us is a freshly-minted incompetent, no matter how much prior competence we may’ve built up.

And this defines the double-edged sword of OSS. The pain of feeling incompetent drives the thirst for learning / evolution.

The top-down, bottom-up design process

When planning out a full-stack business / network / services management solution, I tend to follow the top-down, bottom-up design process.

Let’s take the TMN pyramid as a starting point:
TMN Pyramid
Image courtesy of www.researchgate.net

Bottom-up: When designing the assurance stream (eg alarms, performance, etc), I start at the bottom (Network Elements), understanding what devices exist in the network and what events / notifications / monitors they will issue. From there, I seek to understand what tool/s will manage them (Element Management / Network Management), then keep climbing the stack to understand how to present key information that impacts services and the business.

Top-down: When designing the fulfilment stream (eg designs, provisioning, moves/adds/changes, configuration, etc), I generally start at the top* (Business Management), what services are being offered (Service Management) and figure out how those workflows propagate down into the network and associated tools (such as ticketing, workforce management, service order provisioning, etc).

This helps to build a conceptual architecture (ie a layered architecture with a set of building blocks, where the functional building blocks start out blank). From the conceptual architecture, we can then identify the tools / people / processes that will deliver on the functions within each blank box.

This approach ensures we have the big picture in mind before getting bogged down into the minutiae of integrations, data flows, configurations of tools, etc.

To get momentum quickly, I tend to start with the bottom-up side as data flows (eg SNMP traps) are more standardised and the tools tend to need less configuration to get some (but not all) raw alarms / traps into management tools, perhaps just sand-pit versions. For the next step, the top-down part, I tend to create just one simple service scenario, and perhaps even design the front-end to use The Mechanical Turk model described yesterday, and follow the flow manually down through the stack and into element management or network layers. Then grow both streams from there!

* Note that I’m assuming services are already flowing through the network under management and/or the team has already figured out the services they’re offering. In a completely green-fields situation, the capabilities of the network might determine the product set that can be offered to customers (bottom-up), but generally it will be top-down.

Short-sighted / long-sighted OSS

When I hear that the average tenure in tech is just two years, I wonder how anyone gets anything done. When I hear such job hopping justified by the fact that changing companies is the only way to get a raise, I just shake my head at the short-sightedness of such companies.”
David Heinemeier Hansson
here on Signal v Noise.

Have you noticed how your most valuable colleagues also tend to have had lengthy tenures in their workplace*? No matter how experienced you are at OSS, it takes a six month (plus) apprenticeship before you start adding real value in a new OSS role. The apprenticeship is usually twelve months or longer for those who are new to the industry. Unfortunately, it takes that long to develop the tribal knowledge of the tools, the processes, the people, the variants and the way things get done (including knowing how to circumvent rules).

To be honest, like DHH above, I shake my head when employers treat their OSS talent as expendable and don’t actively seek to quell high turnover in their ranks. An average tenure of two years equates to massive inefficiency. That’s my perspective on internal resources, the resources that run an OSS. The problem with internal roles though is that they can be so all-encompassing that resources become myopic, focused only on the internal challenges / possibilities.

The question then becomes how you can open up a wider field of view. The perfect example in our current environment is in the increasing use of CI/CD / DevOps / Agile methods to manage OSS delivery. I hear of a new tool almost every day (think Ansible, Kubernetes, Jenkins, Docker, Cucumber, etc, etc). It bewilders me how people keep up to know which are the best options, yet this is only one dimension of the change that is occurring in the OSS landscape. In these situations, high turnover actually helps with the cross-fertilisation of ideas / tools / practices. Similarly, external consultants can also assist with insights garnered from multiple environments.

There is a place for both on OSS projects, but I strongly subscribe to DHH’s views above. It’s the age-old question – how to attract and retain great talent, but do we give this question enough consideration??

* BTW. I’m certainly not implying that by corollary all long-tenured resources are the most valuable.

Ramping down network variants, ramping up digital variants

Voice and data are no longer the services that organisations, large and small, see as making a difference. The services that do make a difference are more dynamic and diverse – digital distribution, promotion and marketing, payments and billing, business intelligence, business continuity (including security) and more – the factors that make their organisations thrive.

Our OSS and BSS are currently complex due to all the network variants that they handle. But if customers don’t value the network (as a differentiator) then why are we putting so much effort / attention there? If customers want ubiquitous, secure data streams with digital services on top, then why aren’t we reducing network variants and correspondingly reducing complexity in our network-based OSS / BSS?

That will give us the head-room to enhance our tools and ramp up the digital services that organisations do value.

Customers like options. But if all the options are available on the digital services / bundles, customers won’t really care if they’re delivered over a network stream that has almost no variants. This also allows a transition to more of a consumption-based model rather than all the variants of speeds and feeds and protocols.

The big challenge here is convincing the networks teams to ramp down and allow digital teams to ramp up. That concept won’t go down too well at most service providers though will it?

The three big lies of the telecoms industry

What are the three big lies of the telecoms industry?
The first lie is that data monetisation is coming. Well we are still waiting.
The second is that we have billions of customers. Well are they really our customers or are they people who just tolerate us and are really customers of someone else?
The third lie is that we are utility so we have stable returns, and because we have spectrum allocations that is our safety net. EBITDA multiples for the telco industry were at around 6, while utilities were at multiples of 12 to 16, so it could not be said that telcos – which often had up to five competitors in markets – were utilities
.”
Alexey Reznikovich

Three valid points. OSS / BSS could be highly influential in whether these are actually lies or not.

Data:
If we think of data as carriage, that’s clearly not monetising for most telcos currently. Well, it does bring in revenues but at a diminishing rate per bit. If we think of data in terms of content (eg voice, video, text, etc), then there are some monetisation wins (eg Game of Thrones) but more content is coming on line so there is more supply, making the profitability tail longer. If we talk about data as insight (or supporting the generation of insights if selling analytics or API offerings) then this will never go out of fashion (although with more “insights” being generated, the bar will be raised on what is truly insightful)

Customers:
Alexey’s note here that our customers just tolerate us and are really customers of someone else possibly has some merit. It’s the reason why the OTT play has been so successful. I still have the sense that there is an implicit trust in our service providers, due to the long subscription/billing history, media / shareholder attention on them and regulation that governments place on them (even if not an implicit trust in their customer service). Not all OTT players have the same track record of regulatory governance. Some OTT providers are invisible, hidden somewhere out on the cloud. I feel that this could represent a strong opportunity in a world where crypto-currencies carry vastly more value than they do today.

Utilities:
This comes down to the business model of any given Telco and / or the regulatory frameworks they operate within. They could opt to go down the path of ubiquitous data (like ubiquitous voice of the distant past), or like most, they can go down the path of being a digital service provider. To be honest, there are probably quite a few incumbent providers that are probably more closely aligned to utility than DSP in the collective way of thinking within their workforce. That often transfers to their mindset in building OSS.