text:
Pagani have launched a limited edition Huayra Roadtser with the BC name. The BC Coupe was released at the 2016 Geneva Autoshow. It was only a matter of time before the BC name graced the Huayra Roadster. After Pagani teased us with the car under covers on social media, the car was released yesterday on mobile drag racing game, CSR 2. Here's what you need to know.
How do Pagani do it? The Huayra is 8 years old at this point if you go back to it being released at the Geneva Autoshow of 2018. Despite its age, it is a design that just keeps on giving. The original Huayra was different to every hypercar that had come before it. The looks are completely ridiculous in my view. They're outrageous which is exactly how a hypercar should be. It shouldn't be conservative in any way. The Huayra still looks like a spaceship in its standard form. The BC takes things to another level. It brings a track focused vibe to the alien looks that really suits the car in my view.
The Huayra isn't just about looks. Almost everything has its purpose. Flaps on the front and the back of the car that will rise and fall to create downforce for example. This is a feature found on the standard Huayra, however even 8 years later, I haven't got past how cool it is. Along with the flaps, the BC also has a large rear wing that isn't found on the standard car. Once again, in the name of creating downforce. Of course however, aerodynamics wasn't the only thing on the minds of Pagani when creating the BC Roadster. Like in a sophisticated watch, every single component of the Roadster BC is a concentration of Pagani Automobili's ultimate design, technology and engineering expertise encapsulated in just 1,250 kg (2,756 lbs), the car is so light due to the carbon-triax material that was first used in the hardtop BC. The weight is really impressive, especially as you can take the roof off.
The engine is the twin turbo 6.0 litre Mercedes AMG from the Huayra BC, the first result of the Roadster BC scientific research is its beating heart: the new Pagani V12. This jewel boasts more than 800 hp and a torque of 1,050 NM already at 2,000 rpm, with one of the best weight-power ratios in the category. The coupe didn't exactly lack power in the first place, but an increase in power will make up for a slight weight increase. The power is sent through an Xtrac 7-speed sequential gearbox, with a single clutch. A single clutch is much lighter than a double clutch, however the gearshifts aren't quite as fast.
The interior is as special as you'd expect from a brand like Pagani. There is a gorgeous mix of leather and carbon fibre that is beautifully designed. When you have a fantastic exterior, you have to have an interior to match. The Huayra really does have that interior too. No expense is spared here and why should there be? This is the place where you drive the car and it has to be special in my view.
All of this doesn't come cheaply however. The car is even rarer than we predicted in our previous article on the car. Only 40 BC Roadsters will ever be built, and with a £2.7 million price tag, it isn't exactly attainable. Certainly an incredible car that hopefully the lucky owners will enjoy massively.


