Identifying and Understanding Problems and Opportunities

From SEBoK
Revision as of 21:36, 17 August 2011 by Radcock (talk | contribs) (Soft Problems)
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 Problems

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

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.

An important factor in defining the problem or opportunity is the scenario in which the problem or opportunity will exist. (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 arounf a System of Interest. We can consider the inital identification of a "Problem Context" as the outcome of this part of the systems approach.

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.


List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

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.

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

Additional References

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

Article Discussion

[Go to discussion page]

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