To gain significant potential for cost reduction and efficient management, one strategy is to identify a standard pricing model and associate it with agreement types. Some of these types include firm fixed-price contracts, fixed-price incentive contracts, cost-plus incentive-fee contracts, and cost-plus award-fee contracts. Each agreement type offers benefits and drawbacks. You should document your rationale for choosing an agreement type, including consideration of risk and risk distribution between the acquirer and the supplier. Matt comments on this topic in the executive meeting.

Your acquisition strategy describes any incentive structure for the project and outlines how the structure encourages the supplier to provide the technology solution at or below cost objectives while meeting schedule and quality objectives. Your strategy also defines how you approach the terms and conditions of the supplier agreement and any business decisions that deviate from your standard terms and conditions.

Your acquisition strategy identifies how the technology solution will be supported during its projected life span, and who will support it. Defining these types of handoffs includes how you will transfer ownership to the customer after the product or service is delivered. Matt explains the need to look at how the system will be managed after deployment.

The meeting agenda turns to personnel questions, and Steve speaks up to tell the team a story.

Every acquisition project is subject to external and internal factors that create risks for the acquirer. Strategies and plans must account for and deal with these risks in a manner that maximizes the likelihood of success. Matt drives that point home.

When establishing the acquisition strategy or when a project is just beginning, you need an easy way to systematically assess the business and technical risks that you can expect to encounter. One technique is to use a simple risk management scorecard to quickly and inexpensively determine whether there are any major technical or business risks that you need to manage. This scorecard can be as simple as a list of ten questions: five for technical risks and five for business risks. The idea is to assign a numerical value to each risk to arrive at a number that reflects the total risk for a project.

Technical risk is covered by five parameters:

The following parameters cover business risk:

To start, use a simple method to characterize risk; in the early stages of a project, you seldom have enough information to permit a comprehensive and detailed risk analysis. This basic risk management scorecard enables you to begin understanding your chances of achieving success.

You should also look for indicators of potential issues that might occur. Depending on how your acquisition team fills out the risk management scorecard, you may need to raise additional questions. For example, if you’ve selected a supplier that is strong in a particular technology but is only 18 months old, that should raise a red flag. You should stop and consider this a risk. Remember that you must assess and manage all risks, even those that are ultimately assigned to the supplier to manage.

In general, most project failures are caused by business risk. This is not because acquisition organizations are less competent than their suppliers, but rather because business risk is a much tougher problem than technical risk. Technical risk is governed by the laws of science, which do not change very often. In contrast, managing business risk means reflecting the uncertainties of what may be a diverse group of stakeholders. These people may have differing needs, they may have trouble expressing these needs, and their needs may change over time. This makes business risk a more formidable challenge than technical risk.

The need for early and aggressive detection of risk is compounded by the inherent complexity of the acquirer-supplier relationship. Examples of such risks include the acquirer’s capabilities, the supplier’s experience of working with the acquirer, the supplier’s financial stability, or the adoption of well-defined dispute resolution processes.

At our executive meeting, Steve clarifies how he has handled business risks in the past.

Matt supports Steve and adds his own viewpoint.

Renegotiation of agreements is another business risk that Steve wants to mention.

Matt nods in agreement.

Additional risks associated with working with suppliers abound. For example, there are risks associated with geographic separation between acquirer personnel and supplier personnel. Other risks are the cultural gap between you and your suppliers’ organizations, and the limitations of the communications and transmission systems between the two. Having remote suppliers can expose geopolitical risks, sovereignty risk, and exchange rate risk.

This by no means implies that technical risks are easy to address. Technical risks are rooted in the complexity of the solutions you need. In the past, for some IT solutions, all that was needed was a mainframe and a database; this limited the complexity and the number of components that could fail. With the proliferation of technology over the past 10 to 20 years, an application may have separate databases, a data warehouse, Web servers, customizable user interfaces, application code servers, wide area and local area networks, and routers, among other infrastructures. Now there are many more potential points of failure, and this risk becomes even more challenging as new technologies continue to proliferate.

Many technical risks stem from inadequate resources to accomplish required tasks, sometimes fostered by imprecise estimates of the work required to complete the project.

Steve comments on the challenges of technical risks and obsolescence.

Matt knows exactly what Steve is talking about.

Steve laughs but then gets a somber look.

Incorrect estimates can stem from poorly defined tasks, from excessive optimism, or from adjustments made by management. Some suppliers deliberately lowball their estimates to get the contract and then worry later how to execute it.

Your acquisition strategy initially identifies the risks associated with an acquisition. Then you plan your approach based on those risks. As the project progresses toward selecting a supplier, the risks specific to the supplier’s technical and management approach become important. These risks particularly lie in the supplier’s capability to meet contractual requirements, including schedules and cost targets.

The CMMI-ACQ provides specific recommendations on how to develop and maintain a business and technical management framework, a strategy for planning, directing, contracting for, and managing an acquisition project or program (see Table 2-1).

The acquisition strategy results from a thorough understanding of both the specific acquisition project and the general acquisition environment (Table 2-1, practice 1.1). You identify the capabilities and objectives that the acquisition is intended to meet. Typically, the capabilities documented in the acquisition strategy highlight the characteristics of the target technology solution. The strategy also identifies dependencies or interoperability requirements for planned or existing capabilities of other technology solutions in your intended environment.

The acquisition strategy also establishes planned milestone decision points and acquisition phases. It prescribes the accomplishments for each phase and identifies the critical events affecting project management. Schedule parameters include, at a minimum, the projected dates for project initiation, other major decision points, and initial operational capability.

Moreover, your acquisition strategy defines the acquisition approach that the project will use to achieve full capability: whether evolutionary or single-step. The strategy should include a rationale justifying the choice. When a project uses an evolutionary acquisition approach, the acquisition strategy describes the initial capability and how it will be funded, developed, tested, produced, and supported. The acquisition strategy previews similar planning for subsequent increments or spirals and identifies the approach used to integrate or retrofit earlier increments with later increments.

The acquisition strategy also describes how risk is to be handled, identifies major risks, and documents which risks are to be shared with the supplier and which risks are to be retained by the acquirer. Standardized procurement documents (for example, standard supplier agreements) are yet another ingredient of an acquisition strategy. The acquirer determines the type of supplier agreement planned for acquiring the technology solution (for example, firm fixed-price; fixed-price incentive; cost-plus incentive fee; and cost-plus award fee) and the reasons it is suitable, including considerations of risk assessment and reasonable risk sharing by the acquirer and the supplier.

The acquisition strategy also explains the planned incentive structure for the acquisition and describes how it gives the supplier an incentive to provide the product or services at or below the established cost objectives and to satisfy the schedule and key performance objectives. If more than one incentive is planned for a supplier agreement, the acquisition strategy explains how the incentives complement each other without overlapping. The acquisition strategy identifies any unusual terms and conditions of the planned supplier agreement and all existing or contemplated deviations to an organization’s terms and conditions, if any.

Finally, the acquirer develops a strategy for supporting the acquired technology solution as part of the acquisition strategy. The support strategy addresses how the acquirer has planning to support the fielded technology solution throughout its life.

Typically, you develop two WBSs for an acquisition project: an acquirer overall project WBS and a supplier WBS. The scope of the acquirer WBS is the entire project or program, including work performed by your employees as well as the products and services acquired from the supplier. Your overall project WBS clearly identifies which elements are acquired, and which are the result of your internal efforts. This WBS includes activities performed by you as well as milestones and deliverables for the suppliers.

From an acquirer’s point of view, the acquirer’s WBS tends to be much more focused on the project life cycle, whereas the supplier WBS is typically structured around the deliverables. The supplier WBS defines the structure to be used by the supplier in reporting costs and progress. The supplier milestones and deliverables are typically associated with payments if the supplier meets the milestone or deliverable acceptance criteria. Usually, the acquirer defines the WBS only to two or three levels of detail, as depicted in Table 2-2. Suppliers often expand these WBS elements into deeper levels of detail to suit their project management and delivery processes and procedures.

Creating the WBS helps you in developing estimates for the project work, including high-level estimates of the work to be done by suppliers. If you don’t have any estimates, you risk making the wrong decisions for the right reasons. In any case, the organization runs the risk of suboptimizing the project and any associated projects by removing the wrong items from the scope or looking only at the short term and sacrificing long-term opportunities.

Often when engineers look at quality, cost, and schedule for programs and projects, optimism takes over. There is a strong tendency to overcommit. As a result, every estimate covers only 50 percent of what is truly involved to meet the commitment. This is like “management by rebate”; everything is half-off.

When an organization understands and recognizes this tendency, it has taken the first step toward correcting the behavior. Acquirers are always eager to put technology in place, because they know it has the potential of making the organization more efficient and thus more profitable. A specific technology may be deployed only once in an organization, but the supplier may have packaged, implemented, and configured this particular solution a hundred times before, especially if it is a COTS product. As an acquirer, you must reenergize the supplier with your excitement about the pending technology solution as if the supplier were implementing it for the first time. You must work to form a cohesive team and at the same time leverage the fact that the supplier has done this a number of times.