text:
Aligning flexibility with uncertainty in software development arrangements through a contractual typology
Journal of Global Operations and Strategic Sourcing
Publication date: 19 February 2018
The purpose of this study is to identify a typology of procurement contracts in the context of software development projects that allows firms to align design flexibility with design uncertainty at the project level. The theoretical lenses of contract theory and software engineering are used to explain why the five archetypes in the proposed typology provide gradually increasing levels of design flexibility and to develop hypotheses about the associations between design flexibility and a set of project cost dimensions.
The hypotheses are tested with objective contractual data from 270 software development contracts entered into by a leading international bank over a period of three years.
Data analysis confirms the existence of the proposed typology and shows that design flexibility is negatively associated with control and positively associated with coordination, trust, duration and price.
Research limitations/implications
Although the findings are based on the contracting practices of a single, albeit sophisticated, organization, they shed light on the ability of firms to align flexibility with uncertainty at the onset of new projects by taking advantage of nuanced contractual mechanisms to produce a broader set of contractual archetypes.
This paper is the first in the outsourcing literature to analyze a nuanced contractual typology in software development projects through the perspectives of both contract theory and software engineering.
Fink, L., Wyss, S. and Lichtenstein, Y. (2018), "Aligning flexibility with uncertainty in software development arrangements through a contractual typology", Journal of Global Operations and Strategic Sourcing, Vol. 11 No. 1, pp. 2-26. https://doi.org/10.1108/JGOSS-11-2016-0033Download as .RIS
Emerald Publishing Limited
Copyright © 2018, Emerald Publishing Limited
Although information technology (IT) outsourcing is a mature practice, it remains a managerial challenge, with the fundamental issues of developing an outsourcing capability, defining the scope of outsourcing and selecting an outsourcing partner as the most pressing issues (Gewald and Schäfer, 2017). Of the variety of IT activities, software development remains one of the most complex, uncertain tasks to outsource and its outsourcing continues to grow at an annual rate of over 10 per cent, according to authoritative estimates (Deloitte, 2016). A major challenge in outsourced software development projects is bridging the gap between the frequent need to modify the design of the system under development and the binding nature of the contract governing the relationship between the parties (Goo et al., 2009; Sia et al., 2008). Custom-made software is often developed through a time-consuming process, during which environmental changes may occur and render previous development efforts ineffective (Austin and Devin, 2009). However, adaptations in ongoing external development efforts are not easily attained. The contractual nature of external development processes constrains their ability to accommodate change relative to development processes that are confined within organizational boundaries. When the external competitive environment, the internal organizational environment or the technological environment changes in a manner that necessitates software design modifications, adaptability is constrained by the contractual rigidity of software development arrangements (SDAs).
This challenge is not unique to outsourced software development projects. Discrete resource acquisition through procurement projects is a common interorganizational situation. Firms rely on procurement projects to acquire various resources, such as building constructions (Bajari and Tadelis, 2001), offshore drilling (Corts and Singh, 2004) and marketing campaigns. All these examples represent discrete project relationships. Although such relationships may be repeated between the same two partners, the distinctive feature of such relationships is that a separate contract is negotiated and signed for each new project. This contractual nature of procurement projects may limit their adaptability to environmental changes.
The motivation behind this study was thus to identify contractual mechanisms that can sustain the adaptability of SDAs. The study, therefore, had two objectives. The first objective was to address the gap between the various needs for business adaptability and the limitations of formal contracts in the practice of software engineering. Although the literature focuses on two types of contracts, fixed-price (FP) and time-and-materials (T&M) (Gopal et al., 2003), practitioners are aware of the limitations of the dichotomy (Gaebert, 2015) and find nuanced approaches to narrow this gap (i.e. to align flexibility with uncertainty). The second objective was to analyze the theoretical mechanisms underlying these nuanced approaches, as identified by contract theory (Bolton and Dewatripont, 2005; Hart and Holmstrom, 1985).
The rationale underlying our approach may be described as follows. Different procurement projects are associated with different levels of uncertainty about design adaptations (Bajari and Tadelis, 2001). Sustaining the adaptability of procurement projects requires the alignment of design flexibility with design uncertainty at the project level. This proposition is in line with the study of Anderson and Dekker (2005), who showed that misalignment between uncertainty and contract design is associated with performance problems. It is also in line with the findings of Gulati et al. (2005, p. 415), who showed "that performance differences across modes of procurement arise as a function of the match between adaptive capacity and adaptation requirements". Because uncertainty represents a continuum (Harrington et al., 2004), i.e. it is not necessarily either high or low, such alignment is unlikely when firms use a very narrow set of procurement arrangements. Hence, firms seek to institute a variety of procurement arrangements that range from extremely inflexible to extremely flexible. Firms moving along the design flexibility continuum face two opposing incentives. On the one hand, they are motivated to move up the continuum to increase flexibility. On the other hand, design flexibility is associated with project costs and process inefficiencies (Gopal and Koka, 2010), which motivate firms to restrict it. Therefore, sustaining the adaptability of procurement projects is contingent upon the institution of a design flexibility continuum and the capacity to align design flexibility with design uncertainty at the onset of each new project. If such adaptability is absent, the probable consequence is either projects with suboptimal flexibility (when uncertainty exceeds flexibility) or projects with suboptimal costs (when flexibility exceeds uncertainty).
In the context of SDAs, we define design flexibility as the degree to which an SDA provides structural mechanisms to accommodate changes in the specifications of the software product. To validate the approach presented above, we examine two of its key assumptions in the context of SDAs. The first assumption is that firms use an institutionalized variety of procurement arrangements with increasing levels of design flexibility. The second assumption is that design flexibility is associated with project costs. These two assumptions, which research has not addressed to date, are empirically tested in this study to offer an explanation of how adaptability is sustained in SDAs.
To examine the two assumptions, we draw on the theoretical frameworks of contract theory and software engineering. Consequently, this study contributes to two streams of literature. The contribution of this study to the contract theory literature stems from addressing an important gap between theoretical predictions and empirical evidence about menus of contracts. Studies have shown that in situations of asymmetric information (one party has information that is not available to the other party), characterized by a screening problem, the uninformed party screens the informed party by offering a menu of contracts from which the informed party selects a specific contract, thus revealing its private information (Bajari and Tadelis, 2001; Bolton and Dewatripont, 2005). However, empirical studies have not been able to confirm this normative prediction and have shown that elaborate menus of contracts are not used in practice (Bajari and Tadelis, 2001; Laffont and Tirole, 1993). The present study offers a unique interpretation of the concept of "menu of contracts". It aims at demonstrating that menus of contracts do indeed exist in practice to align the incentives of buyers and sellers, even though those incentives may be associated with motivations other than ex ante screening. The contribution of this study to the software engineering literature is the novel demonstration of the need for and the costs of facilitating the flexibility of software development. Research has generally addressed the need for design flexibility in software projects by focusing on the development methodologies. In this regard, a notable trend in the past decade has been the embracing of agile methodologies (Boehm, 2002; Dingsøyr et al., 2012; Martin, 2003) because "the traditional, plan-driven software development methodologies lack the flexibility to dynamically adjust the development process" (Nerur et al., 2005, p. 73). However, in the quest for agility, software engineering research has largely overlooked other project governance issues, in particular those related to the interorganizational mechanisms underlying the development process. Against this backdrop, this study is the first to demonstrate the importance of client–vendor arrangements in determining software design flexibility as well as the consequences of such flexibility for project performance.
The outline of this paper is as follows. The next section develops a contractual typology of SDAs, demonstrates why this typology represents a continuum of design flexibility and analyzes the consequences of each contractual archetype for different project cost dimensions. The third section builds on this theoretical framework to formulate a set of hypotheses about the associations between design flexibility and cost dimensions. The fourth section describes the research methodology used in this study to collect objective contractual data from 270 software development contracts made by a leading international bank over a period of three years. The fifth section describes the data analysis techniques used in this study to test the hypotheses and the results obtained. Finally, the last section discusses the findings and their implications.
Theoretical framework: a contractual typology
We define an SDA as a contractual arrangement that involves the development of full or partial custom-made software by external vendors. In SDAs, software development activities are managed by the vendor and performed outside the client's premises. This definition differentiates SDAs from other forms of software-related outsourcing; contracting for consulting services or "body leasing" is typical of projects managed by the client, and contracting for licensing of off-the-shelf software usually does not involve significant software development (although it may involve software customization by the client). Procurement arrangements in general have been classified into two archetypes – FP and cost-plus (Bajari and Tadelis, 2001). SDAs have similarly been classified as either FP or T&M (Banerjee and Duflo, 2000; Gopal et al., 2003; Lichtenstein, 2004; Schermann et al., 2016; Whang, 1992). With FP contracts, the price for completing the project is predetermined. Conversely, T&M contracts do not specify a price but rather reimburse the vendor for its costs plus a predetermined profit. While contract theory suggests that contract diversification is the consequence of adverse selection problems, Bajari and Tadelis (2001) argue that different types of contracts are needed because of the importance of ex post adaptation, i.e. design changes that are required after the contract has been signed. They note that "the procurement problem is primarily one of ex post adaptations rather than ex ante screening" (Bajari and Tadelis, 2001, p. 388). Projects with high levels of design completeness (i.e. adaptations are not likely to be needed) are procured using FP contracts, whereas projects with low levels of design completeness are procured using T&M contracts. Therefore, ex ante design completeness is related to ex post design flexibility (Tadelis, 2002). Design flexibility has been recognized in the management literature as a central concept in new product development under uncertainty (Krishnan and Bhattacharya, 2002).
Formal models show that "the optimal contract is always either a fixed-price or a time and materials contract" (Banerjee and Duflo, 2000, p. 996). However, these two contractual archetypes offer a very limited choice between the extremely low design flexibility of FP contracts and the extremely high design flexibility of T&M contracts. We argue that such a narrow set of procurement arrangements cannot provide the continuum of design flexibility necessary to align design flexibility with design uncertainty at the project level. On the one hand, firms that opt for FP contracts are locked into inflexible arrangements that increase the likelihood of suboptimal flexibility, whereas on the other hand, firms that opt for T&M contracts benefit from flexible arrangements that increase the likelihood of suboptimal costs. We thus posit that adaptability in contracting for software development requires a broader variety of SDAs with gradually increasing levels of design flexibility.
Our conceptual analysis develops a novel typology of five contractual archetypes (Fink et al., 2013). We begin with the traditional distinction between FP and T&M contracts and rely on two assumptions to combine and separate these two prevailing archetypes into five new archetypes. The first assumption is that a continuum of design flexibility requires that FP and T&M contracts should not remain mutually exclusive. This assumption leads to the definition of an archetype that is based on a relatively balanced combination of FP and T&M arrangements – the mixed archetype. This archetype allows both low and high levels of design flexibility to coexist within a single contract and thus affords an intermediate level of design flexibility. The second assumption is that a continuum of design flexibility requires more variance at its low and high ends, which can be achieved by defining archetypal variations of FP and T&M contracts. We define two archetypal variations of FP contracts and two archetypal variations of T&M contracts by drawing on contracting techniques described in the literature. We focus on a single technique for each class of archetypes (FP or T&M) so as to maintain the relative simplicity of the typology. The criterion for identifying the most relevant technique for each class of archetypes is the ability of the technique to moderate the extreme level of design flexibility characterizing the class. The most relevant technique for FP contracts is the change provision, which is a specific contractual clause with explicit change management principles and guidelines. The change provision is most relevant for FP contracts because it addresses the need to introduce design changes, which is the major risk associated with the low design flexibility of these contracts. Consequently, we define two archetypal variations of FP contracts, FP contracts without a change provision and FP contracts with a change provision, where the latter is characterized by higher design flexibility than the former. The most relevant technique for T&M contracts is the price cap, which is a predetermined maximum price specified in the contract (Kalnins and Mayer, 2004). The price cap is most relevant for T&M contracts because it addresses price escalation, which is the major risk associated with the high design flexibility of these contracts. Consequently, we define two archetypal variations of T&M contracts, T&M contracts without a price cap and T&M contracts with a price cap, where the latter is characterized by lower design flexibility than the former. This conceptual analysis produces the following contractual typology, which represents a continuum of design flexibility[1]:
Archetype 1: FP contracts without a change provision (FP-w/o-change);
Archetype 2: FP contracts with a change provision (FP-w/-change);
Archetype 3: Mixed FP and T&M contracts (Mixed);
Archetype 4: T&M contracts with a price cap (T&M-w/-cap); and
Archetype 5: T&M contracts without a price cap (T&M-w/o-cap).
We use two theoretical perspectives, software engineering and contract theory, to identify the implications of using each contractual archetype in SDAs. Software engineering represents the actual craft through which the resource is acquired, and therefore, this perspective is essential for identifying the implications of each archetype for project performance measures of time, cost and quality. Contract theory, as a theory of incentives, information and economic institutions (Bolton and Dewatripont, 2005), highlights the economic implications of the different relational arrangements. In concert, the two perspectives provide a conceptual platform to identify the task and relational implications of each archetype. Next, we describe the emerging typology of five contractual archetypes, demonstrate why they represent a continuum of design flexibility and discuss their cost implications in the context of SDAs. We then build on these implications to develop a set of research hypotheses.
Archetype 1: fixed-price contracts without a change provision
The FP-w/o-change archetype is an arrangement in which the price for project completion is predetermined. This characteristic creates inflexibility and increases the threat of holdup or costly renegotiation should there be a change in the desired specifications (Corts and Singh, 2004; Kalnins and Mayer, 2004). Furthermore, this archetype includes no provision for change, i.e. there is no structural mechanism in the contract to accommodate changes in the specifications of the software product. Because the option of renegotiation is not formally defined, we view this archetype as offering the lowest level of design flexibility.
In software development projects characterized by high design completeness, structured software engineering methodologies (e.g. waterfall model of the software development life cycle) are most effective. Structured methodologies emphasize "fully elaborated documents as completion criteria for early requirements and design phases" (Boehm, 1988, p. 63). The complete and detailed specifications reduce the need for communication and coordination with external stakeholders and increase the usefulness of control as a mechanism for revealing quality problems in the early stages of development. The detailed specifications enable more accurate cost estimation and minimize the premium for uncertainty. For this reason and because of the intensive use of control, a high level of trust is not warranted (Mayer et al., 1995). Accordingly, vendor familiarity becomes less critical, bidding is highly competitive and the likelihood of selecting foreign vendors increases (Iacovou and Nakatsu, 2008). Because of the firmness of the price for project completion (fixed without a renegotiation option), the vendor has the incentive to reduce costs and shorten the project duration (Gopal et al., 2003).
Archetype 2: fixed-price contracts with a change provision
The FP-w/-change archetype represents an FP contract that includes a specific clause with explicit change management principles and guidelines. Such a clause may describe procedures for change requests, for analyzing their impacts and for renegotiation discussions. Research has highlighted the importance of the inclusion or omission of such a clause in a contract (Chen and Bharadwaj, 2009; Saunders et al., 1997; Sia et al., 2008). Contingency planning constitutes one of the main categories of terms in which contractual safeguards are embedded (Argyres et al., 2007). In principle, in most contractual arrangements the client is free to raise change requests, which the vendor may reject or choose to accept contingent on ensuing changes to the project scope, time or price. However, we distinguish between FP-w/o-change and FP-w/-change arrangements because the latter provides a structural mechanism for adaptation. This distinction rests on the assumption that, ceteris paribus, a change request is more likely to be accepted when a change provision clause has been included in the contract. This assumption implies that FP-w/-change arrangements are designed better than FP-w/o-change arrangements to deal with adaptation and, therefore, offer a higher level of design flexibility.
The FP-w/-change archetype, like the FP-w/o-change archetype, requires a high level of design completeness and frequently uses structured software engineering methodologies. However, the inclusion of a change provision mechanism in the contract loosens the implications attributed above to the FP-w/o-change archetype. First, greater familiarity and trust are needed because of the higher expectation and likelihood of renegotiations. Second, the price for project completion should be higher to reflect the premium for the renegotiation option. Changes increase cost volatility, thus affecting the premium for cost risk (Eremenko, 2007). Third, control may be less intensive and project duration may be longer to facilitate the adaptability enabled by the change provision.
Archetype 3: mixed fixed-price and time-and-materials contracts
In the mixed archetype, the product is delivered through a relatively balanced combination of FP and T&M arrangements. This archetype combines the strengths of both arrangements – work packages with high levels of design completeness can be procured using FP mechanisms, and work packages with low levels of design completeness can be procured using T&M mechanisms. Hence, the client is able to align, to a limited extent, design flexibility with design uncertainty at the work package level rather than at the project level. Because of this higher sensitivity of mixed arrangements to uncertainty, and because they include T&M mechanisms, we consider them as superior to FP-w/o-change and FP-w/-change arrangements in terms of design flexibility.
Mixed arrangements require the integration of work packages with high design completeness and work packages with low design completeness within a single project. Lacity and Willcocks (1998) define "mixed" outsourcing contracts as combinations of "detailed" contracts, in which requirements are fully specified, and "loose" contracts, in which requirements are loosely defined. Because uncertainty is high in the early stages of software development and decreases in later stages (Boehm et al., 2000), FP arrangements should replace T&M arrangements as the project progresses. Accordingly, Banerjee and Duflo (2000) define "mixed" software development contracts as contracts in which specifications tend to be written on a T&M basis, and the rest of the work (development and testing) tends to be done on an FP basis. In such projects, semi-structured software engineering methodologies, such as rapid application development, may prove most effective because these methodologies advocate the combination of structured techniques and prototyping techniques (Martin, 1991). In mixed contracts, control still plays an important role as a consequence of the FP arrangements, and coordination and trust play an important role as a consequence of the T&M arrangements. The combination of FP and T&M arrangements also leads to risk being shared between vendor and client. Mixed arrangements represent an aggregation of several project phases or sub-systems, and thus their price is expected to be relatively high.
Archetype 4: time-and-materials contracts with a price cap
This archetype is a T&M contract that includes a price cap. As with any T&M arrangement, the vendor is not limited in the use of resources but only up to a predetermined maximum price. The price cap indicates that the client has performed some evaluation of the main features of the software and has evaluated, to some degree, the overall price of these features. In this sense, T&M-w/-cap arrangements resemble FP arrangements. The difference between the two lies in the fact that in FP arrangements these evaluations are binding, whereas in T&M-w/-cap arrangements they represent a general threshold.
Placing a price cap on a T&M contract represents another approach to combining the features of T&M and FP arrangements and to balancing incentives for quality and cost efficiency (Kalnins and Mayer, 2004). Using reasoning similar to ours, Kalnins and Mayer (2004) argue that the parties may choose to use a T&M-w/-cap contract when uncertainty is at an intermediate level. We agree but argue that T&M-w/-cap arrangements afford a higher level of design flexibility than mixed and FP arrangements because they by and large rely on T&M mechanisms. However, T&M-w/-cap arrangements afford a lower level of design flexibility than T&M-w/o-cap arrangements because they embed an FP element that increases the vendor's motivation to control costs, vulnerability to costly renegotiation and hence reluctance to accept proposed changes.
The T&M-w/-cap archetype should be used in projects with low design completeness. In such projects, unstructured software engineering methodologies, such as agile software development, should be more effective (Austin and Devin, 2009). Agile development is an overarching concept used to describe a group of methods designed to reduce the cost of change throughout a project (Highsmith and Cockburn, 2001). These methods are characterized by short iterative cycles of development driven by product features, incorporation of rapid feedback and change and continuous integration of code changes into the system under development (Cockburn, 2002; Nerur et al., 2005). Because design completeness is low, there is a need for more intensive coordination, higher familiarity and trust and longer duration to allow for experimentation and feedback and to accommodate probable specification changes. The existence of a price cap reduces the risk of project escalation. The intensity of control is low to facilitate change, although the price cap warrants some control. Risk is allocated mainly to the client, but the vendor bears some risk because of the price cap.
Archetype 5: time-and-materials contracts without a price cap
This archetype is a typical T&M contract, in which the price for project completion is not constrained. The client reimburses the vendor for its costs plus a predetermined profit. The primary benefit of this archetype, relative to an FP contract, is the reduced renegotiation cost (Bajari and Tadelis, 2001), which comes at the expense of introducing a moral hazard problem (Corts and Singh, 2004). As requirements change in T&M contracts, the vendor is more likely to accept changes requested by the client without any need for renegotiating the initial contract (Kalnins and Mayer, 2004). Among the archetypes in the proposed typology, this archetype offers the best conditions to satisfactorily address situations in which adaptation is needed because the contract places no limitations on the vendor's ability to allocate resources to the project. We thus view this archetype as offering the highest level of design flexibility.
T&M-w/o-cap arrangements are similar to T&M-w/-cap arrangements in many respects: both are characterized by low design completeness, use of unstructured software engineering methodologies, intensive coordination, low control intensity and longer duration. However, because price is not constrained in T&M-w/o-cap arrangements, project escalation poses a significant risk. As risk is borne mainly by the client, high familiarity and trust are very important, and consequently, the likelihood of selecting foreign vendors is low.
Table I summarizes the implications of the five archetypes in the proposed contractual typology based on the theoretical perspectives of software engineering and contract theory.
Research hypotheses: design flexibility and cost dimensions
The five contractual archetypes described in the previous section represent a continuum of design flexibility, which is lowest in FP-w/o-change arrangements and increases with each transition from one archetype to the next. Previous research has relied on a dichotomous view of procurement contracts as either FP or T&M to offer a dichotomous view of their associated costs. For instance, Bajari and Tadelis (2001) summarize the "conventional wisdoms" about the consequences of procurement contracts (e.g. risk allocation, client administration, flexibility for change) in the form of a table with two columns, one describing the consequences of FP contracts and the other describing the consequences of T&M contracts. In the preceding section, we extended previous research by developing a continuum view of procurement contracts. In this section, we further advance the literature by offering a continuum view of the costs associated with different contractual archetypes.
Table I shows that moving along the design flexibility continuum, from FP-w/o-change arrangements to T&M-w/o-cap arrangements, has implications for key project cost dimensions. Moreover, the table implies that design flexibility is monotonically associated with these cost dimensions, so that increasing levels of design flexibility are associated with either increasing or decreasing levels of cost dimensions. In the following sections, we analyze the implications presented in Table I to identify a set of five project cost dimensions – coordination, control, trust, duration and price – and to describe how they are associated with design flexibility. The complete research model developed and tested in the following sections is presented in Figure 1.
Coordination is the management of dependencies among activities (Malone and Crowston, 1994), and it is central to the literature about procurement, outsourcing and software engineering (Cataldo and Herbsleb, 2013; Dibbern et al., 2008; Gopal et al., 2011; Gulati et al., 2005; Herbsleb et al., 2006). Gulati et al. (2005, p. 419) argue that coordination problems can persist even after cooperation is achieved because "cooperation problems are rooted in motivation, whereas coordination problems arise due to the cognitive limitations of individuals". Coordination is required either when environmental contingencies influence the terms and conditions of a transaction (Williamson, 1985) or when reciprocal interdependencies, such as ongoing decision-making about task allocation and continuous communication, are needed (Gulati et al., 2005). Coordination in software development is achieved when different people involved in a common project agree to a common definition of what they are building, share information and mesh their activities (Kraut and Streeter, 1995). Empirical studies have shown that coordination is one of the most difficult and pervasive problems in development projects (Herbsleb et al., 2006). Coordination breakdowns can occur at different levels, including the team level (related to system design and implementation) and the corporate level (related to product attributes, schedules and resources) (Curtis et al., 1988). Such breakdowns in coordination negatively affect the outcomes of software projects (Faraj and Sproull, 2000).
Following these conceptualizations, we define coordination in procurement projects as a formal mechanism that enables both the client and the vendor to manage interdependencies among activities during the project. Such a mechanism should facilitate access to resources, information sharing, problem solving and decision-making. For instance, such a mechanism can allow the vendor to access users to get their feedback on partial deliverables or allow the client to access the vendor's development team when design changes are required. Coordination differs from control, because the former focuses on managing interdependencies among individuals or activities, whereas the latter focuses on improving performance relative to the overall goal (Sabherwal, 2003).
We expect coordination to be more intensive as design flexibility increases. First, environmental contingencies are associated with coordination problems (Gulati et al., 2005), and research has found that coordination is more difficult in software projects that are uncertain, unstable or involve novel technical problems (Kraut and Streeter, 1995). Therefore, projects with high uncertainty, in which T&M contracts are more frequently used, should involve more intensive coordination. Second, FP contracts involve considerable coordination in the contract negotiation and drafting stage, whereas T&M contracts trade-off ex ante coordination for ex post coordination. The detailed specifications in FP contracts demand little coordination during the project. Conversely, the ongoing modification of specifications in T&M contracts requires substantial coordination beyond the formal contract. These two observations are also valid for the specific archetypes in our contractual typology. FP-w/o-change arrangements have the highest level of design completeness, and thus coordination is expected to be minimal in these arrangements. Because changes are not planned, coordination for change management is also not required. FP-w/-change arrangements are less stable because of the change provision, and they require a higher level of coordination to identify opportunities for change and to manage its consequences. Similarly, T&M-w/o-cap arrangements require more intensive coordination than T&M-w/-cap arrangements as a consequence of the lower design completeness. As design completeness diminishes, coordination mechanisms should be institutionalized to allow the project to advance successfully:
Design flexibility is positively associated with coordination.
Control refers to attempts by one individual or organization to motivate another to act in a manner consistent with specific expectations and objectives (Ouchi, 1979). We focus on formal outcome control rather than on informal or behavior control because such control is central to legally binding contracts governing procurement projects in general and software development projects in particular (Choudhury and Sabherwal, 2003; Gopal and Gosain, 2011; Gregory et al., 2013; Sabherwal, 1999). Formal control is exercised when targets are prespecified and rewards are contingent on the achievement of targets (Eisenhardt, 1985). Outcome control involves the definition of specific desired outputs, where the client explicitly defines goals and the vendor is rewarded for meeting those goals (Kirsch et al., 2002). The primary mechanism of formal outcome control in external software development is the deliverable and payment schedules, known as project milestones. Milestones are described as "the bedrock of successful software development" (Roditti, 1998, pp. 7-21), as they provide a mutually agreed upon sequence of activities and results and allow the client to either accept or reject intermediate and final deliverables (Roditti, 1998; Sommerville, 2000). Empirical studies have shown a positive relationship between control and performance (Bartölke et al., 1982). However, cost-benefit considerations may limit the intensity of control because milestones that are too close together may cause the project team to spend much of its time preparing deliverables that are not essential for the progress of the project (Sommerville, 2000). Empirical studies of the antecedents of control have mostly tied sources of uncertainty to types of control, as in the relation of outcome measurability and behavior observability to outcome and behavior controls (Eisenhardt, 1985; Henderson and Lee, 1992).
It becomes more difficult to define formal outcomes as design uncertainty increases. Moreover, the definition of formal outcomes constrains the ability to introduce changes in the progress of a project. Hence, the client is less motivated to control formal outcomes as design flexibility increases. These two predictions lead to the following hypothesis:
Design flexibility is negatively associated with control.
Trust is the expectation that alleviates the fear that an exchange partner will act opportunistically (Bradach and Eccles, 1989). At the organizational level, firms develop close bonds with other firms through recurrent interactions that create preferential and stable trading relationships (Gulati, 1995). Trust becomes more important as uncertainty increases and as detailed contracts and formal controls become more costly (Gefen and Reychav, 2014; Gefen et al., 2008; Oshri et al., 2015). FP arrangements are characterized by low design uncertainty, and thus, the risks of unforeseen contingencies and vendor opportunism are small. FP arrangements are also characterized by high design completeness, which facilitates formal control. Consequently, FP arrangements are more likely to be used with relatively unfamiliar, less-trusted vendors. In contrast, T&M arrangements, as well as agile methodologies, are characterized by high design uncertainty and low design completeness, and thus the risk of vendor opportunism is considerable and formal controls are more difficult to implement. The result is that trust becomes critical (McHugh et al., 2012), and T&M arrangements are more likely to be used with trusted vendors.
We hypothesize that our contractual typology also demonstrates this positive association between design flexibility and trust, namely, we suggest that trusted vendors are more likely to be contracted as design flexibility increases along the typology. FP-w/-change contracts include a change provision that facilitates renegotiation. This provision increases the risk that the vendor will take advantage of the client's new needs to opportunistically renegotiate higher prices or reduced effort. Thus, we expect higher levels of trust in FP-w/-change arrangements than in FP-w/o-change arrangements. T&M-w/-cap contracts include a price cap that limits the risk of cost escalation. Therefore, we expect lower levels of trust in T&M-w/-cap arrangements than in T&M-w/o-cap arrangements. Finally, mixed arrangements should involve intermediate levels of trust because they combine FP (less risky) and T&M (more risky) mechanisms:
Design flexibility is positively associated with trust.
Duration is the estimated length of time for the procurement project, namely, it is the expected time period for the project at the time the contract is signed. The duration of a project has been found to influence outsourcing arrangements (Gefen et al., 2016). In FP arrangements, the duration is defined clearly in the contract's binding deliverables schedule. In arrangements that include T&M mechanisms, duration is typically estimated and agreed upon by both client and vendor, but the estimate is not binding. We expect a positive association between design flexibility and duration. First, long-duration projects require more flexible arrangements because of the higher likelihood that the business and technological environment will change during the project. As a consequence of environmental turbulence, the longer the project is in progress, the higher the likelihood that business changes (e.g. mergers and acquisitions, strategic reorientation) or technological changes (e.g. emerging architectures and standards) will require design modifications in the software being developed. Second, more flexible arrangements require a longer duration because time compensates for uncertainty and design incompleteness. When uncertainty is high and design completeness is low, more time has to be allocated to the project to allow more degrees of freedom in accommodating the probable design adaptations. In developing H1, we discussed the positive association between design flexibility and coordination. Coordination mechanisms require time, and we expect arrangements with higher design flexibility to accommodate the need for more intensive coordination by allowing longer duration. FP-w/-change arrangements, for instance, should have longer duration than FP-w/o-change arrangements because of the time involved in coordinating changes and negotiating their implications. T&M arrangements should have longer duration than FP arrangements because of the time involved in ongoing coordination regarding the detailed software specification. Such a process may require input and approval from multiple stakeholders, which are time-consuming activities:
Design flexibility is positively associated with duration.
Price is the estimated monetary value of the procurement project at the time the contract is signed. The size of a software development project, which is reflected in its price, has a strong influence on the manner in which the project is managed (Sommerville, 2000) and on its contracting terms in an outsourcing context (Fink and Lichtenstein, 2014). By definition, the predetermined price in FP arrangements is binding. Conversely, the ex ante price in arrangements that include T&M mechanisms is based on non-binding estimates of the expenses incurred by the vendor. We anticipate a positive association between design flexibility and price. This association is largely explained by the inclusion of a premium for uncertainty and design incompleteness in the project price. Design adaptations are unlikely in FP-w/o-change arrangements, and therefore their price need not include a premium for uncertainty and design incompleteness. A renegotiation option is embedded in FP-w/-change arrangements, and their price should be higher to reflect a premium for this option. The price of mixed arrangements should be relatively high, not only because of their partial T&M orientation but also because of the additional effort and resources involved in integrating the FP and T&M elements. The price of T&M-w/-cap and T&M-w/o-cap arrangements should be high as a consequence of the significant premium for their high uncertainty and low design completeness. This premium should be higher for T&M-w/o-cap arrangements because of their higher uncertainty, which is reflected in the absence of a price cap:
Design flexibility is positively associated with price.
This section presents the research methodology by describing the research setting and the process of data collection, including the measures used to proxy for the various cost dimensions. The next section presents the procedures used to analyze the data and the results we obtained.
Research setting
The research setting for this study is the financial services industry, which is considered to be highly competitive, dynamic and information intensive. This industry is the largest user of IT in the industrial sectors (Zhu et al., 2004) and tends to have the highest IT investment risk (Dewan et al., 2007). While almost all industries are currently influenced by digital technology, banking is at the forefront of digital competitive pressures (e.g. Fintech), significant regulatory changes and opportunities for new efficiencies (Constâncio, 2016). We collected data on SDAs in a leading international bank. The bank, headquartered in Europe, is among the largest in the world. It provides retail and commercial banking, wealth management, and investment banking in dozens of countries and has tens of thousands of employees. The bank's IT department employs about 3,000 permanent employees and 2,000 contractors.
The bank's systems are either developed in-house, by internal staff complemented by external consultants and programmers, or they are developed through SDAs. The bank contracts out system development through about 100 local and international vendors. Its methods of managing SDAs are typical of other banks and large institutions. The bank maintains a software acquisition process that includes eight main steps: request for proposals, vendor evaluation, vendor selection, negotiation, closure, fulfilment, extension and cancellation. The bank aims at using its standard SDA contracts wherever possible. The standard contract is similar to contract forms described in the literature (Kutten, 1988; Pearson, 1984). This contract is about ten pages in length, excluding appendices for scope and schedule. The contract itself includes a definition of its purpose and content, the vendor's obligations, scope changes, acceptance testing, warranty and guarantee, expenses and payment terms, training, ownership of intellectual property, breach penalty, liability, confidentiality and data protection and prohibition against enticement or employment of bank staff. The appendices describe project scope, milestones, payment details, the bank's obligations and project organization. The standard contract also defines actions to be taken if the schedule is not maintained, which include either setting a new schedule or the option of canceling the contract. The bank's contracting guidelines permit changes to the standard contract within defined limits.
Data collection
This study continues the recent trend toward the quantitative analysis of contractual provisions in actual outsourcing contracts (Argyres et al., 2007; Chen and Bharadwaj, 2009). Consistent with previous research, the unit of analysis in this study is the contract (Ethiraj et al., 2005; Gopal et al., 2003; Gulati, 1995). We collected detailed quantitative data from the bank's contract repository. Each record in the repository represented a single contract and included the contract number, start and end dates, contract price, vendor name and an electronic scan of the contract. We were given access to all software development contracts signed between January 2000 and April 2003 – 424 contracts in total. Due to time constraints, we were able to collect detailed data only on a representative sample of 270 contracts, which formed our data set.
We followed a systematic scheme to categorize the contracts into the five archetypes in our contractual typology. The distinction between FP and T&M contracts was explicitly stated in the contracts. We classified contracts as mixed when they combined both FP and T&M arrangements. Pure FP contracts were classified as either FP-w/-change, if they included a change provision (i.e. a specific clause with explicit change management principles and guidelines, describing procedures for change requests, for analyzing their impacts and for renegotiation discussions), or FP-w/o-change, if such a provision was not included. Contracts that were pure T&M were classified as either T&M-w/-cap, if they included a price cap (i.e. a predetermined maximum price), or T&M-w/o-cap, if such a cap was not included. Among the 270 contracts in our data set, there were 42 FP-w/o-change, 139 FP-w/-change, 32 mixed, 14 T&M-w/-cap and 43 T&M-w/o-cap arrangements.
Cost dimensions were evaluated as follows. Coordination was operationally defined as the frequency of routine meetings between client and vendor representatives defined in the contract. Coordination was assigned a value of "0" when regular meetings were not defined in the contract, a value of "1" when regular monthly meetings were defined or a value of "2" when regular bi-weekly or weekly meetings were defined. Control was operationally defined as the intensity of milestones specified in the contract. Control intensity was calculated as the sum of the numbers of payment, delivery and project milestones, divided by contract price. Payment milestones were taken as those milestones at which a portion of the price was due. Delivery milestones were taken as delivery dates at which a work package had to be delivered to the client without a payment. Project milestones were neither payment nor delivery milestones; rather, they represented defined end-points in the progress of the project. They could describe certain compulsory meetings, client sign-off of specification documents or the end of internal testing. Trust was operationally defined as client-vendor familiarity (Gefen et al., 2008), which was measured with two variables. The first variable was vendor experience, which we calculated as the accumulated price of previous contracts signed with the same vendor after January 2000 (in all 424 contracts signed during the period we studied). The second variable was vendor locality, which was a dichotomous variable that indicated whether the vendor was international ("1") or local ("2"). Duration was operationally defined as the number of days between the contract's start date and its expected completion date, as recorded in the contract repository. This value represented the duration of the project as contracted between the bank and the vendor. Price was defined as the total price of the contract in US dollars. The price of each contract was copied as explicitly stated in the contract. This value represented the binding price for FP contracts or the estimated price for T&M contracts.
To control for project size, we used two scope dimensions, which served as proxies for the size of the software product being developed. The first dimension was external scope, which was operationally defined as the number of external scope documents (e.g. requirements, system specifications and system design documents) referred to in the contract. The second dimension was total scope, which was operationally defined as the extent of both internal and external scope documents. This dimension could be awarded a value of "0" (no scope documents), "1" (one non-detailed internal scope document), "2" (one-two scope documents), "3" (three-four scope documents), "4" (five-nine scope documents) or "5" (ten or more scope documents). All measures used in this study were objective and involved no subjective judgment. Descriptive statistics are presented in Table II.
We used three statistical methods to test the five hypotheses about the associations between design flexibility and cost dimensions – coordination, control, trust (vendor experience and vendor locality), duration and price. First, we used a one-way analysis of variance (ANOVA) to test for differences among the five contractual archetypes for each cost dimension. The mean values of cost dimensions across contractual archetypes and ANOVA results are presented in Table III. The ANOVA results were statistically significant at the 0.001 level (the F value for duration was significant at the 0.01 level), indicating that there were significant mean differences among contractual archetypes for all cost dimensions. Second, we used a Spearman correlation analysis as an initial test of the hypotheses because the design flexibility scale was ordinal. This analysis also minimized the effect of outliers. Spearman's rho values, also presented in Table III, were all statistically significant at the 0.001 level. They were all in the hypothesized direction – positive for coordination (0.347), vendor experience (0.307), vendor locality (0.349), duration (0.259) and price (0.358) and negative for control (−0.297).
We then repeated these analyses with the two scope dimensions as the dependent variables. The results of these analyses are presented in Table IV. The ANOVA results were statistically significant at the 0.001 level for both external scope and total scope. However, these effects were the consequence of one archetype having significantly higher scope values than other archetypes: scope values were higher in Mixed contracts than in other archetypes. A Spearman correlation analysis, which tested whether design flexibility was associated with scope dimensions, showed no statistically significant correlation for either external scope (rho = −0.007, p = 0.905) or total scope (rho = 0.078, p = 0.199). These results rejected the possibility that design flexibility confounded with scope and enhanced the validity of our findings concerning the correlations between design flexibility and cost dimensions.
Last, we performed six separate regression analyses to examine the effects of design flexibility, external scope and total scope on each of the six cost dimensions. Because of the different types of dependent variables (i.e. cost dimensions), three different regression methods were used:
four ordinary least squares (OLS) regression models estimated the effects of design flexibility and scope dimensions on control, vendor experience, duration and price (continuous variables);
an ordinal regression model estimated the effects of design flexibility and scope dimensions on coordination (ordinal variable); and
a logistic regression model estimated the effects of design flexibility and scope dimensions on vendor locality (binary variable).
A common approach in previous studies has been to use the log of variables that measure duration or monetary value because of their skewed distribution (Chen and Bharadwaj, 2009; Ethiraj et al., 2005). We therefore used the log of vendor experience, duration and price in the OLS models. The results of the regression analyses are presented in Table V (OLS regression models) and Table VI (ordinal and logistic regression models). The results showed that design flexibility had a significant effect in the hypothesized direction in all six models – the regression coefficients of design flexibility were −0.043 for control, 0.251 for vendor experience, 0.065 for duration, 0.169 for price, 0.565 for coordination and 0.699 for vendor locality. These effects of design flexibility on cost dimensions were all statistically significant at the 0.001 level. In contrast to design flexibility, external scope had no significant effect in any of the six models, and total scope had a significant effect only on price, with a coefficient of 0.189 (p < 0.01)[2]. Taken together, the correlation and regression findings showed that design flexibility was associated with all cost dimensions and that scope dimensions were not associated with either design flexibility or cost dimensions (except for the effect of total scope on price). Based on these findings, we concluded that all five hypotheses were supported by the data collected in this study.
Software development remains a complex task to outsource, and therefore, it continues to be a suitable context for analyzing the nuances of flexibility, coordination, control and trust in formal contractual arrangements. In this study, we show that five contractual archetypes have evolved to provide a continuum of design flexibility and that moving along this continuum is associated with multiple project costs. Our findings shed light on the ability of firms to align flexibility with uncertainty at the onset of new projects and on their incentives for doing so. Firms respond to design uncertainty by seeking design flexibility. However, the need for design flexibility is balanced by the need to minimize project costs. As the variance of uncertainty increases, these conflicting needs should drive firms to break away from the prevailing typology of procurement contracts as either FP or T&M and move toward a broader set of contractual archetypes.
The contractual data we collected confirm that the proposed contractual typology does indeed exist in practice. While some archetypes are used more frequently than others – with FP-w/-change being the most frequently used (51.5 per cent) and T&M-w/-cap being the least frequently used (5.2 per cent) – all five archetypes defined in this study are unambiguously and repeatedly detectable in the data. Furthermore, data analysis supports all five hypotheses. It shows that higher flexibility is associated with higher coordination, lower control, higher trust (vendor experience and locality), longer duration and higher prices. It also shows that these associations cannot be explained by scope differences across the archetypes.
However, the significant associations between design flexibility and cost dimensions are not reflected in every transition from one archetype to another for every cost dimension. While data analysis illustrates that costs do increase with increasing design flexibility, we find particular instances in which making a transition from an archetype with lower design flexibility to an archetype with higher design flexibility does not have the hypothesized effect. This observation is more marked at the high end of the design flexibility continuum. The typology suggests that the inclusion of a price cap in a T&M contract should have a limiting effect on project costs. However, this hypothesized effect was not found consistently in our data. A plausible explanation for this finding is based on the relatively small number of T&M-w/-cap contracts in the data (14 contracts). Such a number makes it difficult to draw firm conclusions about the cost differences between T&M-w/-cap and T&M-w/o-cap contracts. The finding that T&M-w/-cap contracts constituted the smallest share of the contracts in the data (5.2 per cent), considerably smaller than that of T&M-w/o-cap contracts (15.9 per cent), may imply that when clients opt for T&M contracts, their default choice is not to constrain the vendor's flexibility. In contrast, data analysis provides stronger support for the hypothesized effects at the low end of the design flexibility continuum. Our findings confirm that the inclusion of a change provision in an FP contract is sufficiently significant to increase project costs.
The mixed archetype exhibits the most unexpected pattern of costs. The typology regards this archetype as representing an intermediate level of design flexibility between the two relatively inflexible FP archetypes and the two relatively flexible T&M archetypes. An assumption underlying the typology is that a design flexibility continuum requires that FP and T&M archetypes should not remain mutually exclusive. For a continuum to exist, there should be an archetype that combines the different mechanisms into a single arrangement. Accordingly, we expected mixed contracts to be associated with intermediate levels of project costs. The results show that the cost pattern of mixed contracts is somewhat similar to that of the two T&M archetypes. Moreover, price is highest in mixed contracts. We propose two explanations for these results. First, it may very well be that mixed contracts are more flexible than we think. The ability to mix FP and T&M mechanisms in a variety of combinations may yield flexible arrangements that bring together the advantages of both mechanisms. Mixed contracts may therefore be both the most flexible and the most costly. Second, mixed contracts are frequently an aggregation of several phases or sub-systems. The upside of this archetype is that it allows different levels of design completeness to coexist within a single contract. Its downside lies in the additional effort and complexity involved in bridging and integrating the different arrangements. The relatively high costs associated with mixed contracts may be the consequence of this additional complexity. This explanation is supported by our findings that both scope dimensions are significantly higher in mixed contracts than in other archetypes.
Theoretical contributions
This study uses the theoretical lenses of contract theory and software engineering to construct and test a contractual typology for software development. It therefore contributes to both streams of research. The study makes an important contribution to the general literature on procurement contracts (Bolton and Dewatripont, 2005; Hart and Holmstrom, 1985), particularly contractual arrangements aimed at software development. The contractual typology developed in this study is founded on a continuum perception of design uncertainty, completeness and flexibility, which is conceptually distinct from the prevailing dichotomous perception of these concepts. To develop this continuum perception, we do not reject the traditional distinction between FP and T&M procurement contracts. On the contrary, we rely on this distinction in our proposition that archetypal variations of FP and T&M contracts have evolved to provide a continuum of design flexibility between the extreme levels of design flexibility characterizing these two dominant archetypes. This continuum perception of design flexibility and the ensuing contractual typology are novel. They have emerged from a conceptual analysis of the existing literature and from our extensive familiarity with the contractual mechanisms that are used to adapt SDAs to environmental changes. We consider this perceptual change, which is supported by our empirical investigation, to be a valuable contribution to the state of the art. An implication of this perceptual change for research is that contractual nuances, such as the inclusion of a change provision in a contract, have important consequences for project performance. Researchers should pay careful attention to such minor variations when analyzing projects and contracts, as their identification and consideration can be helpful in understanding incentives and risk sharing in outsourcing arrangements.
Another important contribution comes from the multidimensional analysis of project costs associated with design flexibility. Many previous studies have focused on a single cost dimension as the endogenous effect of project characteristics (Rustagi et al., 2008; Sabherwal, 2003). While such an approach has been valuable in unveiling the mechanisms that explain significant variance in project performance, it has not advanced our understanding of how multiple cost dimensions change in concert. This limitation is addressed in the present study, which explores the consequences of moving along the design flexibility continuum in terms of coordination, control, trust, duration and price. The multidimensional approach taken in this study illustrates the trade-off between coordination and control. H1 and H2 describe the associations of design flexibility with coordination and control, respectively. These hypotheses and their underlying rationales suggest that coordination and control are substitutes in SDAs. Control, defined here as an outcome-oriented concept, is a more effective interaction mechanism in arrangements with low design uncertainty and high design completeness, i.e. where deliverables are easier to define and less susceptible to change. In contrast, coordination, defined here as a behavior-oriented concept, is a more effective interaction mechanism in arrangements with high design uncertainty and low design completeness, i.e. where deliverables are harder to define and more susceptible to change. This important observation about the substitutability of coordination and control could not have emerged without a multidimensional approach to the implications of design flexibility.
Practical implications
The present study offers insight into how adaptability is sustained in contracting for software development. It is in this insight that the main practical implications of this study lie. Given the trend toward the external acquisition of IT resources and the emergence of new business models based on these resources, the management of relationships with IT vendors is a major challenge facing managers (Applegate et al., 2009; Gewald and Schäfer, 2017). The ability of managers to meet this challenge is, in part, contingent upon their ability to design and use contractual mechanisms that maximize the alignment between the environmental and structural characteristics of their external relationships. However, with the increasing gap between the complexity of contemporary business environments and the simplicity of prevailing contractual arrangements, it is inevitable that many external relationships will fail to achieve their objectives.
Firms increasingly find themselves in a situation of having to rely on external arrangements to develop software, on the one hand, and having to adapt software resources to frequent environmental changes, on the other hand. Those firms that rigidly use a single contractual archetype or a narrow set of contractual archetypes may find that the variety in their environment exceeds the repertoire of their potential actions. This gap may lead to low design flexibility (if FP contracts alone are used), high project costs (if T&M contracts alone are used) or a failure to balance design flexibility and project costs (if only FP and T&M contracts are used). The use of a broader set of contractual archetypes may allow firms to improve the cost effectiveness of design flexibility. As demonstrated in the present study, such a broader typology does not have to be formally defined at the organizational level. It may be based on variations of established archetypes, as long as these variations are used consistently to increase the design flexibility of constraining arrangements or reduce the design flexibility of costly and risky open-ended arrangements, thus creating a continuum of design flexibility. This study shows that including a change provision in FP contracts, including a price cap in T&M contracts, and mixing FP and T&M mechanisms generate such a broader typology along a continuum of design flexibility. The change provision and price cap are important for the construction of a broader typology because they address the major risks associated with FP and T&M contracts and thus moderate their extreme levels of design flexibility. Using such a broader typology is a prerequisite to being able to align flexibility with uncertainty for each new project. Overall, this study provides insight into the contractual mechanisms that can allow clients to have SDAs with different levels of flexibility, improving their capability to outsource (Pratap, 2014).
Limitations and future research
This study has two major limitations, which restrict the generalizability of its findings, yet offer avenues for future research. First, the data were collected in a single organization. While the bank that granted us access to its contractual data is among the largest in the world, it is fair to assume that its outsourcing and contracting practices have been shaped to some extent by the national culture (Barthelemy and Geyer, 2001) and the existing organizational culture. This limitation offers an interesting direction for future research. The logic of this study suggests that firms in rapidly changing environments need to use a broader set of contractual archetypes. This logic implies that firms in relatively stable environments may use a narrow set of one or two contractual archetypes. Our research setting suggests that the breadth of contractual archetypes needs to be higher in industries that are characterized by high levels of information intensity and environmental turbulence, such as finance and digital media, but lower in industries that are less information intensive and turbulent, such as manufacturing (Yap et al., 2016). Future research could use a multi-site design to explore the relationship between environmental uncertainty and dynamics, on the one hand, and the breadth of the contractual typology practiced, on the other hand. Second, the data were collected from the bank's contract repository at a single point in time. Therefore, the data are correlational in nature. Moreover, some of the cost dimensions, particularly duration and price, are based on project estimates rather than actual project performance. The internal validity of the flexibility-cost relationship in SDAs should be further demonstrated by additional research, designed to collect both contractual data and project performance data. Finally, another direction for future research can be the relation between agile software development methodologies (Dingsøyr et al., 2012) and formal contracting. As agile methods have become increasingly popular, addressing the issues discussed in this paper in the context of these methods can be a promising avenue for research on software development outsourcing.
Implications of contractual archetypes based on software engineering and contract theory perspectives
|Software engineering perspective
|Contract theory perspective
|FP contracts without a change provision
|High level of design completeness
Structured software engineering methodologies
Less coordination needed
Control maximized to reveal quality problems early
Good cost estimation
|Risk allocated mainly to vendor
Competitive bidding
High familiarity and trust not needed
Relatively high likelihood of selecting foreign vendors
Intensive control as a substitute for trust
Vendor has incentive to shorten duration
Minimal premium for uncertainty
|FP contracts with a change provision
|High level of design completeness
Structured software engineering methodologies
|Risk allocated mainly to vendor
Somewhat higher familiarity and trust needed because of the renegotiation option
Price should reflect a premium for the renegotiation option
|Mixed FP and T&M contracts
|Intermediate level of design completeness
Semi-structured software engineering methodologies
T&M fits early stages (high uncertainty) and FP fits late stages (low uncertainty)
Control intensity should be related to the relative scale of FP and T&M arrangements
|Risk shared between vendor and client
Price expected to be relatively high because mixed contracts are an aggregation of several phases or sub-systems
Familiarity and trust needed because of T&M segments
|T&M contracts with a price cap
|Low level of design completeness
Unstructured software engineering methodologies
Price cap limits project escalation
High coordination required
Lower control intensity
Longer duration to allow for experimentation, user feedback and changes
|Risk allocated mainly to client, but vendor bears some risk because of the price cap
High familiarity and trust needed
|T&M contracts without a price cap
|Low level of design completeness
Unstructured software engineering methodologies
Significant risk of project escalation
High coordination needed
Control minimized
Longer duration
|Risk allocated mainly to client
Familiarity and trust very important
Relatively low likelihood of selecting foreign vendors
Descriptive statistics (N = 270)
|Cost dimension
|Coordination – Frequency of routine client-vendor meetings defined in the contract
(0 = not defined; 1 = monthly meetings;
2 = bi-weekly/weekly meetings)
|Control – Intensity of milestones specified in the contract
(sum of payment, delivery and project milestones, divided by contract price)
|Vendor experience (trust) – Accumulated price of previous contracts with the vendor
(in thousands of US dollars)
|Vendor locality (trust) – Whether the vendor was international or local (1 = international; 2 = local)
|Duration – Period of time between the contract's start date and its completion date (in days)
|3 days
|880 days
|189.60 days
|143.30 days
|Price – Total price of the contract
(in thousands of US dollars)
|Scope dimension
|External scope – Number of external scope documents referred to in the contract (numeric)
|Total scope – Extent of both internal and external scope documents (0 = no documents; 1 = one undetailed internal document; 2 = 1-2 documents; 3 = 3-4 documents; 4 = 5-9 documents; 5 = 10 or more documents)
ANOVA and correlation results for cost dimensions
|Cost dimension
|Vendor experience (trust)
|Vendor locality (trust)
|(1) FP-w/o-change
|129.45 days
|(2) FP-w/-change
|182.70 days
|(3) Mixed
|230.45 days
|(4) T&M-w/-cap
|242.46 days
|(5) T&M-w/o-cap
|222.49 days
|Rho (Spearman)
*p < 0.05;
**p < 0.01;
***p < 0.001; two-tailed p values are reported
ANOVA and correlation results for scope dimensions
|Scope dimension
|External scope
|Total scope
|(1) FP-w/o-change
|(2) FP-w/-change
|(3) Mixed
|(4) T&M-w/-cap
|(5) T&M-w/o-cap
|Rho (Spearman)
*p < 0.05; ** p < 0.01;
***p < 0.001; two-tailed p values are reported
Results of OLS regression models
|OLS regression model
|Log (vendor experience)
|Log (duration)
|Log (price)
|0.293*** (0.053)
|5.374*** (0.232)
|1.847*** (0.091)
|4.175*** (0.150)
|Design flexibility
|−0.043*** (0.010)
|0.251*** (0.043)
|0.065*** (0.017)
|0.169*** (0.028)
|External scope
|0.000 (0.005)
|0.018 (0.022)
|0.007 (0.009)
|0.023 (0.014)
|Total scope
|−0.036 (0.021)
|0.085 (0.093)
|0.053 (0.037)
|0.189** (0.061)
|Adjusted R2
Unstandardized coefficients are shown with standard errors in parentheses;
*p < 0.05;
**p < 0.01;
***p < 0.001; two-tailed p-values are reported
Results of ordinal and logistic regression models
|Ordinal regression model
|Logistic regression model
|Vendor locality (trust)
|−1.319 (0.813)
|Design flexibility
|0.565*** (0.116)
|0.699*** (0.171)
|External scope
|0.114 (0.073)
|0.396 (0.222)
|Total scope
|0.351 (0.283)
|0.273 (0.405)
|Log likelihood
|Pseudo R2 (Nagelkerke)
Estimated coefficients are shown with standard errors in parentheses; *p < 0.05; **p < 0.01;
***p < 0.001; two-tailed p-values are reported
Although we consider the contractual typology as representing a continuum of design flexibility, the five discrete archetypes that comprise the typology do not really provide a continuous range of contracts.
To ensure that our findings were not due to the log transformation of vendor experience, duration and price, we reran the OLS models with the original values of these variables. The results were consistent with the findings for the log values – the regression coefficients of design flexibility were 1,210,742 for vendor experience (p < 0.001), 21.947 for duration (p < 0.01) and 39,364 for price (p = 0.05). The only significant effect of scope dimensions on cost dimensions was that of external scope on price, with a coefficient of 61,288 (p < 0.001).
Anderson, S.W. and Dekker, H.C. (2005), "Management control for market transactions: the relation between transaction characteristics, incomplete contract design, and subsequent performance", Management Science, Vol. 51 No. 12, pp. 1734-1752.
Applegate, L.M., Austin, R.D. and Soule, D.L. (2009), Corporate Information Strategy and Management: Text and Cases, 8th ed., McGraw-Hill, New York, NY.
Argyres, N.S., Bercovitz, J. and Mayer, K.J. (2007), "Complementarity and evolution of contractual provisions: an empirical study of IT services contracts", Organization Science, Vol. 18 No. 1, pp. 3-19.
Austin, R.D. and Devin, L. (2009), "Weighing the benefits and costs of flexibility in making software: toward a contingency theory of the determinants of development process design", Information Systems Research, Vol. 20 No. 3, pp. 462-477.
Bajari, P. and Tadelis, S. (2001), "Incentives versus transaction costs: a theory of procurement contracts", RAND Journal of Economics, Vol. 32 No. 3, pp. 387-407.
Banerjee, A.V. and Duflo, E. (2000), "Reputation effects and the limits of contracting: a study of the indian software industry", Quarterly Journal of Economics, Vol. 115 No. 3, pp. 989-1017.
Barthelemy, J. and Geyer, D. (2001), "IT outsourcing: evidence from France and Germany", European Management Journal, Vol. 19 No. 2, pp. 195-202.
Bartölke, K., Eschweiler, W., Flechsenberger, D. and Tannenbaum, A.S. (1982), "Workers' participation and the distribution of control as perceived by members of ten German companies", Administrative Science Quarterly, Vol. 27 No. 3, pp. 380-397.
Boehm, B. (2002), "Get ready for agile methods, with care", Computer, Vol. 35 No. 1, pp. 64-69.
Boehm, B.W. (1988), "A spiral model of software development and enhancement", Computer, Vol. 21 No. 5, pp. 61-72.
Boehm, B.W., Abts, C., Brown, A.W., Chulani, S., Clark, B.K., Horowitz, E., Madachy, R., Reifer, D.J. and Steece, B. (2000), Software Cost Estimation with COCOMO II, Prentice Hall, Upper Saddle River, NJ.
Bolton, P. and Dewatripont, M. (2005), Contract Theory, MIT Press, Cambridge, MA.
Bradach, J.L. and Eccles, R.G. (1989), "Price, authority, and trust: from ideal types to plural forms", Annual Review of Sociology, Vol. 15 No. 1, pp. 97-118.
Cataldo, M. and Herbsleb, J.D. (2013), "Coordination breakdowns and their impact on development productivity and software failures", IEEE Transactions on Software Engineering, Vol. 39 No. 3, pp. 343-360.
Chen, Y. and Bharadwaj, A. (2009), "An empirical analysis of contract structures in IT outsourcing", Information Systems Research, Vol. 20 No. 4, pp. 484-506.
Choudhury, V. and Sabherwal, R. (2003), "Portfolios of control in outsourced software development projects", Information Systems Research, Vol. 14 No. 3, pp. 291-314.
Cockburn, A. (2002), Agile Software Development, Addison-Wesley, Reading, MA.
Constâncio, V. (2016), Challenges for the European Banking Industry, European Central Bank, available at: www.ecb.europa.eu/press/key/date/2016/html/sp160707_1.en.html
Corts, K.S. and Singh, J. (2004), "The effect of repeated interaction on contract choice: evidence from offshore drilling", Journal of Law, Economics, and Organization, Vol. 20 No. 1, pp. 230-260.
Curtis, B., Krasner, H. and Iscoe, N. (1988), "A field study of the software design process for large systems", Communications of the ACM, Vol. 31 No. 11, pp. 1268-1287.
Deloitte (2016), "Global outsourcing survey 2016", available at: www2.deloitte.com/us/en/pages/operations/articles/global-outsourcing-survey.html
Dewan, S., Shi, C. and Gurbaxani, V. (2007), "The risk-return relationship of information technology investment: firm-level empirical analysis", Management Science, Vol. 53 No. 12, pp. 1829-1842.
Dibbern, J. Winkler, J. and Heinzl, A. (2008), "Explaining variations in client extra costs between software projects offshored to India", MIS Quarterly, Vol. 32 No. 2, pp. 333-366.
Dingsøyr, T., Nerur, S., Balijepally, V. and Moe, N.B. (2012), "A decade of agile methodologies: towards explaining agile software development", Journal of Systems and Software, Vol. 85 No. 6, pp. 1213-1221.
Eisenhardt, K.M. (1985), "Control: organizational and economic approaches", Management Science, Vol. 31 No. 2, pp. 134-149.
Eremenko, P. (2007), "A conceptual framework for choice of form for acquisition contracts", available at: http://ssrn.com/abstract=999147
Ethiraj, S.K., Kale, P., Krishnan, M.S. and Singh, J.V. (2005), "Where do capabilities come from and how do they matter? a study in the software services industry", Strategic Management Journal, Vol. 26 No. 1, pp. 25-45.
Faraj, S. and Sproull, L. (2000), "Coordinating expertise in software development teams", Management Science, Vol. 46 No. 12, pp. 1554-1568.
Fink, L. and Lichtenstein, Y. (2014), "Why project size matters for contract choice in software development outsourcing", ACM SIGMIS Database, Vol. 45 No. 3, pp. 54-71.
Fink, L., Lichtenstein, Y. and Wyss, S. (2013), "Ex post adaptations and hybrid contracts in software development services", Applied Economics, Vol. 45 No. 32, pp. 4497-4508.
Gaebert, C. (2015), "The fixed-price contract: a challenge for the software development project", in Holzinger, A., Cardoso, J., Cordeiro, J., Libourel, T., Maciaszek, L. and van Sinderen, M. (Eds), Software Technologies: Communications in Computer and Information Science, Springer, Berlin, Vol. 555.
Gefen, D. and Reychav, I. (2014), "Why trustworthiness in an IT vendor is important even after the vendor left: it is accepting the message and not just the messenger that is important", Omega, Vol. 44, pp. 111-125.
Gefen, D., Gefen, G. and Carmel, E. (2016), "How project description length and expected duration affect bidding and project success in crowdsourcing software development", Journal of Systems and Software, Vol. 116, pp. 75-84.
Gefen, D., Wyss, S. and Lichtenstein, Y. (2008), "Business familiarity as risk mitigation in software development outsourcing contracts", MIS Quarterly, Vol. 32 No. 3, pp. 531-551.
Gewald, H. and Schäfer, L. (2017), "Quo vadis outsourcing? A view from practice", Journal of Global Operations and Strategic Sourcing, Vol. 10 No. 1, pp. 2-17.
Goo, J., Kishore, R., Rao, H.R. and Nam, K. (2009), "The role of service level agreements in relational management of information technology outsourcing: an empirical study", MIS Quarterly, Vol. 33 No. 1, pp. 119-145.
Gopal, A. and Gosain, S. (2011), "The role of organizational controls and boundary spanning in software development outsourcing: implications for project performance", Information Systems Research, Vol. 21 No. 4, pp. 960-982.
Gopal, A. and Koka, B.R. (2010), "The role of contracts on quality and returns to quality in offshore software development outsourcing", Decision Sciences, Vol. 41 No. 3, pp. 491-516.
Gopal, A., Espinosa, J.A., Gosain, S. and Darcy, D.P. (2011), "Coordination and performance in global software service delivery: the vendor's perspective", IEEE Transactions on Engineering Management, Vol. 58 No. 4, pp. 772-785.
Gopal, A., Sivaramakrishnan, K., Krishnan, M.S. and Mukhopadhyay, T. (2003), "Contracts in offshore software development: an empirical analysis", Management Science, Vol. 49 No. 12, pp. 1671-1683.
Gregory, R.W., Beck, R. and Keil, M. (2013), "Control balancing in information systems development offshoring projects", MIS Quarterly, Vol. 37 No. 4, pp. 1211-1232.
Gulati, R. (1995), "Does familiarity breed trust? The implications of repeated ties for contractual choice in alliances", Academy of Management Journal, Vol. 38 No. 1, pp. 85-112.
Gulati, R., Lawrence, P.R. and Puranam, P. (2005), "Adaptation in vertical relationships: beyond incentive conflict", Strategic Management Journal, Vol. 26 No. 5, pp. 415-440.
Harrington, R.J., Lemak, D.J., Reed, R. and Kendall, K.W. (2004), "A question of fit: the links among environment, strategy formulation, and performance", Journal of Business and Management, Vol. 10 No. 1, pp. 15-38.
Hart, O. and Holmstrom, B. (1985), The Theory of Contracts, World Congress of the Econometric Society, Cambridge, MA.
Henderson, J.C. and Lee, S. (1992), "Managing I/S design teams: a control theories perspective", Management Science, Vol. 38 No. 6, pp. 757-777.
Herbsleb, J.D., Mockus, A. and Roberts, J.A. (2006), "Collaboration in software engineering projects: a theory of coordination", 27th International Conference on Information Systems, Milwaukee, WI, pp. 553-568.
Highsmith, J. and Cockburn, A. (2001), "Agile software development: the business of innovation", Computer, Vol. 34 No. 9, pp. 120-127.
Iacovou, C.L. and Nakatsu, R. (2008), "A risk profile of offshore-outsourced development projects", Communications of the ACM, Vol. 51 No. 6, pp. 89-94.
Kalnins, A. and Mayer, K.J. (2004), "Relationships and hybrid contracts: an analysis of contract choice in information technology", Journal of Law, Economics, and Organization, Vol. 20 No. 1, pp. 207-229.
Kirsch, L.J., Sambamurthy, V., Ko, D.G. and Purvis, R.L. (2002), "Controlling information systems development projects: the view from the client", Management Science, Vol. 48 No. 4, pp. 484-498.
Kraut, R.E. and Streeter, L.A. (1995), "Coordination in software development", Communications of the ACM, Vol. 38 No. 3, pp. 69-81.
Krishnan, V. and Bhattacharya, S. (2002), "Technology selection and commitment in new product development: the role of uncertainty and design flexibility", Management Science, Vol. 48 No. 3, pp. 313-327.
Kutten, L.J. (1988), Computer Software: Protection/Liability/Law/Forms, West Group Publishing, St. Paul, MN.
Lacity, M.C. and Willcocks, L.P. (1998), "An empirical investigation of information technology sourcing practices: lessons from experience", MIS Quarterly, Vol. 22 No. 3, pp. 363-408.
Laffont, J.J. and Tirole, J. (1993), A Theory of Incentives in Procurement and Regulation, MIT Press, Cambridge, MA.
Lichtenstein, Y. (2004), "Puzzles in software development contracting", Communications of the ACM, Vol. 47 No. 2, pp. 61-65.
McHugh, O., Conboy, K. and Lang, M. (2012), "Agile practices: the impact on trust in software project teams", IEEE Software, Vol. 29 No. 3, pp. 71-76.
Malone, T.W. and Crowston, K. (1994), "The interdisciplinary study of coordination", ACM Computing Surveys, Vol. 26 No. 1, pp. 87-119.
Martin, J. (1991), Rapid Application Development, Macmillan Publishing Company, New York, NY.
Martin, R.C. (2003), Agile Software Development: Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, NJ.
Mayer, R.C., Davis, J.H. and Schoorman, F.D. (1995), "An integrative model of organizational trust", Academy of Management Review, Vol. 20 No. 3, pp. 709-734.
Nerur, S., Mahapatra, R. and Mangalaraj, G. (2005), "Challenges of migrating to agile methodologies", Communications of the ACM, Vol. 48 No. 5, pp. 72-78.
Oshri, I., Kotlarsky, J. and Gerbasi, A. (2015), "Strategic innovation through outsourcing: the role of relational and contractual governance", Journal of Strategic Information Systems, Vol. 24 No. 3, pp. 203-216.
Ouchi, W.G. (1979), "A conceptual framework for the design of organizational control mechanisms", Management Science, Vol. 25 No. 9, pp. 833-848.
Pearson, H.E. (1984), Computer Contracts: An International Guide to Agreements and Software Protection, Chapman & Hall, London.
Pratap, S. (2014), "Towards a framework for performing outsourcing capability", Strategic Outsourcing: An International Journal, Vol. 7 No. 3, pp. 226-252.
Roditti, E.C. (1998), Computer Contracts: Negotiating Drafting, Matthew Bender, New York, NY.
Rustagi, S., King, W.R. and Kirsch, L.J. (2008), "Predictors of formal control usage in IT outsourcing partnerships", Information Systems Research, Vol. 19 No. 2, pp. 126-143.
Sabherwal, R. (1999), "The role of trust in outsourced IS development projects", Communications of the ACM, Vol. 42 No. 2, pp. 80-87.
Sabherwal, R. (2003), "The evolution of coordination in outsourced software development projects: a comparison of client and vendor perspectives", Information and Organization, Vol. 13 No. 3, pp. 153-202.
Saunders, C., Gebelt, M. and Hu, Q. (1997), "Achieving success in information systems outsourcing", California Management Review, Vol. 39 No. 2, pp. 63-79.
Schermann, M., Dongus, K., Yetton, P. and Krcmar, H. (2016), "The role of transaction cost economics in information technology outsourcing research: a meta-analysis of the choice of contract type", Journal of Strategic Information Systems, Vol. 25 No. 1, pp. 32-48.
Sia, S.K., Koh, C. and Tan, C.X. (2008), "Strategic maneuvers for outsourcing flexibility: an empirical assessment", Decision Sciences, Vol. 39 No. 3, pp. 407-443.
Sommerville, I. (2000), Software Engineering, Addison-Wesley, Reading, MA.
Tadelis, S. (2002), "Complexity, flexibility, and the make-or-buy decision", American Economic Review, Vol. 92 No. 2, pp. 433-437.
Whang, S. (1992), "Contracting for software development", Management Science, Vol. 38 No. 3, pp. 307-324.
Williamson, O.E. (1985), The Economic Institutions of Capitalism, Free Press, New York, NY.
Yap, C.S., Lim, Y.M., Jalaludin, F.W. and Lee, T.H. (2016), "Determinants of ICT outsourcing among the locally-owned manufacturers in Malaysia", Strategic Outsourcing: An International Journal, Vol. 9 No. 3, pp. 324-342.
Zhu, K., Kraemer, K.L. and Dedrick, J. (2004), "Information technology payoff in e-business environments: an international perspective on value creation of e-business in the financial services industry", Journal of Management Information Systems, Vol. 21 No. 1, pp. 17-54.
Supplementary materials

