2.3 Project Control
2.3.2 Control mechanisms
2.3.2.1 Output control
Output control, first proposed by Ouchi (1975; 1979), then taken up by Eisenhardt (1985; 1989a) has become sufficiently established that the concept is used unchanged by subsequent authors, although Kirsch (1996) refers to it as “outcome control”. The term “output control” will be used in this thesis.
Output control is exercised by measuring and rewarding results without concern for how those results were obtained. Originally, Ouchi analysed the different mechanisms with which organisations performed various functions. The market mechanism of determining prices for goods was one of the mechanisms (Ouchi, 1979) but it was only later (Ouchi and Maguire, 1975) that the term “output control”, rather than “market control”, was used to describe the control mechanism used within an organisation. Performance is linked to concrete results such as paying a commission on sales (Hamilton and Kashlak, 1999). This is in contrast to paying wages for a sales role with no commission for sales. Contractual progress payments linked to agreed milestones would be an example of output control, as would be piecework payments which are based on the number of items produced.
Some software development projects involve buying components on the open market. There are the obvious components such as compilers, debuggers and other tools used during development but not part of the final product and there are also components such as protocol stacks, VBX controls or C++ components that would be incorporated into the final product. Such component purchases use the market mechanism described by Ouchi in the same way as any other
acquisition. Software development projects may let a contract to develop a specific part of the system or perform a specific function within the project. Bids may be sought from several potential suppliers with the contract specifying progress payments on achieving certain
Page 27
milestones, a type of output control. While payments are tied to milestones, the project manager may or may not require visibility into how those milestones are achieved.2.3.2.2 Behaviour control
Control that is achieved through prescribing behaviour to be followed is referred to as behaviour control (Ouchi and Maguire, 1975). This type of control is exercised by bureaucracies through rules “concerning processes to be completed or rules which [sic] specify standards of output” (Ouchi, 1979). Ouchi distinguishes rules from prices, used in output control, by arguing that the rules are “incomplete bundles of information”. Hamilton and Kashlak (1999) characterize behaviour control as “the degree to which an employee is held accountable regardless of the results; the degree to which there is concern for procedures or methods; the degree to which performance programs are imposed from the top down; the frequency with which employees receive feedback or performance evaluation.”
Eisenhardt (1985) refers to knowledge of the transformation process or task programmability while Kirsch (1996) retains the term “knowledge of the transformation process.” Both authors are referring to the degree to which behaviours or procedures can be described that will reliably achieve the desired outcomes. The familiar form of this in the workplace are office procedures, explicit work practices or other documented instructions pertaining to how work will be carried out. Often products are delivered with an operations manual that describes how to operate the device and sometimes how to perform routine maintenance and routine problem diagnostics. Such operations manuals conform to the description of behaviour controls by the supplier to an organization to control how the device will be operated by its users.
Software development methodologies describe how the various development activities are to be performed. They vary from the very high level, general methodologies described in international standards such as ISO 12207 (2002) or ISO 15288 (2003) through to the very detailed
commercial methodologies such as Rational Unified Process (RUP, 2003).
While empirical data on the spread of knowledge and agreement on software development processes is scarce, an indication can be gained from the international acceptance of the Capability Maturity Model (SEI, 2004b) and its successor the Capability Maturity Model Integration (SEI, 2004a). Both of these define a collection of software development processes and prescribe the outcomes that must be achieved during those processes. While this would tend to categorise the CMMI as an output control, its adoption and use requires that a software development methodology be defined and adopted, thus implementing behaviour controls. The CMM and CMMI originated in the USA but have been adopted throughout the world, in particular in India (Carmel and Agarwal, 2002), indicating that not only are the transformation
Page 28
processes of software development widely understood and agreed, but that measures of software process capability are also widely understood and agreed.2.3.2.3 Clan control
Clan control is exercised through adherence to shared values. Ouchi (1979) distinguished between bureaucratic (behaviour) control and clan control by pointing out that some tasks are inherently ambiguous, such as in a hospital, and precise description of how a task is to be performed is impossible. Instead, almost all workplaces have a period of indoctrination while people learn how work is carried out and the values that guide the work. Ouchi acknowledges that similar values shared by people spread over many organizations are referred to as a
profession. When referring to shared values of a political organization, it is a culture. When the shared values describe the unique properties of an organization, Ouchi defines it as a clan (Ouchi, 1979).
Essential to clan control is the period, sometimes lengthy, of indoctrination to acquire the values expected of the profession, political party or organization. Ouchi argues that once someone understands the values and is trying to achieve the “right” objectives, their manager can eliminate many costly forms of auditing and surveillance. In the case of professions such as doctors, lawyers, engineers or academics, it may be that absorbing the “right” values is a condition of admission to the professional association. While many countries have professional bodies to which software developers may belong, thus forming a recognised clan, membership is rarely compulsory. A professional software development or IT related culture has been proposed (Carayannis and Sagi, 2001) but with limited evidence of its strength compared to national cultures. Duliba (1991) investigated whether there was such a thing as an occupational community but concluded that there was not. Thus, evidence that software developers the world over or those engaged on the same project form a clan, in Ouchi’s use of the term, is limited. 2.3.2.4 Input control
Agency Theory (Eisenhardt, 1989a) examines the problem of risk sharing when cooperating parties have differing goals and division of labour. The agency relationship is where one party (the principal) delegates work to another party (the agent) who performs that work. Using the perspective of Agency Theory to examine control system selection in multinational corporations, Hamilton and Kashlak (1999) proposed “input control” in contrast to “clan control”.
Where clan control is exercised by the clan and within the clan, input control is exercise by a principal over an agent. Hamilton and Kashlak characterise input control as being exercised through recruitment and training. The multinational company “establishes the best staffing procedures available; becomes involved in the skill development of an employee; performs
Page 29
multiple evaluations before hiring an individual; provides opportunities for broadening a skill set of an employee; takes pride in hiring the best employees possible and the overallcommitment of the firm to training and development.” (Hamilton and Kashlak, 1999)