Acquirers tend to use estimation models and tools that they are comfortable with—unfortunately, in some cases, whether or not the models and tools support the acquisition modus operandi. Most of the time, the models or tools in use are more appropriate for in-house work, and therefore they’re not calibrated for outsourcing technology solutions. Historically, they tend to take a very “insourced” view of delivering technology solutions.

Matt recognizes this at both the project and the organizational level as the acquisition strategy for this latest project is being developed. To correct this, he requires the project managers to come together and build an estimation model that takes outsourcing into account.

Matt also asks to see the operating model and requires that it include personnel and associated skills. And finally, he wants an overall risk assessment of the outsourcing engagement, including such elements as how the company’s skills and maturity will help or hinder this approach, as well as recommendations for mitigating any organizational issues that might arise.

Although Steve believes that this is a “mission impossible” task, he is up for the challenge. By the time he is finished, he has talked to key leaders and collected their input through a series of workshops and personal interviews. One need he has identified is the need for global reach. Other needs include the following:

All the leadership team members agree that upon closer analysis it is short-sighted to move to outsourcing or change the mix of internal to external resources because it is in vogue, or simply because it might potentially reduce costs; instead, they have worked to make sure that outsourcing is a fit for the organization by ensuring that the organization can continue to meet its stated goals and objectives.

Steve works with the finance staff to build an “as-is” cost and resource model, and for the first time he has a detailed handle on which expenditures are truly technology-related. He also has the first draft of an operating model in the anticipated outsourced environment. He calls a meeting, inviting Matt as well as Kristin Wells and George Taylor, executives for one of the company’s key suppliers.

Kristin elaborates on this point.

Understanding and estimating the total work are critical, and so are the decisions about which life-cycle approach best delivers a technology solution. When you’re acquiring technology solutions, multiple life cycles are probably involved in a project. Your life cycle typically begins at the inception of the acquisition—a time when a need is recognized and a determination is made to address it. The life cycle extends at least until the delivery, acceptance, and commissioning of the acquired product. Sometimes, it is extended to cover acquisition of support and maintenance services after the product is fielded.

The supplier’s life cycle, in contrast, begins with the issuance of the solicitation package by the acquirer. For the successful bidder, the life cycle extends until the delivery and acceptance of the technology solution. In some cases, the supplier is also responsible for training, support, and maintenance. In other cases, training and support may be provided by independent suppliers. In such cases, you negotiate separate agreements with these suppliers and they in turn establish their own life cycles.

Matt interjects a question.

The project plan is an important communication tool, and it provides an overarching framework against which all work is accomplished. For that, the plan documents the tasks required to deliver a technology solution and to facilitate success throughout the project’s life cycle. Developing an effective project plan is a challenge in itself, and it can be even more daunting if it’s being done for the first time. Even those with advanced degrees may not have learned how to put together a comprehensive project plan for acquiring technology solutions.

It’s important to think about all the relevant facets, but it is equally important not to get bogged down with unnecessary detail early in a project. Generating a large volume of paper is definitely not the best game plan early on. Acquirers do not want to find themselves in a situation where the maintenance of the project plan and the project paper flow become as crucial as accomplishing the tasks that the project needs to complete. George Taylor speaks up.

Project plans are living documents. They contain information that is needed to understand the scope of work required and the likely structure of the project, and to determine the risk of continuing to the next phase of the acquisition project, including having a good handle on the likelihood that you’ll be able to hit the delivery date. The plan also identifies dependencies between various organizations within the acquirer and with the supplier.

Information acquired before it is needed—or, even worse, information acquired and never used—is a waste of time and money. Steve emphasizes this point.

As the project is defined—and in many cases, throughout the project—the plan is updated several times, each time increasing the level of detail and confidence that all the essential work has been covered.

The specific format of a project plan isn’t critical, but Matt highlights what is important about planning.

Senior managers in the acquisition organization are not the only people who find project plans invaluable. For technology project managers, careful preparation of a plan is an opportunity to think through all facets of a project, to examine the consequences of various approaches to deployment, operations, and financing, and to determine what human, physical, and financial resources are required. The plan facilitates error-free delivery of technology solutions and avoids the crippling expense of trial-and-error operation.

The discipline of writing a project plan can cause program or project managers and their teams to realize that (using an engineering example) the major application of a technology is not to create efficiencies in the existing product development process but instead to allow customers to directly interact with the engineering staff during product development. Then a good project manager can change the focus of the project accordingly. The successful project manager finds that the plan helps in monitoring the project’s performance. If the need arises to modify the project’s direction, the project manager can do so rapidly by adjusting the plan, getting it approved, and using it to communicate effectively to all stakeholders.

A plan typically starts with a summary, as shown in Table 2-3. For instance, it summarizes the technology solution briefly and describes the nature and current condition of the targeted business process and industry. In this way, it shows where and how the technology fits in, along with potential customers and physical locations where the technology may reside.

A section in the plan usually contains detailed information about the technology solution and highlights its distinctive features and the needs it satisfies. Diagrams and sketches are useful to clarify the project’s intent. Steve explains.

The plan also discusses in some detail the nature and size of the targeted business process and potential users. Furthermore, key financial characteristics, as well as recent trends and the growth potential of the targeted business processes, lead to initial demand estimates for the acquired product or service.

Program managers must develop enough facts to convince themselves and senior management that the business process for the acquired product or service is such that return on investment targets can be met despite competition and other factors. The business process analysis must home in on the area addressed by the technology solution. If the business process analysis lacks insight and information, the whole project plan will be vague and risky. A good business process analysis goes a long way toward creating a value-added technology solution and should be viewed as the plan’s keystone. The choice of deployment strategies, the size of the project team and support organization, and facilities are all derived from the project team’s understanding of the targeted business process.

Deployment is part of a well-conceived project plan and a prerequisite for success. A comprehensive plan details the steps necessary to penetrate the targeted business process and includes a description of the solution’s warranty as well as strategies for distribution and training. It is critical to work closely with your business partners to specify deployment objectives. These objectives should be quantifiable and measurable, and they should specify a time frame.

You set your initial deployment objectives early on when you capture ideas for transforming or improving a business process and tentatively allocate a budget for their exploration. These initial objectives are often an educated guess that you refine throughout the project’s life cycle.

The plan deployment also discusses the kinds of users who will be targeted for an initial rollout and those who will be sought for later deployments. The plan specifies methods of identifying and contacting specific potential users and lists the features that will be emphasized to support adoption of the solution by the users.

The project plan covers the nature and extent of required design and development work by the supplier. This work might include the engineering necessary to convert a prototype to a finished product, the design of special interfaces to use the product in a business process, the effort of a user interface designer to make the product more usable, or the identification and organization of people, equipment, and special techniques to implement a service.

To make all this happen, you need people, facilities, and capital equipment. Acquisition personnel carefully weigh make-or-buy decisions in terms of which parts of the technology solution will be purchased and which operations will be performed by your workers. The acquisition strategy provides clear direction for this. Work should be allocated to your employees if it matches your organization’s strategy and fits the identified core competencies. Often, it becomes a challenge for an organization when its skills and experience to support identified core competencies, such as requirements elicitation and program management, are inadequate. In this case, you might elect to contract for supplemental staff—temporary personnel who have the needed skills.

This approach allows you to move forward with a project while buying time to close the skill and experience gap with internal resources. No acquirer can afford to be exposed in one of its core competencies for too long a time. It is important that the supplemental staffing not come from the same suppliers that are providing the technology solution. Otherwise, your ability to execute might be eroded and a conflict of interest might arise.

The plan extends throughout the projected useful life of the technology solution in the acquirer’s or customer’s environment. This component of the plan is critical, because for most technology solutions the initial cost of acquiring the product is only a fraction of the total cost of ownership. The project plan shows the analysis of operations and support via cost-volume information at various levels of operation, with breakdowns of applicable material, labor, purchased components, and management overhead. It also describes the approach to quality, production, and inventory control. For example, the plan contains readiness criteria for the technology solution, the operations organization, and the support organization. Quality control and inspection procedures are important so that operations teams can minimize service problems and ensure customer satisfaction. In addition, it is important to plan how purchasing will operate during the steady use of the technology so that you have adequate materials on hand to ensure uninterrupted operations, that you have obtained the best price and payment terms, and that you have minimized in-process inventory.

The project team is the key to this success, as Matt explains.

Accordingly, every plan needs a description of the key members of the project team and their primary responsibilities.

The project plan also indicates the financial potential of the project, its return on investment, and its capital needs. The financial plan includes details of the financial commitment to operate the solution after transition from the supplier into the intended environment. When you seek funds for a project to acquire a technology solution, the organization should review the balance sheet and income statement of the affected area for the current and the two prior years. Together with the responsible business lead, you should make a financial projection for the next three years to show the impact of the proposed solution and to highlight the necessary operational financial commitments. You can then analyze this financial information to determine whether the described approach is the best use of resources, or whether there are other ways to improve customer service using the same amount of resources, to offer a new product to your customers, or to deliver more output with fewer resources. The financial analysis gives a clear understanding of the return on investment of a given project.

