Once you’ve prepared the short-list it’s time to get into specifics. We generally do this via a PoC (Proof of Concept) phase with the short-listed suppliers. We have a few very specific principles when designing the PoC:
We want it to reflect the operator’s context so that they can grasp what’s being presented (which can be a challenge when a vendor runs their own generic demos). This “context” is usually in the form of using the operator’s device types, naming conventions, service types, etc. It also means setting up a network scenario that is representative of the operator’s, which could be a hypothetical model, a small segment of a real network, lab model or similar
PoC collateral must clearly describe the PoC and related context. It should clearly identify the important scenarios and selection criteria. Ideally it should logically complement the collateral provided in the previous step (ie the requirement gathering)
We want it to focus on the most important conditions. If we take the 80/20 rule as a guide, will quickly identify the most common service types, devices, configurations, functions, reports, etc that we want to model
Identify efficacy across those most important conditions. Don’t just look for the functionality that implements those conditions, but also the speed at which they can be done at a scale required by the operator. This could include bulk load or processing capabilities and may require simulators (or real integrations – see below) to generate volume
We want it to be a simple as is feasible so that it minimises the effort required both of suppliers and operators
Consider a light-weight integration if possible. One of the biggest challenges with an OSS is getting data in and out. If you can get a rapid integration with a real network (eg a microservice, SNMP traps, syslog events or similar) then it will give an indication of integration challenges ahead. However, note the previous point as it might be quite time-consuming for both operator and supplier to set up a real-time integration
Take note of the level of resourcing required by each supplier to run the PoC (eg how many supplier staff, server scaling, etc.). This will give an indication of the level of resourcing the operator will need to allocate for the actual implementation, including organisational change management factors
Attempt to offer PoC platform consistency so that all operators are on a level playing field, which might be through designing the PoC on common devices or topologies with common interfaces. You may even look to go the opposite way if you think the rarity of your conditions could be a deal-breaker
Note that we tend to scale the size/complexity/reality of the PoC to the scale of project budget out of consideration of vendor and operator alike. If it’s a small project / budget, then we do a light PoC. If it’s a massive transformation, then the PoC definitely has to go deeper (ie more integrations, more scenarios, more data migration and integrity challenges, etc)…. although ultimately our customers decide how deep they’re comfortable in going.
Best of luck and feel free to contact us if we can assist with the running of your OSS PoC.
“There are ratings and rankings that ostensibly exist to give us information (and we are supposed to use that information to change our behavior).
But if we don’t know what variables matter, how is it supposed to be useful?
Just because it can be easily measured with two digits doesn’t mean that it’s accurate, important or useful.
[Marketers learned a long time ago that people love rankings and daily specials. The best way to boost sales is to put something in a little box on the menu, and, when in doubt, rank things. And sometimes people even make up the rankings.]”
Seth Godin here.
Are there any rankings that are made up in OSS? Our OSS collect an amazing amount of data so there’s rarely a need to make up the data we present.
Are they based on hidden variables? Generally, we use raw counters and / or well known metrics so we’re usually quite transparent with what our OSS present.
What about when we’re trying to select the right vendor to fulfill the OSS needs of our organisation? As Seth states, Just because it can be easily measured with two digits* doesn’t mean that it’s accurate, important or useful. [* In this case, I’m thinking of a 2 x 2 matrix].
The interesting thing about OSS ranking systems is that there is so much nuance in the variables that matter. There are potentially hundreds of evaluation criteria and even vast contrasts in how to interpret a given criteria.
For example, a criteria might be “time to activate a service.” A vendor might have a really efficient workflow for activating single services manually but have no bulk load or automation interface. For one operator (which does single activations manually), the TTAS metric for that product would be great, but for another operator (which does thousands of activations a day and tries to automate), the TTAS metric for the same product would be awful.
As much as we love ranking systems… there are hundreds of products on the market (in some cases, hundreds of products in a single operator’s OSS stack), each fitting unique operator needs differently… so a 2 x 2 matrix is never going to cut it as a vendor selection tool… not even as a short-listing tool.
Better to build yourself a vendor selection framework. You can find a few OSS product / vendor selection hints here based on the numerous vendor / product selections I’ve helped customers with in the past.
When we’re preparing a design (or capturing requirements) for a new or updated OSS, I suspect most of us design with functional requirements (FRs) in mind. That is, our first line of thinking is on the shiny new features or system behaviours we have to implement.
But what if we were to flip this completely? What if we were to design against Non-Functional Requirements (NFRs) instead? [In case you’re not familiar with NFRs, they’re the requirements that measure the function or performance of a solution rather than features / behaviours]
What if we already have all the really important functionality in our OSS (the 80/20 rule suggests you will), but those functions are just really inefficient to use? What if we can meet the FR of searching a database for a piece of inventory… but our loaded system takes 5 mins to return the results of the query? It doesn’t sound much, but if it’s an important task that you’re doing dozens of times a day, then you’re wasting hours each day. Worse still, if it’s a system task that needs to run hundreds of times a day…
I personally find NFRs to be really hard to design for because we usually won’t know response times until we’ve actually built the functionality and tried different load / fail-over / pattern (eg different query types) models on the available infrastructure. Yes, we can benchmark, but that tends to be a bit speculative.
Unfortunately, if we’ve built a solution that works, but end up with queries that take minutes… when our SLAs might be 5-15 mins, then we’ve possibly failed in our design role.
We can claim that it’s not our fault. We only have finite infrastructure (eg compute, storage, network), each with inherent performance constraints. It is what it is right?…. maybe.
What if we took the perspective of determining our most important features (the 80/20 rule again), setting NFR benchmarks for each and then designing the solution back from there? That is, putting effort into making our most important features super-efficient rather than adding new nice-to-have features (features that will increase load, thus making NFRs harder to hit mind you!)?
In this new world of open-source, we have more “product control” than we’ve probably had before. This gives us more of a chance to start with the non-functionals and work back towards a product. An example might be redesigning our inventory to work with Graph database technology rather than the existing relational databases.
How feasible is this NFR concept? Do you know anyone in OSS who does it this way? Do you have any clever tricks for ensuring your developed features stay within NFR targets?
Our most recent two posts, from yesterday and Friday, have talked about one stunningly simple idea that helps to overcome one of OSS‘ biggest challenges – data quality. Those posts have stimulated quite a bit of dialogue and it seems there is some consensus about the cleverness of the idea.
I don’t know if the idea will change the OSS landscape (hopefully), or just continue to be a strong selling point for CROSS Network Intelligence, but it has prompted me to think a little longer about innovating around OSS‘ biggest challenges.
Our standard approach of just adding more coats of process around our problems, or building up layers of incremental improvements isn’t going to solve them any time soon (as indicated in our OSS Call for Innovation). So how?
Firstly, we have to be able to articulate the problems! If we know what they are, perhaps we can then take inspiration from the CROSS innovation to spur us into new ways of thinking?
Our biggest problem is complexity. That has infiltrated almost every aspect of our OSS. There are so many posts about identifying and resolving complexity here on PAOSS that we might skip over that one in this post.
What do you notice about the root-causes in that 5-whys analysis? Most of the biggest causes aren’t related to system design at all (although there are plenty of problems to fix in that space too!). CROSS has tackled the data quality root-cause, but almost all of the others are human-centric factors – change controls, availability of skilled resources, requirement / objective mis-matches, stakeholder management, etc. Yet, we always seem to see OSS as a technical problem.
How do you fix those people challenges? Ken Segal puts it this way, “When process is king, ideas will never be. It takes only common sense to recognize that the more layers you add to a process, the more watered down the final work will become.” Easier said than done, but a worthy objective!
“Those who rule data will rule the entire world. That’s what people of the future will say.”
But one question keeps coming back to me… if you’re ruling poor quality data, will you rule nothing whatsoever?
Along the same lines, the old adage, “practice makes perfect,” is not very helpful if you’re not practicing in a constructive way. A better (albeit somewhat impossible) variant on the adage would be “PERFECT practice makes perfect.”
Let me share an example. There is a product that is completely ground-breaking in its ability to automate and optimise designs of large-scale network roll-outs – designs that include outside plant and access network technologies. In bake-offs with some of the best available network designers, this product and its algorithm consistently beats the humans by far more than 25% (when measured by capital costs, implementation time and various other metrics).
Its one challenge in taking over the world and automating every future network design is having a base set of data that is so perfect that no re-design work is required. For example, if the base data says a duct route is available and has capacity for inserting a cable, then the product assumes it can use the duct in its optimal design. But when the field techs arrive at site, they find the duct is too badly damaged to use or already filled to capacity with other cables that can’t be overhauled. A new optimal design has to be calculated to consider the lack of availability of that duct.
The tool still gives great results, even after all the manual intervention, but perfect source data would give breathtaking results.
So I’d look to make one small tweak to Masayoshi Son’s quote. “Those who rule PERFECT* data will rule the entire world. That’s what people of the future will say.”
* whereby perfect means as high in quality as realistically possible.
So, perhaps those expensive data audits and cumbersome data quality processes will have a far greater ROI (Return on Investment) in future than any of us could ever estimate.
Trust is the glue that allows OSS projects to happen. Not only that, it becomes a catch-22 with complexity. If OSS partners don’t trust each other, requirements, contracts, etc get more complex as a self-protection barrier. But with every increase in complexity, there becomes an increasing challenge to deliver and hence, risk of further reduction in trust.
On a smaller scale, you’ve seen it on all projects – if the project starts to falter, increased monitoring attention is placed on the project, which puts increased administrative load on the project team and reduces the time they have to deliver the intended outcomes. Sometimes the increased admin / report gains the attention of sponsors and access to additional resources, but usually it just detracts from the available delivery capability.
Vish Nandlall also associates trust and complexity in organisational models in his LinkedIn post below:
This is one of the reasons I’m excited about what smart contracts can do for the organisations and OSS projects of the future. Just as “Likes” and “Supplier Rankings” have facilitated online trust models, smart contracts success rankings have the ability to do the same for OSS suppliers, large and small. For example, rather than needing to engage “Big Vendor A” to build your entire, monolithic OSS stack, if an operator develops simpler, more modular work breakdowns (eg microservices), then they can engage “Freelancer B” and “Small Vendor C” to make valuable contributions on smaller risk increments. Being lower in complexity and risk means B and C have a greater chance of engendering trust, but their historical contract success ranking forces them to develop trust as a key metric.
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 long, long time ago Dennis Haslinger told me that most of the most serious mistakes I would make in life would be bad ego decisions. I have found that to be true.”
OSS is an industry filled with highly intelligent people. In every country I’ve visited to work on OSS assignments, perhaps excluding Vietnam, my colleagues have been predominantly male. Dare I say it, do those two preceding facts imply a significant ego level exists on many (most?) OSS projects (or has it just been a coincidence that I’ve experienced)?
Given that OSS projects tend to cross business units, inter-departmental power plays like the one described in the Dilbert comic below can become just another potential pitfall.
To be honest, I can’t recall any examples where ego (mine or others) has lead to serious mistakes as such, but I’ve seen many cases where it’s lead to serious stagnation, delays in project delivery, that have been extremely costly.
Stakeholder management and change management are highly underestimated factors in the success of OSS projects.
PS. The “intellectual brilliance” link above also talks about the possible benefits of smart contracts in OSS delivery. I wonder whether smart contracts will reduce some of the ego-related stagnation on OSS projects, or simply shift it from the delivery phase to the up-front smart contract agreement phase, thus introducing more “what if scenario” stagnation?
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?
The diagram below provides a time-sequence view of how tech-debt accumulation eventually strangles new OSS feature releases unless the drastic measures described are taken.
At start-up (t0), the system is brand new and has no legacy to maintain, so all effort can be dedicated to delivering new features (or products) as well as testing to ensure control of quality.
But over time (t0 + 10, where 10 is a nominal metric that could be days, years, release cycles, etc), effort is now required to maintain existing functionality / infrastructure. Not only that, but the test load increases. New features need to be tested as well as regression testing done on the legacy because there are now more variants to consider. You’ll notice that less of the effort is now available for adding new features.
The rest of the chart is self-explanatory I hope. Over a longer period of time, so much effort is required just to maintain and assure the status quo that there is almost no time left to add new features. Any new features come with a significant testing and maintenance load.
Many traditional telcos (Mammoths) and their OSS suites have found themselves at t0+100. The legacy is so large and entwined that it’s a massive undertaking to make any pivotal change (the chess-board analogy).
This is where startups and the digital / cloud players have a significant disruptive advantage over the Mammoths. They’re at t0 to t0+10 (if the metric is in years) and can roll out more new features proportionally.
What the chart above doesn’t show is subtraction projects, the effort required to ensure the legacy maintenance load and number of variants (ie testing load) are hacked away at every opportunity. The digital players call this re-factoring and the telcos, well, they don’t really have a name for it because they rarely do it (do they?).
Telcos (and their OSS suites) are like hoarders, starting off with an empty house (t0) and progressively filling it with stuff until they can barely see any carpet for the clutter (t0+100). It generally takes the intervention of an outsider to force a de-cluttering because the hoarder can’t notice a problem.
The risk with the Agile, DevOps, continuous release movement that’s currently underway is that it’s rapidly speeding up the release cadence so we might be near t0 now but we’re going to get to t0+100 far faster than before when release cadences were far slower.
Can we all see that an additional colour MUST be added to the time-series chart above – the colour that represents reductionist effort? I’m so passionate about this that it’s a strong thread running through the arc of my next book (keep an eye out for upcoming posts as I’ll be seeking your help and insights on it in the lead-up to launch).
Eric Ries’ “The Lean Startup,” has a short chapter entitled, “Get out of the Building.” It basically describes getting away from your screen – away from reading market research, white papers, your business plan, your code, etc – and out into customer-land. Out of your comfort zone and into a world of primary research that extends beyond talking to your uncle (see video below for that reference!).
This concept applies equally well to OSS product developers as it does to start-up entrepreneurs. In fact the concept is so important that the chapter name has inspired it’s own hashtag (#GetOutOfTheBuilding).
This YouTube video provides 10 tips for getting out of the building (I’ve started the clip at Tendai Charasika’s list of 10 ways but you may want to scroll back a bit for his more detailed descriptions).
But there’s one thing that’s even better than getting out of the building and asking questions of customers. After all, customers don’t always tell the complete truth (even when they have good intentions). No, the better research is to observe what they do, not what they say. #ObserveWhatTheyDoNotWhatTheySay
This could be by being out of the building and observing customer behaviour… or it could be through looking at customer usage statistics generated by your OSS. That data might just show what a customer is doing… or not doing (eg customers might do small volume transactions through the OSS user interface, but have a hack for bulk transactions because the UI isn’t efficient at scale).
Not sure if it’s indicative of the industry as a whole, but my experience working for / with vendors is that they don’t heavily subscribe to either of these hashtags when designing and refining their products.
Does your OSS collect primary data to #ObserveWhatTheyDoNotWhatTheySay? If it does, do you ever make use of it? Or do you prefer to talk with your uncle (does he know much about OSS BTW)?
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:
Do they need less staff to run / maintain
Do they allow products to be released more quickly to market
Do they allow customer services to be ready for service (RFS) faster
Are mean times to repair (MTTR) faster when there’s a problem in the network
Are bills more accurate (and need less intervention across all of the parties that contribute)
Are there less fall-outs (eg customer activations that get lost in the ether)
Are we better at delivering (or maintaining) OSS on budget
Are your CAPEX and OPEX budgets lower
Are our front-office staff (eg retail, contact centres, etc) able to give better outcomes for customers via our OSS/BSS
Are our average truck-rolls per activation lower
Are the insights we’re identifying generating longer-run competitive advantages
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 same clean / dirty construct applies to automation projects / tools such as RPA (Robotic Process Automation).
Clean Automation = simply building robotic automations (ie fixed algorithms) that manage existing process designs
Dirty Automation = understanding the process deeply first, optimising it for automation, then creating the automation.
The first is cheap(er) and easy(er)… in the short-term at least.
The second requires getting hands dirty, analysing flows, analysing work practices, analysing data / logs, understanding operator psychology, identifying inefficiencies, refining processes to make them better suited to automation, etc.
Dirty automation requires analysis, not just of the SOP (Standard Operating Procedure), but the actual state-changes occurring from start to end of each iteration of process implementation.
This also represents the better launching-off point to lead into machine-learning (ie cognitive automation), rather than algorithmic or robotic automation.
“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.”
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.
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.
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 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 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.
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 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 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.
Killing 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.
Anything 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).
Principles: 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.
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.
Endless 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 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
Linchpin: 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.
Dangerous Company: Consulting Powerhouses and the Companies They Save and Ruin
by Charles Madigan and James O’Shea
This book provides some insights into the best and worst of management consulting. It is a little old now, dating back to the late 1990’s but it had a significant impact on me when I read it in the 2010’s. It describes some of the unscrupulous acts / tactics / results that have lead to the poor reputation that consulting has in some circles. It also reinforced a strong belief I’ve always had in doing right by the client before the firm because building reputation and integrity ultimately benefits the firm anyway.
Made 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.
Purple 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.
The 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
Mastering 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 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 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 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.”
“Forcing people to follow new rules is always an uphill battle, but getting them to buy into a concept to the point where they start contributing their own ideas can literally create a movement within an organisation.”
I’ve really diverted away from direct discussions about OSS in a couple of recent posts about influence, persuasion and change. However, as the link suggests, I recently had a late-onset epiphany in relation to what’s needed to take OSS forward. I’ll give you a hint – it’s not OSS technology change per se.
The recent Call for Innovation has sparked significant direct feedback and a large up-tick in traffic here on PAOSS. This interactivity says that there’s a significant latent appetite for drastic change in our industry.
We’re all really busy, mostly on implementations, so its not change we’re lacking. It’s a lack of fundamental change. Big picture change. The type of change that takes significant collaborative effort, but a correspondingly massive mindset shift of the collective.
That’s the challenge that I’m now grappling with. How do we take the leap from being an implementer of incremental change to sparking something much bigger? It’s also a realisation that the skillsets are different to what most of us in OSS tend to try to develop.
I’d love to hear your thoughts and words / experiences of inspiration.
Something dawned on me recently – People who want to save money don’t want to spend money.
That statement has more profound implications for the world of OSS than you might initially think. Let me explain.
If someone’s main priority is to save money, what are the chances that they’ll spend money to buy a product (let’s say a book) that shows them how to save? I imagine it takes REALLY compelling marketing to overcome the customer’s primary urge.
Is it the same in business? Does someone who’s been tasked with saving money for their company readily open the purse-strings in order to save? This is a little less clear-cut than for the individual case – the employee may’ve been assigned a budget to spend with expected savings attached to it.
What if I offered these alternatives:
Spend money to save money; OR
Spend money to make money
Which is more compelling?
The “cost out” sales model appears rampant in the OSS industry at the moment – if you buy this tool, your headcount / costs will go down by X. [Did someone just mention AI?]
That’s just capitulating to the mantra that OSS will only ever be cost centres (and allowing bean-counters to dictate that costs must be reduced).
We don’t strive hard enough to fasten our metrics to the positives (eg income generation)? If anything, our OSS tend to be associated with loss-related metrics (eg network outages, faults, SLA degradation, etc). That’s the O (Operations) in OSS talking. If we only frame our thinking to building solutions for Operations, we’re pushing the figurative ship uphill to make a sale*.
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.”
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.