Problematics LLC is concerned with the development and application of fundamentally new problem solving methods. The two methods we are primarily focused on today are the Dependency Structure Method (DSM) and Cause and Effect Analysis (CEA).
Let's look at DSM first.
Originally DSM was called the Design Structure Matrix. It was developed in the late 1960's and published in 1981 both as an article (The Design Structure System: A Method for Managing the Design of Complex Systems in IEEE Transactions on Engineering Management) and in that same year as a book Systems Analysis and Management: Structure, Strategy and Design.
Various versions of the Design Structure Matrix have been used for engineering design by a number of Fortune 500 companies. In 1999 MIT initiated what has become a yearly series of DSM International Workshops that is still functioning.
However, Problematics believes that DSM is more than an engineering method. It is a fundamental problem solving method applicable to many types of problems that extend far beyond just engineering.
Many of the 'new' management proposals advanced over the last few decades have called for flatter organizations and greater empowerment. But these methods have failed to meet their expectations. Problematics believes this is because when an organization is flattened and its people empowered, they still need to be directed and held accountable for their work, a capability that is lost when the hierarchy is abandoned.
Mary Parker Follett, before her death in 1933, noted that industry was too complex to be managed from the top alone. She proposed that management should be dispersed among many managers with each having visibility of the situation. She was very perceptive. But it has not been until more recently that two vital ingredients necessary to provide that visibility have become available. Networks of desktop computers can now distribute that visibility. And now DSM provides the method for representing that visibility. When everyone has this visibility, they can align their work with the goals of the enterprise.
Up through the Industrial Age we did our planning and observed our progress through the observation of Things, Tasks and Time. Critical path scheduling, for example, involved looking at the relations between Tasks that produce Things over Time. But when the products we are developing consist largely of information, we now need to look at the domain of Information Relations and Flows.
We begin by taking the following view of what a business is.
The business of business is solving problems.
A business solves its own problem of making revenues by supplying products and services that help other businesses solve their problems. DSM can be used for this problem solving.
Using DSM, one first lists all the information items that must be determined before it can be said that the problem is solved. Then a spreadsheet like matrix is used to show which information items depend directly on which other information items. This gives us what is called the structure of the problem.
But when we look at the structures of the complex problems that businesses are trying to solve today, we find that they don't lend themselves to being solved top-down by divide-and-conquer as had been assumed in hierarchical organizations. The structures of these problems typically involve circuits. A circuit arises when some information item depends on other items that can't be determined until this item has been determined. Such circuits are handled by making assumptions to break the circuits, then working around the circuit until arriving back at what had been assumed. Then a review can be made as to whether the original assumption was adequate, or whether the process must be repeated with a new assumption.
Problematics has developed the PSM32 program that allows one to develop the structure of the problem and analyze this structure to choose an approach showing where to use assumptions to minimize time and risks. After doing this analysis, a plan can be made where the assumptions and risks are made explicit so they can be managed. This has a distinct advantage over the usual plan making where assumptions are buried in the plan and often not recognized until they may prove to be wrong, causing delays, cost overruns and heightened blood pressures.
PSM32 can be used to give everyone involved in a project a view of how his or her work is related to everyone else's. They can also see the status of the information they need as it is being developed. Using PSM32 one has a better picture of progress because one can see whether or not work completed is really done or may still depend on open assumptions and thus be subject to the possibility that it may have to be redone with new assumptions.
In a hierarchy each person has only that visibility granted by his or her managers. Managers must anticipate what each of their people needs to know. But when these persons know more than their managers about how to solve the problem, they need to seek the visibility only they recognize as being necessary. This also allows for more creative thinking. People can also see and learn from what others are doing and pitch in to help when they see someone could use their assistance.
Elsewhere on this web site is an article on the use of PSM32 in management, called Let's look at the situation. This article will show a simple example of how this system works.
A demonstration version of the PSM32 program capable of handling 40 information items as well as tutorials are available through this web site as a free download. These limits can be extended by entering a registration code that can be purchased from Problematics for $542 (sales@problematics.com).
We are looking for someone to work with us to implement this system in their environment to provide everyone on a project with visibility of the situation and to manage risk during the execution of the project. We welcome your inquiries.
Now let's look at Cause and Effect Analysis
There has been a great deal of interest lately in Knowledge Management. But the real purpose of knowledge is to be able to use it to solve problems. Problematics is developing software that closes the gap between knowledge and problem solving by using cause-and-effect relations.
Cause and effect is one of our most basic methods of reasoning. The behavior of many systems can be described by a system of cause and effect relations. These relations can be used to find hypotheses that would explain the causes and cures for a system not behaving as it should.
When a defect is noticed, the usual approach is to guess at a hypothesis for the cause, use the cause and effect relations to deduce the consequences of this hypothesis and see if those consequences correspond to what is to be explained. But this is a trial and error process looking for a satisfactory hypothesis. Furthermore, once finding a hypothesis, one does not know whether there may be other equally satisfactory hypotheses that have been overlooked.
Problematics has developed a preliminary version of the COPE software (Cause Or Prevention of Effects) which solves the Boolean expressions that represent the cause and effect relations so as to be able to find all the explanations within the scope of a set of cause and effect relations.
This technique has many conceivable applications such as:
- Diagnosing symptoms to explain their cause and cure, such as:
- Medical diagnosis.
- Equipment failure.
- Accident diagnosis.
- Quality assurance - tracing the causes of product defects.
- Crime analysis.
- The Scientific Method:
- Finding the hypotheses that would explain various phenomenon.
- Testing new observations to see whether they too could be explained by these same hypotheses.
- Determining various ways by which something might be achieved:
- Developing the 'creative' design of processes to achieve certain results with given capabilities. (We usually call an idea creative if involves concepts that are not obvious to most people, which could be the case here.)
- Developing a dynamic business plan that can be changed as quickly as circumstances change.
If you have further interests in this approach, please see The Knowledge Gap elsewhere on this site. That article shows how a simple system of cause and effect relations might be used to describe and diagnose the behavior of an automobile. It also discusses our concept of a Wiki Problem Solver.
We thought that this technique would be useful for creating scenarios of how terrorists could act, then show how these scenarios could be prevented. But our attempts to discuss this with the Department of Homeland Security have only led to two years of utter frustration. We think that DHS has confused what we are proposing with something else they might already be looking at. But in talking to people who have worked with abduction over a period of years and reading their materials, we conclude that our technique is different than those known to be developed elsewhere and has the advantage of finding all the hypotheses within the scope of the system of cause and effect relations.
We would be very open to hearing your ideas as to how this can be used and will soon make our primitive version available to anyone daring enough to try it.
Work with the Dependency Structure Method (DSM) has now taken two courses. It is being widely applied to engineering design. MIT has been a leader in that work as well as those who have been attending the six yearly DSM International Workshops, started at MIT in 1999.
But DSM can also be viewed as a fundamental problem solving method.
The Dependency Structure Method (DSM) was originally developed in the late 1960's by Donald V. Steward. But it was not approved for publication until 1981 when it appeared as The Design Structure System: A Method for Managing the Design of Complex Systems in IEEE Transactions on Engineering Management and in that same year as a book Systems Analysis and Management: Structure, Strategy and Design.
MIT and others have been responsible for much of the development leading to applications of DSM and other types of Boolean matrices to engineering. Problematics is concerned with its applications both to engineering and to business, but has focused mostly on business.
Problematics has come to see DSM not just as a way of applying adjacency matrices to engineering design, but as a fundamental problem solving method.