Every project has issues and risks, and the project plan invariably contains some implicit assumptions about them. Any risks identified during creation of the acquisition strategy should be captured in the plan. It is important that you understand and communicate negative factors that affect projects. If these factors are not identified and communicated, the credibility of the project manager is at risk and it jeopardizes any future requests for funding. On the other hand, taking the initiative to identify and discuss risks helps demonstrate that risks and issues have been anticipated and can be managed.

Not all risks are created equal. Every project must determine which are most critical to success. The project then must attempt to minimize the impact of unfavorable developments in each risk area. Together with the acquisition strategy, the risks identified in project planning form the basis for some of the criteria used in evaluating suppliers. As the project evolves, risks may be revised based on changing conditions (e.g., new circumstances during execution of the supplier agreement).

A schedule that shows the timing and dependencies of the major tasks and events such as milestones is an essential part of a project plan. In addition to a planning aid that shows critical deadlines, a well-prepared schedule can be an effective communication and management tool. Such a schedule demonstrates the ability of the project manager and the team to plan for successful delivery of a technology solution in a way that recognizes obstacles and minimizes risk.

The most elegant plan has no value without organizational commitment. Project plans should be circulated among the acquisition team members to ensure consistency, to stakeholders for review and comment, and to management for review and approval. Nevertheless, an executable plan evolves over time, as teams find alternative technologies or better ways to deliver functionality.

The CMMI-ACQ provides specific recommendations on project planning as it relates to estimation of the work for a given project, both for the work required by the acquirer and the work that is negotiated from the supplier. It also establishes the chosen life cycle, a top-level WBS, and project effort and cost (see Table 2-4).

Project planning involves developing the plan, interacting with stakeholders, obtaining commitment to the plan, and managing the plan (Table 2-4, practice 1.1). You build the acquisition plan on the acquisition strategy, which you develop by applying the processes in the Solicitation and Supplier Agreement Development process area. The plan must reflect the objectives of the acquisition as well as constraints, technologies, supplier agreement types, end user requirements, risk, and product support.

Planning focuses initially on estimates of project planning parameters. These include estimates for the work to be done by you and high-level estimates of the work to be done by the supplier.

Estimates used in putting together the initial plan will be revised later based on suppliers’ estimates in response to the proposal (Table 2-4, practices 1.2–1.4). In formulating these estimates you should consider project requirements (including any specific products or technologies), organizational requirements, and any customer requirements. The scope of the project is also important. The scope can be managed in a project plan in a number of ways, including breaking the scope into manageable, deliverable pieces by using an incremental acquisition approach. The list of deliverables, along with their complexity, has a direct impact on the schedule. When you’re converting project attributes into labor hours and costs, it’s useful to study historical data from similar projects.

The WBS delineates the work that is given to the acquirer and the work that is given to the supplier based on the acquisition strategy. The supplier work becomes the basis for the statement of work as a part of the solicitation proposal from the acquirer.

The CMMI-ACQ also provides specific recommendations for project planning as it relates to the creation of an integrated plan that manages the work of the acquirer and supplier. It also acknowledges the use of project planning to manage the solicitation and management activities for a given effort (see Table 2-5).

After project estimates are completed, the project’s budget and schedule can be finalized. The project’s budget and schedule include the efforts of the acquirer, the efforts of the supplier, and those of any supporting organizations for the duration of the project (Table 2-5, practice 2.1).

You establish major milestones to ensure the completeness of one or more deliverables. Milestones can be either event-based or calendar-based. Many schedules include durations for activities for which little or no data is available. Identifying the extent and potential impact of these assumptions gives you some insight into an overall level of confidence for the project.

Constraints in the project need to be identified as early as possible because they limit the options you will have. This is of particular importance because some of these constraints are directly related to characteristics that are used to prequalify suppliers—characteristics such as technology capabilities, processes, domain knowledge, and production capability.

Risks to the project should be identified and analyzed (Table 2-5, practice 2.2). These risks come from multiple perspectives, including acquisition, technology, management, operations, supplier agreements, industry, support, and users. Statutory and regulatory requirements also must be analyzed from a risk perspective.

Together with the acquisition strategy, risks are used as part of the basis for evaluation criteria for supplier proposals. As the project evolves, you update the risks based on any changes. Risks should be documented and managed based on their potential downside to the project.

Data management includes all the forms of documentation required to support a project (Table 2-5, practice 2.3). Data requirements should be established based on a common set of standards for the organization. Standards for data management are important for consistent, efficient management. One of the most important aspects of data in an acquisition is to specify who creates what data and how data will be shared between the acquirer and the supplier. The supplier agreement should outline any uses of data and data access rights. It’s crucial to the viability of a product’s operation that you plan for data management as the product transitions to operations.

You use initial estimates to build required project resources for the plan (Table 2-5, practices 2.4–2.8). The expansion of the WBS allows you to create a resource plan that can be tracked and managed. The plan should identify the necessary skills to execute the project based on the defined roles. The plan also identifies any critical facilities or equipment.

In addition, the CMMI-ACQ provides recommendations on project planning as it relates to capturing the specific commitments that have been made, including resources, requirements, and stakeholders (see Table 2-6).

After the plans are developed, you should review them to understand the commitments based on the estimates and compare them to the available resources (Table 2-6, practice 3.1). Then you reconcile any differences by prioritizing technical requirements, obtaining more resources, finding ways to make the execution of the project more efficient, purchasing some of the technology components, or adjusting the mix of staff skills (Table 2-6, practice 3.2). During supplier selection and negotiation, you also reconcile the planned project work with supplier proposals. Following the completion of the supplier agreement, you incorporate the supplier’s plans into the overall project plan in order to ensure alignment. This consolidation should include the agreed-to major milestones, deliverables, and reviews.

Stakeholder commitment is also obtained (Table 2-6, practice 3.3). The individual or group making the commitment should have a high level of confidence that the work can be performed within the specified cost, schedule, and performance constraints. Occasionally, provisional commitments are adequate to support initial work. You can use the WBS to manage commitments throughout the plan. Internal and external commitments should be reviewed with management as appropriate.

In a technology sourcing relationship, one of your most important decisions is which supplier to partner with, whether you are purchasing one capability or a portfolio of initiatives. It is critical to conduct research to determine the pool of capable suppliers. This may be as simple as leveraging technology research firms like Gartner or Forrester, surveying other organizations in the same industry to leverage their expertise, or submitting a request for information (RFI) to potential suppliers.

Consistent with the acquisition strategy and with the project being sourced, you develop a list of potential suppliers that can deliver the required capability. These suppliers are identified from a variety of sources, including past experience, industry analyses, and industry publications. This list should be kept to a manageable size to avoid excessive costs in managing the outsourcing efforts. Even if you typically rely on the major companies in the field, you should include an adequate number of suppliers to foster a competitive environment.

A competitive environment is valuable not only from a pricing perspective but also because it allows you to review various technology solutions and look at alternatives from the competing suppliers. Another approach is to sole-source the project if it has characteristics that warrant this action. You might choose this option if you have worked with a supplier on this project and this supplier is the most efficient builder of certain additional functionality. Another reason might be that the supplier happens to have sole access to technology that is critical to the delivery of the specified functionality.

Before you consider a supplier, it should pass certain criteria: its experience with similar projects, whether it has the critical technical resources to execute the project, and the availability of these critical resources. In addition, the supplier’s current financial status, credit status, financial stability, and access to capital need to be evaluated.

The pool of viable supplier candidates can be small. For example, if you decide to bundle products or services into one solicitation package, then there may not be a single supplier that can meet all your needs. In this case, you can identify a small group of suppliers that can work in various technology areas to deliver the desired capability. In addition, you must have the appropriate level of oversight in place to manage a multisupplier engagement, with clearly identified roles and responsibilities among the suppliers and your own personnel. You must clearly identify how the various suppliers will work with each other to deliver the solution.

Let’s return to our fictitious acquisition project. It’s time to narrow the number of suppliers for his solicitation proposals, and Matt has choices to make. He can use a “safe” set of suppliers that the company traditionally has used for the required technology solution. He can rely on these suppliers because they own the majority of the market share in this technology space and can leverage their remote development centers to get lower, blended rates for skilled labor. Another alternative is to go to the major suppliers in India and negotiate deals directly. The choice is not an easy one, because Matt has talked to people in other organizations who have gotten mixed results from using both models.

Matt and Steve have had numerous discussions about the paradigm shift of moving to an outsourcing model for new areas of technology. They’ve talked about which technology areas should continue to be executed by their own organization.

Traditionally, outsourcing has focused on big deals—those that come from billion-dollar organizations and run for years. So if you’re working in a medium-sized or small organization, you may question whether you can compete with larger companies for the same supplier resources. Do a supplier’s best technology architects always go to the biggest contracts, leaving the medium-sized or small acquirers to work with whoever is left? How can such acquirers be sure that they are getting the best resources for their money? What is the industry saying about the treatment of medium-sized or small companies in the outsourcing market?

