3.1.1. Process definitions

The literature is abundant with different process definitions depending on the purpose, research approach and even on the environment in question. They emphasize certain characters of the process and ignore others. This may be due to the imprecise nature of the processes as the definition may only unfold as the process is followed through (Warboys, Kawalek et al. 1999). Here some appropriate definitions for a process are given:

• The Oxford English Dictionary gives a formal definition for a process that is “A continuous and regular action or succession of actions, taking place or carried on in a definite manner and leading to the accomplishment of some result; a continuous operation or series of operations”[1]. Focus on continuity.

• Armistead et al. (1996) defines transformation process as the conversion of inputs (resources) into outputs (goods and services).

• Davenport (1993) defines the process to be a specific ordering of work activities across time and place, with a beginning, an end and clearly identified inputs and outputs: a structure for action. Focus is on a structural element.

• Pressman (1997) defines the process in a software development context to be a framework for the tasks that are required to build high-quality software. Focus on the engineering approach.

• Zahran (1998) defines the process with three aspects: the process definition, the process learning and the process results. Gives a holistic view.

• Van de Ven and Poole (1995) refer to process as the progression (i.e. the order and sequence) of events in an organizational entity’s existence over time. Focus is on development.

In Fig. 13 the inputs consist of the transformed resources that can be described by resources, which are converted in some way, e.g. a combination of materials, information and customers themselves and from transforming resources that are the resources, which act upon the transformed resources. The two key inputs here are the facilities (buildings and equipments) and operating, maintaining, planning and managing staff.

The transformation process combines the resources to produce the planned output. The conversion process may follow different routes characterized by improving, care taking, or transferring. According to Armistead et al. (1996) only a relatively small number of types of transformation process emerge, usually combinations of two or more of these basic types – improving, care taking and transferring.

Products and services can characterize the transformation process’ outputs, where the goods are tangible, storable and transportable. Services again are intangible and are not storable and transportable. They are typically consumed simultaneously during the production process. The outputs from the transformation process is usually a combination of these both products and services outputs.

Two additional process definitions are used in software related standards:

• Information technology – the software life cycle processes standard defines the process as a set of interrelated activities, which transform inputs into outputs (ISO/IEC-12207 1995). Focus on activity (black-box).

• IEEE Recommended practice for software acquisition standard defines the software acquisition process as a period of time that begins with the decision to acquire a software product and ends when the product is no longer available for use (IEEE/Std-1062 1998). Focus on product’s whole life cycle.

From the above spectrum of different definitions the conclusion can be drawn that to define, to describe, not to mention to analyse the processes is a laborious task with many perspectives to take into account. Zahran (1998) notes that the process is the glue that ties the skills, technology, organizations and management together in order to achieve set business goals and objectives. He also compares the organizations with and without a process-focus and finds the latter one acting as a fire-fighting brigade focusing its efforts constantly to deal with the problem areas, Table 4. As he notes further this is more visible and sometimes more ‘heroic’ than the processes unfolding smoothly without any great visibility and problems (ibid).

Still the process approach is not the final salvation for the software community as Davis (1995) criticizes the one-sided focus’ shift from product issues to process issues. She further notes that during the last few years various methods and solutions to tackle the problems belonging to software development have emerged, but the swings from one extreme to another do not solve the problem as long as product and process are treated as forming a dichotomy instead of a duality (ibid). This emphasizes that the world is not black and white.

Van de Ven (1992) introduces three different characterizations for processes:

• A logic that explains a causal relationship between independent (inputs) and dependent (outputs) variables in a variance theory. This needs a process story or logic to explain the interdependence between the input and output variables.

• A category of concepts or variables that refers to actions of individuals or organizations. These concepts are e.g. communication frequency, workflows, decision-making and techniques.

• A sequence of events that describes how things change over time, i.e. it has a historical perspective and focuses on the sequences of incidents, activities and stages that unfold over the duration of a focal subject’s existence.

As Pettigrew (1997) argues that only the last definition explicitly and clearly examines the process in action and thereby is able to describe how some entity develops and changes over time. He emphasizes the time and context where the events, actions and activities unfold.

3.1.2. Process characteristics

As can be noted in the previous paragraph the process definitions vary considerably thus the characteristics that describe the processes must vary accordingly. Subsequently is described and analysed some central process classifications that also are found interesting for the purposes of this thesis.

