Technology Acquisition: Buying The Future Of Your Business

Paperback | June 5, 2001

byAllen Eskelin

not yet rated|write a review

With proven, step-by-step solutions, this unique and practical book shows information technology (IT) project managers how to acquire the right technology from the right vendor at the right price for their business. There are numerous project management books on how to build technology, but the increase in project failure, limited resources, and accelerated change in systems and platforms has forced IT managers to move from building to buying technology, thereby shifting substantial risks to third parties. Allen Eskelin, drawing on his own experience managing acquisition projects, thoroughly explains each task required to buy technology successfully from outside vendors.

Technology Acquisition covers all facets of technology acquisition management, including the "people dynamics" that can make or break a project. The book offers useful templates, example documents, checklists, and schedules that guide you through the entire procedure, as well as case studies to illustrate the processes described. These processes include:

  • Initiation--creating and chartering a project to address your business needs
  • Planning--organizing teams; defining and prioritizing requirements; identifying vendors
  • Research--gathering information on vendors and their technologies
  • Evaluation--interpreting the results of research; selecting a vendor
  • Negotiation--defining a negotiating strategy; planning the negotiation; negotiating successfully
  • Implementation--developing, testing, and deploying vendor solutions
  • Operations--managing an ongoing process to extend the life of the product
  • http://www.technologyacquisition.com provides a forum for sharing experiences in project management. It also updates and supplements information on topics covered by the book.

Pricing and Purchase Info

$37.77

In stock online
Ships free on orders over $25

From the Publisher

With proven, step-by-step solutions, this unique and practical book shows information technology (IT) project managers how to acquire the right technology from the right vendor at the right price for their business. There are numerous project management books on how to build technology, but the increase in project failure, limited reso...

From the Jacket

With proven, step-by-step solutions, this unique and practical book shows information technology (IT) project managers how to acquire the right technology from the right vendor at the right price for their business. There are numerous project management books on how to build technology, but the increase in project failure, limited reso...

Allen Eskelin is an author and speaker on topics related to IT leadership. He is currently an IT manager at Starbucks Coffee Company in Seattle, Washington. He previously managed IT projects for Gateway 2000 in North Sioux City, South Dakota. For more information about him, visit www.technologyacquisition.com. 020173804XA...
Format:PaperbackDimensions:208 pages, 9 × 7.1 × 0.6 inPublished:June 5, 2001Publisher:Pearson EducationLanguage:English

The following ISBNs are associated with this title:

ISBN - 10:020173804X

ISBN - 13:9780201738049

Customer Reviews of Technology Acquisition: Buying The Future Of Your Business

Reviews

Extra Content

From the Author

