International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 1

ISSN 2229-5518

Outsourcing and Acquisition Models Comparison Related to IT Supplier Selection Decision Analysis

Lucas Grossi, Jose A. Calvo-Manzano

Abstract— This paper presents a comparison of acquisition models related to decision analysis of IT supplier selection. The main standards are: Capability Maturity Model Integration for Acquisition (CMMI-ACQ), ISO / IEC 12207 Information Technology / Software Life Cycle Processes, IEEE 1062 Recommended Practice for Software Acquisition, the IT Infrastructure Library (ITIL) and the Project Management Body of Knowledge (PMBOK) guide. The objective of this paper is to compare the previous models to find the advantages and disadvantages of them for the future development of a decision model for IT supplier selection.

Index Terms— Acquisition Models, Decision Analysis, Outsourcing, Supplier Selection.

——————————  ——————————

INTRODUCTION

T supplier selection is a complex and opaque decision problem. Managers facing a decision about IT supplier selection have difficulty in framing what needs to be thought about further in their discourses. Framing is one of the most crucial steps of decision making and needs to be
assisted to better understand a decision situation [2].
In the past few years IT outsourcing has gained a lot of im- portance in the market and, e.g., the IT services outsourcing market is still growing every year. Outsourcing as a concept gained common acceptance in the 1980s and today is still used to describe “a contractual relationship with a specialized outside service provider for work traditionally done in- house”[5].
Trend analysts such as Morgan & Chambers [13] and IDC [10] predict annual growth figures of approximately 10%. IDC is of the opinion that customers in USA will increase their outsourcing spending from 2011 as the economy revives and expects spending for these services to reach an estimated $57 billion by 2014 [6]. Aarkstore Enterprise predicts annual spend on outsourcing will exceed $700 billion globally by
2013 [1].
Talking in financial terms, Byrne et al. [3] claimed that global outsourcing in the electronic industry was set to rise from $138 billion in 2003 to $294 billion by 2008, giving an indication of the importance and growth rate of this sector.
Although the popularity of information technology (IT)

————————————————

 Lucas Grossi is currently pursuing PhD degree program in computer science in Universidad Politécnica de Madrid, Spain, 28660. E-mail: lgc- grossi@gmail.com

 Jose A. Calvo-Manzano is currently an assistant professor at Universidad Politécnica de Madrid, Spain, 28660. E-mail: joseanto- nio.calvomanzano@upm.es

outsourcing has grown over the last two decades, many out- sourcing arrangements do not last. According to a study of SEI (Software Engineering Institute) [15], 20 to 25 percent of large information technology (IT) acquisition projects fail within two years and 50 percent fail within five years. Mis- management, poor requirements definition, lack of compre- hensive evaluations, which can be used to come up with the best candidates for outsourcing, inadequate supplier selec- tion and contracting processes, insufficient technology selec- tion procedures, and uncontrolled requirements changes are factors that contribute to project failure. The majority of pro- ject failures could be avoided if the acquirer learns how to understand the decision problems, make better decision analysis, and good judgment [15].
A major reason for the failure of the outsourcing relation- ship is that top executives in highly competitive IT-intensive industries are discovering that IT infrastructure is, in fact, a competitive asset. Hence, a bad decision in selecting a suppli- er could generate poor service, price and relationship be- tween acquirer and supplier [8], which will end in the failure of the outsourcing relationship. When the contract is finished because of the failure, the next action is backsource or switch supplier, which according to Dorothy [8] is not possible with- out cost and risk. Due to the return of employees, assets, and knowledge into firm, switching cost can be significant, and the estimation of the cost of backsource for example, is usual- ly between 2% and 15% of the annual cost of a contract [8].
The decision making process of selecting an IT supplier is very important to increase the success rate of an outsourcing relationship and tends to be an important topic. This paper presents a comparison of outsourcing and acquisition models that will act as a basis for a future development of an IT sup- plier selection decision model.
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 2

ISSN 2229-5518

2 OUTSOURCING AND ACQUISITION MODELS

The main standards are: Capability Maturity Model Integra- tion for Acquisition (CMMI-ACQ) [15], ISO / IEC 12207 In- formation Technology / Software Life Cycle Processes [17], IEEE 1062 Recommended Practice for Software Acquisition [9], the IT Infrastructure Library (ITIL) [4] and the Project Management Body of Knowledge (PMBOK) guide [14]. Each model has a different nomenclature, which is showed in Table
1. The elements that will be compared in each acquisition model are represented in bold.

TABLE 1

NOMENCLATURE OF THE ACQUISITION MODELS ELEMENTS

Models Nomenclature

CMMI Process area -> specific practice

TABLE 2

PROCESSES AREAS SUMMARY

PA Abbr. ML Agreement Management AM 2

Acquisition Requirements Development ARD 2

Configuration Management CM 2

Measurement and Analysis MA 2

Project Monitoring and Control PMC 2

Project Planning PP 2

Process and Product Quality Assurance PPQA 2

Requirements Management REQM 2

Solicitation and Supplier Agreement Development SSAD 2

Acquisition Technical Management ATM 3

Acquisition Validation AVAL 3

Acquisition Verification AVER 3

ISO/IEC