Matt has this discussion with Kristin Wells (recall that Kristin is a senior executive at one of the suppliers Matt has worked with for a number of years). Kristin tries to assure Matt that his fears are unfounded, but he knows he must be vigilant in verifying that the resources being put in place by suppliers and the quality of the deliverables they were producing are up to snuff.

Matt smiles.

Kristin pauses for a moment.

Acquirers often notify potential suppliers that a solicitation package will be coming soon. One of the reasons for the advance notice is to determine whether the suppliers you’ve identified are interested. Given the costs of preparing proposals, it is important to determine their interest and then put appropriate nondisclosure agreements in place. You need to communicate the scope and schedule of the project (and the proposal response), the processes to be used during the proposal process, your evaluation criteria, supplier qualifications, and a date for the supplier to respond.

Most organizations can access credible information about potential suppliers through business contacts and technology knowledge management organizations (for example, Gartner or Forrester). This reduces the need to spend months on RFIs, site visits, and initial due diligence. Nevertheless, you can use success factors available from industry analysts to rank potential suppliers, and you should consider them as part of your outsourcing strategy.

The size of the supplier, the availability of required skills, any past history with the customer, and a demonstrated understanding of the assignment are all major factors in selecting a potential supplier. How well the supplier will work with the internal team and with other partners in a multisourced environment are also important. These cultural factors are subjective and difficult to evaluate, but they must be considered. They require significant flexibility as you build relationships with your suppliers. The cultural factors include organizational structures, the predominant forms of communication (formal and informal), and ways that knowledge is transferred.

In a work environment, culture translates into the ways individuals deal with people, processes, performance, values, and expectations. Measuring cultural alignment is one of the most difficult aspects of an acquirer-supplier relationship. Some indicators of cultural sophistication (or its lack) may be how a supplier handles human resources policies, how its organization is structured, and how it sets goals and executes to them—as well as how it deals with customers when goals cannot be met.

George Taylor, the supplier’s program manager, has firsthand experience with a cultural mismatch that occurred in one of his outsourcing assignments. He relates this experience to Steve, who has encountered a similar situation.

Steve nods.

The solicitation package is a combination of form and function. Its structure should support an accurate and complete response from potential suppliers, which in turn supports an effective base on which to compare proposals. A typical solicitation package includes three basic things:

In government agreements, some or all of the content and structure of the solicitation package may be dictated by regulation.

A solicitation package also includes the criteria that will be used to evaluate the proposals so that bidders understand where to focus their responses. It also includes documentation requirements, which can consist of specific forms and templates to capture information (such as staffing in a specific geography or a schedule that lists the various rates for specific resource skills). There are also provisions in the solicitation package to answer any questions or concerns on the part of the supplier and a schedule for completing the solicitation process.

The solicitation package must be comprehensive enough for the supplier to formulate an accurate and targeted response but flexible enough to allow the supplier to offer suggestions of other ways to satisfy the requirements. One way to approach this challenge is to offer the supplier an option to respond as provided but also submit an alternative solution in a separate proposal. You must be careful to write the solicitation package so that it is commensurate with the value and the risk associated with the proposed acquisition. It is inconsistent and unfair to ask a supplier to respond in great detail to a proposal that is of small monetary value. The detail required in the bid should match the supplier’s expected return on investment.

Sample content of the statement of work in a solicitation proposal includes the following:

In its most basic form, an acquisition encompasses one supplier performing to a supplier agreement written to cover deliverables for one project, such as building a single specific system. Although this approach may be the simplest one, it doesn’t take advantage of economies of scale that could be obtained if, for example, you apportioned to specific suppliers (with a plan for delivery) an overall technology portfolio for the year, or even an identified area of work such as an engineering program. Bundling projects means that you can better leverage the work of the supplier and generate an overall better return on investment. In contrast, if an organization is new to acquisition and hasn’t yet established working relationships with any suppliers, the risks increase when an acquirer clusters a large portion of the overall work and awards the contract to only one supplier.

Another aspect of structuring the outsourced work is to break it down so that you give suppliers an incentive to improve service and reduce costs. In one approach, you associate services that tie the work of the supplier to accountability for cost and service improvements. For example, suppose you outsource a technology solution—such as consolidating management of Web applications—to a single supplier. This gives the supplier an incentive to make repetitive administrative support tasks more efficient and thus cost-effective. The result is lower costs for the supplier and improved service for you.

You must also consider the number of supplier agreements that you have the capacity to oversee during a given period. This decision in turn drives the number of solicitation packages that you develop and send out. An organization might have a handful of suppliers it would like to work with, but if it distributes a large number of individual proposals it could end up with a significant number of supplier agreements to manage.

An alternative is to align the number of proposals with the natural segmentation of the work. For example, you could negotiate agreements with one supplier to perform all engineering services that cover the three major areas of engineering. These might segment into engineering around the desktop, engineering visualization, and engineering business systems. In this example, specific managers in your organization could efficiently oversee the supplier in a specific engineering area and deliver to specific customers in that engineering area, and you would thereby minimize the number of agreements and suppliers. Each major engineering area could ensure that its specific requirements were captured in its solicitation proposal.

Another consideration is that the larger the number of individual agreements, the greater the need for resources to manage their execution. Decisions about segmenting outsourcing work can be based on business domains or on other dimensions such as availability of acquirer resources to manage more granular segments.

A typical technology solicitation package contains a number of contracting documents, including a standard set of terms and conditions for supplier agreements. Typically the terms and conditions for one agreement are written so that they can be reused in other agreements. Using standard language for terms and conditions, bidding suppliers are asked to respond to this language as part of their formal response. Often the final agreement of the supplier to the acquirer’s terms and conditions becomes the first step in determining whether the acquirer and supplier can work together.

The solicitation package may include a set of methods, standards, and tools that the acquirer expects the supplier to conform to and use. As part of its response, the supplier must describe the standards and methods it will use to complete the project. Key staff members should be identified, along with their qualifications. Pricing is also part of the supplier’s response, and the supplier’s technical portion describes how it will manage any necessary knowledge transfer.

The solicitation package should give bidders some latitude for describing areas of opportunity for transforming the use of technology in the acquirer or customer organization. This could be as simple as a supplier presenting a set of processes or tools for the integrated team to use, or as significant as identifying a new technology set to leverage. The more complete the solicitation package, the more complete the suppliers’ responses should be.

It is also important to create traceability between the project requirements and the solicitation package. The solicitation package is reviewed by stakeholders to ensure that the requirements are accurately and completely addressed. Often, for larger outsourcing agreements, peer review teams are asked to exchange packages and provide objective feedback to improve the solicitation package before it’s distributed. It may be prudent to include suppliers in this review so that you can test the solicitation package for clarity by someone outside the organization. You also ensure that the solicitation package meets all legal requirements and includes all qualified suppliers.

After the solicitation package is distributed to potential bidders, it is critical to ensure that all potential suppliers have equal access to information that clarifies points of confusion in the requirements and any disconnects or concerns with the solicitation package. If questions arise that have implications for all bidders, you should formulate the answers and distribute them among all bidding suppliers.

Steve evaluates options with Matt to handle acquirer-supplier interactions during the proposal process.

Communication is critical as you and suppliers work together to answer all questions and resolve as many issues as possible before the supplier agreement is awarded. This means that part of your responsibility is to conduct formal, detailed reviews with each bidding supplier so that everyone involved has a clear understanding of all aspects of the solicitation package. This may require two or three rounds of documented feedback or face-to-face sessions. Any changes or errors identified in the solicitation package need to be communicated to all suppliers. This collaboration and exchange continues until the bidding suppliers submit their final proposals, which should include a plan for addressing all the aspects needed to meet business requirements, pricing that’s in line with the solicitation package requirements, and a transformation road map for implementing the customer vision.

The CMMI-ACQ provides specific recommendations on qualifying potential suppliers, creating and gaining stakeholder concurrence for the solicitation package, and distributing the package to qualified suppliers (see Table 2-7).

Consistent with the acquisition strategy and along with the project’s scope and requirements, you indemnify potential suppliers who will receive the solicitation package (Table 2-7, practices 1.2 and 1.3). To reduce costs and effort, you limit the number of suppliers from which you solicit proposals, while at the same time making sure that you have included suppliers that can meet the requirements and ensuring that enough suppliers are included to provide a competitive environment.

You structure the solicitation package to facilitate an accurate and complete response from each potential bidder and to allow for an effective comparison and evaluation of proposals. The package is rigorous enough to ensure consistent, comparable responses but flexible enough to allow suppliers to suggest alternative ways to satisfy the requirements.

The solicitation package is reviewed with end users and other stakeholders to make sure that the requirements have been accurately and sufficiently stated so that the solicitation can lead to a manageable agreement (Table 2-7, practice 1.4). Then the solicitation package is distributed to the potential bidders that have been identified through research or other means (Table 2-7, practice 1.5). You use standard project planning, monitoring, and control practices to manage your activities during the solicitation process as necessary.

