Difference between revisions of "Acquisition"

Revision as of 20:25, 31 August 2015

1 Introduction

As indicated earlier in the <a href="http://eitbokwiki.org/Change_Initiatives">Change Initiatives</a> chapter of this book, there are many reasons to consider outsourcing, including potentially reducing costs or avoiding capital expenditures, speed to market, resource flexibility, and a lack of internal expertise. Outsourcing is called Acquisition. Acquisition may involve hardware components, hardware systems, software components, software systems, or any combination of hardware and software, up and including turnkey systems.

Acquisition is the process of obtaining a system, product, or service and ensuring its successful implementation, whether the supplies or services already exist or must be created, developed, demonstrated, and evaluated (ISO/IEC/IEEE 12207:2008 and ISO/IEC/IEEE15288:2008. ). Acquisition also includes ensuring that proper mechanisms are in place to monitor the supplier’s/vendors’ performance in providing support and fulfilling other contractual obligations.

The first task, already accomplished in the EIT planning stage(s), was to do the analysis necessary to determine if acquisition of a needed product or service is preferable to creating it in-house. This is often called a “buy or build” decision. It also provides information about acquisition options (outsourcing models), contracting for acquisitions, resource management, and key elements to be accounted for in implementing the acquisition. The “buy or build” decision is made after strategic direction has been set, during the definition of change initiative projects. An acquisition requires a project of its own, which may be embedded in a larger project.

Generally, this EITBOK assumes that the Build/Buy decision will have been made during the definition of Change Initiatives in Chapter 3. This chapter focuses on the ensuing activities to implement a “Buy” decision. This chapter provides an overview of key activities associated with acquisition including determining whether an enterprise should purchase or build a solution in-house, planning for the acquisition, selecting the type of solution, and contracting for the solution.

After an organization has analyzed the need for a system and decided to acquire it rather than develop it in-house, acquisition planning begins. The acquisition strategy includes a description of what needs to be acquired as well as estimated implementation timeframe and cost. It also includes a plan for whether the acquirer, the supplier, or a third party will be operating and maintaining the system.

During the planning phase, the acquiring organization lays out the activities it must perform to acquire the system. It also further refines the system requirements, including performance, functional, and nonfunctional requirements. It also considers the desired parameters for the contract with the supplier. As with requirements in other contexts, performance requirements specify technical attributes for the system (such as response time or processor speed), functional requirements identify what the system should do, and nonfunctional requirements stipulate certain quality attributes (such as reliability or maintainability). Contractual requirements lay out the respective responsibilities of the supplier and the acquirer, as well as costs and schedules, bonus conditions and penalty conditions.

2 Goals and Guiding Principles

These are the goals of acquisition:

• To ensure that any decision to acquire a technology component or solution is most appropriate in the situation at hand
• To ensure that a provider is selected by evaluating its capabilities against the project’s most salient criteria
• To ensure that the conditions of acquisition appropriately provide for its successful implementation and support

These are the principles that guide effective acquisition:

1. Best Value for Purpose: The acquired solution should fulfill the requirements. Often, though, the technical allure of “bells and whistles” tempt the acquirer to buy more than needed.
2. Fairness, Integrity and Transparency: The contract should be fair to both parties, and should provide adequate mechanisms for each party to track the other’s compliance with the contract. Each should avoid practices intended to take undue advantage of others or the system.
3. Importance of Effective Competition: Effective competition exists when two or more competing offerings are judged solely on their merits, and they acting solely on their own behalf, without collusion.
4. Separation of duties to attain checks and balances: Both the acquirer and the supplier should ensure that no conflicts of interest on either side skews the acquisition process.
5. Environmental Consideration: Many ITC organizations are becoming increasingly conscious of the impact of their purchasing decisions on the environment, as well as the rising costs of energy consumption.

3 Context Diagram

add image

4 Analysis of Acquisition Feasibility

Various analysis techniques are used to evaluate the feasibility of a particular solution option. In this sense, analysis is a careful, formal assessment of how things stand today, with the objective of making good decisions about how to move forward.

4.1 Definitions of Requirements and Customer Needs

System requirements are discussed in detail in the Requirements chapter of this book. All of the considerations presented in that chapter apply when acquisition is being considered.