12207

Process group -> life cycle process ->

activity > task

Decision Analysis and Resolution DAR 3

Integrated Project Management IPM 3

IEEE 1062 Phases of life cycle -> step -> activity

ITIL Area -> process -> topic

PMBOK

Guide Knowledge area -> process

2.1 CMMI for Acquisition Model

The CMMI-ACQ, V1.3 model is a collection of best practices that is generated from the CMMI V1.3 Architecture and Framework. This collection includes acquisition best practic- es from government and industry. CMMI-ACQ is based on the CMMI Model Foundation or CMF (model components com- mon to all CMMI models and constellations), the CMMI Acqui- sition Module, and the Software Acquisition Capability Ma- turity Model (SA-CMM).
Table 2 provides a list of CMMI-ACQ process areas and their associated abbreviations and maturity levels. The pro- cesses shaded in the table are the ones related to decision analysis of IT outsourcing supplier selection.

Organizational Process Definition OPD 3

Organizational Process Focus OPF 3

Organizational Training OT 3

Risk Management RSKM 3

Organizational Process Performance OPP 4

Quantitative Project Management QPM 4

Causal Analysis and Resolution CAR 5

Organizational Innovation and Deployment OID 5

The following sections describe only the process areas that focus on Decision Analysis and Selection Supplier specific practices.

2.1.1 Decision Analysis and Resolution

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established cri- teria [15].
The Decision Analysis and Resolution (DAR) process area involves establishing guidelines to determine which issues should be subject to a formal evaluation process and applying formal evaluation processes to these issues.
A formal evaluation process is a structured approach to evaluating alternative solutions against established criteria to determine a recommended solution [15].
A formal evaluation process involves the following actions:
1. Establishing the criteria for evaluating alternatives.
2. Identifying alternative solutions.
3. Selecting methods for evaluating alternatives.
4. Evaluating the alternative solutions using the estab- lished criteria and methods.
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 3

ISSN 2229-5518

5. Selecting recommended solutions from the alterna- tives based on the evaluation criteria.
A repeatable criteria-based decision-making process is es- pecially important, both for making critical decisions that define and guide the acquisition process and later for critical decisions made with the selected supplier. The establishment of a formal process for decision making provides the acquirer with documentation of decision rationale. Such documenta- tion allows criteria for critical decisions to be revisited when changes or technology insertion decisions that impact re- quirements or other critical project parameters are consid- ered. A formal process also supports the communication of decisions between the acquirer and supplier. A formal evalua- tion process reduces the subjective nature of the decision and has a higher probability of selecting a solution that meets the multiple demands of relevant stakeholders [15].
Guidelines are created for deciding when to use formal evaluation processes to address unplanned issues. Guidelines often suggest using formal evaluation processes when issues are associated with medium to high risks or when issues affect the ability to achieve project objectives.
Formal evaluation processes can vary in formality, type of criteria, and methods employed. Less formal decisions can be analyzed in a few hours, use only a few criteria (e.g., effec- tiveness and cost to implement), and result in a one- or two- page report. More formal decisions may require separate plans, months of effort, meetings to develop and approve criteria, simulations, prototypes, piloting, and extensive doc- umentation.
Both numeric and non-numeric criteria can be used in a formal evaluation process. Numeric criteria use weights to reflect the relative importance of the criteria. Non-numeric criteria use a more subjective ranking scale (e.g., high, medi- um, or low). More formal decisions may require a full trade study [15].
A formal evaluation process identifies and evaluates alter- native solutions. The eventual selection of a solution may involve iterative activities of identification and evaluation. Portions of identified alternatives may be combined, emerg- ing technologies may change alternatives, and the business situation of suppliers may change during the evaluation peri- od.
A recommended alternative is accompanied by documen- tation of the selected methods, criteria, alternatives, and ra- tionale for the recommendation. The documentation is dis- tributed to relevant stakeholders; it provides a record of the formal evaluation process and rationale that are useful to other projects that encounter a similar issue.
DAR involves the following specific practices:
1. Establish Guidelines for Decision Analysis: establish and maintain guidelines to determine which issues are subject to a formal evaluation process.
2. Establish Evaluation Criteria: establish and maintain criteria for evaluating alternatives, and the relative ranking of these criteria.
3. Identify Alternative Solutions: identify alternative solu- tions to address issues.
4. Select Evaluation Methods: select evaluation methods.
5. Evaluate Alternatives: evaluate alternative solutions using established criteria and methods.
6. Select Solutions: select solutions from alternatives based on evaluation criteria.

2.1.2 Solicitation and Supplier Agreement Development

