ACTIVITY SYSTEMS

It is not a straightforward task to contextualise the activities in the case organisation into the activity theoretical model even if the aim was a description of the context.

The obvious starting point could be the products under development. Practically all interviewees were working in one business unit, developing network infrastructures and services. Moreover, the traditional “products” are clearly focused as the expansion of the service business was not topical amongst interviewees in 2003 nor was it in the business unit at large at the time of the interviews. Regarding the products under development, they are highly complex and developed in incremental steps. Previous (and sometimes future) confi gurations and generations need to be taken into account in the development of the current version. Further, for example network element products need to be built compatible with a network system. The network elements (products) are developed within projects. These projects may consist of several sub-projects concentrating on various sub-systems, e.g. software sub-systems. There are also dedicated sub-projects for related and needed add-ons like customer documentation (technical writing) or PCT (product competence transfer directed to customers and company internal personnel).

In all these cases the object of activity is relatively easy to identify, if one maintains that it is a product-related object of activity.¹ For a sub-project it can be a software sub-system. For a product program it is a product (network element). (Some products may consist of only software like the network management system and some can consist of both software and hardware like the base stations.) For a system product program the object of activity is a system product. A platform project deals with a computing platform as an object of activity. Usually one platform is used by several products. The overall interrelatedness and intertwining within one system and towards other related systems is striking. Within product programs there are several process phases (system design, design, implementation, testing, integration & verifi cation) and domains like software and hardware. Following the extended enterprise model, some parts of the system are developed within the case company and some parts in the partner compa-nies. In the incremental way of developing, these process phases are accomplished in

1. The object of activity in some other organisational units not directly dealing with the customer products might, for example be a process. The product creation process is directly related to developing products. An enabler process would describe how a product development “enabler” project is conducted (e.g. how a new methodology like object oriented SW development methodology is taken into use or how a new learning portal is developed). IT and other tools development have their own activity systems.

parallel with incremental release cycle. In incremental development changing customer needs are more easily taken into account.

Developing these interrelated platforms, system products and products with their numerous sub-projects requires ongoing sense-making and negotiation among all con-cerned. People need to orient themselves to new work situations over and over again, they need to have an ability to make mental images of the whole product or process at hand and they need to be able to anticipate the future in relation to the steps they are taking at a certain point in time. (cf. Hinds & Kiesler, 2002, Meil & Heidling, 2003) People encounter boundaries like geography, time zone, technology and culture in their work and they use boundary practices like sharing identity, aligning effort and interacting face-to-face in order to traverse the boundaries (cf. Orlikowski, 2002). Even if an individual is allocated to work within one project developing one product or part of it, his/her work is about continuous traversing of boundaries towards other related projects, products and organisations. He/she may need to deal with other domains, process phases, and possibly with partners and/or customers. The case organisation is a true “multi-organizational terrain occupied by multiple activity systems” (Engeström, 2005b) and a prime example of co-confi guration work (Victor & Boynton, 1998) or fl exible knotworking (Engeström et al., 1999).

Engeström (2005b) refers to multi-organizational terrains that are occupied by multiple activity systems which “commonly do not collaborate very well although there are pressing societal needs for such collaboration”. In the context of for-profi t companies, even if the fi nal outcomes are products, the object of activity needs to be continuously negotiated. Because the individual participants engaging in the knot-work represent different backgrounds, they also envisage the object of the activity in different ways; it is through the negotiation and sense-making processes that the object of the activity also develops further and in concrete terms is made ready to be sold to customers one day (and to be re-worked for the next confi guration in parallel and to be gradually abandoned one day after a lengthy period of maintenance when a new generation or technology steps into the picture.)

In terms of the object of activity, the negotiation may take place on any level of an organisation or have any scope; a team might negotiate what the inputs and outputs of the team are or on a larger scale, as when services as a new type of business model/

product stepped into the picture. Also, it is debatable whether the ultimate object of activity is to maximize shareholder value or to come up with competitive products.² The object of the activity is not a straightforward, clear-cut issue in a complex distrib-uted company dealing with high-technology and complex system products. The object of activity is contested, developing and transforming as also are the activity systems.

Figure 19 presents a simplifi cation of how the activity in the case business could be split up to activity systems if the products are taken as a starting point.

2. In the mobile device business it is debatable whether the company should be a customer driven, technology driven or market driven and whether it should be a product company or a technology company.

Figure 19. Basic rudimentary mapping of product programs and a system product program to the activity theoretical model in the case organisation

In this simplifi ed example a system product program contains several product programs, a system customer documentation project (technical writing) and a product training project. The system product program coordinates the complex product development work done in product programs that includes all process phases. Those working in system product programs have the system product as their main object of activity (object 5). The product programs within the system program have their own objects of activity that need to be fi tted into the system product program’s object of activity.

Within the product programs there are several sub-projects. Thus, individual employees being responsible for one piece of a much larger product need to have the ability to envisage the bigger picture and the integration of their piece in the total product. Also, anticipation capacity is very much needed as these projects and programs proceed in unlinear pace and often the dynamically living end-result is years ahead (cf. Meil &

Heidling, 2003).

A system product program envisaged in Figure 19 does not even contain all the obvious activity systems that need to be taken into account. Other related activity

System

Product Program

Object 3 Subject

Product Program 1

Subject Object 4

Product Program 2

Subject

Object 1

System Customer Documentation Project

Subject Object 2

Product Training Project

PCT (Product Competence Transfer) Object 5

Sy ste m Pro du ct

Sense, meaning

Outcome

systems would be related research projects, technology development or tools projects, process development projects, other system product programs, previous generation and next generation projects and programs, standardization (e.g. 3GPP), handset development, competence development and human resources (especially in terms of R & D incentive/bonus systems). Further, the system program as well as the product programs (and possibly the sub-projects) need to collaborate and align with the (com-puting) platform activity system that needs to collaborate with other system programs and product programs at the same time. The system product program (for example a radio access system) needs to collaborate and align with other system programs (like a compliant core network system) and possibly with an overall system (for example 3G) program. Moreover there are domains like HW or SW that need to align within their own domain and towards other domains. Partner fi rms and their representa-tives are interfaces that bring new activity systems into the picture. Further, there are customers and customer account teams, marketing and product marketing that need to be involved in the program work.

In this multi-terrain of activity systems I have described customer documenta-tion and product training (product competence transfer) as their own activity systems embedded in the system product activity system. This is because I perceive that they clearly have their own objects of activity which is at the same time separate from and included in the common system product object of activity.

One could actually ask what an activity system is in the type of work context that the case organisation exemplifi es. What would be a natural or ideal activity sys-tem or a group of related activity syssys-tems in the multi-terrain of activity syssys-tems to be studied? My view is that an activity-theoretical approach complemented with a work developmental and expansive learning approaches are extremely valuable tools (see e.g. Virkkunen et al., 1997). However, in reality it is actually quite diffi cult to identify activity systems and especially what related activity systems should be brought into the picture to have a close to complete view of the important interfaces of one activity system. In practical terms it is quite easy to create a “natural work unit or team”. However, as stated by Tuomi, activity systems are still institutionalized units of study; in their complete form they already contain a defi ned (even if it was likely to transform) division of labour (Tuomi, 1999, pp. 271-273).