Curtis et al. (1992) have tackled the problem arising from the associated complexity of the processes. They have introduced four different process views:

• Functional – what process elements are performed and what are the relevant information flows,

• Behavioural – how and when process elements are performed,

• Organizational – where and who performs the process elements and

• Informational – what informational elements are produced or manipulated by the process.

These perspectives are later augmented with an interactional view of process activity to combine the behavioural and organizational views (Warboys, Kawalek et al. 1999). These activities include different components, some are human and some are technological components. What is also important is that the components interact with each other in a regular fashion, though the degree of regularity may vary.

Armistead and Rowland (1996) give other features for processes that are structural, operational and limiting output.

• Structure depicts the basic model where the resource inputs are transformed into outputs of the focal process. During the transformation process value is added to the inputs. The second process uses the first’s process’ outputs as its inputs and further the second process’ outputs are again inputs for the third process, thus the processes form a network of processes.

• Operational aspects describe the purpose of the process at any level and the tasks belonging to it. Also the ownership, commitment and control of the resources to achieve the task.

• The features that may limit the consistent output are those that entail variability or uncertainty in resource or capabilities usage.

Armistead (1996) describes the processes by hierarchies of elements that facilitate the analysis and description of the focal processes, as the influence, causality and system dynamics in the process network in whole is studied, see Fig. 14.

For example if the business process in Fig. 14 were the customer services process, it could be divided into four process elements, e.g. marketing, sales, order management and logistics. Further the sales process element could be defined by three activities, the management of customer accounts, customer sales support and claims processing. Finally the activities can be defined to the task level, which can be written up as procedures with individual process owners.

The driving assumption behind processual thinking is that the reality is not a steady state, but it is a dynamically evolving phenomenon. This study tries to “catch in flight” the development process in a longitudinal way following the actions and unfolding of events and outcomes from the start to the end of the focal software contracting process. For this, a proper and relevant taxonomy that can be used to describe the process is needed, including the becoming, emerging, developing, transforming and decaying phases. Pettigrew (1997) states that in a processual analysis the language used must be grounded in action as the actions drive the processes. Actions are still embedded in contexts, which limit their information, insight and influence. However, the dual quality of agents and contexts must be recognized. Contexts are shaping and shaped. Actors are producers and products. The aim of this study is to find out patterns and habits that are contained in the focal processes as well as to find the mechanisms that drive these processes. To make the results more reliable the different cases are compared and similarities as well as differences in their operation are searched as the links between the processes and their outcomes are of interest, too. Pettigrew states that the processual analysis should study and explain the what, why and how of the links between the context, processes and outcomes. He further expresses five internally consistent guiding assumptions to be taken in to account when conducting processual research (ibid, 340):

• Embeddedness, studying processes across a number of levels of analysis;

• Temporal interconnectedness, studying processes in past, present and future time;

• A role in explanation for context and action;

• A search for holistic rather than linear explanation of process; and

• A need to link process analysis to the location and explanation of outcomes.

Embeddedness in this research setting means that the level one processes are the processes with which the contracting process is closely operating and the level two processes are those company processes that the contracting process is not so closely working with or they are even outside the company. The empirical data available describes the behaviour of these focal companies during the contracting processes. From this data the elements in the past that shape the present and the present elements that in turn shape the future are the ones which have to be found. The task is to understand the sequence and flow of events over time and to build a model that would benefit companies in the future with the contracting processes. The question is how it is possible to find patterns with some simultaneity, regularity and cycles? To establish a holistic picture about the contracting process and its effects on the surrounding processes is done by comparing and combining the findings and explanations of the several cases. This process study gives knowledge about contracting processes and their outcomes as well as why and how the outcomes of the processes shape them differently in different companies?

According to Tinnilä (1994) the main characteristics of processes are:

• They have customers, i.e. processes have defined business outcomes and there are recipients of these outcomes. The customers may be internal or external of the company.

• They cross organizational boundaries, i.e. either functional or company barriers.

• Their efficiency should be assessed from the customers’ viewpoint.

• They have owners, i.e. a person responsible for the process exists.

The above list shows the four keywords characterizing the process. The process must have a customer, be it inside or outside the firm, but there must be someone for whom the resources are used and who values the outcome. Besides this, the process must be maintained and developed by its owner and definitely from the customer’s perspective. The process, as defined, acts efficiently over organizational borders, again inside or outside the firm.