The purpose of Solicitation and Supplier Agreement Devel- opment (SSAD) is to prepare a solicitation package, select one or more suppliers to deliver the product or service, and es- tablish and maintain the supplier agreement [15].
The Solicitation and Supplier Agreement Development process area provides a set of practices that enables the ac- quirer to initialize and formalize a relationship with the sup- plier for the successful execution of the project. A supplier agreement is an agreement between the acquirer and suppli- er. This agreement may be a contract, license, or memoran- dum of agreement. The acquired product or service is deliv- ered to the acquirer from the supplier according to the sup- plier agreement.
A supplier agreement created using these practices ena- bles the acquirer to monitor and control supplier activities using other process areas, such as Project Monitoring and Control, and Agreement Management.
The practices of SSAD process area apply equally to initial supplier agreements and to subsequent change orders, task orders, or amendments related to those agreements.
The acquirer is responsible for establishing and maintain- ing ground rules for communicating with the supplier, docu- menting decisions, and resolving conflict through the life of the agreement. The acquirer facilitates these activities with relevant stakeholders. Roles and responsibilities of relevant stakeholders during the interaction with suppliers are de- fined, coordinated, and adhered to [15].
The specific goals and specific practices of this process ar- ea build on each other. The Prepare for Solicitation and Sup- plier Agreement Development specific goal and its associated specific practices identify potential suppliers and develop and distribute the solicitation package, including evaluation crite- ria and the statement of work. The solicitation package is developed using work products from other process areas
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 4

ISSN 2229-5518

(e.g., requirements and design constraints from Acquisition Requirements Development, supplier project and technical measures and objectives from Project Planning, and Meas- urement and Analysis).
The Select Suppliers specific goal and its associated specif- ic practices use work products from the preparation of the solicitation to solicit responses from potential suppliers, evaluate these responses, negotiate with potential suppliers, and select a supplier who can best deliver.
Subsequently, the Establish Supplier Agreements specific goal and its associated specific practices are used to establish and maintain the supplier agreement. In turn, data provided by the supplier and documented in the supplier agreement (e.g., cost, schedule, risks) are used by Project Planning prac- tices to update the project plan.
The SSAD involves three specific goals, but in this work DAR will be applied just on specific goal 2, Select Supplier, then the following specific practices will be explained:
1. Evaluate Proposed Solutions: evaluate proposed solu- tions according to documented proposal evaluation criteria.
2. Establish Negotiation Plans: establish and maintain ne- gotiation plans to use in completing a supplier agree- ment.
3. Select Suppliers: select suppliers based on an evalua- tion of their ability to meet specified requirements and established criteria.

2.2 ISO/IEC 12207 Information Technology/Software

Life Cycle Processes

ISO/IEC 12207 establishes a common framework for soft- ware life cycle processes, with well defined terminology, that can be referenced by the software industry. It contains pro- cesses, activities, and tasks that are to be applied during the acquisition of a software product or service and during the supply, development, operation, maintenance and disposal of software products and the software portion of a system, whether performed internally or externally to an organiza- tion [17].
The purpose of ISO/IEC 12207 is to provide a defined set of processes to facilitate communication among acquirers, suppliers and other stakeholders in the life cycle of a software product. It is written for acquirers of systems and software products and services and for suppliers, developers, opera- tors, maintainers, managers, quality assurance managers, and users of software products [17].
ISO/IEC 12207 groups the activities that may be per- formed during the life cycle of a software system into seven process groups. Each of the life cycle processes within these groups is described in terms of its purpose and desired out-
comes and lists activities and tasks which need to be per- formed to achieve these outcomes.
1. Agreement Processes — two processes.
2. Organizational Project-Enabling Processes — five pro- cesses.
3. Project Processes — seven processes.
4. Technical Processes — eleven processes.
5. Software Implementation Processes — seven process- es.
6. Software Support Processes — eight processes.
7. Software Reuse Processes — three processes.
The purposes and outcomes of the life cycle processes con- stitute a Process Reference Model. These life cycles process groups are introduced below and depicted in Figure 1. The life cycle process related to IT outsourcing supplier selection decision is highlighted in the picture.

Figure 1 - Life cycle process group

The following section describes only the life cycle process- es that focus on decision analysis.of IT outsourcing supplier selection.

2.2.1 Acquistion Process

The purpose of the Acquisition Process is to obtain the prod- uct and/or service that satisfies the need expressed by the acquirer. The process begins with the identification of cus- tomer needs and ends with the acceptance of the product and/or service needed by the acquirer.
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 5

ISSN 2229-5518