Security should especially be a major consideration from the beginning of any acquisition project. In order to do due diligence with regard to assuring security in acquired products and services, it is sometimes necessary to perform an audit of a proposed vendor/supplier’s facilities and work processes. See Chapter 5 on security for more information specific to security.

In order for any acquisition effort to be successful, it is imperative that the enterprise’s and project’s requirements and constraints be well understood by these parties:

1. Person(s) writing the Request for a Proposal or Request for a Bid
2. Vendor evaluator(s)
3. Contract writers
4. Vendors
5. Bidders

4.2 Candidate Tools/Products

A detailed business case produced during the Build/Buy decision process will provide a reasonable idea of the magnitude of the project. In addition, the Business Impact analysis provides an indication of constraints that the selected vendor must accommodate. Both of these inputs need to be considered in devising the framework for evaluating vendors.

By scanning the vendor environment, it’s possible to come up with a list of candidate tools, products, or service providers. One common way to narrow down the list of possible vendors is to create an evaluation matrix. One axis contains the most salient requirements that have been identified. The other axis lists the vendors. As the vendors’ capabilities are discovered, the matrix is filled in, either with +/- to indicate presence or absence, or with a numerical value to indicate how strongly a condition (requirement) is satisfied.

4.3 Analysis of Alternatives

Requirements can be of several types (e.g., customer requirements, product requirements, product component requirements), and each type can address functional and nonfunctional considerations. That said, it is always possible that what the “buyer” (the enterprise or a particular department) says is needed is not actually needed — but they want it. When faced with this type of situation, use the Analysis of Alternatives techniques to focus on the mission that the desired procurement is meant to serve. That often helps eliminate unnecessary frills.

Alternatives must be considered when enhancing a project or program as life-cycle costs and risks — as well as the ultimate goals of the project or program — are considered. This is called analysis of alternatives (AoA). The U.S. Air Force’s. Analysis of Alternative (AoA) Handbook is one source for more information on the AoA method.

The AoA has several objectives:

1. Qualify and refine alternatives
2. Refine criteria requirements culled from input documents
3. Refine evaluation matrix/criteria
4. Work to gain consensus
5. Reduce uncertainty about the qualifications of vendors and their products
6. Result in the choice of an alternative

AoA requires consideration of important feasibility factors, such as technology maturity, integration risk, manufacturing feasibility, and, where necessary, supplier maturation (including reliability of performance). It should consider such factors as threat scenarios, operating environment, operations concept, measures of performance, and life-cycle costs.

4.4 Reference Architectures

A reference architecture is used to guide and constrain instantiation of a solution architecture. In its broadest sense, an organization’s reference architecture is the technology infrastructure that is already in place, that the new solution must fit into. Thus, the reference architecture presents a set of operational requirements and constraints that must be taken into consideration in evaluating vendors’ products.

Reference architectures emphasize commonality, providing a shared vocabulary and a template solution in a particular domain. A technical reference architecture provides a basis for ensuring consistency and applicability of technology within an enterprise. It usually displays the functions and application programming interfaces (APIs) in use, as well as an indication of functions outside the scope of the particular architecture. It provides the framework for a family of software systems, and may include hardware components.

The Zachman Framework for defining an enterprise, TOGAF, and DoDAF are common architectures currently used by the ITC community; however, many (perhaps most) organizations have evolved their own reference architectures over time. When contemplating acquisition of a new capability, it is essential to understand how the proposed capability will be integrated into the existing framework.

4.5 Risks and Constraints

Risk is the probability of damage, injury, liability, loss or any other negative occurrence. It has two vectors: degree of probability that it will occur, and degree of damage it will cause if it occurs. Selecting any outside vendor involves evaluating the risks that the vendor and the vendor’s technology bring to the acquiring organization.

Elements of risk — risk factors — associated with each vendor and productshould be identified in advance, before the project starts, and can be reduced or contained by appropriate project management planning. Here are some common elements of risk

• Lack of vendor track record
• Vendor track record of not delivering on time
• Vendor product stability
• Overstated product capability

When risk factors are recognized in advance, they can be managed. Options for managing them can be evaluated, and the most appropriate options can be selected. There are four approaches to risk management:

• Avoidance (also called elimination) — Removing the risk factor. This may mean eliminating the alternative.
• Control (also called reduction) — Reducing the chances that the risk factor will have an impact or reducing the impacts. For example, the acquirer may require certain types of testing and results that meet predefined limits.
• Transference — Transferring the exposure to the vendor. It is common to transfer the financial consequences of loss exposure by imposing penalties if deadlines are not met, for example.
• Retention — Retaining a loss exposure means accepting (rather than transferring) the consequences if the loss occurs. This is usually accomplished by a form of self-insurance — setting aside a contingency reserve (a budget reserve or schedule buffer) to be used, if needed. In addition, it can involve establishing backup in-house skills or vendor skills that can perform any needed corrective work.

Risks should not be confused with constraints. A constraint, on the other hand, is something known (or at least knowable) that imposes a restriction. Constraints can include available resources, deadlines, organizational issues, and access to persons knowledgeable about the specific applications involved. They are boundaries to the “space” you are allocated to operate in when defining the specifications for an acquisition.

4.6 Procurement Policies and Procedures

ITC procurement activities are bounded by enterprise policies and procedures. These activities involve both strategic and administrative responsibilities, and they cross many organizational boundaries. In order to make sure that each department plays by the same rules in handling procurements and doesn’t break any laws or financial restrictions, an organization usually creates policies about what approvals are necessary for purchases along with the financial limits of signature authorities. In addition, policies control the creation and management of requests for quotations (RFQs), requests for proposals (RFPs), requests for information (RFI) and managing supplier relationships. Day-to-day tasks may include conducting market research, negotiating pricing, establishing terms and conditions for services, resolving invoice discrepancies and communicating the status of purchases with internal customers.

5 Acquisition Strategy and Outsourcing Models

An organization’s acquisition strategy often drives the selection and use of outsourcing models. The acquisition strategy serves as a roadmap for the acquisition portion of the investment life cycle. It describes the overall approach for acquiring the capabilities needed to fulfill the objectives established in strategic planning and the definition of change initiatives.

5.1 Commonly Used Resource Options

The subsections below describe several commonly used outsourcing options. Each option carries its own risks, and each requires the acquiring organization to manage the vendor to ensure that it meets its contractual obligations. Whichever sourcing strategy an organization chooses should leave room for negotiations between the acquirer and the supplier.

5.1.1 Software as a Service (SaaS)

When an acquiring organization subscribes to a SaaS solution, the supplier provides remote access to a software-intensive ITC product on a subscription basis. While this seems the simplest approach, it requires a lot of research to make sure that the service work well within the built ITC environment, for example, that it can “talk” to all relevant in-house systems and share information as needed. It also requires very careful development of a contract, to ensure that up-time and other quality attributes are provided.

5.1.2 Turnkey

In many ways, this really is the simplest solution. In its ideal form, a turnkey solution arrives ready to be smoothly inserted into current business processes. This approach assumes business and operational readiness to receive and implement the solution. The question of whose responsibility it is to get the customer ready to use the solution is often an open issue. The acquisition strategy must therefore include assignment of responsibilities for assuring business and operational readiness to accept the new capability, and for installation, verification and validation, and cut-over. (See the chapter on Transition for more information.) The strategy must also address maintenance and defect issues.

5.1.3 Single Vendor

The single vendor approach is just what it sounds like — one vendor supplies the desired system or service to the acquiring organization. While this approach can reduce risk and confusion, it may not provide the most cost-effective or richly featured solution. However, when it does meet all the requirements of the solution and of the contractual framework, this can be an ideal situation.

An inherent danger of single vendor acquisitions is that the acquiring organization is often susceptible to becoming too “comfortable” with that vendor, because the vendor may have become too comfortably embedded in the enterprise’s operations, its present environment, and its long-term goals. Familiarity with a vendor can lead to subsequent selections of the same vendor, because it seems a much lower career risk to the ICT managers who are responsible for the decision. The result of familiarity is often that newer and improved products and services are overlooked.

5.1.4 Multiple Vendors

In the multiple vendors approach, an organization combines products and services from a blend of external providers to meet its needs. While this approach can seem most cost-effective, managing a spider web environment of multiple vendors can be challenging, especially when multiple vendors have to be managed and multiple pieces of an acquisition need to be updated to stay in sync. It leads to extra work for enterprise ICT organization. Here are some examples:

• Matching vendor capabilities to the other vendors correctly.
• Managing each vendor’s contract.
• Accommodating differing schedules for updates.
• Getting bug ownership clarified and injecting bug fixes from multiple sources, and can lead to confusion for customers and inconsistent quality of service delivery.
• In addition, this acquisition strategy may necessitate a provision for collecting data from the various vendor system components and creating a centralized repository.

5.2 Procurement

The processes used in establishing and managing contracts with third-party service providers have become fairly standardized, especially across larger buying organizations, and include the documents described below. It is important to ask for — and check — references. The same format for each of these should be sent to prospective vendors, so that they can be compared more easily:

• Request for Information (RFI): This is a request for more information about a given product or service. The vendor comparison matrix that lists the requirements for the intended solution can be used to formulate the request.
• Request for Quote (RFQ) (also called Invitation for Bid): This is used to invite potential suppliers into a bidding process for a specific product or service. It generally follows the RFI, but if sufficient information exists to create a detailed RFQ, the RFI may be skipped.
• Request for Tenders (RFT): Like the RFQ, this invites qualified suppliers or contractors to submit sealed bids for supplying specific and clearly defined goods or services during a specified timeframe.
• Request for Proposal (RFP): This is used in sealed-bid procurement procedures, advising potential suppliers of these factors:
  
  • Scope of work (a statement of work)
  • Description of goods and services to be procured
  • Sufficient specifications to enable an accurate bid
  • Required schedules or timelines
  • Contract type (cost-plus, fixed fee, etc.)
  • Supporting data requirements
  • Contract terms and conditions
  • General criteria used in evaluation procedure
  • Instructions for preparing and submitting technical, management, and cost proposals
  RFPs are publicly advertised and suppliers respond with a detailed proposal, not with only a price quotation. They provide for negotiations after sealed proposals are opened, and the award of contract may not necessarily go to the lowest bidder.

For links to examples for each of these, read more at http://www.businessdictionary.com/.

Organizational infrastructure and negotiation skills are needed to effectively implement these processes. The ICT organization may not have the necessary skills internally to write the requests or evaluate the responses, and so should work with the corporate services that do have the skills and experience, assuming that they are available. If such resources are not available, careful research into these procurement instruments is required.

6 Contracting

A contract is an agreement between a supplier (seller) and an acquirer (buyer). At a minimum, the contract for the final selection must include specification for the following items, and should mirror any statement of work used in previous communication with the vendor:

• Bill of Materials (BOM) — A list and description of exactly what will be delivered.
• Supplier Management — A description of exactly how and by whom the supplier will be managed.
• Invoice Management — A specification of when and how invoices will be received, tracked, and paid.

Here are some additional considerations for framing a contract to acquire products, components, or services:

• Ownership of delivered Intellectual Property, Technology and Methods
  While ownership of the IP that has produced items that are procured off-the shelf retain the makers’ copyrights and trademarks unless stipulated otherwise, items that are created specifically for the contract are “work for hire” and thus their associated IP belongs to the acquirer. Physical items that are purchased belong to the acquirer, but items that are leased belong to the supplier. It is important to define in the contract where ownership will reside at contract completion.
• Identification of Changes and change Management
  While alterations should, in general, be minimized, any known changes or extensions required with regard to the vendor-supplied components, such as APIs, user interfaces, or equipment tolerances, should be specified. Any changes that are identified during the project should be subject to the acquirer’s normal change management processes, both financial and technical. If changes are required to the existing infrastructure, the acquirer’s change control board should be included in the approval process.
• Identification of Software and Hardware Integration Concerns
  The acquiring organization should identify at least two potential critical issues that could arise when integrating vendor software at the contract level, to ensure that these areas are monitored throughout the process.
• Identification of Integration Concerns
  The contract should explicitly identify all interface requirements between the vendor-provided business application and the existing organizational infrastructure.
• Identification of Data Needs
  The process for moving data out of an old system and into the acquired new system should also be clearly outlined in the contract. Requirements for data exchange with other systems should be clearly defined.
• Provision for Rollback
  If things don’t go as expected, it’s important to have a provision for rollback, or returning the system to a previously defined state.
