What is “design process”?
Every design professional knows the answer to that question; all of them do it every day. But what are the chances that any two of them would describe it the same way?
Most architects see design process as being iterative; as making progress across a spiral of iterations. I describe this iterative process in TQM and ISO 9000 for Architects and Designers, Chapter 5.1, which you can download here.
I think part of the difficulty with getting a succinct picture of “design process” is that we are by nature and self-perspective “problem solvers”. By extension, the solution is embodied in the problem, and doesn’t exist without a problem to be solved.
Check “design” in Wikipedia; you will get a quite good discussion of the question. Wikipedia begins with a description of the “rational” model of design, but notes: “The Rational Model has been widely criticized on two primary grounds:
Certainly both of these grounds are true in the built-environment design disciplines, despite determined efforts by project managers to get designers to think and work “rationally”.
Can we “manage” design?
In the 4,000-year context of the history of architecture, the concept of “Design Management” is a comparative infant – only about a decade old. Design professionals traditionally saw the design process as something that could not be “dissected” without destroying its essence. As noted above, design professionals traditionally have not mentally separated design content from design process; they see these as entwined together.
These issues are important, because, while the content of design – the combination of conditions that drive project development – are infinity varied, the processes of design, however complex, are universal. Only by separating them is it possible to create automated tools to effectively manage design process.
What rethinking is required?
If you concur with the above, and with Dana Cuff”s points in the sidebar, it seems obvious that we need to do as I suggest above: Create a model that is generally linear in problem-solving, but accepts an iterative path to get there, and which seeks universal process steps that can suitably be adapted to any project.
That is an ambitious challenge, one that is top-of-mind throughout this site and the various papers that support it.
Although there are a number of “practice management” tools available, as well as several “project management” tools (mostly for scheduling), to this point nobody has yet created a generic model for managing the design processes for the built-environment disciplines, perhaps because of the complexity of these issues.
Nevertheless, a combination of pressures of varying kinds on our design professions strongly suggest that we need such tools, now more than ever before: the time is right.