Identifying and Understanding Problems and Opportunities

From SEBoK
Revision as of 04:40, 18 August 2011 by Sjackson (talk | contribs) (Primary References)
Jump to: navigation, search


Jenkins according to (Checkland, 1999, p. 140) states that the first step in the Systems Approach is “the recognition and formulation of the problem”. In a hard system approach we start from the assumption that there is a problem to be solve. We have used the phrase "problem or oppourtunity" in this topic to recognise the fact that the "problem" need not be a negative one, but coild represent a positive oppourtunity to develop a system. In the sense the "problem" is that we do not have a system to take advantage of this new oppourtunity.

The Systems Approach described in this knowledge area follows is predominantly a hard system approach. The Analysis, Synthesis and Proving parts of the approach assume a problem or oppourtunity has been agreed and an Engineered System is needs to be developed against that need.

The Problem and Oppourtunity part of the approach has some overlaps with soft system approaches. This is discussed in more detail below.

This section will summarize problem and opportunity exploration as described by (Edson, 2008) and others.

Soft Problem Exploration

Soft System Thinking does not look for "the problem", but considers a problematic situation. Forming systems views of this situation can help stakeholders to better understand each other viewpoints, and provide a starting point for direct intervention in the current system context. If a full soft systems intervention, such as Soft Systems Methodology (SSM) (Checkland, 1099), is undertaken, this will not include formal Analysis, Synthesis and Proving. However, the SSM method was originally based on hard methodologies, in particular (Jenkins, 1969), it does follow the basic principles of a systems approach: "analysing" conceptuals models of shared understanding; "synthesising" intervention strategies; and "proving" improvements in the problematic situation.

Often the distinction between hard and soft methods is not as clear cut as the theory might suggest. Checkland himself has been involved in applications of SSM as part of the development of Information System design (Checkland and Howelwell, 1998). It is now agreed by many that while there is a role for a "pure soft system" approach, the service and enterprise problems now being tackled can only be dealt with successfully by a combination of soft problematic models and hard system solutions. (Mingers and White, 2009) give a number of releavnt examples of this, including (Checkland and Winters 2006). Thus, we might expect Systems Engineering problems to be stated, solved and used as part of a predominately soft intervention. The will place pressures on the speed of develoment needed for in the solution space. This is discussed more fully in under Life Cycle Models.

The critical systems thinking and multimethodology approaches (Jackson, 1985) take this further by advocating a "pick and mix" approach in which the most appropriate models and techniques are choosen to fit the problem rather than following a single methodology (Mingers and Gill, 1997). Thus, even if the hard problem identification approach describe below is used we should consider the use of some of the soft system techniques (such as rich pictures, root definitions or conceptual models) within it.

Hard Problem Exploration

Hard System Thinking is based on the idea that a problem does exist, which can be state by one or more stakeholders in an objective way. This does not mean that hard systems approaches start with a defined problem, exploring the potentialproblem with key stakeholders is still an importnat part of the approach.

According to (Blanchard and Fabrycky, 2006, pp. 55-56) defining a problem is sometimes the most important and difficult step. Defining a problem is asking the questions: What needs to be improved? What is the purpose of the system you want to define? Sometimes a problem is known as a “need.” In short, a system cannot be defined unless you can define what it is supposed to accomplish.

According to (Edson, 2008, pp. 26-29), some of the questions that need to be asked are as follows:

First, how difficult or well understood is the problem? Problems can be “tame,” “regular,” or “wicked.” The answer to this question will help define the tractability of the problem.

  • For tame problems, the solution may be well defined and obvious.
  • Regular problems are those that are encountered on a regular basis. Their solutions may not be obvious, so serious attention should be given to all aspects of them.
  • Wicked problems may not be solvable using obvious approaches, so detailed attention should be given to them.

The next factor that needs to be considered is who or what is impacted? There may be elements of the situation that are causing the problem, other elements that are impacted by the problem, and other elements that are just in the loop. Beyond these factors, what is the environment and what are the external factors that affect the problem?