Introduction A very large number of Information Technology (IT) projects fail every year. Some studies have shown that only one fourth of all IT projects undertaken by Fortune 500 companies are completed successfully. Others give IT projects only a 50 percent chance of being completed within time and cost budgets. Would you invest millions of dollars in a project with a 25 percent chance of success? IT managers are increasingly answering no to this question. So what is their alternative? Their alternative is to shift this risk to a third party. The risk can be reduced by acquiring technology from outside companies specializing in building technology instead of attempting to build it internally. The Shift from Building to Buying Technology There are many trends that are causing IT managers to shift from building to buying technology. One of these trends is an increase in demand for IT professionals. As technology becomes more critical to all businesses, the need for quality IT professionals increases. This increase in demand has caused the price of these resources to rise to a point where it is much more costly to develop technology inhouse than ever before. One painful consequence of the IT resource shortage is that as demand for IT professionals far exceeds supply, companies are being forced to extend development schedules and limit their growth plans. Another trend is the increasingly high rate of change in new technology. As growth in technology accelerates, it becomes more difficult to keep up with current technology and remain competitive. Combine these trends, the high rate of IT project failure, the shortage of IT professionals and its impact on project schedules, and the increasingly high rate of change in technology, and it’s no wonder that IT managers are starting to buy instead of build their technology whenever possible. The Ground Rules The goal of this book is to describe a way of managing a technology acquisition project that will facilitate the decisionmaking process so that you select the right vendor, with the right technology, for your business. The book also discusses how to implement and operate the technology once you have selected the vendor. Early in my career, I managed several software development projects. One day, I was asked to manage a project to acquire technology. I searched everywhere looking for information on how to manage this type of project. I perused bookstores, libraries, magazines, and the Internet looking for anything I could find on the subject. I found many books on the topics of project management, negotiation, outsourcing, software development, government technology acquisition, and business acquisition. But there was nothing that specifically addressed these topics in the context of acquiring technology for a typical business. I was forced to read several books on the topics previously listed in order to extract the information that would help me successfully manage this type of project. I eventually ended up creating my own project life cycle. After applying this project life cycle to several successful technology acquisition projects, I decided to share my findings with other project managers who are faced with the same challenges I faced. I am writing the book I wish I had before managing my first technology acquisition. I have tried to keep the information presented in this book at a level where it will be most useful to an experienced project manager who is new to managing a technology acquisition project. However, if you have 10 years’ experience in managing technology acquisitions, you shouldn’t jump to the conclusion that there is nothing here for you. This is not a book about managing government technology acquisitions or $100 million or more technology acquisitions. An experienced project manager who has never managed a technology acquisition will more than likely not get a chance to manage an acquisition of more than $10 million on his first project of this type. Additionally, a process this extensive would be difficult to justify on an acquisition of less than $500,000. This book is targeted at the experienced project manager who will be, or is, managing his first technology acquisition of $500,000 to $10 million. That said, there is also value for anyone who is involved with a technology acquisition. This includes executive management, IT management, project stakeholders, project sponsors, project teams, vendors, implementation teams, support teams, or any others who are impacted in some way by a technology acquisition project. As you read this book, you might find that this process is simple. I have elected to outline a stepbystep process that will be simple enough to use in your first technology acquisition project. As you gain experience, you may elect to modify this process or expand it to better fit your situation. My goal is to help you through the first project successfully while providing you with practical advice and techniques and an understanding of how to deal with the most important ingredient of any project, the people. The Technology Acquisition Project Life Cycle Many internal development efforts fail, and many trends are causing a shift from building to buying technology. Due to this increase in the acquisition of technology, there is a need for a project life cycle that project managers can use to manage an acquisition project. Before discussing the project life cycle, a few definitions are in order: Project: A temporary endeavor undertaken to create a unique product or service (The Project Management Institute, Project Management Body of Knowledge, 2000 Edition). Project life cycle: The division of a project into phases to provide better management control and appropriate links to ongoing operations of the performing organization. Collectively, the phases are known as the project life cycle (The Project Management Institute, Project Management Body of Knowledge, 2000 Edition). Technology acquisition: A project undertaken to acquire technology from a third party and implement it within the performing organization. With these definitions in order, let’s move on to discussing a project life cycle for a technology acquisition project. There are many project life cycles available for the technology development project. These life cycles generally include phases for definition, design, development, testing, implementation, and operations. Figure I1 illustrates some of the project life cycles for building technology. Figure I1: Development project life cycles Many of the phases used in a development project are also used in a technology acquisition project. But, there are additional phases needed for a technology acquisition project life cycle to be complete. Although there are many project life cycles available for development projects, there isn’t a generally accepted project life cycle for technology acquisition projects. When I was faced with my first technology acquisition project, I was unable to find a project life cycle that specifically addressed this type of project. Over the course of several years and several technology acquisitions, I was able to develop and fine tune a project life cycle that addresses this need. Figure I2 represents the project life cycle for managing a technology acquisition project. Figure I2: Technology acquisition project life cycle The process begins with the Initiation phase. All projects are initiated. Sometimes this process takes a few minutes and other times it takes months. The important thing to determine is what the business need is. You can then create a project or projects to implement the solution(s) selected to address that business need. The Initiation phase is described in greater detail in Chapter 1. Once the project has been properly initiated, the Planning phase begins. During this phase, the following tasks take place: Project plans are developed A project team is developed Requirements are defined and prioritized A solution is defined Vendors are identified and contacted. The Planning phase is described in greater detail in Chapter 2. All activities involved in researching the vendors and their technologies are included in the Research phase. There are several methods that can be used to research vendors. Chapter 3 provides a detailed description of several research methods and discusses when it is appropriate to use each method. Once you have completed the research, it is time to evaluate the results and select a vendor. These activities take place during the Evaluation phase. Chapter 4 provides a detailed description of the techniques used to evaluate and select a vendor. The activities involved in negotiating a contract with the selected vendor are part of the Negotiation phase. Chapter 5 discusses the negotiation strategy, tactics, planning, and documentation. After the technology is selected and the contracts are signed, the Implementation phase begins. Chapter 6 discusses the processes for developing, testing, and deploying vendor solutions. The final phase of the technology acquisition is the Operations phase. This process extends throughout the life of the product. Chapter 7 defines the details surrounding the continuing support process. Many case studies are inserted throughout the book. These examples are derived from reallife situations. A fictional name (Jack Smith) and company (XYZ Corporation) have been substituted in order to honor the confidentiality agreements that always exist in this type of project. The People Although few will argue the importance of process, the people involved in the technology acquisition are equally, if not more, important. People dynamics can make or break a technology acquisition. One of the most important objectives of the technology acquisition process is to objectify a subjective decision about which vendor and solution is best for your situation. The processes included in the project life cycle described in this book are designed to accomplish this by breaking a large subjective decision down into many small subjective and objective decisions. This will objectify the overall decision as much as possible. With that said, people will still have a significant influence on the final decision. At times, they will even override it. It is unrealistic to think that a process or a formula can provide the answer, with 100 percent accuracy, to such a complex question of which vendor and technology are best for your current situation. What a process can do is help people make a more educated decision and understand what is being decided. A significant portion of this book is dedicated to the people involved in the technology acquisition project and the roles and functions that they provide. Many groups of people are involved in a technology acquisition. Table I1 lists the primary groups involved in this type of project. Table I1: Technology Acquisition Teams and Members GroupOrganizationInvolvement Project sponsorCustomer or ITMedium Project stakeholdersCustomer, IT, and vendorLow Project managerCustomer or ITHigh Project teamCustomer and ITMedium Vendor sales teamVendor salesHigh Negotiation teamCustomer, IT, and legalMedium Internal Implementation teamCustomer and ITHigh Vendor Implementation teamVendor consultingHigh Internal support teamITMedium Vendor support teamVendor supportMedium End UserCustomerHigh The members and groups listed in Table I1 are discussed in greater detail in their appropriate chapters throughout the book. After reading these chapters, you should have a good understanding of who they are and what their roles, challenges, opportunities, and motives are. The Tools This book also provides a set of templates and sample documents that can be used in a technology acquisition project. Your company may already have standard templates for some of these documents. If not, these samples will help you create your own templates and documents for your first technology acquisition project. The sample documents were used in actual technology acquisition projects, but the data has been modified in order to honor the confidentiality agreements that are essential in this type of project. The samples shown are the best examples and formats used in a number of projects; all content has been modified to simulate a fictitious technology acquisition project. 020173804XP05302001