Solicitation packages and supplier responses are key documents supporting a series of activities that culminate in the selection of a supplier. The request for proposal is the initial requirements document for the supplier and serves as the base document against which the bidders’ responses are measured. Responses are read in their entirety by acquirer team members. They use criteria based on the requirements to determine whether each response is complete, includes all the requested information, and is in the requested form.

You may invite bidding suppliers to present their proposals to your team, giving the bidders a chance to answer any questions from your review and to ensure that your team members fully understand the supplier’s response. Any risks or assumptions in the response are validated through due diligence activities: reviews of the requirements with current suppliers that are performing similar work, reviews of any affected technology solutions, validation of bidder references, reviews of any affected operating facilities and capabilities, and reviews of bidder capabilities.

Due diligence is a legal term that refers to how parties to an agreement ensure that they understand the work that is being contracted for and any associated risks. Suppliers as well as acquirers should perform due diligence. Initial supplier responses are built on the information presented in the solicitation package. A period of time should be spent on additional investigation so that each supplier can validate its assumptions, verify the information submitted by the acquirer in the solicitation package, and obtain additional information about the work. At this point, the acquirer expects that the supplier will adjust its response, especially in delivery solution, transformation, and costs. The acquiring organization ensures that all data is available to answer supplier questions, including metrics, reporting, and key personnel.

You perform your own due diligence to ensure that the bidder can deliver as described in the response. In the case of technology development, you should visit supplier delivery sites to examine personnel and capacity and ultimately judge whether the supplier can fulfill the business objectives. You should ask a number of questions: Do the suppliers have significant experience in the delivery of the technology needed? Can they demonstrate a track record of success, including documented customer satisfaction results?

Steve and Matt review this issue in a discussion.

Steve supports Matt’s statements.

Based on new information from due diligence, suppliers may update their proposed technology solutions, transformation plans, and even cost models. Why should you expect pricing changes after due diligence? The reason is that more recent data and an external view of the environment may result in a more current and comprehensive understanding of cost drivers, including newly identified risks and material deviations from the solicitation package. That said, all substantive changes should be justifiable by the supplier, and you should cast a wary eye toward any wide swings in the cost models at this point.

Ideally, due diligence is a two-way street. In addition to responding to supplier inquiries, you should continue your own investigations by visiting delivery sites, checking with reference customers, and continuing to drive the solution and project planning. Organizations need to manage risk by confirming that bidding suppliers have successfully delivered technology solutions in the past.

After the proposals are evaluated, a negotiation plan is developed for each of the candidate suppliers. The size of the negotiation team depends on the size and complexity of the project and the overall outsourcing deal. The negotiation team is composed of individuals who have knowledge of the statement of work and the solicitation package. The team has the support of your legal staff, financial staff, and purchasing staff. The roles and responsibilities of the negotiation team include the following:

“Why should I choose you?” is the initial question that Matt asks as he begins each session with a bidding supplier. It’s an important question, because as Matt talks to various groups sent from the same supplier, he gets various answers, and these answers allow him to formulate a clearer, more well-rounded picture.

Beyond this simple question, Matt has a set of solid criteria that is shared with each supplier. He and the negotiation team use these criteria to rank each bid. The criteria include identification of each major chunk of work, such as scope, SLAs, overall approach, tools and technology, process and methods, personnel skills, continuous improvement, and global support. His CIO wants to capture other considerations.

Steve also weighs in on the responses.

Often, the supplier’s sales team is the only group working with you until the response is submitted. It is important for your team to ask for a supplier pursuit team that will deliver the technology solution. This means that key individuals are identified and brought in early as part of the initial supplier pursuit team. You also need to understand the supplier’s physical locations where the work will be done. As you continue to evaluate a specific supplier, technical and cultural differences should emerge. A working marriage is important, because recovering from a “divorce” from a supplier is painful and difficult.

Steve describes a situation he experienced when the delivery team did not show up until after the ink was dry on the agreement.

Suppliers typically have numerous questions about organizational structures and processes as they put together their responses. Suppliers’ proposals include details about the program management office, reporting structure, service level targets, benchmarking and auditing, and quality improvements to indicate to the customer organization how such a structure supports the inevitable changes in staffing that occur as the program evolves. Bidders want to give the acquirer visibility into the skills of their staffs. And because suppliers know that there is shared risk inherent in outsourcing, they want to surface the management structure they believe will mitigate risks, usually a structure that has been used in other engagements. Suppliers also identify dependencies on the acquisition organization that impact their ability to meet commitments.

Down-selecting—narrowing the field of bidders—is a significant activity that can occur several times during solicitation. Typically, the initial list of suppliers is larger than you can manage in final negotiations. The list is narrowed to one or two as the teams plan for and execute the negotiation process. Down-selecting can happen at the end of the first proposal review and again after due diligence. If down-selecting is part of your process, you should include each of these milestones in the supplier selection activities communicated in the solicitation package.

Matt wants his team to clearly understand when they can down-select the suppliers who are submitting bids. He has a team of several staff members working full-time on these deals, and he wants to make sure that two down-select steps are completed at the appropriate time. He discusses the timing with his team.

Matt pauses to look around the table.

Matt distributes a handout and takes the group through a bullet list of criteria.

A key element in evaluating the proposed solutions is directly tied to the delivery of quality within an agreed-upon budget. Can suppliers deliver with increasing quality at a lower cost?

One of the drivers for the achievement of this goal is standardization in the technology industry.

Another criterion to be considered is the supplier’s domain expertise and its importance to the project. Some suppliers are stronger than others in a specific area such as product development or marketing domains. Finding a supplier that can combine domain expertise with technology prowess can offer tremendous value. Unfortunately, many suppliers are technologists first and domain experts second. The importance of domain expertise relates to strategic insight. The functionality required by the end customer can be enhanced by the supplier’s knowledge and experience. Domain expertise also fosters mutual respect between you and your supplier. If the relationship is grounded on mutual respect within a certain domain, more partnering occurs, and the likelihood increases that the organizations can weather challenges in the relationship. Other considerations include the supplier’s delivery approach (e.g., offshore versus onshore delivery) and the supplier’s ability to manage certain aspects of technology, such as a secure hosting environment for IT solutions.

Matt and his team are ready for their first down-select. Three candidates remain, and, of the three, two seem to have clearly understood the solicitation package and responded accordingly. The third seems to have put minimal effort into understanding the work, and its response reflects that level of effort. In addition, its pricing is way out of line compared with the other bidders. In the down-select meeting, the acquisition team looks at the three supplier scores side-by-side. Steve expresses his disappointment with the respondent that has put minimal effort into its proposal.

Matt looks around the table. Everyone is nodding in agreement.

Negotiating the language of the final supplier agreement should be based on the final responses submitted by the suppliers. After comparing the final responses, you usually perform a down-select to one supplier. Negotiations—in-depth discussions with the selected supplier—focus on reaching compromises on any remaining issues such as outstanding contract terms, concerns about SLAs, or any of the details in the plans and deliverables. Usually, the suppliers not chosen for final negotiations are not informed immediately. If you cannot reach an agreement with the supplier in negotiations, then you may want to enter into negotiations with an alternative supplier.

One of the challenges in negotiation is the need to preserve cost visibility in the agreements as negotiations evolve. This element, along with flexibility, also can create issues with the supplier’s future performance, especially when it assigns personnel with specific skill levels to the projects.

Before negotiations begin, you must establish the negotiation team members, their roles, and the rules of engagement. Team members begin by translating the supplier’s motives into potential negotiation levers to realize the best deal.

Matt brings his team together to discuss some of the rules of negotiation.

Matt pauses and consults his notes.

Steve, who has put in many hours evaluating proposals, is not happy about this edict and the ramifications of putting communications under such stringent controls.

Matt looks at Steve, who nods.

Matt wants to talk about supplier motives before he lets the team walk through a mock session of how negotiations would go.

Matt nods and looks at the team.

It is important to set the supplier’s expectations indicating what you believe the work is worth from a cost perspective. In some cases, you set cost targets as part of developing the solicitation package. Many acquirers set very aggressive cost targets and see how the suppliers respond. The upside of this technique is that it gives the supplier a sense of the value you place on the work. The overriding concern about targets is the potential impact on quality. For a supplier, cost can be reduced in a number of areas: process, testing, scope, staff, and more. You also need to be sure that your message is viewed by each bidding supplier as a challenge to stretch from a number of points of view. You want suppliers to stretch by looking at costs, margins, resource mix, and offshore versus onshore and come up with a solution that really meets your needs. That should not compromise quality. Each supplier should work the various cost components and determine the optimal mix to meet or exceed the targets you’ve set. You can then come back and revisit the targets to make sure that requirements are still being met.

It is important for an acquirer to understand who is willing to take a run at the target and how creative they can be. This also says a great deal about how that supplier can and will work with you and how flexible it is willing to be. These are characteristics that you would like to see translated into transformational activities as the supplier identifies opportunities for your organization. If a bidding supplier is not willing to try to meet the targets, this needs to be noted as you make your evaluations.

