by John Sterman, MIT Sloan School of Management

31 July 2000

The article’s focus is squaring upon the processes and results of re-engineering an actual business during that business’s evolution into a Total Quality Management (TQM) corporate environment. The corporation for MIT Sloan School of Management’s case study is Analog Devices, Incorporated (ADI) between the time periods 1987 through approximately 1993.

The case study’s objective was to observe the connection between quality improvement and financial results, which, in this case appears weak. In short, the study uncovered two basic elements separating TQM improvements and how they worked counter-productively to yield adverse results. But, before entering this discussion, a brief explanation of ADI’s business is in order. ADI is a leading manufacturer of integrated circuits. Thus, their business model contains two core components: (a) product development (indirect costs) and (b) manufacturing (direct costs). These two core components, as well as the personnel and the functionality associated with and within each of these, are at the heart of the counter-productive results displayed during the adoption and subsequent execution of ADI’s TQM implementation.

Briefly, the manufacturing component of ADI’s business (the direct costs) achieved outstanding results. Within three years, product defects fell by a factor of 10 and semiconductor yields nearly doubled while manufacturing cycle time fell by half. Conversely, ADI’s product development component could not keep pace. "Many engineers didn’t think TQM could improve product development and thought it interfered with their autonomy". In short, efforts to speed product development and reorient ADI’s capabilities to meet changing customer needs could not stimulate demand fast enough to match the improvements in capacity caused by faster cycle time, higher yield, and fewer defects. R&D, sales, marketing, distribution, and management, the activities driving indirect costs, all had higher technical and organizational complexity as well as intrinsically longer improvement half lives than the manufacturing activities driving unit production costs. Within two years of implementing TQM, indirect costs fell just 9%.

Primarily, "management’s desire to build commitment to TQM by demonstrating early results focused attention (and, admittedly throughout the article, resources) on operational issues and slowed progress in new product development, contributing to excess capacity". Obviously, the poor corporate financial results in the early 1990‘s can be directly attributable to this factor.

Many factors discussed above have direct implications to software dynamic modeling. System dynamic modeling was the modeling methodology chosen by the MIT team in capturing the complex interventions between the physical and institutional structure of ADI’s organization and the external market forces acting upon it.

How does this article and its subject matter tie into Systems Dynamic Modeling and the elements for understanding and guiding this student throughout this project?

• One primary issue is People, People, People…

At ADI, people didn’t want to improve so much that their job would be eliminated – One thing stated in during one of my MBA classes at UMass-Dartmouth (Organizational Behavior course) by UMass – Dartmouth Business Prof. W. Einstein was that "All problems are people problems". Well, some might say, "That’s a nice socialistic attitude, but what does it have to do with System Dynamic Modeling?"

Hypothetically, that "Groupware" topics studied in Human Computer Interactions, may have a place within the Dynamics of the modeling, specifically during the early (estimation) phases of building the modeling components of a project and, subsequently, the processes of interacting the results of those components. In short, these models should be developed with components which can include a variety of elements and personnel within the corporation and not just management’s input. But, one does not want to cross the line to a point where bureaucracy dominants and stifles the simplicity and robustness of the model.

People represent the various actors in the system, or in this case, their feelings and attitudes are representative of the cause-effect components within the system dynamic model. Thus, the role of modeling "soft" variables such as workforce commitment, morale, and fear of job losses, played an important role in understanding the dynamic interaction unfolding during the period under study. Continuing to expand the complexity of the corporate/personnel dynamic within the model for any situation, whether in software project management or "building-a-bridge" project management, would yield extreme benefits to the realism which the model could portray.

• Another issue is diagnosing flaws in the model being developed!

John Sterman’s synopsis discussed in Chapter 21 (Truth and Beauty: Validation and Model Testing) of his book titled "Business Dynamics: Systems Thinking and Modeling for a Complex World", cuts to bone in simplistic easy-to-understand terminology. His belief is that no models are valid or verifiable in the sense of establishing their truth. The question is "Are they useful"! Sterman stresses:

• Involving the client in the modeling process – make them a partner and develop a deep understanding of the system and the confidence to use that understanding to take action.
• Testing is an integral part of the iterative process of modeling
• Use all types of data (numerical and qualitative) and multiple data sources (provides cross checking opportunities).
• Consider extreme test conditions
• Test the model’s sensitivity to its boundaries as well as variations to parameter values
• Most of all – the model must be fully replicable and available for critical review.

Clearly, the role of indirect costs within a business needed to be better understood to successfully implement a succinct TQM corporate business model. Management’s short term interests in "window dressing" (looking for short term, gratifying results) places ADI in a vulnerable financial and operationally stressful position. So what’s the point! The same thing can happen in Software project management. Understanding, up front, the requirements and placing up-front efforts to design project pitfall "escape hatches" can assist the project management team. But, most of this discussion focuses on qualitative issues.

Well, the use of simulation software to mental prepare and training the team for various situations and pitfalls. Additionally, the simulation can act like a mentor tool for reference at a point in the project where scenario/situation playing with various parameters may help the team decide what path the project should ultimately travel.

Should there be an Interactive "Groupware" component to Software System Dynamic Modeling? And, if so:

1. Are the concepts of individual elements defined well enough to attempt to model interactive, group component tools into a Dynamic Model?
2. Who are the players to participant within the organization?

Lastly, the role of "inspections" appears to be a HOT topic in today’s realm of software There are several articles to be reviewed for this project which relate to inspections and inspection criteria. Currently, however, Sterman’s approach regarding to this topic, appears rational and adaptive, but unfortunately tedious, time consuming and expensive. Expensive from the perspective that each model may need extensive alterations dependent upon the project at hand.