As a result of successful implementation of the Acquisition
Process:
1. Acquisition needs, goals, product and/or service ac- ceptance criteria and acquisition strategies are de- fined.
2. An agreement is developed that clearly expresses the expectation, responsibilities and liabilities of both the acquirer and the supplier.
3. One or more suppliers is selected.
4. A product and/or service is acquired that satisfies
the acquirer’s stated need.
5. The acquisition is monitored so that specified con- straints such as cost, schedule and quality are met.
6. Supplier deliverables are accepted.
7. Any identified open items have a satisfactory conclu- sion as agreed to by the acquirer and the supplier.
Then, the acquirer shall implement the following activities in accordance with applicable organizational policies and procedures with respect to the Acquisition Process:
1. Acquisition Preparation - This activity consists of the following tasks:
1.1. The acquirer begins the acquisition process by de- scribing a concept or a need to acquire, develop, or enhance a system, software product or software service.
1.2. The acquirer shall define and analyze the system re- quirements. The system requirements should in- clude business, organizational and user as well as safety, security, and other criticality requirements along with related design, testing, and compliance standards and procedures.
1.3. The acquirer may perform the definition and analysis of software requirements by itself or may retain a supplier to perform this task.
1.4. If the acquirer retains a supplier to perform system or software requirements analysis, the acquirer shall retain approval authority for the analyzed re- quirements.
1.5. The acquirer shall consider options for acquisition against analysis of appropriate criteria to include risk, cost and benefits for each option. Options in- clude: a) purchase an off-the-shelf software product that satisfies the requirements; b) develop the soft- ware product or obtain the software service inter- nally; c) develop the software product or obtain the software service through contract; d) a combination
of a, b, and c above; e) enhance an existing software product or service.
1.6. When an off-the-shelf software product is to be ac- quired, the acquirer shall ensure the following con- ditions are satisfied: a) the requirements for the software product are satisfied; b) the required doc- umentation is available; c) proprietary, usage, own- ership, warranty and licensing rights are satisfied; d) future support for the software product is planned.
1.7. The acquirer should prepare, document and execute an acquisition plan. The plan should contain the fol- lowing: a) requirements for the system; b) planned employment of the system; c) type of contract to be employed; d) responsibilities of the organizations involved; e) support concept to be used; f) risks considered as well as methods to manage the risks.
1.8. The acquirer shall define and document the ac- ceptance strategy and conditions (criteria).
1.9. The acquirer should document the acquisition re- quirements (e.g., request for proposal), the content of which depends upon the acquisition option se- lected. The acquisition documentation should in- clude, as appropriate: a) system requirements; b) scope statement; c) instructions for bidders; d) list of software products; e) terms and conditions; f) control of subcontracts; g) technical constraints (e.g., target environment).
1.10. The acquirer should determine which processes of this International Standard are appropriate for the acquisition and specify any acquirer requirements for tailoring those processes. The acquirer should specify if any of the processes are to be performed by parties other than the supplier, so that suppliers may, in their proposals, define their approach to supporting the work of other parties. The acquirer shall define the scope of those tasks that reference the contract.
1.11. The acquisition documentation shall also define the contract milestones at which the supplier's progress shall be reviewed and audited as part of monitoring the acquisition.
1.12. The acquisition requirements should be given to the organization selected for performing the acquisition activities.
2. Acquisition Advertisement - This activity consists of the following task:
2.1. The acquirer shall communicate the request for the supply of a product or service to identified suppli- ers.
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 6

ISSN 2229-5518

3. Supplier Selection - This activity consists of the following tasks:
3.1. The acquirer should establish a procedure for sup- plier selection including proposal evaluation criteria and requirements compliance weighting.
3.2. The acquirer should select a supplier based upon the evaluation of the suppliers' proposals, capabilities, and in accordance with the acquirer's acceptance strategy and conditions.
4. Contract Agreement - This activity consists of the follow- ing tasks:
4.1. The acquirer may involve other parties, including po- tential suppliers or any necessary third parties (such as regulators), before contract award, in de- termining the acquirer’s requirements for tailoring of this International Standard for the project. In making this determination, the acquirer shall con- sider the effect of the tailoring requirements upon the supplier’s organizationally-adopted processes. The acquirer shall include or reference the tailoring requirements in the contract.
4.2. The acquirer shall then prepare and negotiate a con- tract with the supplier that addresses the acquisi- tion requirements, including the cost and schedule, of the software product or service to be delivered. The contract shall address proprietary, usage, own- ership, warranty and licensing rights associated with the reusable off-the-shelf software products.
4.3. Once the contract is underway, the acquirer shall control changes to the contract through negotiation with the supplier as part of a change control mecha- nism. Changes to the contract shall be investigated for impact on project plans, costs, benefits, quality, and schedule.
5. Agreement Monitoring - This activity consists of the fol- lowing tasks:
5.1. The acquirer shall monitor the supplier's activities in accordance with the Software Review Process (clause 7.2.6) and the Software Audit Process (clause 7.2.7). The acquirer should supplement the monitoring with the Software Verification Process (clause 7.2.4) and the Software Validation Process (clause 7.2.5) as needed.
5.2. The acquirer shall cooperate with the supplier to provide all necessary information in a timely man- ner and resolve all pending items.
6. Acquirer Acceptance - This activity consists of the follow- ing tasks:
6.1. The acquirer should prepare for acceptance based on the defined acceptance strategy and criteria. The preparation of test cases, test data, test procedures, and test environment should be included. The extent of supplier involvement should be defined.
6.2. The acquirer shall conduct acceptance review and acceptance testing of the deliverable software prod- uct or service and shall accept it from the supplier when all acceptance conditions are satisfied.
6.3. After acceptance, the acquirer should take the re- sponsibility for the configuration management of the delivered software product.
7. Closure – This activity consists of the following tasks:
7.1. The acquirer shall make payment or provide other agreed consideration to the supplier for the product or service rendered.

2.2.2 Decision Management Process