3.1.3. Process theory classification

Van de Ven, Poole and others introduce four different types of process theories, i.e. four basic schools of thought that explain the change behaviour in the organization: life cycle, evolutionary, dialectical and teleological (Van de Ven & Poole 1995, Poole, Van de Ven et al. 2000). They suggest that these four basic types of theories are adequate alone or combined to explain all specific theories of organizational change and development, see Table 5. In making good use of these theories new perspectives can be found as defined and analysed the conceptual models of different process patterns.

These theories have distinct event sequences and generative mechanisms that they call as motors. These engines as Aldrich (1999) calls them explain how and why changes happen and why the process progresses. Further they define change, to be a one type of event of an empirical observation of difference in form, quality, or state over time in an organizational entity. The entity may be an individual’s job, a work group, an organizational strategy, a program, a product, or the overall organization.

Development is a change process (i.e., a progression of change events that unfold during the duration of an entity’s existence – from the initiation or onset of the entity to its end or termination). Process theory is an explanation of how and why an organizational entity changes and develops (Van de Ven & Poole 1995). The subsequent discussion related to software contracting processes is based on the pre-understanding and available literature and its purpose is to give the reader insight into the environment where the software business is completed.

Life cycle theory. Table 5 shows the key metaphor for the life cycle theory to be an organic growth that explains the progression of development processes found e.g. in a software producing company. The life cycle paradigm is common in the software development environment where even a life cycle model standards ISO/IEC-12207 exists for software development and the linear sequential model that is also called the “classic life cycle” or the “waterfall model” (1995) and (Pressman 1997), cf. also Section 2.2.2. In business and management literature the life cycle metaphor is familiar, too. For example the business process, product and development life cycles are commonly used concepts (Hammer & Champy 1993).

The life cycle theory assumes that the change is imminent, i.e. there is an underlying and pre-programmed unfolding of changes in a unitary, cumulative sequence. The outside events and processes may affect the development, but they are still filtered thorough immanent logic. There exists in advance path that depicts the trajectory until the end state; in our case it is the stable state.

The life cycle theory suits organizations that have an explicit plan or standard for the software contracting process all the different stages, actors, entities, inputs and outputs included in the process are described. In Fig. 15 and through Fig. 16 – Fig. 18 the arrows on the lines represent likely sequences among events, not causation between the events.

The contracting process can be seen to belong to this operational mode as the final state (the contract) is prefigured and it requires a specific historical sequence of events, i.e. the negotiation process. According to Van de Ven each of these events (negotiation meetings, delivery of new proposal) contributes a certain piece to the final product that in the case of this study is the (written) contract. The events must unfold in a certain order, as the outcome of the preceding event affects the next one. This is also the case in the software contract negotiations process that requires successful, possibly several, negotiation rounds to take place before the parties will achieve an agreement. A life cycle theory often materializes in organizations by institutional rules and directives, standards, quality guides and process guides that advise the progress of these activities in a prescribed sequence (Van de Ven 1992). The contract negotiations are comprised of formal customs and informal business traditions that shape and contribute to the outcome of the negotiations (Houtsonen 2000). This is, in addition, also a culture dependent matter.

The motor (the different event sequences and generative mechanisms) of a life cycle theory can be described by an entity progressing through a necessary sequence of phases. In general terms the processes have three components: starting conditions, i.e. input, development or change process, i.e. the “black-box” and functional end-point, i.e. output. The life cycle theory includes all three elements, but emphasizes the starting conditions and organizational rules and guidelines. According to Van de Ven (ibid) it still describes the following process stage and the final output stage.

Evolution theory. Van de Ven (ibid, see also Aldrich 1999) describes the evolution theory with a biological analogue where change proceeds in a continuous process as a recurrent, cumulative and probabilistic progression of variation, selection and retention. Variations of new forms are created and they emerge by random chance, Fig. 16. Selection occurs through natural competition in which the best forms suitable for a respective environment continue to evolve. Retention on the other hand stabilizes the change process with forces that oppose the changes happening and to become as a new feature (Van de Ven 1992). This theory is very similar to Darwinian theory with a continuous and gradual process of evolution. The feedback loop of the evolutionary process is depicted in Fig. 16.

