Technology Acquisition: Buying the Future of Your Business

Description

• Copyright 2001
• Dimensions: 7-3/8" x 9-1/8"
• Pages: 216
• Edition: 1st

• Book
• ISBN-10: 0-201-73804-X
• ISBN-13: 978-0-201-73804-9
• eBook
• ISBN-10: 0-7686-8482-X
• ISBN-13: 978-0-7686-8482-7

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.



Extras

Related Articles

10 Keys to Successful Technology Acquisitions

Buy vs. Build

Identifying and Contacting Vendors

The Role of Leverage in a Technology Acquisition Negotiation

Why You Should Visit the Customer Site of a Prospective Vendor



Sample Content

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:
eskelinch2.pdf

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

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 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

Index

A

Account managers, 119-122

Accountability, 160

Administrators, contract, 52-54, 145

Agenda(s)

for meetings in the Evaluation phase, 128-129

for negotiations, 136, 139, 140

for project kick-off meetings, 59

Agreements. See also NDAs (nondisclosure agreements)

SLAs (Service Level Agreements), 45, 162, 165

written, importance of, 144-145

verbal, weakness of, 145

ALLPM.com Web site, 168

Analysts. See Technology analysts

Appendices, for RFPs, 74, 83

Applications architects. See Technology analysts

Approvals

for business needs, 5, 7

for project closures, 161

Architects. See Technology analysts

ASP (Application Service Providers), 135

Assessment

during the Evaluation phase, 62-64, 68-69, 125

external, 62-64, 68-69, 125

impact, in project charters, 8, 9

Assumptions, about business needs, 5, 7

Attorneys, 53, 142, 144-145

B

Backups, 163

Bandwidth, 151

Benchmarks

Evaluation phase and, 125

Research phase and, 62-65, 117-119

Best practices

evaluating, 41

industry, 41

internal, 41

Blackmail, 121

Books, recommended, 167

Bribery, 121

Budget cuts, 16-17

Business SMEs (subject matter experts), 52, 152-153

identifying good resources through, 53-54

retaining, importance of, 59

Business leads, 141

Business needs

addressing the wrong, 3-5

basic description of, 2

Initiation phase and, 2-7

sample, 6-7

summarizing, at meetings, 59

template for, 5

Buyer(s)

advantage, 137

-seller relationship, 134-135

C

Capability Maturity Model (CMM), 68

Cause, champions of, 14

Change(s)

management, 17, 26, 28

to products, 164

Character. See also Integrity

of undesirable team members, 55-57

of vendors, 121

Charters, project

basic description of, 5

communicating, 12

Initiation phase and, 2, 5-7

sample, 9

summarizing, at meetings, 59

templates for, 7-11

Clarity, increased, through RFPs, 70

Closure, project, 157-158, 159-161

CMM (Capability Maturity Model), 68

Commitment, facilitation of, through RFPs, 70

Communication

of performance expectations, 58

of project charters, 12

Compatibility, verifying, 149-150

Competencies, core, 44-45

Competition

creating more, through vendor conferences, 114

Planning phase and, 43, 45

project managers and, 17-18

Research phase and, 121

Computing environment

monitoring, 163

testing, 118

Concept, proof of, 117

Conferences, vendor, 62-64, 114-117, 126

Confidentiality. See also Confidentiality agreements; NDAs (nondisclosure agreements)

lack of, 67

of RFPs, 83

Confidentiality agreements. See also Confidentiality; NDAs (nondisclosure agreements)

Initiation phase and, 17

new technology and, 17

Consensus, getting, 21

Consistency, provided by RFPs, 70

Context, of business needs, 5, 6

Contract administrators, 52-54, 145

Contracts. See Agreements

Core competencies, 44-45

Cost(s)

long-term, 101

management plan, 26, 30

requirements, 36

of research, 65, 74, 79, 83, 100-103, 106-107, 112-118

specification of, in RFPs, 74, 79, 83, 100-101

Customer(s)

references, 35-36, 108-109, 111, 121

retaining, 19, 20

satisfaction of, with prospective vendors, 35-36, 108-109, 111, 121

site visits, 62-64, 81, 110-113, 126

strategic, 137

D

Data analysts. See Technology analysts

Data architects. See Technology analysts

Data flexibility, in RFPs, 94-95

