Most process-intensive organizations look to a process specification document as the final word on development activities. We noted three problems with this approach in practice: lack of empirical conformance between practice and process specifications; incompleteness of process models; and inability to capture long-term stable process abstractions. Many processes exhibited such broad variation in behavior that it was difficult for process specifiers to agree on a process that represented the typical scenario. Many organizations informally built process specifications from anecdotal process experience instead of driving the baseline process model with empirical models and data. Many organizations we studied created an ideal specification instead of capturing empirical practices [BibRef-Archibald1993 ]; organizations used those specifications as a baseline for improvement despite this mismatch. Because many process specification models were divorced from empirical practice, nothing forced development practice into statistical control.
Second, process models were often incomplete and inconsistent. Most process models focused on the task and event perspective, leaving artifacts, roles, actors and agents as secondary abstractions. Much of this task perspective was driven by a preoccupation with interval prediction and reduction on one hand (one manages overall interval by focusing on individual intervals) and quality on the other (methodical reviews form obvious task/event benchmarks). Task models fit well the waterfall-based development model that is predominate in most development cultures. Furthermore, task models held up the promise of process automation (e.g., [BibRef-KrishnamurthyRosenblum1991 ]). We note that the disconnect between process tasks and the artifacts they produce continues to plague most of the organizations we work with today.
Third, many organizations built their process improvement programs around the task or event dimension of process. Well-understood processes (like bug report flow) often can be regularized, but the core processes of architecture, design, implementation and validation are poorly understood from a task perspective. We have found that task ordering changes rapidly in a high-technology development organization, so it can't be counted on as a stable component of process structure.
One large organization we studied surveyed its developers and found that 80% of them were working under officially granted process waivers instead of the official common process, largely because the project's process standard didn't capture the essential, stable structure of the process. One reason that task chain models don't capture the stable structure is because of the high degree of concurrency present in modern software development. It is interesting to note that iterative and incremental design cultures were demonstrating success at about the same time that process consciousness was growing.
Project managers still find it difficult to reconcile iterative and incremental techniques with process standards that prescribed process steps [BibRef-Archibald1993 ]. Many organizations we studied exhibited concurrent engineering practices, where requirements, design, and implementation activities proceeded in parallel [BibRef-Hartley1992 ]. Few organizations intentionally applied concurrent engineering. In fact, many organizations using concurrent engineering (as we discovered empirically) remained stalwart about the accuracy of their waterfall design methods (as stipulated in project process documents). We felt that a role-based model would be a better match for these concurrent engineering organizations than would models based on tasks and events.
There is growing recognition that even if process models could represent interesting aspects of an organization, they aren't terribly useful as a guide for carrying out the work of the business. In Contextual Design ([BibRef-BeyerHoltzblatt1998 ], p. 41), Beyer and Holtzblatt note:
In Contextual Design, we always try to build on natural human ways of interacting. It is easier to act, not out of a long list of rules, but out of a simple, familiar model of relationship. A list of rules says, "Do all these things" — you have to concentrate so much on following the rules you can't relate to the customer. It's too much to remember. A relationship model says, "Be like this" — stay in the appropriate relationship, and you will naturally act appropriately.
And this position in turn builds on longstanding observations of human behaviour; Beyer and Holtzblatt cite Goffman's work from almost a half-century ago as foundation for this position ([BibRef-Goffman1959 ]). We sought to counter the problems of an explicitly process-based approach to organizational improvement with an explicitly role-based modeling approach.
We wanted to adopt process formalisms that would allow us to compare iterative processes with traditional waterfall models; this meant going beyond task and event models. While many aspects of process might be automatable, we found that productive processes emphasized the creative value added by the people in the process. In general, this suggested that we should study many dimensions of process: artifacts, organizational roles and structure, personal skill sets, and many other factors. Together, these diverse properties define a process architecture. Architecture is a partitioning of a system that results from applying a set of partitioning principles, together with the relationship between the parts resulting from that partitioning.
Our resources didn't allow us to study all of these at once, we decided to focus on organizational structure, to balance the investment most organizations had made in task models. The industry has a fascination with the relationship between development organizations and the software they create (see [BibRef-Fraser1994a ] and [BibRef-Fraser1994b ]) so we felt there would be interest in such research.
The organizations we studied didn't necessarily correspond to formal organizational structures, but arose as communities of interest develop within a project. The "real" organizations in any culture can be defined in terms of coupling between actors or roles, brought together by a common interest or objective. Such organizations are called instrumental organizations and should be distinguished from the formal organization structure. An instrumental organization is the "instrument which regulates organizational behaviour." ([BibRef-SwieringaWierdsma1992 ], page 10). These two structures line up in some organizations; see the studies by Swieringa and Wierdsma [BibRef-SwieringaWierdsma1992 ].