After an IT system is designed, built, and installed, you may discover that it solves only a part of the initial problem or that the problem was poorly understood to begin with. This happens when participants have different mental images, or models of what the problems are and how they should be remedied. A formal model of the problem makes these perspectives more explicit. A model represents a small-scale simplification of the problem being addressed. It can take the form of a system diagram, a process flow chart, a spreadsheet, a set of equations, or even a computer model.

Collective visions of the problem. The formal model is a public visualization of a problem. It allows people to see how their own assumptions of the problem fit into a larger view that is shared by all.

Reproductions of the problem. A good model can represent the essence of the problem. This helps ensure that the problem is understood well enough to begin investing resources in framing, testing, and evaluating solutions.

More than one thing. A good model is a collection of perspectives that work together to create a precise description of a problem to be solved. Although there are many different types of formal models, most of them share a number of common features including:

• "Stories" of how it works and what's wrong with it. These accounts typically reflect many different points of view. They can be gathered either through a group process or individual interviews.
• Common visuals of the system that needs fixing. These visuals usually take the form of business process maps (see next tool) or structured system flow models.
• Numbers and other measures of key variables. Quantitative models need to be explicit about which measurements are key indicators of the problem.
• Analyses of sources of the problem. The logical reasons for a problem are often revealed by drawing a diagram of a process or system. The elements of the process can be extracted from verbal accounts of the system, and lead to measures of system performance that reproduces the problem.
• Lists of proposed solutions. Ironically, many managers define problems in terms of their solution (e.g., the problem is that we need more people in the field). By collecting lists of what managers think the solutions ought to be, you can more clearly define the problems that are implicit in those solutions.

Making the implicit explicit. Modeling makes individual implicit assumptions and mental pictures explicit. It also imposes a process on a team's thinking about a problem that helps prevent premature conclusions.

Creating common definition of the problem and possible solutions. The process of modeling serves to focus discussion on the root causes of observed problems in order to develop common definitions and potential solutions.

Identifying underlying forces. Models can help analysts and managers come to grips with the causes of problems.

Measuring. Modeling pushes the team to identify which key performance variables really count.

Developing "what if" analyses. Models help participants see how problems would get better or worse under different sets of possible circumstances.

Communicating with external audiences and decision makers. Models help project team members communicate their reasoning to the external audiences that need to be involved in solving the problem or who need to make investment or other decisions.

Expensive and time consuming. Some approaches to modeling a problem (or its solution) may require specialized knowledge and techniques that are hard to find or expensive to apply.

Level of complexity. Sometimes the models themselves can get so complicated that they can't easily be understood. Overly complex models don't help illuminate the core of a problem. But models that are too simple fail to capture enough complexity of a problem to provide new understanding.

Bias. Sometimes the modeling approach that a team chooses has a subtle and biasing effect on how they will look at the problem. For example, spreadsheet models emphasize the financial aspects of a problem, whereas process maps tend to look at workflow.

Validity. Models can be wrong. When this happens, you have a whole group of people aligned around a view of the problem that won't yield solutions. Fortunately, this probably occurs less often with models than without them.

How to model a problem: one approach.

Because there are so many different approaches to modeling a problem, no single way of getting started always works. However, a number of common sense steps can get you far enough down the path to decide whether you can finish a problem-centered model yourself, or need to call in some expert help.

Gaylord, R.J. and L. D'Andria (1998), Simulating Society: A Mathematica Toolkit for Modeling Socioeconomic Behavior. Springer: New York.

Stokey, E. and R. Zeckhauser (1978) A Primer for Policy Analysis. New York: W. W. Norton.