The purpose of the Decision Management Process is to select the most beneficial course of project action where alterna- tives exist. This process responds to a request for a decision encountered during the system life cycle, whatever its nature or source, in order to reach specified, desirable or optimized outcomes. Alternative actions are analyzed and a course of action selected and directed. Decisions and their rationale are recorded to support future decision-making [17].
As a result of the successful implementation of the Deci- sion Management Process:
1. A decision-making strategy is defined.
2. Alternative courses of action are defined.
3. A preferred course of action is selected.
4. The resolution, decision rationale and assumptions are captured and reported.
Then, the project shall implement the following activities and tasks in accordance with applicable organization policies and procedures with respect to the Decision Management Process:
1. Decision Planning - This activity consists of the follow- ing tasks:
1.1. The project shall define a decision-making strate- gy. This includes identifying decision categories and a prioritization scheme, and identifying re- sponsible parties. The decision makers are identi- fied and given the responsibility and authority to make decisions. Decisions may arise as a result of an effectiveness assessment, a technical trade-off, a problem needing to be solved, action needed as a response to risk exceeding the acceptable
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 7

ISSN 2229-5518

threshold, a new opportunity or approval for pro- ject progression to the next life cycle stage. A de- cision-making strategy includes the identification and allocation of responsibility for, and authority to make, decisions.
1.2. The project shall involve relevant parties in the decision-making in order to draw on experience and knowledge.
1.3. The project shall identify the circumstances and need for a decision. This includes record, catego- rize and promptly and objectively report prob- lems or opportunities and the alternative courses of action that will resolve their outcome.
2. Decision Analysis - This activity consists of the follow- ing tasks:
2.1. The project shall select and declare the decision- making strategy for each decision situation. The project shall identify desired outcomes and measurable success criteria.
2.2. The project shall evaluate the balance of conse- quences of alternative actions, using the defined decision-making strategy, to arrive at an optimi- zation of, or an improvement in, an identified de- cision situation.
3. Decision Tracking - This activity consists of the follow- ing tasks:
3.1. The project shall record, track, evaluate and report decision outcomes to confirm that problems have been effectively resolved, adverse trends have been reversed and advantage has been taken of opportu- nities.
3.2. The project shall maintain records of problems and opportunities and their disposition, as stipulated in agreements or organizational procedures and in a manner that permits auditing and learning from ex- perience.

2.3 IEEE 1062 Recommended Practice for Software

Acquisition

IEEE 1062 is a recommended practice for performing soft- ware acquisitions. It describes a set of useful quality practices that can be selected and applied during one or more steps in a software acquisition process. Each organization using it will need to identify the classes of software to which it applies and the specific quality characteristics and activities that need to be included within the acquisition process [9].
The software acquisition life cycle represents the period of time that begins with the decision to acquire a software product and ends when the product is no longer available for use. It typically includes a planning phase, contracting phase, product implementation phase, product acceptance phase,
and follow-on phase. These phases and their key milestones are [9]:
1. Planning phase. This phase begins when the idea or need is established for acquiring software and ends when the request for proposal (RFP) is released.
2. Contracting phase. After the RFP is released, this phase includes activities necessary to ensure that the suppli- er’s products and services can satisfy the acquirer’s quality criteria before signing the contract.
3. Product implementation phase. This phase covers the period from contract signing until the software prod- uct has been received. A key activity is monitoring the supplier’s efforts to ensure that all work and mile- stones are satisfactorily completed prior to delivery of the software product.
4. Product acceptance phase. This phase includes all ac- tivities necessary to evaluate, test, and accept the software product. It begins when the software product is received and ends when the product is accepted.
5. Follow-on phase. After the software product is accept- ed, this phase includes using the product to meet the acquirer’s objectives and evaluating user satisfaction with the software product, its documentation, and support provided from the supplier. This phase con- tinues until all provisions provided in the contract have been completed or until the software product is no longer available for use.
Each of these phases and their key milestones are summa- rized in Table 3. A special feature of this table includes a list- ing of the software acquisition process steps associated with each life cycle phase. The processes related to decision analy- sis of IT outsourcing supplier selection are highlighted in the table.
The following section describes only the steps that focus on decision analysis of IT outsourcing supplier selection of the software acquisition life cycle.
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 8

ISSN 2229-5518

TABLE 3

SOFTWARE ACQUISITION PHASE MILESTONES

2.3.1 Identifying Potential Suppliers

There are five steps that one needs to do when identifying potential suppliers [9]:
1. Gather information on available software products: in- formation should be gathered about available software products. For fully developed software development, the suppliers with MOTS software should be consid- ered. Information may be obtained from sources such as trade publications, consultants, suppliers, and user groups.
2. Evaluate software during a demonstration: it describes to the supplier what the intended use of the software product is, and ask that the demonstration include the intended use. Suppliers like to demonstrate the soft- ware at their own facility or at a customer site. This demonstration provides insight into how well the software functions, how screen displays and reports are generated by the system, how file processing is
handled, and how users can interact with the system. A potential acquirer may find it helpful to review the supplier’s documentation before the demonstration. How well the software matches the documentation may be assessed during the demonstration. However, the acquirer may prefer to have the supplier run the demonstration at a site of the acquirer’s choosing and with the acquirer’s test data. If this is not possible, ex- isting users should be contacted to obtain insight from their experience in using the product or in dealing with the supplier.
3. Survey users of the supplier’s software: one indicator of the quality and effectiveness of a software product is the number of satisfied companies currently using the software. Users can provide information on volume throughput planning and system degradation, and im- portant insights on correcting software failures. The nature, quality, speed, and reliability of maintenance may be determined by exploring other us- ers’ experiences. The following should be considered:
1)Establishing functional and performance require- ments; 2) Evaluating software product against the above; 3) Evaluating the adequacy of the development process including the activities of quality assurance, configuration management, verification and valida- tion, reliability measurement, documentation, and maintenance.
4. Review performance data from previous contracts: if software has been previously acquired from any of the potential candidates, it would be helpful to review per- formance data on each supplier from previous con- tracts and to determine user satisfaction with the software and supplier support.
5. Survey several supplier’s offerings: survey suppli- ers’ offerings, evaluating their capability to provide quality software products and services, and identify any limitations and liabilities in meeting the organiza- tion’s objectives. After evaluating the suppliers on the basis of their answers to the following elements: fi- nancial soundness, experience and capabilities, devel- opment and control processes, technical assistance, quality practices, maintenance service, product usage, product warranty, costs, and contracts, the best two or three candidates to receive the RFP should then be chosen. Each candidate should conduct a demonstra- tion and provide formal proposals with detailed cost estimates as input to the final decision.

