Managing technology acquisition project life cycles




Some businesses choose to buy instead of build their own technology to avoid development timelines, minimize risk of project failure and keep up with changing technology. As a result, project managers must know how to navigate a project team through a process to select the right technology, for the right price, from the right vendor to meet the business needs.

While technology acquisition projects all contain the same basic phases (see sidebar, “Step-by-Step”), different situations call for different organization of these processes. Three project life cycles (PLCs) can be used to manage a technology acquisition project: the Basic PLC, Phased PLC and Multi-Solution PLC (see Figure 1).

The Basic PLC

The Basic PLC assumes that each process is completed before the next one begins. There are several benefits to using this simple model for your technology acquisition project. It allows the team to complete each process entirely before beginning the next and simplifies what can already be a complex project. It's also easy to understand and communicate. Last, there are clear milestones at the end of each process to measure progress.

However, there are drawbacks to the Basic PLC. For example, it requires the team to conduct all research and evaluation methods for all vendors participating in the process. Additionally, it doesn't handle multi-solution technology acquisitions very well.

The best time to use the Basic PLC is when a project involves only one solution and a small handful of vendors. It is also a good idea to use the simple model if this is your first time managing a technology acquisition project.

In 1997, a multibillion dollar Fortune 500 personal computer company began a project to acquire a predictive dialer technology for all outbound call centers. At the time, there were only three vendors in predictive dialer technology that were big enough to support a large implementation, so the Basic PLC was a good fit. The process was completed within three months, the technology was implemented six months later, and the equipment is still in use today.

The Phased PLC

The Phased PLC includes the same processes as the Basic PLC but uses several iterations of the research and evaluation processes. The idea is that the Round 1 elimination starts with a large group of vendors and takes them through a few research methods, a request for proposal (RFP) and reference calls. Each vendor then is evaluated and the list is reduced to six to eight vendors.

Next, the Round 2 elimination takes the remaining vendors through additional research methods (onsite demonstrations or vendor conferences). The goal of Round 2 is to reduce the list to three vendors.

Round 3 elimination includes the final and most expensive research methods (vendor site visits, vendor customer site visits or benchmarks/pilots). After completing Round 3, the vendors should be ranked in order of preference using an objective scoring method. Then, negotiation proceeds just as in the Basic PLC.

The Phased PLC reduces a large list of vendors to three, ranked in order of preference. It enables you to save money by reserving the costly research methods for the small list of vendors in Round 3. Finally, time and effort can be focused on differentiating the final list of vendors instead of vendors who are not in the running. The best time to use the Phased PLC is when there are a large number of vendors and the cost of research must be minimized.

The main drawback to the Phased PLC is the risk of eliminating a vendor in Round 1 because it submits a poor RFP response when, in fact, it may be the best option.

In 2000, another multibillion dollar Fortune 500 retail company began a project to select a gift card solution. There were 27 prospective vendors, so the Phased PLC was implemented. Round 1 consisted of a two-page request for information with approximately 15 disqualifying questions, allowing the team to efficiently narrow the list to six vendors. Round 2 consisted of an RFP and reference calls, and the list was shortened to three vendors. Round 3 consisted of full-day onsite meetings with the vendors, which were ranked in order of preference. This process took three months and produced a very competitive multimillion dollar deal for the company. This gift card solution was recently implemented in more than 3,000 retail locations across North America.


A technology acquisition consists of many activities organized into processes:

Initiation. A project is born when it is clearly defined and the key decision-makers within the organization agree to proceed. Initiation includes defining the business needs and developing a project charter.

Planning. This process includes all activities used to prepare for researching, evaluating, negotiating, implementing and operating the new vendor and technology. Planning typically includes developing a project plan, defining requirements, prioritizing requirements, defining a solution and identifying and contacting vendors.

Research. This process includes all activities used to learn about the vendors and their technologies. The extent of research will typically be consistent with the size and criticality of the project. There are several ways to research vendors and their technologies:

  • Buy existing research
  • Hire a vendor to do the research
  • Use a request for proposal
  • Call vendor references
  • Have the vendor demo their products at your site
  • Travel to the vendor's site for a demonstration
  • Visit the vendor's customer site for a demonstration
  • Host a vendor conference
  • Benchmark/pilot a vendor's solution.

