Action, Learning, and Project Organizations

Projects are designed for action. In particular, getting things done by fulfilling an explicit and predetermined task is the main justification for the project itself. In normal projects such efforts are concerned with the orchestrated, concerted action of a group of people, the team. That team is entrusted with the project and the obligation of the members of the team is to get the project done. The function of the project manager is to see to it that measures are taken and that results are achieved in such a way that the task is fulfilled. In the popular view among professionals in the area, the only thing that counts is the project and the fulfillment of the task. Efficiency in working with the project at hand is of utmost importance.

Defining a project as a project points to the need for action. An implication of this is that the project as a work form comes in handy when a need for action is recognized. "Something has to happen" is a phrase often used in connection with unique projects. A project is called for when there is a need to focus a particular task and when it comes to intra-organizational projects, the task is related to the host organization itself.

A project does have one built-in weakness as an organization, though. It does not have an infrastructure of its own handy. The reason for that is simple. A project is a time-limited venture that eventually will evaporate or be dissolved. Thus, the team members and other resources made available for the project manager are the means to fulfill the task at hand. Whatever aptitudes and knowledge not possessed by the team members and needed to fulfill the task have to be fetched from somewhere else. The knowledge needed has to be stored in a readily retrievable way. Conversely, there is no readily available infrastructure to take care of knowledge generated in action over the lifetime of the project. One classical, not to say eternal, problem in any projectized company concerns how to distill knowledge generated in a project and how to store those experiences so that they can be put into use in future projects. Otherwise a lot of useful experiences might be wasted.

A traditional organization—to be thought of as permanent for the purposes at hand in the present context—has advantages over projects when it comes to transforming learning to knowledge and storing the results of the transformation in a retrievable system. This means that traditional organizations and projects might be thought of as complements to each other. Project action generates learning and a set of experiences in a knowledge formation process and the knowledge can be stored in a permanent organization.

It should be observed that knowledge in this case is not necessarily abstract and free of context. Rather, knowledge should be thought of as embedded knowledge. Ekstedt et al. (1999, 128) have analyzed notions of different forms of knowledge embeddedness. One form is when knowledge is embedded in physical equipment. This is capital-embedded knowledge. Another form is when knowledge is embedded in the organization (organization-embedded knowledge). A third, related form is when knowledge is embedded in institutions and "rules" of importance for more than one organization (institution-embedded knowledge). Individual-embedded knowledge is the traditional case when knowledge is associated with the individual only.

The notion of embeddedness is important since many of the renewal projects carried out for industrial firms are aimed at renewing the embedded knowledge. For that case the storing of the knowledge generated in a permanent organization is more or less natural since it is so well connected to the aim of the work. All the twenty-five renewal cases alluded to by Ekstedt et al. (1999) are good examples of how knowledge created in projects is stored in the organization. The renewal program of ABB Sweden, the T50 (meaning that all lead-times in the production should be slashed by 50 percent) has definitely resulted in a renewed set of embedded knowledge for most of the subsidiaries participating in the renewal program.

Storing knowledge generated for a customer outside the organization is more difficult. To mention one example, the habit in architectural firms is to store solutions to architectural problems from finalized projects in such a way that they are retrievable. (Such storage and retrieval is easier now than in old days with the extensive use of computer-aided design, IT, and electronic storage.) These solutions might be used for future projects. Storing knowledge related to how the project process, per se, is run is probably the most difficult case. In most project-organized activities in businesses, projects are evaluated in terms of the project process in the sense that evaluation reports are written to document what was good and what was bad. This is a regular habit when it comes to product development projects in industry. In practice it seems difficult to transform those experiences for future use in a systematic way, though.

This concludes our discussion concerning the implications of combining action prone projects and decision-oriented organizations. Suffice it to say at this point that this is a major task for what has been called "neo-industrial management" (Ekstedt et al. 1999). There are some good examples for how that can be handled.