The CMMI-ACQ provides specific recommendations on how to evaluate proposed solutions in accordance with the time line, the preliminary project plans, and the evaluation criteria. The recommendations include the formulation and execution of negotiations that culminate in the selection of a supplier (see Table 2-8).

Proposals submitted in response to solicitation packages are evaluated based on the proposal evaluation criteria, the established time line, and the project plan (Table 2-8, practice 2.1). Evaluation notes should be documented and maintained. You refine your negotiation strategy based on your evaluation of the suppliers’ proposals and the evaluation of the suppliers. The proposal evaluation and the negotiations with the suppliers provide the basis for selecting a supplier that is best able to meet the requirements of the solicitation.

For each of the candidate suppliers, you develop a negotiation plan based on evaluation of the suppliers and their proposals (Table 2-8, practice 2.2). The size of the negotiation team depends on the size and complexity of the project. The negotiation team typically is supported by legal staff, a financial analyst, purchasing, and the project manager.

Proposal evaluation results are used to select a supplier based on the outcome of negotiations (Table 2-8, practice 2.3). The negotiation enables you to ensure that you are selecting the best supplier for the project. The evaluation results, along with the negotiation results, support the selection decision or cause you to take other action as appropriate.

After you negotiate the agreement, you and the supplier write a formal supplier agreement based on your acquisition needs and the supplier’s proposed approach. It is important for you to ensure that all critical aspects of the supplier’s final bid, especially the negotiated changes and the results of due diligence, are captured in the supplier agreement.

These agreements form the basis of the relationship between you and the supplier. They describe the technology solution or solutions to be built, the quality expected, and the timing of the delivery. Agreements define the service level credits to be given to you when supplier commitments are not met.

Supplier agreements can include incentive clauses to encourage performance. For you to realize the benefit of creativity and transformational activities, it’s a good idea to include clauses that support sharing of the monetary value of any improvements or new business achieved by the delivered technology solution. This can happen when a supplier builds a technology solution that has applicability beyond your organization. For example, suppose you and the supplier agree to build a self-service timekeeping system. As the supplier develops this solution, it creates a unique Java component that supports time computation across all possible requirements of calendar management—including geography, language, religion, and culture—for resource scheduling. If the supplier has the freedom to provide this capability to other customers (if it does not relate to your core business or a competitive advantage), then the supplier has an incentive to look for additional opportunities in future projects.

The types of agreements and pricing mechanisms documented in the supplier agreement affect the products and services delivered. The type of agreement you choose depends on the quality of the supplier, your business goals, and the maturity of your processes. Projects that lack a clearly defined scope tend to fall into a time-and-materials type of agreement, because the risks center on effective management and cost overruns. Nevertheless, a time-and-materials agreement gives an organization some visibility into supplier costs and significant insight into how the supplier calculates the costs of an outsourcing engagement. With a time-and-materials agreement, you can see materials costs, rates for specific personnel, and time expended to complete specific tasks.

Matt’s fellow executives want all supplier agreements to be fixed-price. Fixed-price agreements work well for predictable activities that can be accurately scoped, such as maintenance services or network operations. They don’t work well for many of the groundbreaking activities that Matt is looking for, such as transformation opportunities in the IT areas of Web services, reporting, or identity services. After some rather heated discussions, Matt and his staff begrudgingly authorize a combination of time-and-materials agreements and fixed-price agreements.

Matt still has concerns about the impact of fixed-price agreements, especially in the area of skilled workers.

You can employ various types of agreements to reflect combinations of work, such as designing, coding, maintenance, and operation. A design-and-code agreement covers both designing a solution and generating the source code. These agreements are not complex, and they can speed the delivery of projects because they promote innovation and minimize the required knowledge transfer between the designers and the developers.

Agreements that cover designing, coding, maintenance, and operation mirror the life cycle of a technology solution. This approach offers the supplier a number of incentives to deliver quality. Because it must maintain or host the code that it has designed and developed, there is more incentive to deliver first-time quality and build for efficiency in maintenance and operations.

Another approach to the structure of agreements is to create a master agreement. The analogy in nonproductive materials procurement is a blanket order—for example, an open purchase agreement that is used to obtain office supplies on an as-needed basis. In this master agreement approach, you package requirements and select one or a small group of suppliers to meet specific project requests as task orders over a period of time. In this type of agreement, terms are set, but quantity is not. Master agreements can be used with or without competition and speed up the overall acquisition process.

In a master agreement structure, the terms and conditions of the agreement must be generic to support a long-term relationship with the supplier. These terms and conditions are not reviewed every time the project cost is estimated, thereby allowing an expedient project start-up. This structure also supports continuous improvement with the supplier, because a strategic partnership can be forged more easily. A challenge of the master agreement approach is that it requires clarity for overall requirements that are expected for all projects. Because these agreements are in place for extended periods—typically three to five years—they require understanding on your part and accurate documentation to support the strategic partnership.

Although the timing of any project is unknown at the time the master agreement is put into place, price competition becomes important. For pricing to remain fair and competitive, you need mechanisms in place over the period of the agreement to manage pricing. Examples are adjustments for rate cards of supplier services or for supplier resources based on cost of living adjustments. To manage costs and foster continuous improvement, you should use ongoing benchmarking to monitor performance standards and cost standards in the industry.

In the master agreement, the payment mechanism is crucial. Although price certainty is relaxed, the supplier receives a constant revenue stream from the project assignments, which continue to roll in as long as the supplier maintains quality and value. Care must be taken to put in place a payment mechanism that results in the smallest risk premium from the supplier to reflect its estimate of overall uncertainty in the agreement. This structure also affords you an opportunity for cost visibility tied to continuous improvement. Efficiencies come from repeated execution of projects by the same small set of suppliers. If you adopt this approach, you must consider the need for some level of competition now and into the future, especially when the agreement expires. And finally, the mechanism to distribute the work must be clearly documented so that you can realize the flexibility, speed of delivery, quality, reliability, and value that this structure can offer.

In selecting an agreement type and executing against it, both the acquirer and the supplier understand that the basic principles of contract law apply. There are a number of areas to take into consideration to avoid problems and make the most of the acquirer-supplier relationship. If the agreement is not sound and basic tenets are absent, then uncertainty, disputes, and failure will result.

After a brief discussion about what should be in the agreement and what happens if something is missing, Matt looks at Steve and poses a question.

If the description of the desired capability is ambiguous, it leads to scope creep. Clarity is required for the products to be developed or the services to be performed, the timing of delivery, the specific acceptance criteria to be used, and when the supplier can expect to get paid.

Provisions for the ongoing update of technologies should also appear in the supplier agreement. You should outline how new technologies will be introduced, whether this agreement covers one project or many. There should be provisions and some flexibility to handle hidden costs; typically, these types of deviations are controlled through a change management process.

Applying standard agreements is a good practice whenever practical. You can build reusable, standard agreements for technology solutions that can be customized to match the need. For example, nonproductive material agreements used to order office supplies will not work for technology solutions. Even though this seems obvious, some acquirers try to shortcut the agreement development cycle by using something that, even when modified, just doesn’t fit. Acquirers and suppliers should agree and document who owns the intellectual property that will be built, and the copyrights, database rights, and patent rights should be clearly spelled out in the agreement. This ensures that the party that should own the product does indeed own it.

Many organizations have a history of reusing contract language for commodity purchases. In more sophisticated agreement structures, this can be viewed as modularity: Modules of contract language and documents are put together in various combinations to reuse descriptions of how work is to be accomplished by a supplier for a specific customer. Modularity gives you the flexibility to manage variations in specific customer requirements. The variation in any agreement is then focused on the statement of work, which describes the work that needs to be done to develop the specific technology desired. The common agreement language remains the same.

Provisions for open source code should be specified. You and the supplier need to agree on whether it is excluded or included and, if included, who will manage it. The issue of indemnification should also be documented. Often, acquirers want suppliers to indemnify them against any third-party license infringements. Both parties will also want explicit limitations on liability by setting a cap on liability, especially failure to perform. You may ask your suppliers to sign nondisclosure agreements even before the supplier has had a chance to respond to a solicitation package. Nondisclosure agreements should cover the time before, during, and after the award of the agreement.

Required acceptance testing should be clearly defined. Any warranties should be part of the acceptance criteria and should include the requirements for things such as defect-free technology solutions and compatibility with the intended environment, especially infrastructure compatibility.

The management of supplier staff is an area that requires specific detail. The agreement should describe who will manage them, what their reporting structure is, and what processes should be executed for supplier employee performance. This is of particular concern to maintain compliance with labor laws in various jurisdictions. Information security and data protection should be outlined and should always be in compliance with local statutes. Audit trails for the development and deployment of the product should be specified as to the archival and access requirements. And finally, SLAs for responsiveness, availability, and performance should be captured.

Service level agreements—the methods used to measure supplier performance negotiated in agreements—can be effective in motivating suppliers to perform according to the terms of the agreement. As an important part of formulating a response to the solicitation package, bidding suppliers want to understand the methods and the risks associated with service levels. If used appropriately, SLAs work as the foundation for continuous improvement for the supplier and your relationship with the supplier.

