BRYCE ON MANAGEMENT
- It's really not difficult as long as we use a little common sense.
In a recent Information Technology discussion group I am involved with, someone posed the question, "What is complexity?" I was surprised by the question as I thought it was understood what complexity was all about. Evidently not. The person posing the question was primarily concerned with complexity in system design, but I think it goes beyond systems, to all facets of business, be it related to products or services.
Complexity deals with the number of variables a human can successfully juggle at one time. Each of us possess an intellectual capacity to multitask, but there are mental limitations for all of us. It is like a juggler who takes on one too many balls which forces him to drop the lot. Some people can juggle more objects than others, but we all have limitations.
There are three variables in juggling complexity:
1. The volume of components in a product or service. For example, the number of parts in a product, the number of information resources in a system or program, or the number of customers to serve, employees, or vendors. For example, in an information system there are approximately 2,000 components to manage, and approximately 100 in a single program, which is still significant.
2. The characteristics of each component has to be defined. For example, height, length, width, weight, color, etc. Different components, different types of characteristics, e.g.; how we define the characteristics of a girder of steel is different than the characteristics of an employee, or a data element.
3. The number of relationships to other components. For example, how a wheel is related to an axle, how a worker is used on various projects, or how the data element, "Customer Number," relates to records, files, programs and other system components. The problem is compounded when parts are standardized for use in multiple products, as General Motors did years ago in standardizing engine parts across their product line.
Based on these three variables, the human being must manage hundreds, if not thousands of variables in a work assignment. In an average information system design, there are approximately 50,000 variables to manage, and for a single program, there are about 2,000 variables. Workers are selected for assignment, in part, based on the number of variables they can juggle at one time.
The next obvious question becomes how to manage all of these variables. If we're lucky, a person will use a reliable method of documentation to record them, such as blueprints in architecture and engineering, ledgers in accounting, or a "bill of materials" for a product. A bill of materials is a schematic depicting the parts in a product, how they relate to each other, and the characteristics of each component. Anyone who has a product warranty book for home appliances or major garden tools can find such a schematic, it is a common and effective technique for managing complexity. This concept is so effective, it was used as the basis for developing the data dictionary and Data Base Management System (DBMS) as used in application development work. However, the discipline to share and reuse components in the systems world, as logical as it may sound, is still the exception as opposed to the rule. Consequently, it is common to find considerable redundancy in system and data components, e.g; data elements, records, files, programs, business processes, etc. Consider this, it is highly likely there are multiple interpretations of "Customer Number" in a single company, as is "Product Number," "Part Number," the calculation of "Total Sales," etc. Such redundancy complicates system integration thereby adding to the complexity problem.
The final problem is assembling the right parts to form the right products. This explains the rationale for such things as assembly lines and methodologies which define "Who" is to do "What," "When," "Where," "Why" and "How" (the 5W's + H). Such assembly lines/methodologies are devised by Industrial Engineers who are charged with assembling products in the most expeditious way possible.
There is actually nothing magical in managing complexity. It is just a matter of admitting our limitations and embracing a standard approach for documenting components, their characteristics, and interrelationships. The biggest danger is when we try to manage all of the variables in our head which, unfortunately, is how many programmers work today. Unfortunately, this results in considerable redundancy, lack of system integration, thereby complicating complexity further. All that is needed is little common sense, a standardized approach to documenting components, and some discipline to make it all happen.
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Author: Tim Bryce, Managing Director, M&JB Investment Company
Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at [email protected]
Copyright © 2015 by Tim Bryce. All rights reserved.