Deal sheets, for negotiations, 142

Decision making. See also Priorities

decision scoring matrix for, 38-40

documentation supporting, 159-160

Evaluation phase and, 124-125, 127-130

Operations phase and, 159-160

Negotiation phase and, 141-142, 145-146

Planning phase and, 38-40

project sponsors and, 15

surprises that surface after, 128

Defects, fixing, 164

Demos, on-site, 62-64, 105-108, 126

Deployment

Implementation process and, 148, 150-153

support, 153

Depreciation cycles, for products, 135

Design

Implementation process and, 148-149

project life cycles and, xvii

Development, during the Implementation phase, 148, 149, 154

Disaster recovery, 163

Discussion boards, support via, 164

Documentation. See also Templates

assembling, into project notebooks, 159

libraries, 159

during the Operations phase, 159

project closure and, 159-160

through RFPs, 70-71

supporting decisions, 159-160

vendor selection summaries, 129-130

E

Economic conditions, 18

Education. See also Training

Operations phase and, 160

through RFPs, 70

vendor, 106, 115

E-mail

newsletters, 166

support via, 164

"Empire building," use of the term, 40

Employee(s)

retail, 19, 20

satisfaction, 9

End users

basic description of, xx-xxi

Operations phase and, 165-166

support for, 165-166

Enhancements, 157-158

Environment, computer

monitoring, 163

testing, 118

Evaluation phase

assessment during, 62-64, 68-69, 125

basic description of, 123-132

case studies, 128

checklist, 132

end user support and, 162

making sure to complete, before making decisions, 62

number of vendors you should enter into, 49

project life cycles and, xvii-xix

scenario planning and, 126-127

subprocesses of, 123-124

technology analysts and, 52

tips, 129

Executive management

decisions, which become obstacles, 17

Initiation phase and, 17, 20

presentations, at project team meetings, 60

Research phase and, 120

stakeholders with influence on, 20

Experience

gained through benchmarks/pilot research, 118

past, finding vendors through, 48

of vendors, 99, 109, 111

Experts, industry

hiring, 47

identifying possible vendors through, 47

Extensibility, in RFPs, 90

External assessment, 62-64, 68-69, 125

F

Facilitators, 144

"First to a market," 137

Fixes, 157-158

Forecasting, in RFPs, 85

Formalization, through RFPs, 70

Fortune 500 companies, xv

Functionality requirements, in RFPs, 30-31, 73, 79, 83, 84. See also Requirements definition

G

GUI (graphical user interface), 3-4

H

Hardware

cost of, 100

maintaining, 163

Human resource management plan, 26, 28-30

I

Impact assessments, in project charters, 8, 9

Implementation phase. See also Implementation teams

basic description of, 147-155

case studies, 151

checklist, 152

deployment and, 148, 150-153

project life cycles and, xvii-xix

project managers and, 152-154

in RFPs, 99

subprocesses of, 148-152

testing and, 148, 149-150

Implementation teams. See also Implementation phase

basic description of, xx-xxi, 154-155

internal, 152-154

Industry experts

hiring, 47

identifying possible vendors through, 47

Initiation phase

accountability and, 14-15

basic description of, 1-22

business needs and, 2-7

case studies and, 12

checklist, 12

decision making and, 15

executive management and, 17, 20

getting consensus and, 21

integrity and, 18

project charters and, 2, 5-12

project life cycles and, xvii-xix

project managers and, 15-18

stakeholders and, 16, 18-21

templates for, 5, 7-11

two subprocesses of, 2-3

Insurance, 160

Integration, in RFPs, 97

Integrity

of researchers, 66, 68

of vendors, 109, 111, 121

ISO (International Organization for Standardization), 68

Issue management plan, 25, 27

L

Lawyers, 53, 142, 144-145

Leadership

basic description of, 13

discussion of, in RFPs, 99

management and, difference between, 13

vendors and, 35

Leads, business, 141

Legal representatives, 53, 142, 144-145

Letter(s)

of intent (LOI), 25, 49, 72

of transmittal, 76-78, 82

Leverage, in negotiations, 136-138, 139, 140

Life cycle, project, xvii-ix, 1. See also specific phases

M

Magazines, finding prospective vendors through, 48

Maintenance, during the Operations phase, 163