2.3.2 Evaluating Proposals and Selecting Supplier

The objective is to ensure that a skilled and responsible sup- plier is selected. The supplier qualification and selection pro- cess is established as a part of the software acquisition pro- cess and includes, as a minimum, the following activities:
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 9

ISSN 2229-5518

1. Evaluate supplier proposal: 1) use the evaluation crite- ria established in the acquirer’s proposal evaluation standards to review supplier’s responsiveness to the software requirements, deliverables, and software support requirements described in the RFP. Consider the supplier’s management qualifications, technical approach, quality assurance program, and proposed cost estimate; 2) consider any results observed during supplier demonstrations at the supplier’s site or the acquirer’s site, and supplier facility visits; 3) deter- mine for whom the supplier has produced work. Solic- it comments from the supplier’s prior customers; 4) costs should be compared to other supplier’s prices and schedules. Caution should be exercised when the supplier’s proposed costs are much higher or lower than the average of all costs received; 5) suppliers that are not completely responsive to the requirements in the RFP should be eliminated from further considera- tion.
2. Visit supplier facilities: 1) during the proposal evalua- tion period, visit supplier facilities to investigate and evaluate various factors, including financial position, technical capability, experience, and quality practices;
2) determine whether or not the supplier’s staff has experience with the required languages and with the software and hardware to be used during develop- ment. Review CV (curriculum vitae) of personnel who would be assigned to the project. Conduct interviews if needed; 3) determine whether any changes are under consideration that might impact the progress of the development project, i.e., changes in organization, moving of supplier offices, or change in ownership.
3. Select a qualified supplier: summarize the results achieved from supplier evaluations, demonstrations, and visits to supplier facilities and compare the results against the proposal evaluation standards. Select a qualified supplier from the best two or three candi- dates and begin negotiations.
4. Negotiate the contract: since this activity is more re- lated to outsourcing contract engineering, then it is not going to be specified here.

2.4 The IT Infrastructure Library (ITIL)

The ITIL library has the following components:
1. The ITIL Core – best practice guidance applicable to all types of organizations who provide services to a busi- ness.
2. The ITIL Complementary Guidance – a complementary set of publications with guidance specific to industry sectors, organization types, operating models and technology architectures.
The ITIL Core consists of five areas (Figure 2). Each area provides the guidance necessary for an integrated approach, as required by the ISO/IEC 20000 standard specification. The area related to IT outsourcing supplier selection decision analysis is highlighted in the figure.

Figure 2 - ITIL core

The ITIL for Service Design forms part of the overall ITIL Service Management practices and covers the design of ap- propriate and innovative IT services to meet current and future agreed business requirements. It describes the princi- ples of Service Design and looks at identifying, defining and aligning the IT solution with the business requirements. It also introduces the concept of the Service Design Package and looks at selecting the appropriate Service Design model.
It is important that the right interfaces and links to the de- sign activities exist. When designing new or changed services, it is vital that the entire Service Lifecycle and IT Service Man- agement (ITSM) processes are involved from the outset. Of- ten difficulties occur in operations when a newly designed service is handed over for live running at the last minute. The following are actions that need to be undertaken from the outset of a Service Design to ensure that solution meets the requirements of the business [4]:
 The new service solution should be added to the over- all Service Portfolio from the concept phase, and the Service Portfolio should be updated to reflect the cur- rent status through any incremental or iterative de- velopment. This will be beneficial not only from the fi- nancial perspective, but also from all other areas dur- ing design.
 As a part of the initial service/system analysis, there will be need to understand the Service Level Require- ments (SLRs) for the service when it goes live.
 From the SLRs, the Capacity Management team can model this within the current infrastructure to ascer- tain if this will be able to support the new service. If
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 10

ISSN 2229-5518

time allows, the results from the modeling activities can be built into the Capacity Plan.
 If new infrastructure is required for the new service, or extended support, Financial Management will need to be involved to set the budget.
 An initial Business Impact Analysis and risk assess- ment should be conducted on services well before im- plementation as invaluable input into IT Service Con- tinuity Strategy, Availability Design and Capacity Planning.
 The Service Desk will need to make aware of new ser- vices well in advance of live operation to prepare and train Service Desk staff and potentially IT customer staff.
 Service Transition can start planning the implementa- tion and build into the change schedule.
 Supplier Management will need to be involved if pro- curement is required for the new service.
