How smart contracts might reduce risk and enhance trust on OSS projects

Last Friday, we spoke about all wanting to develop trusted OSS supplier / customer relationships but rarely finding them and a contrarian factor for why trust is so hard to achieve in OSS – complexity.

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.

An OSS niche market opportunity?

The survey found that 82 percent of service providers conduct less than half of customer transactions digitally, despite the fact that nearly 80 percent of respondents said they are moving forward with business-wide digital transformation programs of varying size and scale. This underscores a large perception gap in understanding, completing and benefiting from digitalization programs.

The study revealed that more than one-third of service providers have completed some aspect of digital transformation, but challenges persist; nearly three-quarters of service providers identify legacy systems and processes, challenges relating to staff and skillsets and business risk as the greatest obstacles to transforming digital services delivery.

Driving a successful digital transformation requires companies to transform myriad business and operational domains, including customer journeys, digital product catalogs, partner management platforms and networks via software-defined networking (SDN) and network functions virtualization (NFV).
Survey from Netcracker and ICT Intuition.

Interesting study from Netcracker and ICT Intuition. To re-iterate with some key numbers and take-aways:

  1. 82% of responding service providers can increase digital transactions by at least 50% (in theory).  Digital transactions tend to be significantly cheaper for service providers than manual transactions. However, some customers will work the omni-channel experience to find the channel that they’re most comfortable dealing with. In many cases, this means attempting to avoid digital experiences. As a side note, any attempts to become 100% digital are likely to require social / behavioural engineering of customers and/or an associated churn rate
  2. Nearly 75% of responding service providers identify legacy systems / processes, skillsets and business risk as biggest challenges. This reads as putting a digital interface onto back-end systems like BSS / OSS tools. This is less of a challenge for newer operators that have been designed with digitalised customer interactions in mind. The other challenge for operators is that the digital front-ends are rarely designed to bolt onto the operators’ existing legacy back-end systems and need significant integration
  3. If an operator want to build a digital transaction regime, they should expect an OSS / BSS transformation too.

To overcome these challenges, I’ve noticed that some operators have been building up separate (often low-cost) brands with digital-native front ends, back ends, processes and skills bases. These brands tend to target the ever-expanding digitally native generations and be seen as the stepping stone to obsoleting legacy solutions (and perhaps even legacy business models?).

I wonder whether this is a market niche for smaller OSS players to target and grow into whilst the big OSS brands chase the bigger-brother operator brands?

We all want to develop trusted OSS partnerships, so why does so much scepticism exist?

Every OSS supplier wants to achieve “trusted” status with their customers. Each supplier wants to be the source trusted to provide the best vision of the future for each customer.

I’m an independent consultant, so I have been lucky enough to represent many organisations on both sides of that equation. And in that position, I’ve been able to get a first-hand view of the perception of trust between OSS vendors / integrators (suppliers) and operators (customers). Let’s just say that in general, we’re working in an industry with more scepticism than trust.

So if trust is so important and such a desired status, where is it breaking down?

Whilst I’d like to assume that most people in our industry go into OSS projects with the very best of intentions, there are definitely some suppliers that try to trick and entrap their customers whilst acting in an untrustworthy way. For the rest of this post, I’m going to assume the best – assume that we all have great intentions. We then look at why the trust relationships might be breaking down and some of the ways we can do better.

Jon Gordon provides a great list of 11 ways to build trust. Check out his link for a more detailed view, but the 11 factors are as follows:

  1. Say what you are going to do and then do what you say!
  2. Communicate, communicate, communicate
  3. Trust is built one day, one interaction at a time, and yet it can be lost in a moment because of one poor decision
  4. Value long term relationships more than short term success
  5. Sell without selling out. Focus more on your core principles and customer loyalty than short term commissions and profits.
  6. Trust generates commitment; commitment fosters teamwork; and teamwork delivers results.
  7. Be honest!
  8. Become a coach. Coach your customers. Coach your team at work
  9. Show people you care about them
  10. Always do the right thing. We trust those who live, walk and work with integrity.
  11. When you don’t do the right thing, admit it. Be transparent, authentic and willing to share your mistakes and faults

