Couple of words about complexity management

In general complexity management is quite elaborated area and there are a lot of studies on subject available in free access I have no ambition to cover all the aspects. The goal is to share some practical thoughts on how the complexity could be reduced as in most cases this matter is not instituted within service providers and it is paid less attention that it deserves.

From one side complexity of telecommunications infrastructure is the consequence of the industry innovative nature and its constant positioning on the front edge of the technologies development. From the other side a lot of complexity within an operator is artificially created resulting in higher implementation and maintenance costs.

To make its clear by complexity I mean additional efforts required to support exotic, insignificant or low priority use cases. This definition is not comprehensive but it fits best to subject of this post. It is quite an obvious fact that complexity has a multiplier effect within operator's technical environment. In other words complexity tends to spread itself every domain it touches multiplying costs up to several times. Here are some root causes of such an artificial complexity

• Solution recently implemented as temporary way-out then was coated with business processes and required to be reproduced in every newly implemented system.
• Support of legacy products and product models.
• Support of legacy equipment not compatible with the newer standard integration interfaces.
• Unreasonable toughening of business requirements. Too literal understanding of business requirements.

And hundreds more.

So let’s add Pareto principle to our armory and start going into details.

One of the major reason of unnecessary complication is simply peoples unwilling to bother themselves with looking on the problem from end-to end prospective. What means answering following questions

How support of this use case will impact the efforts of current project?
How the necessity to support this use case will impact other areas e.g. product management, assurance, provisioning, billing, customer care, selling, supply chain management, network management etc?
How support of this use case will impact the operational and phase out costs?
What is the aggregated impact?
How does impact correlate with the commercial or non commercial (loyalty, prestige) effects of use case support?

Moreover, asking and answering all these questions doesn't make sense if there is no feedback between business and engineering. Implementation project should be always able to negotiate the business requirements provided otherwise the implementation costs will rise uncontrollably. Business always requires more in hope to receive at least half of what have been requested. Too literal treatment of business requirements is frequently worse than too free one.

Personally I have one criteria to consider complexity evaluation thinking. It is 5% and it is much thinner margin than in Pareto law. For example, does this use case impacts less then 5% of customers? Why so? Just for fun. 5% forms up a critical mass to trigger self-synchronizing behavior among the rest 95% of any given people set if they do something simultaneously. You'd never offend the 5% of innovators promoting the new products.

Final conclusion. Each case is unique and there is no common solution. But always bear in mind your strategic principles one of which should be Perfection and another one keeping thing as simple as they could be.

The force of habit

The habits obtained are a big thing, frequently underestimated. Most of us have professionally grown up within tough conditions of fixed price projects. In some less mature markets, as Ukrainian for example, time & material business models are still viewed as kind of exotic luxury somewhere overseas.

In those circumstances, principle of scope protection became something more important than Ten Commandments for a Christians. The habit to push back requirements and to surround any action committed by the hence of assumptions infiltrates into ordinary life - when you arrange a meeting with friends or negotiate conditions of going to get same food into kiosk around the corner with the wife.

With this background I frequently observe an amusing situation. In time & materials project and situations vendors are supposed to compete for scope they instead, driven by the habit, try to anyway reject requirements and hand it over to other parties in any price.

Be careful Old School is in action!)