eBook
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
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.
Product Details
| ISBN-13: | 9780768685091 |
|---|---|
| Publisher: | Pearson Education |
| Publication date: | 06/05/2001 |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 216 |
| File size: | 3 MB |
About the Author
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.
020173804XAB06042001
Read an Excerpt
PREFACE:
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 ofIT 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.
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.
Preface
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 shortageofIT 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.