Jonas Runberger

Full title: Produktutveckling bortom kunskapens gränser, Mote en osäkerhetens grammatik. Mats Engwall is the new professor in Industrial Economy at IndEk. This book is co-written with Peter Magnusson, Cassandra Marshall, Robert Sandberg and Tommy Olin, who are responsible for the case material in chapters 2-6. It was published in Swedish  by Student litteratur 2003.
The book makes an argument for product development in situations in which the final product, and possibly also the process needed to developed it, are unkown. Missing information is considered normal within the field of product development, and a reason and opportunity to make projects into learning processes.
Four cases are used as the basis for the discussion, all development projects for new products and services within the IT sector in the mid to late 1990s.  I have not read the cases carefully; I have instead focused on the chapters drawing conclusions from the material.
Chapter 1 describes traditional linear development processes, which go through a stage-gate model in which each part of the process is evaluated before moving on to the next phase. These evaluation gates are very formal, and the control of development is close to a production process. Engwall identifes two primary problems with the linear model of development. 1. They do not really correspond to the unstructured and iterative development with a large portion of intuition used in practice. 2. They depend on perfect knowledge of the goal of development (which must not change during the process), meaning that the development team really shouldn´t learn during the process, which makes Engwall conclude that these projects are not development projects at all.
Engwall uses the metaphor of grammar to present the formal development models used by different companies. He stresses that this grammar only sets rules of action, but is not describing the activities themselves. The findings in the book are more based on identified actual activities, than the rules defined by this grammar.
Insecurity is an important concept throughout the book. There are several cases where this becomes an issues. 1. Insecurity due to missing information, in which the problem is identified, but there is simply missing information on how to solve it. This type is defined as projects of low insecurity. 2. Insecurity due to un-clarity, in which the work is conducted outside of the normal procedures and previous experience cannot be directly applied. This type is defined as projects of high insecurity. All projects are also subject to insecurity in product (what should be developed, for whom and why) as well as process (How to do it, what tools to use, what actors to involve). In a linear project, the target/goal of development is frozen before the process is started, but the four cases used in the  book all use insecurity in different ways, and the targtet was defined through iterations isolated experiments, and often also through customer involvement.

Chapter 2 introduces the IT sector, and chapters 3 – 6 are describing the four cases: Department of the Future (DOF), a new Telia brand 1997-1998, Telia Intranet, an internal internet service 1997-1998, Asterix, a new radio base station by Ericsson 1995-1999 and Virtual Call Center, a Telia development for SJ 1995-1999. I have not studied these in detail.
Chapter 7 looks more closely at the linear stage-gate model, in which a building project is put forward as a clear example. The method originated from NASA in the 1960s, where the Phased Project Planning (PPP) model was applied to all development projects. The method was adopted in order to gain administrative and economic control over processes as the organization grew larger and larger, also in order to achieve competition to cut costs.
An important feature is the control logic which makes the development completely internalized and closed to the outside, in order to ensure maximum efficiency in development. Pre-set gates can still include the opportunity to change the direction, or cancel the project if appropriate results have not been achieved. The administrative rules of the set up allow certain decentralize decisions, as long as the initially defined agenda is followed. The method also promotes trust, in the sense that known procedures are used, and only normative solutions are considered.
Engwall refers to Baxter, M. Product design, Chapman and Hall, 1995:”[Product development is] a process of translating an idea for a product into a set of instructions for its manufacture.” He relates this reference to a linear process, in which all ideas are on the table initially, comparable to the input of materials to a production process. He warns for two primary concerns when using linear processes. 1. Some ideas may be discarded as the process is launched, since they have not been fully articulated at that stage. 2. The defined project goals may be very exact, but may not correspond to the understanding and capacity of the participants, in this sense the decision makers are complying with a standard that does not really exist in the actual development process.
Engwall makes a distinction between two different approaches. 1. The implementation project in which the development process and goals are well known, in essence the linear project. 2. The innovation project in which many things are unknown, and there is no real difference between the preparations of the project, and the actual project work. The field of practice is not relevant here, only the previous experience of the developers (a building project may in this sense be more innovative than a nuclear physics project).

[This suggests that the difference is based on subjective methods for handling unsecure conditions.]

Chapter 8 concludes and outlines modes of operations to handle insecurity in product development. Four similar conditions are identified in the cases presented in chapters 3-6: 1. The need for a defined development goal or specification is dismantled (“the freezing point of specification is thawed”), and the work can commence before any specifications are set. 2. Thoughts and actions are linked in compartmentalized experiments with controlled conditions. 3. Common practical examples are created instead of perfect specifications. 4. The customer is involved in the development.

[All these aspects are very similar to my ideas around prototype work. No 4 is the one which is commonly used for physical prototypes (make a mock-up and put it into the hands of the user, then see what happens), and is perhaps the most conventional. If one considers the development of prototypical systems that after being established becomes the platform of interaction between different parties, the notion of customer or client becomes more multiple however. Collaborating designers are actually the first user of the developed system. Still, it may be interesting for me to explore how an end user of a designed environment/product may be a partner in development. This has been somewhat lacking in previous prototype development (although the interaction in exhibitions has been there, I was never fully able to document and learn from this interaction).]

The authors state the importance of not completely abolishing previous methods such as the stage-gate model, but other control mechanisms may be necessary. A number of advices are formulated at the end of the chapter: 1. Act early in order to make sure that a team has a common understanding of what is being developed. 2. Common visualization through modeling and prototyping makes it easier to continue to communicate. 3. A preparation for “unexpected learning” is crucial since the understanding of the development is not complete until the end of the process, and the decision gates are not static but must be seen as hypothesis to be re-evaluated continuously. 4. By structuring for flexibility a preparation for the unexpected is achieved, and even stage-gate models may be valid, if placed in between loops, experiments and iterations, and if models and prototypes are being considered along side of documentation. 5. There is a need for an understanding of different frames of mind; in particular of those outside the development process, otherwise an alienation of the innovation process may be arising. 6. Side stepping regular methods should be done tactically, and not by default.

In an appending note on research methods, the content of the book is recognized as a collective material, and an effort to create and form new concepts, rather than testing established theory. A shift from a logic positivistic research is recognized, and the participation in the four cases is compared to the work of an anthropologist. The pros and cons of this closeness to the object of studied is also discussed, where any conscious act of tweaking the result is considered less concerning when compared to a danger of not seeing certain central aspects due to being too familiar with the material.