Chapter 1. THE DESIGN PROBLEM

Waterfalls and out-of-control speedboats

The dominant process model employed in IS design practice – and upon which most IS development methods are based – is Simon's (1973) ‘rational’ model of ill-structured problem-solving, normally translated to a "waterfall model," where the outputs of one stage of design act as inputs to the next (Royce 1970). Simon argues that design is associated with an objectively-defined problem definition and a set of goals for its resolution that are defined by structures inherent in the situation (Simon 1973; 1996, my emphasis). To close the gap between current organizational performance and a set of  consensual goals, the analyst engages in a process of problem structuring and decompositional means-end analysis. This is performed under the control of a mental process that interprets goals as a way to structure the solution space [1] (the set of potential IT system solutions envisaged by the analyst). The process is shown in Figure 1.2. 

Figure 1.2: A Traditional Model of the IS Design Process (based on Simon 1973; 1996)

• A consensus problem is agreed and goals are defined that will resolve the problem (Simon 1960; 1973; 1981). Requirements for an IS solution are expected to be defined through an analysis of the gap between current performance and goals (Checkland and Holwell 1998; Simon 1981). The decomposition of what is left from the "space" of potential solutions, when constraints imposed by problem-definition and organizational goals are taken into account, provides an optimal system solution. This model is based on the model of problem-solving proposed by Alexander (1964) Alexander – writing in the field of architecture, where design outcomes and exemplars are concrete and visualizable – hypothesized that rational problem-solving was best served by breadth-first decomposition, where problems were broken down into their constituent requirements, then each requirement was broken down into sub-requirements and so on, until a sufficient level of detail had been achieved that requirement-tradeoffs could be analyzed mathematically. This model, known as linear decomposition, was received with great enthusiasm among academics at the time. It provided a solution to how human cognition, a messy and little-understood process, could be linked to the emerging architectures of computer data-processing (Von Neumann 1945).

• This approach suffers from three main limitations as a guide to the design of organizationally-situated information systems (IS). Firstly, it is based on Simon's (1973; 1981) argument that "ill-structured" problems, such as the design of organizational IS, are associated with an objectively-defined set of initial goals, derived from structures inherent in the situation. Yet empirical studies indicate that design goals are subjective, deriving from individual interpretation and political negotiation (Howcroft and Wilson 2003; Walsh et al. 1988; Walz et al. 1993). Secondly, it focuses on individual models of problem-solving, whereas organizational IS design tends to involve group processes, based on joint definitions of problems and appropriate solutions (Curtis et al. 1988; Davidson 2002; Faraj and Sproull 2000; Rittel 1972b; Walz et al. 1993). Thirdly, it ignores the social and cultural context within which a design is constructed (Boland and Tenkasi 1995a; Lave and Wenger 1991; Orlikowski 2002). Therefore, we must search more widely for a suitable model on which to base the management of IS design.

• But the goal-driven process model shown in Figure 1.2 underlies the majority of approaches to IS design and development, including iterations of current evolutionary models such as the Rational UML process. This is mainly because it is easy to understand, but also because the linear decomposition model embeds the comforting assumption that goals and outcomes are either well-defined, or easily capable of definition through consensus. Yet empirical studies have shown that it is intensely difficult to achieve shared understanding of organizational processes, goals, or change-impacts across the boundary between various work units and disciplines (Carlile 2002; Cramton 2001; Fiol 1994). Organizational problems are not amenable to rational structuring, but are socially situated: they cannot be detached from the specific, local context of work and social interactions within which they take place (Suchman 1987). If such problems are defined out of context, they become impossible to resolve, as what-we-do is inextricably associated with how-we-do-things-here (Lave and Wenger 1991).  Therefore, goals emerge through reflective interactions with the problem-situation (Boland and Tenkasi 1995b; Markus et al. 2002b; Schön 1983). Goals appear to reflect post hoc reasoning about the meanings that we perceive in a situation rather than guiding or forming those meanings (Lave 1988; Suchman 1987). In practice, we have an out-of-control speedboat, rather than an orderly waterfall.
  Empirical field studies demonstrate a lack of fit between the goal-driven process models used to manage design and observed design activities. Experienced software designers appear to be “opportunistic” in their use of contextual information to structure a design problem, rather than following the hierarchical strategy prescribed by design methods (Ball and Ormerod 1995; Guindon 1990a). IS professionals extrapolate solutions from problems that they have encountered previously, incorporating implicit knowledge and implied requirements into the framing of new solutions (Dorst and Dijkhuis 1996; Urquhart 2001). If there are no solutions available for a design problem, as currently defined, the problem may be reframed to fit available solutions (Malhotra et al. 1980; Turner 1987).  Both problem and solution definitions emerge through interactions with the social context of inquiry, which includes other design participants, stakeholders and users, as well as artifacts, documents, norms, goals and local work practices (Boland et al. 1994; Schön 1983). This produces “surprising” information (Dorst and Cross 2001), that leads to the reframing of the design problem in unpredictable ways. The resulting process appears to involve the co-evolution of the designer’s problem-frame and the set of partial solutions available to them, until these merge to provide a target system design. A co-evolutionary model has been observed for individual software design, involving the guided fit of problem elements to solution elements, with the process cycling between the two (Dorst and Cross 2001; Maher and Poon 1996).