SLAs are often based on what is known by you and what is easy to measure, rather than align performance measures with the key objectives and expectations of technology delivery. Not all measures are SLAs, nor should all measures be converted into SLAs. To be an acceptable SLA, the product or service to be measured should be described in the statement of work along with the assigned calculations and their timing. In addition, any applicable tools and processes should be defined, along with reporting frequency and content.

Matt wants to be sure that the team is aligned on SLAs, so he uses reports as his example.

Steve is concerned about the implications of service levels to the business objectives. After all, “on time, on budget, with quality” resonates with what he learned many years ago in his computer science classes. Capturing these measures is very simple. In fact, these are the internal measures that his teams are already using. Do they work in an outsourced model? How do they relate to business objectives? What about “real” quality measures? Are they direct or indirect? After the work is outsourced and performed at arm’s length, how do we know that the quality of the staff is up to par, something that becomes a direct reflection of the quality delivered? In other words, what are the predictors of success? Steve discusses the implications of SLAs with the team.

What Steve is really trying to do is to develop an SLA architecture that ties the business goals to the outsourcing goals and then to the services delivered. Operational performance can then be driven through the service requirements.

In general, the number of critical SLAs should be kept to a minimum for each technology solution. SLAs must use the right measures and must have enough influence for you to maintain control of the supplier and result in appropriate performance. The most important aspect of SLAs is tying them to the main objective of the agreement.

After all the parties agree to the terms of the agreement, it needs to be approved by management and other approval staffs (e.g., legal, purchasing, finance). The agreement should take effect on the negotiated date. In addition, those suppliers who were not awarded the contract are notified and any communication between the organizations is completed.

The CMMI-ACQ provides specific recommendations on how to establish an understanding with the supplier about the intent of the supplier agreement through formal documentation and approvals. You and the supplier continue to work together to maintain this mutual understanding through execution to the completion of the project (see Table 2-9).

A formal agreement based on the sourcing decision of the acquirer is established. The acquirer and the supplier work together to gain a mutual understanding of the agreement based on the acquisition needs and the supplier’s proposed solution (Table 2-9, practice 3.1). As points of clarification and ambiguities arise after the contract is awarded, you and the supplier ensure that this mutual understanding is maintained throughout the life of the project.

You and the supplier document the approved supplier agreement (Table 2-9, practice 3.2). This agreement may be a stand-alone agreement or part of a master agreement. When the supplier agreement is a master agreement, the project can be managed as an addendum, work order, or service request to the master agreement. All the standard elements should be in the supplier agreement, including the terms and conditions, which should include the following:

Managing a well-run technology organization that engages in outsourcing doesn’t happen simply because senior management signs the supplier agreement. In the same way that a technology organization should have a governance structure in place that reflects the business areas it supports, there must be a supplier management function to manage the various aspects of an outsourcing engagement. To ensure the success of outsourcing, you must establish a governance structure in cooperation with the supplier. The activities managed under this structure include maintaining ongoing communication and understanding, resolving issues and disputes in a timely fashion, managing any changes to agreements, accepting delivery of supplier-assigned products, and ensuring timely payments.

Information about the awarded agreement and the chosen supplier should be communicated to all affected parties in both organizations. In many instances, these initial communications will be the first time that those outside the pursuit teams begin to learn about the project and its goals. It is important for both organizations to understand what has been negotiated and to have an initial sense of how it will affect them. Roles, responsibilities, and accountability are quickly defined so you and the supplier understand how you will work together to successfully implement the agreement. Planning for implementation should begin long before pen touches paper. After the final down-select occurs and before negotiations start, you should identify implementation leads and begin work on time lines and deliverables, dependencies, governance, and risks. After the agreement is in effect, you can move into the next phase of work by starting to transition knowledge to the supplier.

Steve is proud to have led the solicitation team, which has dedicated itself to hard work and long hours. He feels that it has really paid off in the end, because the team understands what it means to plan ahead and the importance of working in parallel. During the lull while the solicitation package is put together, especially during negotiations, the team members use the supplier operating models in their solicitation package responses to build a high-level view of how their organization and the supplier teams will integrate and work together.

They begin to build a list of deliverables as outlined in the solicitation package and then assign each deliverable a specific target date. They review the staffing model and begin to align their subject matter experts with the supplier’s experts outlined in the proposals. They develop more detailed staffing requirements for each of the identified subject matter experts. They also look at the existing tools and discuss how they can be leveraged across the two groups to begin to share ideas, concepts, and general information. Matt is pleased that this work is coming together in parallel.

Steve wants to make sure that the team understands two more aspects of supplier management: customer delivery and supplier success.

Putting an outsourcing agreement in place is where the business dreams run headlong into the harsh reality of solutions delivery. Steve describes it this way.

After the contract is awarded, the acquirer teams responsible for implementing the supplier agreement must move beyond negotiations and work diligently to build trust with the supplier. In some situations, acquirers who work on negotiation teams find that the style and approach used in the negotiation influences their ongoing relationship with the supplier. This holds true regardless of the type of supplier agreement. If the negotiations are ugly, the deal can get spoiled and the trust relationship never materializes. One way teams resolve this is to expand the integrated team, change team leadership, or otherwise change the team composition to force changes in attitudes formed during the pursuit process. One critical success factor is to transfer the knowledge about the final agreement to the new team.

When there is effective communication between you and the supplier, the relationship thrives; without it, it is at higher risk to wither and die. In outsourcing, both you and the supplier must feel free to discuss performance problems, technical challenges, and any other issues that surface. Communication builds the bridge between the two groups and is based on a foundation of trust.

Both you and the supplier need to be up to speed on available tools to support communications. You should select those that fit the relationship by taking into consideration characteristics like geography and technology, as well as organizational culture. For example, a certain individual might use e-mail for routine communications because she has limited time to access e-mail. But for urgent issues she might use voice mail, because it gives her better, more frequent access. Everyone needs to understand these types of preferences, because they directly affect the effectiveness of communication.

You can use collaboration tools to support your work with your suppliers. These tools allow suppliers to work directly with members of your team across organizational boundaries. You must establish ground rules about what information can be shared. Nondisclosure agreements should be in place, but for information that is considered sensitive—such as finances, documentation of internal escalation, or human resource information—access must be closely managed. Any costs for collaboration tools should be part of the overall contract budget.

Matt speaks to George Taylor, the supplier’s project manager, about how the integrated team needs to leverage the tools that they have defined as a part of the agreement.

Effective communications between you and the supplier must begin as early as the selection process, especially during due diligence. If a supplier believes that you are understating the work involved in the agreement, it will be much harder to build a trusted relationship and it may never happen. One way to manage communications early in the solicitation process is to use a trusted third-party adviser. A consultant can often play this role to explain differences between acquirer views and supplier views and clarify critical topics for both sides. The consultant can rapidly clear up misunderstandings and help align interests between you and the supplier.

Even an invoice is a method of communication. For example, are the charges accurate? Are the listed items clearly associated with the actual work? The need for clear and trusted communication requires that you and the supplier agree on a communication framework, or what has been termed time management, as a significant part of the overall governance structure. Committees, forums, frequency of meetings, roles and responsibilities, and escalation processes are all part of a communication framework that should be detailed in the supplier agreement.

Holding initial face-to-face meetings after the agreement is signed is one way to solidify the human aspects of the contractual relationship. It is beneficial to send your team members to meet with the supplier’s development team members to solidify the integrated team, whether in a formal meeting, a workshop, or a set of team-building sessions.

You might define two or three categories of meetings that support communication for you and the supplier. For example, both leadership teams could get together in a strategic partnership meeting. This meeting would be structured to foster sharing between the two organizations at the executive level and to help resolve any major challenges or issues that arise about the agreement. It is a forum for the discussion of any major changes to programs or projects, especially those that affect cost and require executive approval.

Another kind of meeting is for the people responsible for the processes and procedures related to the purchase of goods or services. This meeting is a forum for discussions about interpretation of contract language, dispute resolution processes, or any other topic that relates to how the organization performs business-to-business purchasing. Yet another set of meetings addresses project reviews, manages issues and risks, and assesses the ongoing progress of the project.

The nature of outsourcing requires that you and the supplier apply process discipline. This means that everyone is clear about who does what, how it is done, who measures what, and who owns what. Suppliers support this need for clarity by sharing with you what has worked in past engagements, viewing communication as a value-added feature rather than an afterthought, creating a climate of collaboration by removing defensiveness in communication, and approaching all communication from a position of mutual respect. These are all ways to facilitate good communication during an engagement. Mechanisms put in place to understand one another’s perspectives build an environment of mutual trust and benefit.

Matt’s team demonstrates a commitment to making the deal work and, through word of mouth, also gets some of the “techies” in the organization interested in what the supplier has proposed. The team also offers feedback to the negotiation team and begins immediately to promote the value of the proposal. Matt didn’t predict this excitement, and he sees it as a major win.