Management. See also Managers, account; Managers, project

basic description of, 13

of change, 17, 26, 28

decisions, which become obstacles, 17

Initiation phase and, 17, 20

leadership and, difference between, 13

presentations, at project team meetings, 60

Research phase and, 120

stakeholders with influence on, 20

Managers, account, 119-122

Managers, project, 54, 154

basic description of, xx-xxi, 51-52

Implementation phase and, 152-153

Initiation phase and, 15-18

maneuvering of projects by, through organizations, 16-18

Negotiation phase and, 141

objectivity and, 15-16

Market conditions, 18

Marketing references, in RFPs, 81

Meetings. See also Negotiations

agendas for, 128-129

in the Evaluation phase, 128-129

project kick-off, 59-60

Monitoring, during the Operations phase, 163

Motives, of stakeholders, 16

N

Name recognition, 137

NDAs (nondisclosure agreements). See also Agreements; Confidentiality

basic description of, 50

Evaluation phase and, 131

Planning phase and, 25, 50

Research phase and, 62, 67

Needs, business

addressing the wrong, 3-5

basic description of, 2

Initiation phase and, 2-7

sample, 6-7

summarizing, at meetings, 59

template for, 5

Negotiation(s). See also Negotiation phase

agendas for, 136, 139, 140

deal sheet, 142

between decision makers, 141-142, 145-146

leverage in, 136-138, 139, 140

teams, xx-xxi, 139, 141, 144-146

Negotiation phase. See also Negotiations

basic description of, 133-146

checklist, 143-144

number of vendors you should enter into, 49

planning, 141-142

project life cycles and, xvii-xix

strategies, 134-141

template, 139, 142

Network(s)

architecture, in RFPs, 90

-user relationships, 135-136

Network communication architects. See Technology analysts

Newsletters, e-mail,166

O

Objectives, in project charters, 7-8, 9

Objectivity

gained through RFPs, 71

Initiation phase and, 15-16

of vendor reference call research, 109, 112

Operations phase

basic description of, 157-162

checklist, 161

end users and, 165-166

project life cycles and, xvii

subprocesses of, 157-158

support issues and, 157-159, 162-165

P

Payment options, 101

People, primary groups of, involved in proejcts, xx-xxi. See also Teams

Performance

expectations, for project teams, 58

proof of, 117

Pilots

Evaluation phase and, 125

Research phase and, 62-65, 117-119

testing, 150

Plan(s). See also Planning phase

basic description of, 24, 25-37

change management plans, 26, 28

cost of, 26, 30

human resource management plans, 26, 28-30

issue management plans, 25, 27

product management plans, 26, 28

quality management plans, 26, 28

release management plans, 26, 28

review meetings, 27-28

risk management plans, 25, 27

templates, 25-37

Planning phase. See also Plans; Project teams

basic description of, 23-60

case studies for, 55

checklist, 50

decision making and, 38-40

industry experts and, 47

priorities and, 36-47

project life cycles and, xvii-xix

project plans and, 25-37

solutions and, 24-25, 42, 40-47, 59

subprocesses of, 24-25

templates, 38-40

POS (Point of Sale) systems, 19

PPR (Project Plan Review) meetings, 27-28

Pricing

effective dates of, 81

specification of, in RFPs, 81, 100-101

scope, 100

Priorities. See also Decision making

approval of, 40

basic description of, 24

defining, 21, 24, 37

Negotiation process and, 138-139

Planning phase and, 36-47

Product(s)

management plan, 26, 28

seeing/visualizing, 102, 105, 110, 115, 117

Programmer analysts. See Technology analysts

Project(s)

closure, 157-158, 159-161

kick-off meetings for, 59-60

overviews, in RFPs, 73, 82

use of the term, xvii

Project charters

basic description of, 5

communicating, 12

Initiation phase and, 2, 5-7

sample, 9

summarizing, at meetings, 59

templates for, 7-11

Project life cycle xvii-ix, 1. See also specific phases

Project Management Institute 167-168

Project management plan, 25, 27

Project managers, 54, 154

basic description of, xx-xxi, 51-52

Implementation phase and, 152-153

Initiation phase and, 15-18

maneuvering of projects by, through organizations, 16-18

Negotiation phase and, 141

objectivity and, 15-16