• An important clue, in the puzzle of how IS design takes place in complex problem-situations is provided by studies in the psychology of programming literature. Expert software designers, working alone, do not conform to a decompositional design strategy, but are "opportunistic" in their use of contextual information to structure a design problem (Ball and Ormerod 1995; Guindon 1990a; Khushalani et al. 1994). Expert designers appear to extrapolate empirical solutions from similar problems that they have encountered previously. They reuse known solutions, by identifying partial sets of requirements that fit with these solutions, incorporating implicit knowledge and implied requirements into the “framing” of new solutions (Curtis et al. 1988; Curtis and Walz 1990; Guindon 1990b; Malhotra et al. 1980; Visser 1994; Visser and Hoc 1990). If requirements do not fit with available solutions, it is often the requirements that appear to be redefined, rather than the solution. This saves the cognitive effort of a new solution search (Guindon 1990a; b; Malhotra et al. 1980; Turner 1987).

• We may extend this understanding to social behavior by examining interactions between expert designers and their clients. Empirical studies in this area reveal that designers reframe both the design solution and the problem, when confronted with new information that conflicts with an implicit requirement for the design (Malhotra et al. 1980; Urquhart 2001). This individual behavior parallels the improvisational adaptation found at the collective level of organizational problem-solving (Orlikowski and Hofman 1997; Weick 1998).  It would therefore appear that the process of converting components of an organizational problem-situation into a set of requirements for an IS solutions is far from the objective, goal-directed process suggested by Simon (1981). Definitions of design problems and solutions appear to converge in tandem (Turner 1987; Visser and Hoc 1990). There is a continual evolution of the design solution-space (the mental representation of the space of possibilities for a design solution) and the design problem-space (the mental representation of perceived elements of and boundaries for the design problem) , until these converge to provide a target system design (Maher and Poon 1996). The process that mediates this convergence appears to rely on problem and solution "framing" activities, that result from social interactions. These concepts are synthesized in Figure 1.3.

• 

  • Figure 1.3:  Design As Convergence Between Problem Space and Solution Space

  Design may therefore be viewed as the co-evolution of a problem-space and a solution-space. The “gap analysis” in this model is different from that in Figure 1.2. In the traditional model of design, a gap analysis represented the solution-space plus the tasks required to achieve a solution. But the convergence model shown in Figure 1.3 explicitly accounts for the solution-space. The gap analysis is therefore focused on the emerging goals associated with emerging problem and solution space definitions and the tasks required to achieve these goals. However, this model still focuses on individual design behavior, whereas most IS design takes place in groups and so is socially-constructed across a diversity of individual understandings (Brown and Duguid 1992; Faraj and Sproull 2000; Lave and Wenger 1991; Markus et al. 2002a; Walz et al. 1993).

[1] The concepts of problem-space and solution-space are taken from the psychology of programming literature. Initially, the problem-space concept was proposed as part of an algebraic representation of human information processing (c.f. Newell and Simon, 1972). More recently, the concepts have been used more fluidly, to denote the “space” of potential design problems or solutions that underlie the selection of specific design attributes (c.f. Dorst Cross, 2001).

Scaling up