Home > Store > Software Development & Management > Management: Lifecycle, Project, Team

Technology Acquisition: Buying the Future of Your Business

Register your product to gain access to bonus material or receive a coupon.

Technology Acquisition: Buying the Future of Your Business

Best Value Purchase

Book + eBook Bundle

  • This product currently is not for sale.
  • About Adobe DRM eBooks
  • This eBook requires the free Adobe® Digital Editions software.

    Before downloading this DRM-encrypted PDF, be sure to:


    • Install the free Adobe Digital Editions software on your machine. Adobe Digital Editions only works on Macintosh and Windows, and requires the Adobe Flash Player. Please see the official system requirements.
    • Authorize your copy of Adobe Digital Editions using your Adobe ID (select AdobeID as the eBook vendor). If you don't already have an Adobe ID, you can create one here.

More Purchase Options

Book

  • Your Price: $27.99
  • List Price: $34.99
  • Available on demand.

eBook (Adobe DRM)

  • Your Price: $22.39
  • List Price: $27.99
  • About Adobe DRM eBooks
  • This eBook requires the free Adobe® Digital Editions software.

    Before downloading this DRM-encrypted PDF, be sure to:


    • Install the free Adobe Digital Editions software on your machine. Adobe Digital Editions only works on Macintosh and Windows, and requires the Adobe Flash Player. Please see the official system requirements.
    • Authorize your copy of Adobe Digital Editions using your Adobe ID (select AdobeID as the eBook vendor). If you don't already have an Adobe ID, you can create one here.

Description

  • Copyright 2001
  • Dimensions: 7-3/8x9-1/4
  • Pages: 208
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-73804-X
  • ISBN-13: 978-0-201-73804-9
  • eBook (Adobe DRM)
  • 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.

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

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

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

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

More Information

Unlimited one-month access with your purchase
Free Safari Membership