• Communication Strategy and Planning
  The contract should explicitly explain how communications regarding the project will work, including who is the single point of contact (SPOC) for the supplier and the SPOC for the acquirer, as well as when specific communications (e.g., monthly performance reports) must occur.
• Coordinating Delivery Schedules with Business/ ICT Schedules
  It is important to coordinate delivery schedules with business/ ICT schedules with integrated project delivery approaches. See the chapters on transition and retirement for more information.
• Handoff to Receiving Organization(s)
  When the supplier moves the responsibility for the system to the acquirer (the Enterprise ICT organization), the process is called handover or handoff. It is also often called transition. The terms and conditions of the handover should be clearly specified in the contract. See Chapter 11 on transition for more detail.
  Handoff to the receiving organization must have the agreement of the receiver that the system is acceptable for use and meets the terms of the contract. See Chapter 11 on transition for more detail. Contract considerations include:
  
  • Verification of Implementation against Requirements and Contractual Obligations
    When the solution has been delivered, it must be measured against the contract to verify that everything has been done and done properly. This contract quality surveillance is the responsibility of the acquiring organization in most cases, as it will be most familiar with the requirement and implementation details.
  • Issue Resolution and Responsiveness to Issues
    Although bug fixes may be the most typical support need, other types of errors also need to be accounted for, such as requirements, architectural, or design flaws. The contract must specify how problem reports are handled. See Chapter 12 on sustainment for more information on this subject.
  • System, Product, or Service Acceptance
    Acceptance is the stage of initial development wherein the system, product, or service is actually put into production and runs real business functions. During this phase, the solution is monitored to ascertain whether it meets the original business requirements and objective and whether it functions according to expectations, as well as to assess its reliability, fault tolerance, and freedom from vulnerabilities.
• System, Product, or Service Follow-on
  No solution lasts forever — even during acquisition, it is important to plan for maintenance, upgrades, and ultimately retirement and replacement. The contract should specify the supplier’s responsibilities for service after acceptance, if the contract is for products. REspponsiblitilels can include update/refresh schedules, notification of new capabilities, etc. For more information about the activities involved, see Chapter 12 on sustainment and Chapter 14 on retirement.
• Resource Management
  Eventually the supplier will transfer the product or service to the acquiring organization. The acquisition plan needs to address what the supplier’s obligations are for providing resources during the transition to operation and what responsibilities lie with the acquirer. Refer to Chapter 11 on transition for more detail.
  Resource management as it pertains to acquisition activities addresses such issues as:
  
  • how the necessary technical knowledge needed to operate and maintain the system is transferred to the Enterprise ICT organization personnel.
  • how any necessary workforce development (employee training, certification, etc.) is achieved
  • ensuring that required processes are in place to support internal ownership of the acquired system
  The teams who receive the new solution, including operations and maintenance personnel, need to be trained on its use and any tools needed for support, and on the processes to be used to support and maintain the system. The contract should provide for appropriate education and training for impacted staff. It should also specify the problem reporting, problem resolution, and contract monitoring processes that will be used. It is critical to the efficacy of the acquisition to monitor contractor performance to ensure that the supplier remains accountable for performing as specified (or better) in the contract.

7 Summary

Acquisition is a multi-faceted activity that occurs after a Build vs. Buy decision has been made. The acquisition process entails all the management activities required in any project. In other words, each acquisition of an ICT product and services solution requires its own project. It requires understanding the business problem to be solved, or the opportunity to be captured, architecting a solution, managing its implementation and delivery, and assuring its fitness for use.

In addition to the management activities required when developing an in-house solution, acquisition requires expertise in contract definition, negotiation with vendors, vendor management, and analysis of risks beyond those associated with in-house development.

8 Important Skills

• Information systems co-ordination
• Enterprise & business architecture development
• Business risk management
• Solution architecture
• Data management
• Stakeholder relationship management
• Change implementation planning & management
• Project management
• Systems development management
• Testing
• Systems integration
• Financial management for ICT
• Problem management
• Procurement
• Supplier relationship management
• Contract management

9 Key Roles

• Product manager
• Architecture team
• Solution manager
• [Organizational] Change manager
• Procurement manager
• Service portfolio manager
• Service strategy manager
• Service owner

10 Standards

Relevant Standards (can pull from reference list when complete)