Kristin Wells, the executive for the winning supplier, is intent on quickly getting the necessary supplier reporting systems in place. She speaks to George Taylor, the supplier’s project manager, about what she wants.

An escalation process as a governing principle is a specific form of communication and should be agreed upon and documented in the supplier agreement. It is a reflection of the rules of cooperation that should be executed by you and the supplier when necessary. To the extent possible, you and the supplier choose to resolve questions or concerns without triggering formal escalation processes or corrective action. The rule should require that any issues or conflicts be resolved as close to their origin as possible. If that fails, then all parties should agree to follow the documented escalation process. For significant issues that cannot be resolved through escalation, an alternative is having a negotiation team and strategy in place to resolve the disputed issues. After the issue is resolved, the terms of the resolution are documented and monitored to ensure compliance by both parties.

Disputes and differing interpretations of the supplier agreement are frequently the result of undercommunication. You and the supplier should make every effort to overcommunicate, especially during the initial stages of the project. George shares the industry statistics he has read that underscore the need for communication and describe what happens if communication doesn’t happen.

On one hand, acquirers want to tie their suppliers to very specific SLAs to assure themselves of a measurable level of performance. On the other hand, they also want their suppliers to be flexible, proactive, and thought leaders. These conflicting expectations can lead to concerns over the loss of control, questions about the cost-effectiveness of outsourcing, unmet expectations for transformation, and so on. Your suppliers may feel that they are required only to meet the SLAs, whereas you may be looking to expand your technology horizons. Because suppliers are accountable for SLAs and there are usually monetary penalties tied to not meeting them, suppliers feel an overriding need to mitigate their own risk by meeting the SLAs first and thinking about creativity and possible innovation second.

In one meeting, George speaks to Matt about what he sees as an unrealistic expectation.

It is up to the acquiring organization and the supplier to determine what is significant enough to warrant a change to the agreement. Kristin runs into this dilemma when the structure of the customer’s change management board is altered. She talks it over with her management team.

Kristin knows that her managers are not pleased with the thought of adding new costs to the contract for this expanded visibility. But when Kristin runs the numbers in her head, she sees that the impact of the change is eight hours per month. If the task is performed offshore, it will cost around $400 per month, for an annualized cost of approximately $4800 per year. For a $10 million contract (annualized), it seems that this cost could be covered without a formal change. Kristin’s management team is willing to cover this expense at no additional cost, but they’re concerned that the accumulation of small items like this one might quickly become a large problem. They ask her to communicate to Matt the implications and cumulative effect of this change and all the changes to date in total.

When there is a change in the environment that affects a project, or when a new project requirement surfaces, requirements documented in the original supplier agreement may no longer be applicable. For example, a new technology may become available or the reporting requirements may be judged too burdensome. There may be changes to the agreement stemming from the supplier’s inability to meet acceptance criteria or service levels. When these situations occur, it is important that the changes be formally documented and agreed to by both the acquirer and the supplier before they are implemented. Changes can have an impact on pricing, the product to be delivered, or the results required from the technology solution. Acquirers typically use their formal configuration management processes to manage these changes.

How well the acquirer-supplier relationship works is driven mainly by how committed each organization is to building true partnerships. Teams must move away from ongoing discussions about “What’s in the contract?” and “That’s not how I read the contract” to “How can we work together to accomplish these goals for the project?” Often, short-term cost savings get in the way of a long-term potential partnership with a supplier. Many elements factor into whether an acquirer chooses to partner, and this also relates directly to what the acquirer wants from the supplier. Organizations understand the need for fixed-price agreements, aggressive price targets, and stringent SLAs to manage delivery, while still encouraging those behaviors that move toward a partnership that can work to the benefit of both acquirer and supplier.

Over the course of the project, the supplier is compensated based on some measure of work completed. The agreement specifies when and under what conditions the supplier is paid. Often, acquirers link the payment of invoices to specific deliverables. This practice lets you manage nonperformance by using the remedies outlined in the agreement, such as withholding or reducing payments. You must ensure that the proper financial controls are in place for compliant invoicing and payment activities.

After a supplier agreement is signed, it becomes expensive to make significant modifications or to change to another supplier. So a change control process is outlined in the agreement’s terms and conditions. To ensure that the agreement remains viable over its intended life, many acquirers use benchmarking to determine whether the agreed system or service costs have changed. If there are significant changes in technology or cost based on this benchmarking data, then you have the option to open the agreement (based on its terms for renegotiation) and work with the supplier to modify any agreement requirements. Opening up an agreement costs time and money, especially if you have multiple agreements with various suppliers. Before an agreement is signed, you can easily make changes as you gain clarity about your needs. But after the deal is signed, risk and interdependency increase, and the acquirer and supplier must look for ways to work together without opening the agreement for renegotiation.

Before the product is accepted, you must ensure that all acceptance criteria in the agreement have been met. If the supplier fails to perform as specified, you can exercise any and all remedies as outlined in the agreement. You provide the supplier with formal written notice that the supplier deliverables have been accepted or rejected. It is also at this point that you assume ownership of the specific deliverables, product, or service as partial or complete performance of the supplier agreement. For you to be assured that all aspects of the agreement are completed, you also need to verify that all specified customer and contractual requirements have been completed. Contractual requirements may include such things as license, warranty, ownership, usage, support, or maintenance agreements. You verify that the requirements are fulfilled and that all contracted deliverables and supporting documents are completed.

You also have the responsibility of communicating that the product is ready for transition to operations. Typically the supplier is responsible for integrating and packaging the product and preparing for the transition to operations and support, as outlined in the agreement. Often you outline a pilot activity during which the supplier maintains control of the product. This gives you the opportunity to validate that the product is usable and ready for full operation. To mitigate risks until the capability is proven to be operational, a pilot is typically deployed only to a subset of the intended user population.

You also must be assured by the supplier that the product can be backed out in the event of any failures before transitioning to the production environment. If there is a warranty period for the technology solution, you and the supplier work together to ensure that the product is operating as specified and that no corrective actions are required. The product is transitioned to the operating team when the team can demonstrate the capability to operate the product.

You are responsible for maintaining oversight until all transition activities are complete and the support of operations is in place. If you group functionality from multiple suppliers to create a release for your customers, then you designate one supplier to function as the prime supplier. The prime supplier is responsible for making sure that all the functionality is integrated so that the release can be successfully deployed.

After the product is transitioned, you are responsible for analyzing and reviewing the results of the transition to make sure that all corrective actions are completed before project close. In addition, you need to ensure that product storage, distribution, and use comply with the terms of the agreement or license.

When the project is completed, transitioned, and deployed successfully, the supplier agreement is formally closed. Closure means that all the supplier requirements in the agreement are complete. Other closure activities include ensuring that all project records are complete and managed for future use. A formal communication is sent to stakeholders to let them know that the supplier agreement has been closed.

The CMMI-ACQ provides specific recommendations on how to manage the execution of the supplier agreement to ensure that you perform in accordance with the agreement (see Table 2-10).

Communication is the key to successfully completing the agreement. You manage the relationship with the supplier through effective communication and mutual understanding throughout the life of the project. It is of particular importance to you that these communications are documented when they affect issues such as a change in the business objectives or business processes that directly affects the project (Table 2-10, practice 1.1). Supplier management also supports the resolution of any issues or disputes between you and the supplier (Table 2-10, practice 1.2). And finally, communication covers information exchange that supports marketing or public relations.

The process of escalating unresolved issues has multiple phases before possible litigation. It is your responsibility to collect and manage issues until they are resolved. These issues can be identified from team communication or in milestone or progress reviews. If the supplier does not comply with corrective action, it is escalated and becomes a supplier agreement dispute.

Suppliers have the option to escalate issues about the agreement, especially those about the acquirer meeting its commitments as outlined in the agreement. Critical stakeholders such as senior managers, governance bodies, and legal counsel may participate.

Changes to the agreement that are deemed necessary by both parties should be captured in the supplier agreement, with the appropriate approvals from both parties (Table 2-10, practice 1.3). Changes can come from new requirements, new technologies, or changes in the SLAs. They can also occur when the supplier’s processes or products do not meet agreed-upon criteria.

Closing a project requires that all the stipulations in the agreement be met, including specified customer requirements, regulation requirements, and specific contractual requirements as well as customer deliverables (Table 2-10, practice 1.4). It is your responsibility to go through the necessary verification and validation processes to ensure that all stipulations have been met.

The CMMI-ACQ provides specific recommendations on how to build the kind of collaborative environment that supports the execution of the agreement and completion of the project (see Table 2-11).

One of the goals of acquisition management is to set up the proper environment for the supplier to work with the acquirer. This includes adopting routines for reviewing and approving invoices as well as building standard acceptance criteria (Table 2-11, practices 2.1 and 2.2). Payments tied to deliverables or completed functionality are important milestones to indicate the readiness of the product to transition. Based on the acquisition strategy, the product is transitioned to the acquirer and placed in operation (Table 2-11, practice 2.3). Your final reviews of the product signal that the project is completed, and the appropriate steps are taken to ensure that all documentation for the technology solution is managed.