More complexity

Most systems deal with complexity by adding more – more systems, more measures, more internal meetings, more units, more custom products, more unique processes, more new initiatives, more coordinators at the interfaces, and on and on. Our belief is that for more companies, the antidote to escalating complexity – and to the greater distance between management and the reality at the front line – is simplification, creating greater focus and liberating energy.”
Chris Zook and James Allen
, in their book, “Repeatability.”

The quote above comes from a book that describes how the most successful organisations in the world have repeatability woven into their business models. It may be a quote about organisations, but it perfectly describes OSS projects don’t you think?

Another quote from the book is as follows, “In the complicated and constantly evolving world of business, keeping your business simple can be and will be a tremendously important competitive advantage. If you engineer your organisation so simplicity can triumph and reign supreme, your competitors will wonder what hit them. Even more importantly, customers will love being the centre of attention.”

Do you agree with Zook and Allen? Do you think that simplicity can be a competitive advantage? If so, why?

I do tend to agree with them. I also believe that it will take an entirely different way of thinking by everyone in your organisation. An entirely less brilliant way.

For example, when defining a list of requirements for our latest OSS, do we have a tendency to think of a scenario and immediately start thinking of all the “what ifs” that could occur? Do we also have a tendency to assume, “this ‘what if’ scenario could definitely happen,” but not actually take the time to investigate and confirm its likelihood? I’ll be honest here and say that I’ve been guilty of this, as have too many past OSS project colleagues for me to count.

Does it make sense that if you truly investigate each requirement and confirm whether it really is important (ie it fits within the 80% of the Pareto Principle), rather than assuming, then you will cut down on the downstream effort (ie to design, to test, to build data sets, to deliver, to maintain, etc)? So many of us just don’t begin to think about what the downstream impact will eventuate from our brilliance (in being able to identify boundary cases).

Less brilliant, but brilliant in its simplicity.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

2 Responses

  1. Great post, Ryan! At TM Forum, we believe you have to build everything round the customer and base everything you do on how best to serve them. The only possible way of doing this is through simplification, although clearly this isn’t easy.

    We also did some research recently with top execs from service providers around the world – complexity was highlighted as the major issue http://bit.ly/1aWSuje

  2. Thanks Sarah

    I think I will have a closer look at that TM Forum report of Rob’s. The summary looks very interesting and has some alignment with my viewpoints too.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.