subset: commoncrawl


text:
Squats for Boxing
When it comes to excess weight teaching for boxing, no other one exercising has designed as a lot of a apparent variance in my boxing as significant squats. When I very first started boxing I experienced come from a long time of fat instruction and had a respectable volume of dimensions and toughness. Regrettably for my top at 5'7″ weighing 177lbs was not going to place me in an useful position to get fights. On my quest to drop weight and get myself down to 165lbs for the middleweight I abandoned most excess weight instruction and trapped to cardio, thrust-ups, burpees, ab do the job, and of study course boxing itself. It took me about 4 months to little by little get to my sought after fat, by the time I was there I felt wonderful and seriously gentle. The funny matter was that even however I had sharpened my procedure, my electric power on a one shot experienced taken a severe nosedive. I don't forget at very first really remaining equipped to transfer fellas again with the jab, and I could toss a appropriate hook to the physique that would echo all through the gymnasium. I did not get worried about it much too much at the time, my techniques had gotten improved and I believed that getting rid of ability was just a organic part of dropping fat and becoming additional exact with approach.
It was not right up until I went to the health and fitness center with a buddy just one working day about 2 years later on that I re-released myself to squats and deadlifts. I could not believe how weak I had turn out to be, it was a strike to the moi that my energy experienced pretty much slash in fifty percent. I manufactured it my mission to get my strength again in the essential lifts (squat, deadlift, and bench push). Soon after about a 6 weeks of steady function most of my power commenced to arrive again, especially in the squat exactly where I used to be able to do 4-6 reps at 315lbs (3 plates on each individual side).
I sparred later on that weak to prep a man for the approaching Provincials, and just after the 2nd round the mentor came all-around to my side of the ring and whispered to me, "hey choose it simple, he claims you're hitting much too tough." What!? I laughed to myself, I'm hitting way too tough!? I hadn't listened to that in a extended time, and especially from a male at this amount. But he was on to something, I noticed I wasn't finding pushed close to as much in the ring, I could maintain my stance, block pictures and then toss with much more sound balance. It also turned straightforward and all-natural to reduced my levels to get under pictures and rip to the entire body. I uncovered myself transitioning and stopping and starting with relative ease. Fundamentally my legs were carrying me close to like it was nothing at all. I hadn't felt this solid because I started out, but now I experienced total arsenal of methods to go with my new uncovered energy.
There is certainly generally the issue of no matter whether excess weight instruction slows you down, my perception is that it does not and can in point speed you up. Nonetheless, introducing far too much weight can sluggish you down inevitably and it can take additional operate on the section of the heart and lungs to guidance that pounds. My information to you from sensible knowledge is to just take squats critically and construct up as a great deal power and energy as you can in this exercising. Check out how substantially much more sound and agile you turn out to be in the ring.