Inside the ITIL for Service Design, the area related to deci- sion analysis of IT outsourcing supplier selection is the sup- plier management process, which will be explained in the next section.

2.4.1 Supplier Management Process

The Supplier Management process ensures that suppliers and the services they provide are managed to support IT service targets and business expectations. The aim of this section is to raise awareness of the business context of working with partners and suppliers, and how this work can best be di- rected toward realizing business benefit for the organization.
It is essential that Supplier Management process and plan- ning are involved in all stages of the Service Lifecycle, from strategy and design, through transition and operation, to improvement. The complex business demands require the complete breadth of skills and capability to support provision of a comprehensive set of IT services to a business, therefore the use of value networks and the suppliers and the services they provide are an integral part of any end-to-end solution. Suppliers and the management of suppliers and partners are essential to the provision of quality IT services.
The purpose of the Supplier Management process is to ob- tain value for money from suppliers and to ensure that sup- pliers perform to the targets contained within their contracts and agreements, while conforming to all of the terms and conditions [4].
The Supplier Management process should include:
 Implementation and enforcement of the supplier poli- cy.
 Maintenance of a Supplier and Contract Database
(SCD).
 Supplier and contract categorization and risk assess- ment.
 Supplier and contract evaluation and selection.
 Development, negotiation and agreement of contracts.
 Contract review, renewal and termination.
 Management of suppliers and supplier performance.
 Agreement and implementation of service and suppli- er improvement plans.
 Maintenance of standard contracts, terms and condi- tions.
 Management of contractual dispute resolution.
 Management of sub-contracted suppliers.
It is possible to see, most of the topics included in the sup- plier management process are related to contract manage- ment, but one, supplier and contract evaluation and selection, contains topics related to Decision Analysis, since it includes the decision process of selecting the best supplier for the acquirer.
The activities associated with the identification of business needs and the subsequent evaluation of new suppliers and contracts are part of the “Evaluation of new Suppliers and Contracts” activity. The outputs from this area provide the inputs to all other stages of the contract lifecycle. IT is vital to the ongoing success of the contract and the relationship that the business is closely involved in all aspects of these activi- ties. Every organization should have templates and a formal method for the production of business case and their approv- al and sign-off. The detailing of the business needs and the content of the business case should be agreed, approved and signed off by both the business and IT.

2.5 Project Management Body of Knowledge

(PMBOK) Guide

The PMBOK guide is intended to provide a common lexicon within the profession and practice for talking and writing about project management. Project management is a relative- ly young profession, and while there is substantial commonal- ity around what is done, there is relatively little commonality in the terms used.
Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accomplished through the use of the processes such as: initiating, planning, execut- ing, controlling, and closing. The project team manages the work of the projects, and the work typically involves:
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 11

ISSN 2229-5518

 Competing demands for: scope, time, cost, risk, and quality.
 Stakeholders with differing needs and expectations.
 Identified requirements.

2.5.1 Project Management Knowledge Areas

The Project Management Knowledge Areas describes project management knowledge and practice in terms of their com- ponent processes. These processes have been organized into nine knowledge areas, as described below and as illustrated in Figure 3. The knowledge area that focus on decision analy- sis of IT outsourcing supplier selection is highlighted in that figure, and will be explained in the next section.

Figure 3 - Overview of project management knowledge areas and project management processes [14]

2.5.2 Project Procurement Management

Project Procurement Management includes the processes required to acquire goods and services, to attain project scope, from outside the performing organization. For simplic- ity, goods and services, whether one or many, will generally be referred to as a product. It contains the following major processes:
 Procurement Planning: determining what to procure and when.
 Solicitation Planning: documenting product requirements and identifying potential sources.
 Solicitation: obtaining quotations, bids, offers, or pro- posals, as appropriate.
 Source Selection: choosing from among potential suppli- ers.
 Contract Administration: managing the relationship with the supplier.
 Contract Closeout: completion and settlement of the con- tract, including resolution of any open items.
These processes interact with each other and with the pro- cesses in the other knowledge areas as well. Each process may involve effort from one or more individuals or groups of individuals, based on the needs of the project. Although the processes are presented here as discrete elements with well- defined interfaces, in practice they may overlap and interact in ways not detailed here.
Project Procurement Management is discussed from the perspective of the acquirer in the acquirer-supplier relation- ship. The acquirer-supplier relationship can exist at many levels on one project.
The supplier will typically manage its work as a project. In such cases:
 The acquirer becomes the customer, and is thus a key stakeholder for the supplier.
 The supplier’s project management team must be con- cerned with all the processes of project management, not just with those of this knowledge area.
 The terms and conditions of the contract become a key input to many of the supplier’s processes. The contract may actually contain the input (e.g., major delivera- bles, key milestones, cost objectives), or it may limit the project team’s options (e.g., acquirer approval of staffing decisions is often required on design projects).
The first four processes will be discussed here, since the last two (contract administration and contract closeout) are more related to contract management.