Project plan(s)

basic description of, 24, 25-37

change management plans, 26, 28

cost of, 26, 30

human resource management plans, 26, 28-30

issue management plans, 25, 27

product management plans, 26, 28

quality management plans, 26, 28

release management plans, 26, 28

review meetings, 27-28

risk management plans, 25, 27

templates, 25-37

Project Plan Review (PPR) meetings, 27-28

Project schedule(s). See also Scheduling

basic description of, 26-30

sample, 31

Project sponsor(s)

accountability and, 14-15

basic description of, xx-xxi, 13

as champions of a cause, 14

as decision makers, during the Implementation phase, 145-146

Initiation phase and, 13-15

presentations, 59

Project team(s)

authority over, 57-58

basic description of, xx-xxi, 51

case studies for, 55

defining and communicating performance expectations for, 58

defining reporting relations for, 57-58

identifying good resources for, 53-54

implementation teams, xx-xxi, 152-155

negotiation teams, xx-xxi, 139, 141, 144-146

Planning phase and, 51-55

roles, 51-53, 54

securing resources for, 57-59

support teams, xx-xxi, 162-165

undesirable members of, 55, 56-57

vendor implementation teams, 154-155

vendor sales teams, xx-xxi, 119-122

Proof of concept, 117

Purchasing leads, 141

Q

Q&A (question and answer) sessions, 108

Quality management plan, 26, 28

R

R&D (research and development), 43-44. See also Research phase

Real-time adherence requirements, in RFPs, 89

Recoverability, of software, in RFPs, 96

Redundancy, in RFPs, 92

References, 35-36, 111, 121

calling, 108-110

in RFPs, 99-100

Release management plan, 26, 28

Reliability, in RFPs, 92

Reporting requirements, in RFPs, 88

Requirements definition

basic description of, 24, 30-33

functionality requirements, 30-31, 73, 79, 83, 84

technology requirements, 33-34, 74, 79, 83, 89-97

Research. See also Research phase

benchmark/pilot method of, 62-65, 117-119, 125

and development (R&D), 43-44

external, 62-64, 65-68, 125

evaluation methods, 124-125

firms, identifying possible vendors through, 47-48

thoroughness of, dependency on, 67, 69

unstructured, 125-127

vendor reference call, 108-110

Research phase. See also Research

basic description of, 61-122

checklist, 119

competition and, 45

costs and, 65, 74, 79, 83, 100-103, 106-107, 112-118

end user support and, 162

pricing and, 81, 100-101

project life cycles and, xvii-xix

scheduling and, 86-87, 103, 107, 115, 118

strategic partnerships and, 74, 79, 83, 98

subprocesses of, 61-70

support issues and, 98-99, 101-103

technology analysts and, 52

templates, 72-101

tips, 67-69, 104, 107-108, 110-113, 116-119

using information gathered during, as leverage in

negotiations, 136-137

Request for Proposal (RFP). See RFP (Request for Proposal)

Request for Information (RFI). See RFI (Request for Information)

Resource(s)

development planning, for project teams, 58-59

securing, 57

Return on Investment (ROI), 44, 117, 135

RFI (Request for Information), 49

RFP (Request for Proposal)

appendices for, 74, 83

basic description of, 69-72, 125

consistency provided by, 70

cost specifications in, 74, 79, 83, 100-101

Evaluation phase and, 125

exceptions to, 83

increased clarity gained through, 70

Planning phase and, 32, 33, 34

purpose of, 80

Research phase and, 61-64, 69-101

templates for, 72-101

Right to reject, 81

Risk

of building technology solutions, 44

legal, minimizing, through RFPs, 71

management plan, 25, 27

in project charters, 8, 9

ROI (Return on Investment), 44, 117, 135

S

Sales management, 120

Scalability

discussion of, in RFPs, 90

proof of, 117

Scenario planning, 126-127

Scheduling. See also Project schedules

benchmarks and pilots, 118

challenges, 103, 107, 115

by demand, 86

optimal, 87

Research phase and, 86-87, 103, 107, 115, 118

in RFPs, 86-87

vendor conferences, 115

Scope, in project charters, 8, 9

Security, specifications regarding, in RFPs, 95

SLAs (Service Level Agreements), 45, 162, 165

SMEs (subject matter experts), 21, 37, 52, 152-153