They all sound quite obvious don’t they? Do you also notice that many of the 11 (eg communication, transparency, admitting failure, doing what you say, etc) can be really easy to say but harder to do flawlessly under the pressure of complex OSS delivery projects (and ongoing operations)?

I know I certainly can’t claim a perfect track record on all of  these items. Numbers 1 and 2 can be particularly difficult when under extreme delivery pressure, especially when things just aren’t going to plan technically and you’re focussing attention on regaining control of the situation. In those situations, communication and transparency are what the customer needs to maintain confidence, but the customer relationship takes time that also needs to be allocated to overcoming the technical challenges. It becomes a balancing act.

So, how do we position ourselves to make it easier to keep to these 11 best intentions? Simple. By making a concerted effort to reduce complexity… actually not so simple as it sounds, but rewarding if you can achieve it. The less complex your delivery projects (or operational models), the more repeatable and reliable a supplier’s OSS delivery becomes. The more reliable, the less friction and a reduced chance of fracturing relationships. Subsequently, the more chance of building and retaining trust.

Hat-tip to Robert Curran of Aria Networks for spawning a discussion about trust.

Interaction points with fast/slow processes

Further to yesterday’s post on fast / slow processes and factory platforms, a concept presented by Sylvain Denis of Orange in Melbourne last week, here’s a diagram from Sylvain’s presentation pack :

The yellow blocks represent the fast (automated) processes. The orange blocks represent the slow processes.

The next slide showed the human interaction points (blue boxes) into this API / factory stack.

Torturous OSS version upgrades

Have you ever worked on an OSS where a COTS (Commercial Off-The-Shelf) solution has been so heavily customised that implementing the product’s next version upgrade has become a massive challenge? The solution has become so entangled that if the product was upgraded, it would break the customisations and/or integrations that are dependent upon that product.

This trickle-down effect is the perfect example of The Chess-board Analogy or The Tech-debt Wreck at work. Unfortunately, it is far too common, particularly in large, complex OSS environments.

The OSS then either has to:

  • skip the upgrade or
  • take a significant cost/effort hit and perform an upgrade that might otherwise be quite simple.

If the operator decides to take the “skip” path for a few upgrades in a row, then it gets further from the vendor’s baseline and potentially misses out on significant patches, functionality or security hardening. Then, when finally making the decision to upgrade, a much more complex project ensues.

It’s just one more reason why a “simple” customisation often has a much greater life-cycle cost than was initially envisaged.

How to reduce the impact?

  1. We’ve recently spoken about using RPA tools for pseudo-integrations, allowing the operator to leave the COTS product un-changed, but using RPA to shift data between applications
  2. Attempt to achieve business outcomes via data / process / config changes to the COTS product rather than customisations
  3. Enforce a policy of integration as a last resort as a means of minimising the chess-board implications (ie attempting to solve problems via processes, in data, etc before considering any integration or customisation)
  4. Enforcing modularity in the end-to-end architecture via carefully designed control points, microservices, etc

There are probably many other methods that I’m forgetting about whilst writing the article. I’d love to hear the approach/es you use to minimise the impact of COTS version upgrades. Similarly, have you heard of any clever vendor-led initiatives that are designed to minimise upgrade costs and/or simplify the upgrade path?

A summary of RPA uses in an OSS suite

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

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

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

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

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

The OSS / RPA parrot on the shoulder analogy

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

The third style is Decision Support. I refer to this style as the parrot on the shoulder because the parrot (RPA) guides the operator through their daily activities. It isn’t true automation but it can provide one of the best cost-benefit ratios of the different RPA styles. It can be a great blend of human-computer decision making.

OSS processes tend to have complex decision trees and need different actions performed depending on the information being presented. An example might be a customer on-boarding, which includes credit and identity check sub-processes, followed by the customer service order entry.

The RPA can guide the operator to perform each of the steps along the process including the mandatory fields to populate for regulatory purposes. It can also recommend the correct pull-down options to select so that the operator traverses the correct branch of the decision tree of each sub-process.

This functionality can allow organisations to deliver less training than they would without decision support. It can be highly cost-effective in situations where:

  • There are many inexperienced operators, especially if there is high staff turnover such as in NOCs, contact centres, etc
  • It is essential to have high process / data quality
  • The solution isn’t intuitive and it is easy to miss steps, such as a process that requires an operator to swivel-chair between multiple applications
  • There are many branches on the decision tree, especially when some of the branches are rarely traversed, even by experienced operators