In this study the evolutionary process theory is the interesting one as in normal organizational life there is seldom the case that the business processes have been described and determined exactly in advance (Morrow & Hazell 1992). On the contrary in the companies the processes even though they may have been defined in the beginning, in time they start to evolve and develop at their own pace. This is especially the case when there is no particular owner of the focal process who would look after the compliance with the defined process description. It is also plausible to claim that the younger the firm is the more immature the business processes are in their structure. The employees in the company may be not so willing to comply with the rules and guidelines.

Dialectic theory. If the contracting process between two companies is considered from a higher perspective it could justify the use of a dialectical process approach, Fig. 17. The contracting process could be seen unfurling with repetitive motions and counter motions until understanding has been reached or the negotiating parties would find out that they are not going to get into a mutual agreement with the focal development project or equivalent joint effort. This is like “a dialectical battle” between the companies trying to reach consensus about the agreement.

This “ping pong” type of negotiation can be found also inside a company (Nystén-Haarala 1998). If we consider e.g. a marketing or sales department in a software company to be interested in incorporating new features demanded by the customers in an application. The requests to make these enhancements goes to the software development department that must evaluate the suitability, resource needs and timetables in question before they can give an answer to the request. The answer can totally decline the amendments or there can be some requests for changes and so forth. These iteration rounds could last several turns before the parties reach a consensus.

The evolution and dialectical theories emphasize according to Van de Ven (ibid), how the change and development occurs. They are, in this sense, explanatory process theories. The dialectical theory is an interesting one in a contractual environment where two parties have opposing views, values and power, but still they have a common goal where they start to work together. This forms a dialectical fight, i.e. bargaining to creative synthesis and unison where the parties have a win-win situation. Dyadic networks can also indicate dialectical processes between partners: competition and cooperation processes (Alajoutsijärvi 1996).

Teleological theory. According to the teleological conception the development of an organizational entity proceeds towards a goal or an end state (Van de Ven & Poole 1995). Purposeful cooperation is the grounding idea behind the teleological theory where the goal formulation, implementation, evaluation and modification of goals based on what was learned repeat in a sequence, Fig. 18. Also the developing entity is purposeful and adaptive, by itself or in interaction with others (Van de Ven 1992). This theory allows the participants to be more innovative and free to choose their goal as well as their means to achieve it. This approach enables more explorative ideas for new established software companies that are searching for their future strategy. On the other hand, there is also a risk, as the companies do not control their processes in an envisioned manner.

According to Van de Ven and Poole (1995) this theory does not specify or presume any necessary sequence of events and it needs no assumption about historical necessity. Still it implies a standard for judging the change, i.e. the development is something that moves the entity toward its final state. Further the teleological theory emphasizes the purpose of the actor or unit as the motor for change, it also recognizes the limits on action. The environment and the resources at disposal constrain the actor’s possibilities. It operates under the assumption of equifinality, there are several equally effective ways to achieve a given goal, thus the trajectory is not determined in advance (Van de Ven 1992). The development can be analysed by purpose, goal, function and desired final state of the process.

In young and start up software producing companies the teleological theory approach could be found first but the aim is still towards the life cycle theory that helps the software contracting process to be understood and defined as a standard procedure in the relationship building. The unit of change in both of these theories is a single entity used to describe and explain the development process. In this case there is an organizational entity i.e. the group of people (employees) that take part in the contract negotiations during the process’s different stages. As the focal companies are relatively small there is usually only some actors participating in these negotiations. But still they can represent several organizational units, e.g. software development, accounting and marketing.

Mode of change. Van de Ven and Poole (1995) further define a mode of change that expresses, whether the sequence of change events is prescribed in advance or whether the progression is constructed and emerges as the change process unfolds.

The prescribed mode – change within existing theory – (life cycle and evolution) is the mode that the companies would be interested in as it gives better managing opportunities for the important contracting process. The variations in the processes that are produced under this mode are prescribed, predictable and the route of development is known and understood. But as the business environment in the software business is turbulent there should be some degrees of freedom to operate in a fast changing tight situations. The management’s problem is to footwork between these two ends of required freedom and control (Poole, Van de Ven et al. 2000).

The constructive mode – a break with the past theory – (dialectic and teleological) on the other hand gives new ideas, innovative and discontinuous contracting models to disclose when the events and the future path of development is not known in advance, i.e. it is unpredictable and even discontinuous. However, this mode of change gives better opportunities for new and original (re)formulation of the entity. This approach and workings are applicable in a turbulent software business environment as the companies are negotiating new contracts and projects.