text:
DAYTONA NEWS-JOURNAL / SEARCH: 600 N Atlantic Avenue Daytona Beach, FL 32118
- 1 baths
- $47,900 price
- 1056188 mls id
- Square Feet: 372 sqft
- Neighborhood: Not In Subdivision
- Status: Active
: PARADISE on the worlds' most famous beach... Income earning condotel just waiting for you! All of the amenities are here...restaurant to wedding planning...spa and conference rooms Even a dedicated office area. Unit is in the rental program Owner can stay a total of 60 days while the unit makes income the rest of the time. Just bring your bathing suit and toothbrush..
Courtesy of: Beach Towne Brokers
Office Phone: (386) 588-9897
Listing Agent: Colleen Pearson
Updated: 2nd December, 2019 4:22 PM.
600 N Atlantic Avenue Daytona Beach, FL
Real Estate | Daytona News-Journal Powered by Placester


text:
Just like Oprah I'll be featuring all my seasonal favourites and how you can bring them straight to your closet.
Spring is hopefully just around the corner so here are my picks for some fabulous pieces courtesy of J.Crew!
Simply click the link and you'll be redirected to the retailer.


text:
Is amd64 the same as x64?
Of course, Intel didn't want to build AMD64 CPUs, so they used the name Intel 64 for that exact same architecture when they copied it. The most neutral name for this architecture is x86-64 (or x86_64), which is sometimes shortened to x64. Microsoft and Oracle tend to use x64 as it is neutral, short and simple.
What is the meaning of amd64?
The AMD64 or x86-64 or x64 is a 64-bit processor architecture invented by AMD. AMD64 is designed to enable simultaneous 32- and 64-bit computing with no degradation in performance.
What is an instruction set architecture?An instruction set architecture (ISA) is an abstract model of a computer. It is also referred to as architecture or computer architecture. A realization of an ISA is called an implementation. An ISA defines everything a machine language programmer needs to know in order to program a computer.
Why is it called x86 and not x32?x86 refers to the processors that followed Intel's 8086 microprocessor. After this one, you had 80186, 80286 and then the 80386, the first one with 32-bits addressing on the family. So the name x86 is not related to the amount of bits of addressable memory.
What does Intel 64 mean?Definition of: Intel 64. Intel 64. A 64-bit upgrade to Intel's 32-bit x86 (IA-32) architecture. Originally designated as EM64T (Extended Memory 64 Technology), Intel 64 added a set of 64-bit instructions that were compatible with AMD's 64-bit instructions (see AMD64).
Can I run amd64 on Intel?
If you are using a 64-bit computer, you will download the amd64 version, regardless what brand of CPU you are using. If you are wondering, a 64-bit computer can run the i386 (32-bit) version of Ubuntu as well. It is just that you are not utilizing your computer to the maximum.
Which one is better x64 or x86?If you use it on a 64bit operating system you will run into limitations such as the processor not being able to access all 4GB+ of ram. The same goes for using a x64 on a 32bit. It will function fine but it is not being used up too it's full potential. Basically, x86 = 32bit(>3.5GB RAM), x64 = 64bit(4GB RAM+).
Is a PI 32 or 64 bit?Raspberry Pi 3 has 64-bit CPU, but 32-bit Raspbian OS (for now) [Updated: Mar. 7] — The Raspberry Pi 3 may have 64-bit CPU, but for now its default Linux OS remains at 32 bits. To ease backward compatibility, the SoC is architecturally quite similar to the BCM2836 of the year-old, quad-core Cortex-A7 Raspberry Pi 2.
Can you upgrade from 32 bit to 64 bit?Use the Windows key + I keyboard shortcut to open the Settings app. Under System type, you will see two pieces of information: if it says 32-bit operating system, x64-based processor, then it means that your PC is running a 32-bit version of Windows 10 on a 64-bit processor.
What is win amd64?
AMD64" is the name for the 64-bit instruction set the x64 Windows is runs on. It just happens to be AMD who invented the 64-bit x86 instruction set, which Intel copied later on.
What does it mean x86?The programs in x86 run normally on a 32 bit microprocessor and run in compatibility mode(Downscaled Instruction-set) in processors having x64 or simply 64 bit Instruction set architecture.
Why do I have program files x86?32 bit application are installed in Program Files (x86) but native 64-bit application run in the "normal" Program Files folder. The x86 version is there for backwards compatibility so that you can run 32bit applications on a 64bit OS. So you need both folders and shouldn't "eighty-six" any of them.
What is the steam in education?STEAM is an educational approach to learning that uses Science, Technology, Engineering, the Arts and Mathematics as access points for guiding student inquiry, dialogue, and critical thinking.
Updated: 2nd October 2019