In these situations the cost of training can far outweigh the cost of building an OSS (RPA) parrot on each operator’s shoulder.

Using RPA to automate OSS activities

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

The first of those styles is automating repeatable tasks by following an algorithmic approach to complete regular, mundane tasks.

Running an OSS has many high value, challenging tasks for operators to perform. Unfortunately, they also have many repetitive, simple (brain-dead?) tasks that need to be done too.

This might include collecting data from various sources and aggregating it into a single file or report for consumption by humans or machines. Other examples include admin clean-up tasks like accounts / tempfiles / processes / sessions and myriad simple process automations.

When we think of OSS automations, we often think of high value but complicated tasks like orchestrations, network self-healing, etc. They can be expensive and inflexible, not always delivering the perceived worth for the investment.

However, when thinking of RPA I think about the simplest stuff first. They are basic and consistent processes that are straightforward to define an algorithm for, making them the “low-hanging fruit” of OSS / RPA activities. They help to build momentum towards the bigger automation fish. Best of all, they free up your talented OSS operators to do more valuable activities.

Automating repeatable tasks is the most basic RPA style. We’ll step up the value chain with each additional style over the next few days.

Onboarding outsiders as a new OSS business model

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

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

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

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

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

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

When low OSS performance is actually high performance

It’s not unusual for something to be positioned as the high performance alternative. The car that can go 0 to 60 in three seconds, the corkscrew that’s five times faster, the punch press that’s incredibly efficient…
The thing is, though, that the high performance vs. low performance debate misses something. High at what?
That corkscrew that’s optimized for speed is more expensive, more difficult to operate and requires more maintenance.
That car that goes so fast is also more difficult to drive, harder to park and generally a pain in the neck to live with.
You may find that a low-performance alternative is exactly what you need to actually get your work done. Which is the highest performance you can hope for
.”
Seth Godin
in this article, What sort of performance?

Whether selecting a vendor / product, designing requirements or building an OSS solution, we can sometimes lose track of what level of performance is actually required to get the work done can’t we?

How many times have you seen a requirement sheet that specifies a Ferrari, but you know the customer lives in a location with potholed and cobblestoned roads? Is it right to spec them – sell them – build them – charge them for a Ferrari?

I have to admit to being guilty of this one too. I have gotten carried away in what the OSS can do, nearer the higher performance end of the spectrum, rather than taking the more pragmatic view of what the customer really needs.

Automations, custom reports and integrations are the perfect OSS examples of low performance actually being high performance. We spend a truckload of money on these types of features to avoid manual tasks (curse having to do those manual tasks)… when a simple cost-benefit analysis would reveal that it makes a lot more sense to stay manual in many cases.

The future of telco / service provider consulting

Change happens when YOU and I DO things. Not when we argue.”
James Altucher
.

We recently discussed how ego can cause stagnation in OSS delivery. The same post also indicated how smart contracts potentially streamline OSS delivery and change management.

Along similar analytical lines, there’s a structural shift underway in traditional business consulting, as described in a recent post contrasting “clean” and “dirty” consulting. There’s an increasing skepticism in traditional “gut-feel” or “set-and-forget” (aka clean) consulting and a greater client trust in hard data / analytics and end-to-end implementation (dirty consulting).

Clients have less need for consultants that just turn the ignition and lay out sketchy directions, but increasingly need ones that can help driving the car all the way to their desired destination.

Consultants capable of meeting these needs for the telco / service provider industries have:

  • Extensive coal-face (delivery) experience, seeing and learning from real success and failure situations / scenarios
  • An ability to use technology to manage, interpret and visualise real data in a client’s data stores, not just industry trend data
  • An ability to build repeatable frameworks (including the development of smart contracts)
  • A mix of business, IT and network / tech expertise, like all valuable tripods

Have you noticed that the four key features above are perfectly aligned with having worked in OSSOSS/BSS data stores contain information that’s relevant to all parts of a telco / service provider business. That makes us perfectly suited to being the high-value consultants of the future, not just contractors into operations business units.