Read from the Book

Introduction A very large number of Information Technology (IT) projects fail every year. Some studies have shown that only one fourth of all IT projects undertaken by Fortune 500 companies are completed successfully. Others give IT projects only a 50 percent chance of being completed within time and cost budgets. Would you invest millions of dollars in a project with a 25 percent chance of success? IT managers are increasingly answering no to this question. So what is their alternative? Their alternative is to shift this risk to a third party. The risk can be reduced by acquiring technology from outside companies specializing in building technology instead of attempting to build it internally. The Shift from Building to Buying Technology There are many trends that are causing IT managers to shift from building to buying technology. One of these trends is an increase in demand for IT professionals. As technology becomes more critical to all businesses, the need for quality IT professionals increases. This increase in demand has caused the price of these resources to rise to a point where it is much more costly to develop technology in-house than ever before. One painful consequence of the IT resource shortage is that as demand for IT professionals far exceeds supply, companies are being forced to extend development schedules and limit their growth plans. Another trend is the increasingly high rate of change in new technology. As growth in technology accelerates, it becomes more difficult to keep up with current technology and remain competitive. Combine these trends, the high rate of IT project failure, the shortage of IT professionals and its impact on project schedules, and the increasingly high rate of change in technology, and it's no wonder that IT managers are starting to buy instead of build their technology whenever possible. The Ground Rules The goal of this book is to describe a way of managing a technology acquisition project that will facilitate the decision-making process so that you select the right vendor, with the right technology, for your business. The book also discusses how to implement and operate the technology once you have selected the vendor. Early in my career, I managed several software development projects. One day, I was asked to manage a project to acquire technology. I searched everywhere looking for information on how to manage this type of project. I perused bookstores, libraries, magazines, and the Internet looking for anything I could find on the subject. I found many books on the topics of project management, negotiation, outsourcing, software development, government technology acquisition, and business acquisition. But there was nothing that specifically addressed these topics in the context of acquiring technology for a typical business. I was forced to read several books on the topics previously listed in order to extract the information that would help me successfully manage this type of project. I eventually ended up creating my own project life cycle. After applying this project life cycle to several successful technology acquisition projects, I decided to share my findings with other project managers who are faced with the same challenges I faced. I am writing the book I wish I had before managing my first technology acquisition. I have tried to keep the information presented in this book at a level where it will be most useful to an experienced project manager who is new to managing a technology acquisition project. However, if you have 10 years' experience in managing technology acquisitions, you shouldn't jump to the conclusion that there is nothing here for you. This is not a book about managing government technology acquisitions or $100 million or more technology acquisitions. An experienced project manager who has never managed a technology acquisition will more than likely not get a chance to manage an acquisition of more than $10 million on his first project of this type. Additionally, a process this extensive would be difficult to justify on an acquisition of less than $500,000. This book is targeted at the experienced project manager who will be, or is, managing his first technology acquisition of $500,000 to $10 million. That said, there is also value for anyone who is involved with a technology acquisition. This includes executive management, IT management, project stakeholders, project sponsors, project teams, vendors, implementation teams, support teams, or any others who are impacted in some way by a technology acquisition project. As you read this book, you might find that this process is simple. I have elected to outline a step-by-step process that will be simple enough to use in your first technology acquisition project. As you gain experience, you may elect to modify this process or expand it to better fit your situation. My goal is to help you through the first project successfully while providing you with practical advice and techniques and an understanding of how to deal with the most important ingredient of any project, the people. The Technology Acquisition Project Life Cycle Many internal development efforts fail, and many trends are causing a shift from building to buying technology. Due to this increase in the acquisition of technology, there is a need for a project life cycle that project managers can use to manage an acquisition project. Before discussing the project life cycle, a few definitions are in order: Project: A temporary endeavor undertaken to create a unique product or service (The Project Management Institute, Project Management Body of Knowledge, 2000 Edition). Project life cycle: The division of a project into phases to provide better management control and appropriate links to ongoing operations of the performing organization. Collectively, the phases are known as the project life cycle (The Project Management Institute, Project Management Body of Knowledge, 2000 Edition). Technology acquisition: A project undertaken to acquire technology from a third party and implement it within the performing organization. With these definitions in order, let's move on to discussing a project life cycle for a technology acquisition project. There are many project life cycles available for the technology development project. These life cycles generally include phases for definition, design, development, testing, implementation, and operations. Figure I-1 illustrates some of the project life cycles for building technology. Figure I-1: Development project life cycles Many of the phases used in a development project are also used in a technology acquisition project. But, there are additional phases needed for a technology acquisition project life cycle to be complete. Although there are many project life cycles available for development projects, there isn't a generally accepted project life cycle for technology acquisition projects. When I was faced with my first technology acquisition project, I was unable to find a project life cycle that specifically addressed this type of project. Over the course of several years and several technology acquisitions, I was able to develop and fine tune a project life cycle that addresses this need. Figure I-2 represents the project life cycle for managing a technology acquisition project. Figure I-2: Technology acquisition project life cycle The process begins with the Initiation phase. All projects are initiated. Sometimes this process takes a few minutes and other times it takes months. The important thing to determine is what the business need is. You can then create a project or projects to implement the solution(s) selected to address that business need. The Initiation phase is described in greater detail in Chapter 1. Once the project has been properly initiated, the Planning phase begins. During this phase, the following tasks take place: Project plans are developed A project team is developed Requirements are defined and prioritized A solution is defined Vendors are identified and contacted. The Planning phase is described in greater detail in Chapter 2. All activities involved in researching the vendors and their technologies are included in the Research phase. There are several methods that can be used to research vendors. Chapter 3 provides a detailed description of several research methods and discusses when it is appropriate to use each method. Once you have completed the research, it is time to evaluate the results and select a vendor. These activities take place during the Evaluation phase. Chapter 4 provides a detailed description of the techniques used to evaluate and select a vendor. The activities involved in negotiating a contract with the selected vendor are part of the Negotiation phase. Chapter 5 discusses the negotiation strategy, tactics, planning, and documentation. After the technology is selected and the contracts are signed, the Implementation phase begins. Chapter 6 discusses the processes for developing, testing, and deploying vendor solutions. The final phase of the technology acquisition is the Operations phase. This process extends throughout the life of the product. Chapter 7 defines the details surrounding the continuing support process. Many case studies are inserted throughout the book. These examples are derived from real-life situations. A fictional name (Jack Smith) and company (XYZ Corporation) have been substituted in order to honor the confidentiality agreements that always exist in this type of project. The People Although few will argue the importance of process, the people involved in the technology acquisition are equally, if not more, important. People dynamics can make or break a technology acquisition. One of the most important objectives of the technology acquisition process is to objectify a subjective decision about which vendor and solution is best for your situation. The processes included in the project life cycle described in this book are designed to accomplish this by breaking a large subjective decision down into many small subjective and objective decisions. This will objectify the overall decision as much as possible. With that said, people will still have a significant influence on the final decision. At times, they will even override it. It is unrealistic to think that a process or a formula can provide the answer, with 100 percent accuracy, to such a complex question of which vendor and technology are best for your current situation. What a process can do is help people make a more educated decision and understand what is being decided. A significant portion of this book is dedicated to the people involved in the technology acquisition project and the roles and functions that they provide. Many groups of people are involved in a technology acquisition. Table I-1 lists the primary groups involved in this type of project. Table I-1: Technology Acquisition Teams and Members Group Organization Involvement Project sponsor Customer or IT Medium Project stakeholders Customer, IT, and vendor Low Project manager Customer or IT High Project team Customer and IT Medium Vendor sales team Vendor sales High Negotiation team Customer, IT, and legal Medium Internal Implementation team Customer and IT High Vendor Implementation team Vendor consulting High Internal support team IT Medium Vendor support team Vendor support Medium End User Customer High The members and groups listed in Table I-1 are discussed in greater detail in their appropriate chapters throughout the book. After reading these chapters, you should have a good understanding of who they are and what their roles, challenges, opportunities, and motives are. The Tools This book also provides a set of templates and sample documents that can be used in a technology acquisition project. Your company may already have standard templates for some of these documents. If not, these samples will help you create your own templates and documents for your first technology acquisition project. The sample documents were used in actual technology acquisition projects, but the data has been modified in order to honor the confidentiality agreements that are essential in this type of project. The samples shown are the best examples and formats used in a number of projects; all content has been modified to simulate a fictitious technology acquisition project. 020173804XP05302001

Table of Contents



Acknowledgments.


Reference Map.


Introduction.


1. Initiation.

The Initiation Process.

The Project Sponsor.

The Project Manager.

The Project Stakeholders.



2. Planning.

The Planning Process.

The Project Team.



3. Research.

The Research Process.

The Vendor Sales Team.



4. Evaluation.

The Evaluation Process.



5. Negotiations.

The Negotiation Process.

The Negotiation Team.



6. Implementation.

The Implementation Process.

The Internal Implementation Team.

The Vendor Implementation Team.



7. Operations.

The Operations Process.

The Internal Support Team.

The Vendor Support Team.

The End User.



Resources.


Index. 020173804XT05242001