Measuring Complexity and Keeping It Simple

I’m about to undertake an initiative at my current place of work to measure complexity throughout the enterprise.  As an SMB, this is actually a realistic undertaking.  In my 18 months on the job, I have frequently lamented the enormous complexity-burden the business has built up over the years.  Every enterprise has more complexity than they would like, however, in over thirty years of experience, I can say that my current enterprise has built up a truly noteworthy and inglorious burden.  

In Chapter 1 of Enterprise Architecture As Strategy (Ross, Weill, & Robertson, 2006), we learned about the importance of building a foundation for execution. Some examples of an enterprise lacking such a foundation are:

1. Different parts of the company give different answers to the same questions.
2. The business lacks agility.
3. IT is consistently a bottleneck.

There were several other examples and all of them accurately describe the current state of my enterprise.  I would even add one more to the list, that being intractable quality issues.  The bottom line is, we need to build our foundation for execution by attacking our complexity.

As I mentioned, I repeatedly lament our complexity problems, however, talk is cheap and it is imperative that I do more to give meaning and substance to the issue, and to make it stick in the minds of the executives.  So, I decided to start by quantifying our complexity, which, admittedly, seems like a complex undertaking that should be doomed to fail due to its own complexity.

To drive home the complexity of assessing complexity, I offer the following text from the Harvard Business Review (Sargut, G., McGrath, Rita, 2011) describing complexity in the modern business and how to assess it.

Three properties determine the complexity of an environment. The first, multiplicity, refers to the number of potentially interacting elements. The second, interdependence, relates to how connected those elements are. The third, diversity, has to do with the degree of their heterogeneity. The greater the multiplicity, interdependence, and diversity, the greater the complexity.

I do not disagree with the theory whatsoever, but I also know that measuring the three properties of complexity are a non-starter - it truly is too complex, at least for me.  It seems then, the critical success factor in measuring complexity is to keep it simple - really simple.  

After a lot of thought and many spreadsheets, it hit me - just count things.  Nearly all problems that burden a workplace can be expressed in the form of a count.  For example, as a law firm, each of our clients (banks) have unique processing requirements that we have a difficult time keeping straight, which in turn leads to quality issues. So, let’s express this problem with a count and consider counting the number of clients with less than five cases per year (these clients add to our complexity without adding much to our revenue).  The bottom line is that a business or IT problem can almost always be expressed as a count.

Eventually, weighting factors will need to be added to show more importance to, say, the number of finance systems in use (a whopping five at my current SMB enterprise) versus something slightly more innocuous, like the number of different database versions we’re running.

A simple four column spreadsheet of 1) the name of the count, 2) the actual count, 3) the weighting factor, and 4) the product of 2 and 3 is what I’ll be using.  By summing up column 4, I’ll get my enterprise’s complexity factor, which, of course, over time we want to drive down.

Some guidelines I’m using for populating my list of counts are:

1. Structure or phrase the count so that simplification is measured by a reduction in the count.
2. Be sure to get the important counts (like the number of unique finance systems) without stressing over the less important counts.  However, when you trip across something, count it.  As an example, when an intranet website was down, I discovered that it was not running on our designated intranet web server.  This adds to our complexity, and even though it’s not a huge deal, it’s still a complexity I’d like to erase, as these small items do add up.
3. Don’t just count IT things, also count business things, such as the number of clients, the number of business units, the number of products, the number of states or countries operating in, the number of facilities, etc.  
4. Don’t avoid counting business things that would be considered negatives if the number went down, such as the number of clients or number of employees.  No matter what, the bigger the number, the greater the complexity, and the goal is to draw attention to the enterprise’s complexity.

This exercise/experiment is full of challenges, such as the subjectivity of the weighting factors, the difficulty of measuring progress if we keep tinkering with the weighting factors, or the difficulty of measure progress if we keep uncovering and adding pre-existing complexities.  

Nevertheless, counting things truly is simple.  It gives an EA Team a metric that can be measured and hopefully evolved into something meaningful and it will help permeate the thinking of the business, leading to decisions that simplify the enterprise, helping to create a foundation for execution.

References

Ross, Jeanne, Weill, Peter, Robertson, David. (2006). Enterprise Architecture As Strategy. Boston, MA: Harvard Business School Press

Sargut, G., McGrath, Rita. (2011, September). Learning to Live with Complexity. Retrieved from
 https://hbr.org/2011/09/learning-to-live-with-complexity