Few consultancy tasks are productisable today, but as technology continues to advance, traditional consulting roles will increasingly be replaced by IP (Intellectual Property) frameworks, data analytics, automations and tools… as long as the technology provides real business benefit.

A deeper level of OSS connection,

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

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

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

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

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

OSS that keep the cuckoos out of the nest

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

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

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

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

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

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

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

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

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

Micro-strangulation vs COTS customisation

Over the last couple of posts, we’ve referred to the following diagram and its ability to create a glass ceiling on OSS feature releases:
The increasing percentage of tech debt

Yesterday’s post indicated that the current proliferation of microservices has the potential to amplify the strangulation.

So how does that compare with the previous approach that was built around COTS (Commercial off-the-shelf) OSS packages?

With COTS, the same time-series chart exists, just that it sees the management of legacy, etc fall largely with the COTS vendor, freeing up the service provider… until the service provider starts building customisations and the overhead becomes shared.

With microservices, the rationalisation responsibility is shifted to the in-house (or insourced) microservice developers.

And a third option: If the COTS is actually delivered via a cloud “OSS as a service” (OSSaaS) model, then there’s a greater incentive for the vendor to constantly re-factor and reduce clutter.

A fourth option, which I haven’t actually seen as a business model yet, is once an accumulation of modular microservices begins to grow, vendors might begin to offer microservices as a COTS offering.

10 ways to #GetOutOfTheBuilding

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)?

Watching customers under an omnichannel strobe light

Omnichannel will remain full of holes until we figure out a way of tracking user journeys rather than trying to prescribe (design, document, maintain) process flows.

As a customer jumps between the various channels, they move between systems. In doing so, we tend to lose the ability to watch customer’s journey as a single continuous flow. It’s like trying to watch customer behaviour under a strobe light… except that the light only strobes on for a few seconds every minute.

Theoretically, omnichannel is a great concept for customers because it allows them to step through any channel at any time to suit their unique behavioural preferences. In practice, it can be a challenging experience for customers because of a lack of consistency and flow between channels.

It’s a massive challenge for providers to deliver consistency and flow because the disparate channels have vastly different user interfaces and experiences. IVR, digital, retail, etc all come from completely different design roots.

Vendors are selling the dream of cost reductions through improved efficiency within their channels. Unfortunately this is the wrong place for a service provider to look. It’s the easier place to look, but the wrong place nonetheless. Processes already tend to be relatively efficient within a channel and data tends to be tracked well within a channel.

The much harder, but better place to seek benefits is through the cross-channel user journeys, the hand-offs between channels. That’s where the real competitive advantage opportunities lie.

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?

6 principles of OSS UI design

When we talk about building capabilities by design, there are a set of four core capabilities that you should keep in mind:

  • Designed for self-sufficiency: Enable an environment where the business user is capable of acquiring, blending, presenting, and visualizing their data discoveries. IT needs to move away from being command and control to being an information broker in a new kind of business-IT partnership that removes barriers, so that users have more options, more empowerment, and greater autonomy.
  • Designed for collaboration: Have tools and platforms that allow people to share and work together on different ideas for review and contribution. This further closes that business-IT gap, establishes transparency, and fosters a collective learning culture.
  • Designed for visualization: Data visualizations have been elevated to a whole new form of communication that leverages cognitive hardwiring, enriches visual discovery, and helps tell a story about data to move from understanding to insight.
  • Designed for mobility: It is not enough to be just able to consume information on mobile devices, instead users must be able to work and play with data “on the go” and make discovery a portable, personalized experience.

Lindy Ryan in the book, “The Visual Imperative: Creating a Visual Culture of Data Discovery.”

When it comes to OSS specifically, I have two additional design principles:

  • Designed for Search – there is so much data in our OSS / BSS suites; some linked, some not; some normalised, some not; some cleansed, some not; This design principle allows abstraction from all those data challenges to allow operators to make psuedo-natural language requests for information. Noting that this could be considered an overlap between points 1 and 3 in the prior list
  • Designed for user journeys – in an omni-channel world, the entry point and traversal of any OSS workflow could cross multiple channels (eg online, retail store, IVR, app, etc). This makes pre-defined workflows almost impossible to design / predict. Instead, on OSS / BSS suite must be able to handle complete flexibility of user journeys between state / event transitions