identifying good resources through, 53-54

retaining, importance of, 59

Software

cost of, 100

maintaining, 163

Solutions

defining, 24-25, 40-47

four methods for identifying, 42

generating interest in new, 165-166

hiring external experts to define, 42

summarizing, at meetings, 59

Sponsors, project

accountability and, 14-15

basic description of, xx-xxi, 13

as champions of a cause, 14

as decision makers, during the Implementation phase, 145-146

Initiation phase and, 13-15

presentations, 59

Stakeholder(s)

approval, in project charters, 8, 9

basic description of, xx-xxi, 18-19

Initiation phase and, 18-21

motives of, 16, 19-20

project managers and, 16

Store managers, 19

Strategic partnership(s)

information regarding, in RFPs, 74, 79, 83, 98

requirements, 34-36

Success

celebrating, 160

measuring, during the Operations phase, 160

measuring, in project charters, 8, 9

Supply chains, 19, 20

Support

analysts, on implementation teams, 154

capabilities, evaluating, 102-103

end user, 162-163

factors, for business needs, 5, 6-7

operational, 163-164

providing adequate, 44

requirements, 35

specifications regarding, in RFPs, 98-99, 101

teams, xx-xxi, 162-165

Systems analysts. See Technology analysts

T

Table of contents, in RFPs, 73, 82

Tactics, for negotiations, 139, 141

Team(s)

authority over, 57-58

basic description of, xx-xxi, 51

case studies for, 55

defining and communicating performance expectations for, 58

defining reporting relations for, 57-58

identifying good resources for, 53-54

implementation teams, xx-xxi, 152-155

negotiation teams, xx-xxi, 139, 141, 144-146

Planning phase and, 51-55

roles, 51-53, 54

securing resources for, 57-59

support teams, xx-xxi, 162-165

undesirable members of, 55, 56-57

vendor implementation teams, 154-155

vendor sales teams, xx-xxi, 119-122

Technology

acquisition, use of the term, xvii

building versus buying, xv-xvi, 43-47

owning versus using, 134

proof of, 117

requirements, 33-34, 74, 79, 83, 89-97

Technology analysts, 52, 54

TechnologyAquisition.com Web site, 166, 167

Templates. See also Documentation

business need, 5

decision scoring matrix, 38-40

Initiation phase, 5, 7-11

project charter, 7-11

project plan, 25-37

RFP, 72-101

Tender transactions, 32-33

Testers, assigned to implementation teams, 153

Testing. See also Benchmarks

computing environments, 118

horizontal, 150

Implementation process and, 148, 149-150

project life cycles and, xvii

specification of, in RFPs, 96

system, 150

user, 150

vertical, 150

Time constraints, in project charters, 8, 9. See also Timelines

Timelines

for research, 66, 67, 107, 108

specification of, in RFPs, 80

for vendor conferences, 114

Trainers, 153, 154. See also Training

Training. See also Trainers

manuals, 164

Operations phase and, 164

requirements, 35

in RFPs, 98

U

Upgrades, providing adequate, 44

User groups, 164-165

Users, end

basic description of, xx-xxi

Operations phase and, 165-166

support for, 165-166

V

"Vaporware," 110, 117

Vendor(s)

communicating results to, 131-132

comparing, 34-40

conferences, 62-64, 114-117, 126

contacting, 24-25, 47-50

creating a list of, 48-49

customer site visits, 62-64, 81, 110-113, 126

establishing relationships with, 121-122

evaluating, 102

guidelines, in RFPs, 73, 79, 82

identifying prospective, 24-25, 47-50

implementation teams, 154-155

importance of your business to, evaluating, 115

Initiation phase and, 17

interface with, lack of, 66-67

on-site demos, 62-64, 105-108, 126

Planning phase and, 24-25, 47-50

profiles, 35, 98

references calls, 62-64, 108-110, 126

responses, to RFPs, 80

sales teams, xx-xxi, 119-122

site demos, 62-64, 101-105, 126

support team, 164-165

technical knowledge of, evaluating, 103

Vendor Selection Summary document, 129-130

Visualization, of products, 102, 105, 110, 115, 117

W

Web sites, recommended, 166, 167-168

"Word of mouth," finding resources via, 48



Updates

Submit Errata