Finally, what are the viewpoints to the problem? Does everyone think it is a problem? Perhaps there are conflicting viewpoints. All these viewpoints need to be defined. Persons affected by the system, stand to benefit from the system, or can be harmed by the system are called stakeholders. (Wasson, 2006, pp. 42-45) provides a comprehensive list of stakeholder types. The use of soft systems models can as discussed above can form an important part of this, describing a problematic situation view can be a useful model to help consider these issues, even if a single problem perspective is selected for futher consideration

Operational Research (glossary) is a hard systems method which concentrates on solving problem situations by deploying known solutions. The Problem Analysis step of a typical approach (Flood and Carson, 1993) asks questions about the limitation and cost of the current system, to identify efficiency improvements that need to be made.

Traditional systems engineering methods (Jenkins, 1969) tend to focus more on describing an abstract model of the problem we would like to solve in terms of the benfits stakeholder expect to see from a solution. The expectation is often that we will need to create a new solution, although this need not be the case. Jenkins suggest that System Engineering is just as applicable to redesign of existing systems. An important factor in defining the desired benefits is the scenario in which the problem or opportunity exists. (Armstrong, 2009, p. 1030) suggests two scenarios: The first is the descriptive scenario. This is the situation as it exists now. The second is the second is the normative scenario. That is the situation as it may be some time in the future. Armstrong suggests that this may be the most difficult part of the problem or opportunity (Armstrong uses the term issue) to define.

Problem Context

In the System Context topic we identify the concept by which a complex system situation can be resolved around a System of Interest. We can consider the inital identification of a "Problem Context" as the outcome of this part of the systems approach.

If we can create an initially description of the Wider System of Interest and Environment this will form our problem or oppoutunity. Desired stakeholder benefits are expressed a outcomes in the wider system and some initila expression of what the System of Interest is for may be identified. Jenkins (jenkins, 1969) defines a problem formulation approach in which we:

  • state the aim of the System of Interest
  • Define the Wider System of Interest
  • Define the Ojectives of the Wider System of Interest
  • Define the objectives of the system
  • Define economic, information and other conditions

The practice of System Engineering described in the SEBOK should follow the important principle that all problems and oppourtunities exist in an engineered System Context.

Linkages to other topics

Capturing of Stakeholder Needs in Systems Engineering.


Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.


Armstrong, Jr., James E., 2009. Issue Formualation. In: SAGE, A. P. & ROUSE, W. B. (eds.) Handbook of Systems Engineering and Management. Second ed. Hoboken, NJ: John Wiley & Sons.

Blanchard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.

Checkland, P. 1999. Systems Thinking, Systems Practice, New York, John Wiley & Sons.

Checkland, P and Holwell, S. 1998. Information, systems and Information Systems; making sense of the field, Wiley and Sons; Chichester.

Checkland, P and Winter, M. 2006. Process and content: two ways of using SSM. Journal of Operational Research Spciety 57 (12), 1435-1441.

Edison, R. 2008. Systems Thinking. Applied. A Primer. In: ASYST INSTITUTE (ed.). Arlington, VA: Analytic Services

Flood, R. L., & Carson, E. R. 1993. Dealing with complexity: An introduction to the theory and application of systems science (2nd ed.). New York: Plenum Press.

Jackson, M. 1985. Social systems theory and practice: the need for a critical approach. International Journal of General Systems 10, 135-151.

Jenkins, G. M. 1969. The Systems Approach, in Beishon, J and Peters, G. (eds) Systems Behaviour (2nd ed.). New York; Harper and Row.

Mingers, J and Gill A. 1997. Multimethodology: Theory and Practice of Combining Management Science Methodologies. Wiley; Chichester.

Mingers, J and White L. 2009. A review of recent contributions of Systems thinking to Operational Research and management Science, Working Paper 197. Kent Business School, Canterbury.

Wasson, C. S. 2006. System Analysis, Design, and Development, Hoboken, NJ, John Wiley & Sons.

Primary References

Blandhard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.

Edson, R. 2008. Systems Thinking. Applied. A Primer. In: ASYST INSTITUTE (ed.). Arlington, VA: Analytic Services

Additional References

Flood R and Jackson M, 1991. Creative Problem Solving: Total Systems Intervention. Wiley; London.

Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->