Procurement Planning

Procurement planning is the process of identifying which project needs can be best met by procuring products or ser- vices outside the project organization and should be accom- plished during the scope definition effort. It involves consid- eration of whether to procure, how to procure, what to pro- cure, how much to procure, and when to procure.
When the project obtains products and services (project scope) from outside the performing organization, the pro- cesses from solicitation planning through contract closeout would be performed once for each product or service item. The project management team may want to seek support from specialists in the disciplines of contracting and pro- curement when needed, and involve them early in the pro- cess as a member of the project team.
When the project does not obtain products and services from outside the performing organization, the processes from solicitation planning through contract close-out would not be performed.
Procurement planning should also include consideration of potential suppliers, particularly if the acquirer wishes to ex-
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 12

ISSN 2229-5518

ercise some degree of influence or control over contracting decisions.

Inputs Tools and Techniques Outputs

singly or in combination. For example, a weighting sys- tem may be used to:
 Select a single source who will be asked to sign a

1. Scope statement

2. Product description

3. Procurement resources

4. Market conditions

5. Other planning outputs

6. Constraints

7. Assumptions

1. Make or buy analysis

2. Expert judgments

3. Contract type selection

1. Procurement management plan

2. Statement(s) work

standard contract.
 Rank order all proposals to establish a negotiating se- quence.
On major procurement items, this process may be repeat-

Figure 4 - Procurement planning process [14]

Solicitation Planning

Solicitation planning involves preparing the documents needed to support solicitation.

ed. A short list of qualified suppliers may be selected based on a preliminary proposal, and then a more detailed evaluation will be conducted based on a more detailed and comprehen- sive proposal.

Inputs Tools and Techniques Outputs

1. Proposals

2. Evaluation criteria

3. Organizational policies

1. Contract negotiation

2. Weighting system

3. Screening system

1. Contract

1. Procurement management plan

2. Statement(s) work

3. Other planning outputs

1. Standard forms

2. Expert judgments

1. Procurement documents

2. Evaluation criteria

3. Statement of work updates

4. Independent estimates

Figure 7 - Source selection process [14]

Figure 5 - Solicitation planning process [14]

Solicitation

Solicitation involves obtaining responses (bids and pro- posals) from prospective suppliers on how project needs can be met. Most of the actual effort in this process is expended by the prospective suppliers, normally at no cost to the pro- ject.

Inputs Tools and Techniques Outputs

3 OUTSOURCING AND ACQUISITION MODELS

COMPARISON

The previous models provide a set of guides and/or best practices focusing on Decision Analysis, but that only shows “what to do” from an abstract level, without the “how to do”. Hence, if an IT company needs to apply one of these models, it will need to analyze each of them, plan and develop a solution for their purpose, which leads to a big effort for the company.
Table 4 shows the comparison between the models ana-

1. Procuremnt documents

2. Qualified seller lists

1. Bidders conferences

2. Advertising

1. Proposals

lyzed in this work. It contains the name of the models in the first row at top right and right below, the name of the process of this model related to decision analysis/supplier selection. The criteria used to analyze each model are presented in the first column and for each criteria two aspects was analyzed,

Figure 6 - Solicitation process [14]

Source Selection

Source selection involves the receipt of bids or proposals and the application of the evaluation criteria to select a pro- vider. Many factors aside from cost or price may need to be evaluated in the source selection decision process.
 Price may be the primary determinant for an off-the- shelf item, but the lowest proposed price may not be the lowest cost if the supplier proves unable to deliver the product in a timely manner.
 Proposals are often separated into technical (ap- proach) and commercial (price) sections with each evaluated separately.
 Multiple sources may be required for critical products.
The tools and techniques described here may be used
the “what to do” and “how to do”. If a criterion is presented in the model analyzed and it shows an explanation of “what to do”, an “x” is marked in the table. The same idea is used for the “how to do” column.
The development of the criteria was based on an analysis of all acquisition models. Each part of the acquisition models related to decision analysis/supplier selection was read and during the reading a list of criteria was created, if a criterion appears for the first time in the analysis of the acquisition models, it was added to this list. The final list is the one pre- sented in the first column of Table 4.
The first disadvantage that is possible to see in Table 4 is that IEEE 1062 model does not contain a specific name for its part concerning decision analysis/supplier selection.
According to [14, 15, 17], it is important that the decision making/selection supplier process include a planning part. Then, IEEE 1062 has another disadvantage here, since it does
IJSER © 2012 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 3, Issue 11, November-2012 13

ISSN 2229-5518

not contain any of the decision planning criteria. PMBOK Guide showed to be the most complete in this step.

TABLE 4

COMPARISON BETWEEN MODEL

CMMI- ACQ (DAR)

ISO/IEC

12207 (DMP)

IEEE

1062

ITIL for Service Design (SMP)

PMBOK Guide (PMP)

Propose d Model

Step

Criteria

What to do

How to do

What to do

How to do

What to do

How to do

What to do

How to do

What to do

How to do

What to do

How to do

Decision

Planning

Establish guidelines for when to use a formal evaluation process

Decision

Planning

Incorporate the use of guidelines into de defined process as apropriate

Decision

Planning

Identify responsible parties (experts)