Regardless of method, the project team must be objective.

Evaluation. Once the vendors and their technologies have been researched and the differences between them are understood, the project team can make a recommendation to the project sponsor, who will ultimately own the final decision.

Negotiation. After selecting a vendor, a negotiation team begins discussing the terms of the relationship with the vendor. During this process, the team determines the strategy, develops a plan and conducts the negotiations, including business and legal discussions.

Implementation. After an agreement has been successfully negotiated with the selected vendor, the vendor's solution can be implemented. This process typically includes development of any enhancements to the vendor's technology, testing and deployment. The vendors themselves will know how to best implement their solution.

Operation. After the project team has implemented the system, there is a transition from project team to operations. Operating the new technology will include managing ongoing fixes and enhancements, supporting the new technology, and closing the project.

The Multi-Solution PLC

The Multi-Solution PLC includes the same processes as the Basic PLC, but some technology acquisition projects require multiple vendor solutions. For example, the project may require separate vendors for hardware, software and consulting for integration into your current environment. Initiation, planning, implementation and operation processes can be combined, but research, evaluation and negotiation processes require separate, parallel paths for each solution.

The Multi-Solution PLC separates decision-making for each solution and allows dividing and focusing the project team members on the solution that is most relevant to the organization.

On the other hand, it also can be a drawback to select each vendor separately, because all solutions may not be compatible and a better price might have been negotiated for the entire solution through one vendor. Some use the Basic PLC in multi-solution technology acquisition projects and only include large consulting firms or integrators who can present a complete solution that leverages several partners and technologies.

The Multi-Solution PLC is best used when there are multiple, separate technologies that can be selected on their own merit, without consideration to the other solutions.

In the early 1990s, a Fortune 500 company used the Multi-Solution PLC to acquire technology and consulting services for an enterprise order management system. This project included separate research, evaluation, and negotiation processes for the hardware platform, database platform, and consulting services (to design, develop, and implement a solution on the selected platforms). Because this was a custom solution, it made sense to select the platforms independently from the consulting services. PM

Editor's Note: For more information on technology project life cycles, see “The Life Cycle of Technical Projects” by Pierre Bonnal, Didier Gourc and Germain Lacoste on p.12 of the March 2002 Project Management Journal.

Allen Eskelin is the author of Technology Acquisition: Buying the Future of Your Business [Addison-Wesley Professional, 2001]. For more information, visit Eskelin is an information technology manager at Starbucks Coffee Co., Seattle, Wash., USA, and previously worked for Gateway 2000.


Figure 1. These diagrams show three project life cycle models for technology acquisition projects.




Related Content

  • Project Management Journal

    People as Our Most Important Asset member content locked

    By Dupret, katia | Pultz, Sabina In this article, we examine how employees experience different types of work commitment at an IT consultancy company using agility to give staff greater autonomy and decision-making latitude.

  • Project Management Journal

    Blockchain Technology for Projects member content locked

    By Lu, Weisheng | Wu, Liupengfei | Xue, Fan This research aims to develop a multicriteria decision matrix (MCDM) for project management practitioners, supporting blockchain type selection.

  • Project Management Journal

    Top Ten Behavioral Biases in Project Management member content locked

    By Flyvbjerg, Bent This article identifies the 10 most important behavioral biases for project management.

  • Project Management Journal

    Perceived Complexity of a Project’s Optimal Work Plan Influences Its Likelihood of Adoption by Project Managers member content locked

    By Brokman-Meltzer, Mor | Perez, Dikla | Gelbard, Roy Perceived complexity is a factor when project managers adopt suboptimal work plans, even when optimal plans are readily accessible.

  • Survival of the Fittest member content open

    By Viturro, Leonor Today's constantly changing world presents companies with the challenge of answering rapidly to uncertain and fluctuating scenarios. Traditional organizational structures and decision-making…