Successful Implementations Report

© KeyInterval Research | keyinterval.com | Page 1
Successful Implementation
About KeyInterval Research
KeyInterval is a practitioner centric market research firm. We survey practitioners in HR and Recruiting to
discover what their work with technology is like. We work at the intersection of HR and Technology. We use a
blend of quantitative and qualitative research to see beyond the more traditional vendor centric view.
The company is driven by the curiosities of its founders, William Tincup and John Sumser. Our goal is to
provide practitioners with a clear view of what actually happens when their peers and colleagues go to work.
We help practitioners understand what is working in the day to day business of HR. We do this by
investigating the realities of work in the HR practitioners’ world. We make maps that help practitioners to work
more effectively and vendors to supply better technology.
As long term participants in the HR ecosystem, we’ve heard a lot of stories about how things work or don’t.
We’ve originated, repeated, recycled, learned and catalogued much of the folk wisdom that passes for rational
thought in HR. We are pretty sure that the realities of HR work are substantially different from the ways they
are portrayed.
We want to discover what is true and accurate. We want to separate that from wishful thinking. We are
mapping the realities of our industry. We will have better questions and better answers as time goes on.
The explosion of technology makes it possible to replace anecdote with fact. Our work combines quantitative
research (surveys) with qualitative (interviews and focus groups). The big vision is to replace fiction with fact
and to sharpen the things that are true.
H
ow to Contact Us
Web: keyinterval.com
Phone: 415.683.0775
Twitter: @keyintervalR
William Tincup: Principal Analyst
@williamtincup
william@keyinterval.com
+1.469.371.7050
John Sumser: Principal Analyst
@johnsumser
john@keyinterval.com
+1.415.683.0775
Copyright 2015 by KeyInterval Research, all rights
reserved. You many not copy, duplicate, or share
this report with anyone, ever. No, not even a teensy-
weensy part of it. If you do, bad things will happen
and all your hair will fall out. Well, maybe not that
last bit. Really, this is proprietary and protected by
copyright. So don’t copy or share. Love, Legal.

Table of Contents
About KeyInterval Research 1
How to Contact Us 1
Introduction 3
Implementation 5
Implementation Defined 5
Variations by Size and Complexity 6
Where Expectations Are Set (Time to Value) 7
Elements of Implementation 8
Important Insights and Major Findings 10
Overview 10
About Transformation 11
Reference Checking 13
Scope, Schedule and Budget 14
Administration (Changes) 15
SOW, SLA or Both? 16
Implementation Team 17
Data 19
Communicating Progress, Problems and Success 20
Why Projects Go Off Track 21
Qualitative Conversations 23
Why Is There No Definition of Excellence? 26
Why Is There No Professional Implementation Training? 28
The SaaS Paradox: Those Changes 28
Mark Berry on Implementations 29
Data Points 32
Overview 33
Myth Busting—Management Support 36
Notables 38
Notable for Administration 39
Notable for Implementation 40
Notable for Training 41
Vendor I Would Most Like to Work With 42
Methodology 43
The Story of the Data 43
Position: Distribution by Function by Company Size 44
Role: Distribution by Role by Company Size 45
How We Collected Data 45
Geographical Distribution of Responses 46
Responses by Industry 47
Pocket Guide: Successful Implementation Checklist 48
Research Calendar 51
Acknowledgements 51

Introduction
KeyInterval is an HR practitioner research company. We examine the intersection of HR workers and the
technology that they use. Through a blend of very large scale quantitative surveys and in depth qualitative
interviews, we are examining and re-examining core assumptions about the meaning and utility of
HRTechnology.
It is a search for standard practices. We are more interested in what practitioners do than what vendors,
analysts, and consultants think they should do. Our goal is to understand the actual experience of the people
who use HR Technology. Then, we want to present it back to practitioners as a toolset based on our findings
about what works.
Since the data in this report is exclusively focused on success, there are some things we could not do in our
analysis. We have no cautionary tales to tell. We cannot warn of things that cause a project to fail. We cannot
wag our fingers and tell you what you what not to do.
This report is exclusively focused on the attributes of success.
In the following pages, you’ll discover actionable intelligence about what it takes to have a Successful
Implementation based on input from 824 people who were a part of one. We round out the story with input
from qualitative interviews.
This report exclusively focuses on the attributes of success. We did not investigate and do not describe the
practices that put projects at risk. We cannot tell you what causes failure.
There is one finding that informs all of the rest of the report.
82% of successful Implementations were Transformation Projects.
(Sometimes, organizations purchase software to improve the effectiveness and efficiency of an existing way
of doing things. These kinds of projects are called Optimization Projects. Other times,they purchase software
as a way of changing the existing way of doing things. These are called Transformation Projects.)
Said another way, only 18% of successful Implementation Projects were purely technical, or Optimization
“Our goal is to
understand the actual
experience of people
using HR Technology,
and present it back as
a toolset based on what
works.
”

Projects.
In the pages of the report, you’ll find the actions and attributes that characterize success:
Chapter 2. Implementations sets the stage with definitions and an analytical framework.
Chapter 3. Important Insights and Major Findings lays out the big picture.
Chapter 4. Qualitative Conversations summarizes our interactions with our advisory panel.
Chapter 5. Data Points is a crisp run through the survey results
Chapter 6. Myth Busting takes a good look at management support.
Chapter 7. Notables is our unique format for presenting practitioner views of who matters.
Chapter 8. Methodology shows who we surveyed and the demographic data on respondents’ industry,
company size, and geographic locations.
Chapter 9. The Pocket Guide/Checklist is a quick gateway to the material.
“This report is
exclusively focused
on the attributes of
success.
”

Implementation
This report describes what makes a software Implementation successful, what that means, and how companies
plan for and execute the addition of new software in getting work done.
Implementation Defined
Implementation is the activity that happens between the time the purchase agreement is signed and when a
company is fully using an HR Technology tool or system. The goal of Implementation is to have the right people
using the new technology, in the right way, to accomplish organizational objectives.
Implementation is the process by which software is integrated into the organization’s workflow.
A vendor’s fees for Implementation are roughly 1/3 of the overall software purchase price. Additional costs
include the time, energy, and resources consumed by the organization that is installing the software. So
consideration of Implementation is an important part of any software purchasing decision.
Some vendors provide incentives for the Implementation process by deferring all billings until the software is up
and running and Implementation is complete.
Implementation, its associated expenses, and the interruption of ongoing business processes are also why
Software as a Service (SaaS) solutions were designed. In theory, a SaaS system requires no new code
(customization). Since SaaS installations are a matter of configuration rather than customization, they are
supposed to be easier, less costly, and faster.
The reality is not quite as good as the theory. Large scale Implementations can take weeks, months, and
sometimes years, even with SaaS solutions.
“The goal is to have
the right people using
the right technology,
in the right way, to
accomplish organizational
objectives.
”

Variations by Size and Complexity
T
he term Implementation is loosely
applied to any integration of software
into a company’s workflow. There are
three important dimensions to think about
with any Implementation:
• The Number of Affected Locations
(Branches, Plants or Offices)
• The Complexity of the Software (From
App to Unique Systems Integration?)
• The Complexity of the Organization (Is
it a one function focused business or is it
a large, distributed project house run as a
matrix?)
In this report, we won’t spend time on
the nuances of these differences. In our
qualitative interviews we found that,
while the size, scope, and complexity of
an Implementation are very important
from a planning perspective, Successful
Implementations had many principles in
common and practitioners used the same
language regardless of project size. This
report focuses on those similarities and
principles of success, and our research
shows no meaningful variability across
settings.

Where Expectations Are Set (Time to Value)
Increasingly, people’s experience downloading software in the consumer marketplace set the expectations for
how a workplace Implementation should go. If a smartphone app can be installed and running in two minutes,
then why can’t enterprise software? The buyers sometimes have an unrealistic view that their consumer
experience can be repeated at work.
Yet, there is a large gap between consumer and business software. The time and planning involved for a
business software Implementation is one place where size and scope does matter.
There are also fundamental differences between how consumer software and workplace software are
purchased, used, and what they do. They serve two radically different functions. The consumer market serves
millions of individuals with unrestricted decision making authority, while a business software market serves
individuals whose decision making is tightly constrained.
To get consumers productive, no collaboration, process improvement, departmental sign off, or budget
approval is required. To get an organization productive, a team response is required for just about anything,
particularly the use of companywide software.
Consumers flip the switch and it works. When it doesn’t, they generally rely on very specific documentation,
access to support (if any), and Internet based community service. Business software doesn’t have those same
economics. Software vendors must invest in providing technical support to all of its customers, sometimes with
actual people making on-site visits.
The cost of development is also different between consumer and business software. Award winning experience
in consumer products can be amortized across tens of millions of users. That creates a single piece of software
with very standard use cases. Development can be measured in cents or dollars per customer.
B2B software is amortized across a much smaller base, is not uniform in its functionality, and must be sold to
buyers whose interests often conflict with end users’ interests. Inherent task complexity makes consumer-like
interface design counterproductive.
S
till, the expectation of a very short
time between purchase and value
is norm. Expectations will only
get higher as consumer tech more fully
penetrates our lives. Both managers and
vendors will have to navigate the difference
between user expectations and reality.
But from one very important perspective—
the actual experience of the user— software
is software. In the absence of B2B software
development experience, it’s hard to
imagine that the economics and business
models are even an element of user
experience. Users just want the software to
work.
The good news is that our research
continues to show that users are generally
satisfied with their software. It is possible
(and we will cover it in a later report) that
any dissonance exists only between the
buyer and the vendor.

Elements of Implementation
In this report, we used the following definitions and ideas as we explored the factors in a successful
Implementation.
• Project Mission
It turns out that the Project Mission is a pivotal driver of success. 82% of successful Implementations are
projects that were intended to transform their organization. The framing of the Project Mission is what
determines the level of resource availability and management support.
• Contract
Implementation begins before the contract is signed. A predictor of success is that the Implementation
Teams meet each other before the contract is signed. The contract nearly always includes a Statement of
Work (SOW), a Service Level Agreement (SLA) or both. Formally, Implementation begins the moment the
contract is signed.
• Implementation Team(s)
Both the vendor and the practitioner have at least one Implementation Team.
• Management Involvement
While we discovered some surprising things about management involvement, every Successful
Implementation has some level of management support. It ranges from a passive reporting relationship to
hands on day to day involvement.
• Implementation Project
This is the work that gets done by the group composed of the two Implementation Teams. It includes
configuring, customizing, installing, testing, modifying, and updating the software. When the software
project is Transformative, Implementation also includes other elements of workflow modification and even
organization redesign.
“A predictor of
success is that the
Implementation Teams
meet each other
before the contract is
signed.
”

Elements, Cont’d.
• Training
Once the software is in place, the Implementation Teams work with the community of users (practitioners,
their managers and company employees) to train (to varying degrees) the users in the use and maintenance
of the system. In this report, training includes support documents, embedded help, on the job training
(OJT) and consulting that optimizes user performance.
• The Inevitable Disaster
Most successful Implementations go through a period when the project goes awry. A significant subset,
about 32%, of Implementations don’t, but 68% do. Smart planning means allowing for delays and disaster
in the basic Implementation plan.
• Acceptance (Sign Off)
In theory, Implementation is complete when the requirements of the vendor’s contract have been met. ‘Sign
Off’ refers to the process by which vendor performance is evaluated and approved.
• User Satisfaction
There is a bit of disconnect between software buyers and their management. Both users and executives
see User Satisfaction as a better indicator of project completion than simply Acceptance. There is generally
a lag between the Acceptance and optimal system performance.
“Both users and
executives see User
Satisfaction as a better
indicator of project
completion than simply
Acceptance.
”

Overview
Successful Implementations begin well in advance of the contract being signed. 92% of the respondents
participated in the evaluation process. Understanding the intent of the contract by participating in vendor
selection prepares the Implementation Team for the work ahead.
O
ur survey examined 824 stories
of successful Implementations
spread across a broad range of
organization size, industry, and location.
The Methodology section defines that
process in detail.
89% of the Implementation Projects
covered by the survey affected the entire
workforce (as opposed to Implementations
that were part of a departmental endeavor).
The results of our survey are broadly
applicable across company sizes and
industries. This section details our major
findings.
Important Insights and Major Findings

About Transformation
Successful Implementation Projects are Transformational. W
hen we designed the survey,
we believed that Transformation
Projects would be the hardest
subjects to document. Our question read:
“Was your last important software
implementation a Transformation Project?
(Sometimes, organizations purchase
software to improve the effectiveness and
efficiency of an existing way of doing things.
These kinds of Projects are called
Optimization Projects. Other times, they
purchase software as a way of changing
the existing way of doing things. These are
called Transformation Projects.)”
We were surprised to see that 83% of
respondents characterized their successful
Implementation Project as a Transformation
Project. We believe this means that
Transformational Projects are significantly
more likely to succeed.

The notion that Transformational Projects are where Implementation success lies is counterintuitive. Much of
the conventional wisdom suggests that Implementation is always a difficult challenge, so that the larger the
scope of the Project, the larger the risk. These results tell us about the quality and quantity of management
support associated with a transformative initiative.
“Conventional
wisdom suggests that
Implementation is always
a difficult challenge.
”

Reference Checking
W
hile virtually all respondents
considered the vendor’s reputation
before awarding the contract (96%),
a smaller (but still significant 84%) actually
checked references. Of the group that
checked references, 84% used independently
sourced recommendations to some extent.
During the reference checking process, the
following topics were discussed:
1. Whether the software worked: 30%
2. The vendor’s response to
problems: 72%
3. How the vendor treated the
customer: 64%
4. Whether the customer trusted
the vendor: 53%
5. Other potential references: 20%

Scope, Schedule and Budget
Building the Implementation Plan involves having a detailed grasp of all of the Implementation Activities in
advance of the Project.
A Good Implementation Plan includes:
The Project Schedule (a detailed definition of project tasks and their relationship to each other)
The Budget (hard and soft cost elements)
The Project Scope (the contract SOW plus internal work)
Work Assignments (team members and their roles)
Risks and Risk Mitigation
In each element, both the internal and external resources should be clearly defined.
Internal
Budget
External
Budget
Project
Schedule
Project
Scope
Vendor Defined 27% 38% 43% 38%
Internally Defined 53% 42% 40% 47%
3rd Party Defined 11% 10% 10% 9%
Did Not/Don’t Know 9% 10% 7% 6%
T
here are several ways to determine
and manage the flow of work in an
Implementation Project. There is
an argument for having a vendor define
the Project. They have broad experience
across a large range of circumstance.
There is a powerful argument for building
internal estimates and managing to them.
This seems particularly important on
situations where vendor-customer trust is
tentative.
Of course, there are amazing third party
firms whose business is the definition and
execution of Implementation programs.
We asked how the elements of the Plan
were estimated.
In almost 40% of cases, the vendor had a
broad charter to define budget, schedule,
and scope parameters. A slightly larger
proportion of success stories feature
internal definition of key project estimates.
Third parties seem to run the show about
10% of the time.

Administration (Changes)
We investigated the question of changes. Missed requirements, misunderstood nuances, unanticipated
interruptions, and a host of other circumstances require complex interactions between vendor and practitioner
during Implementation. We wanted to understand what practitioners do when predictable changes happen.
1. Ask the vendor for an estimate of costs involved....................38%
2. Offer to participate in the Customer Advisory Board..............15%
3. Organize other users to demand a change.............................15%
4. Embed the problem in the contract renewal process..............14%
5. Use other forms of leverage......................................................9%
6. Say “We thought we paid for that.”...........................................5%
7. Call in a favor or two from the vendor.......................................4%
“Building internal
estimates and managing
to them seems
particularly important
when vendor-customer
trust is tentative.
”

SOW, SLA or Both?
T
ypically, a Statement of Work
(SOW) is a narrative articulation
of the work elements that need to
be accomplished in the Implementation
Project. The SOW describes what is to be
accomplished. A Service Level Agreement
(SLA) defines specific quantitative measures
to be applied to the Project’s results.
We asked, “Do you use an SOW, an SLA or
Both?”
Here’s what gets included in SOWs and
SLAs:
1. Testing 63%
2. Time-lines 53%
3. Sign Off Requirements 38%
4. Reliability Goals 34%
5. Availability Targets 25%
6. Penalties 22%
7. Adoption Levels 19%

Implementation Team
In successful Implementations, the person who led the vendor’s sales initiative remains involved in the project
well into the Implementation process. This ensures continuity and that the expectations created during the
contracting phase are met after award.
“In successful
Implementations, the
person leading the
vendor’s sales initiative
remains involved well into
the process.
”

Another key factor in success is that the Implementation Team know each other before the kick off meeting.
93% of the Implementation Teams worked with each other before this particular Implementation. In addition,
clearly defined roles for the Team members are an essential element. N
o one works on the Implementation
Team as a full time job. Generally, the
Implementation Team is staffed by
people who are experienced and influential.
Implementation Team members are chosen
for the following combinations of reason:
1. Experienced 59%
2. Influential 44%
3. Available 33%
4. By Request 21%
5. Political Choice 19%
6. Disinterested Management 16%
Chemistry on the Implementation Team
is deemed important or very important by
92% of the survey respondents.
There appear to be two schools of
thought about the tools used to manage
Implementations. 53% use Project
Management software while 44% use Office
software like Microsoft or Google. The
remainder rely on action item lists.

Data
A central risk and concern in Implementation Projects is data migration. This means moving the data from the
old system to the new. We asked about the method used to move the data from one system to the other:
1. Worked With Vendor.....................................56%
2. Vendor Did It All............................................29%
3. Spreadsheets................................................29%
4. Software Auto Import....................................21%
5. We Did It All.....................................................9%
6. API...................................................................8%
This means that the topic of data migration has to be discussed in detail during the contract award/evaluation
process. In less than 10% of the cases, the practitioner was able to migrate data without the assistance of the
vendor.
In general, it takes less than a month to complete the cleaning and migration of the data. 12% of projects
encounter problems with the data that take months or years to resolve. Interestingly, these projects still
consider themselves successful. That is likely to mean that historical data is less important than current, live
data.
“A central risk
and concern is data
migration; in less than
10% of cases, the
practitioners migrated
data without vendor
assistance.
”

Communicating Progress, Problems and Success
There appear to be two schools of thought about the tools used to manage Implementations. 53% use project
management software, while 44% use office software like Microsoft or Google. The remainder rely on action
item lists.
How do you report progress?
1. Regular Report..............................................81%
2. Staff Meeting Presentations..........................74%
3. Meetings.......................................................71%
4. Executive Presentations................................62%
5. Word of Mouth..............................................52%
6. Email.............................................................44%
When asked: To whom do you report progress, respondents listed one or more of the following:
7. Management.................................................91%
8. Team Members.............................................70%
9. Peers.............................................................60%
10. Employees.....................................................59%
11. Business Unit................................................58%
12. Entire Workforce............................................47%
“53% use project
management software,
while 44% use office
software, and the
remainder rely on action
item lists.
”

Why Projects Go Off Track
It is unusual (but not rare) for an Implementation Project to move along exactly as planned. We examined this
aspect of project management.
Only 1/3 of successful Implementation Projects stay on track for the entire schedule.
We asked what caused the project interruption.
1. It Never Happened........................................34%
2. Confused Communications..........................14%
3. Misunderstood Requirements.......................14%
4. Vendor Delays...............................................12%
5. Software Deficiencies....................................10%
6. Insufficient Staffing..........................................7%
7. Change Management Problems.....................7%
8. Insufficient Budget..........................................4%
In summary, when projects go off the rails, it is a communication problem 28% of the time, a vendor problem
22% of the time and a practitioner problem 18% of the time.
“Only one
third of successful
Implementation Projects
stay on track for the
entire schedule.
”

W
e then asked, “How did you get
things back on track?”
1. Kept moving forward with deeper
additional monitoring and control: 54%
2. Focused on finishing quickly: 16%
3. Revised the project’s scope: 15%
4. Stopped everything and started
over from the beginning: 11%
5. Involved the legal department: 3%
There is great folk wisdom about project
management. The underlying idea is that
you should, once you have a basic plan,
double all of your estimates. Plans often go
awry. It is as true in this case as others.

Qualitative Conversations

Throughout our research on Implementation, we had conversations and interviews with a wide variety of
practitioners (our qualitative panel). The vast majority were from Implementation Teams on the practitioner side
the equation. We interviewed three members of vendor Implementation Team for perspective and to maintain
some level of balance.
In discussing Implementation Success, six primary variables emerged.
• Resource Availability
The availability of the resources required to execute the Implementation is a reflection of the depth of
management support. Our qualitative interviews pointed to a desire for management engagement, not
necessarily management involvement. We also encountered stories of management that claimed to be
supportive, but could never find the resources.
• Mission Clarity
Implementation Projects that can be described simply and as organizational Transformations are most
likely to succeed. Yet, building an effective mission statement is never easy or simple. It always involves
significant work to make the goals and plan clear and easy to communicate.
• Vendor Responsiveness
As we discovered in our first report, “The Ideal Vendor Relationship,” the length of time a vendor takes to
answer a question or problem is the best indicator of the Project’s health. It’s worth considering the use of
Problem Response Time as a measure of health for all sides of the Project.
• Mission Criticality
If a Project involves marginal improvements or purely technical changes, it is less likely to garner resources
in a crisis (most Implementation Projects have at least one crisis). Securing deep management support
completely depends on the degree to which the Implementation is critical to the organization and its future.
“The length of time
a vendor takes to answer
a question or problem is
the best indicator of the
Project’s health.
”

• User Satisfaction
A significant majority of our qualitative panel focused on the importance of User Satisfaction. While they
uniformly agreed that Transformation was a great framework for success, User Satisfaction is the glue that
keeps the success in place.
• Team Continuity
It is important that the contract not be negotiated in a vacuum. Members of the Implementation Teams (on
both sides) should be a part of the initial Evaluation process. One way of thinking about the Project team is
that the Evaluation and Contract Award periods are courtship. Implementation begins the real marriage.
Of course, the software must actually do what it was supposed to do. We heard a number of horror stories from
well designed initiatives that were unsuccessful because the software didn’t actually deliver what it promised.
Does the software work and does it do what it is supposed to do were key factors in reference checks by our
survey respondents. Each of our panelists also emphasized the need to check references as a part of building a
Successful Implementation.
“Evaluation and
Contract Award
are courtship;
Implementation begins
the real marriage.
”

Why Is There No Definition of Excellence?
We asked each member of the panel to describe “excellence” in Implementation Projects. For the most part the
response we got was, ‘We were happy to just get through it.’ Implementation success depends on the Team’s
ability to manage and navigate social and political risk within the organization. ‘Getting ‘er done’ constitutes
most articulations of Implementation Excellence.
In our interviews, there was a good deal of laughter about the reward for great performance being a ‘reduction
in punishment.’ Work on Implementation Teams is usually a fairly thankless addition to an already heavy
workload. Since Implementation Team membership is a project assignment, it usually takes some effort to align
rewards and performance.
Surprisingly, none of our panelists cited leadership as a driving factor in Implementation progress or success.
We didn’t hear a single story about charismatic individuals at the heart of effective project management.
Rather, the stories involved keeping track of what was happening and adaptive responses to trouble when it
developed.
Echoing our quantitative research, we found a definite preference for leaders with project management
experience. About 70% would rather have a seasoned project manager than a software expert. Success
was broadly seen as the completion of the Project rather than a specific impact on the organization and its
processes.
Even in the most celebrated Transformative Projects, the end of the Project is more likely to be a winnowing
down of the Team than a dramatic conclusion. That is why celebration of the final milestone is elusive. We
could not find an example of an organization that reconstitutes its Teams six months or a year after Project
conclusion. Even in the best circumstances, reflection and recognition of accomplishment are not really a part
of this sort of project work.
Excellence is difficult to understand and measure without some distance from the work. Even though the
acquisition and installation of software (and the accompanying set of relationships) is central to organization
function, it appears to be inconsistently managed in HR Departments.
“Success depends
on the Team’s ability
to manage and
navigate social and
political risk within the
organization.
”

It is not the case that HR is ignoring either complexity or risk. Rather, the tendency for a Transformation effort to
turn into a jungle of new policies is not lost on practitioners, and they take efforts to manage that. Knowing that
work expands to consume the available resources, practitioners are wisely uneasy about the prospect of have
a ‘project office.’
While the Project may be imagined and championed by a highly social, upwardly mobile executive, the work of
‘bringing ‘er home’ usually falls to a leader whose specialty is getting things done. By Project completion, these
people are ready to be off to work on the next thing. These leaders are deliverers, not stable administrators.
They thrive on problem solving rather than the maintenance of the status quo.
Without a department or at least a sustained role, there is no way for an organization to retain the knowledge
gained from individual Implementations. The result is a tendency to repeat mistakes. While it would make
sense for a professional association to offer training and certification in this area, there doesn’t seem to be any
immediate takers.
Much of the huge learning in the process happens as the Project is coming to a close and the software is
working systemwide. That’s when the really unanticipated problems (caused by actual usage of the new
software) pop up. Developing a feel for solving those early operational issues seems to be an intuitive skill that
is built through experience.
The other possible repository of wisdom could be the large independent HR consultancies. Unfortunately,
organizational transformation is rarely executed well by a third party.
When we asked our panel what would make a great outcome for an Implementation, our panelists offered some
possible visions of excellence:
• Installing User Delight
• Joy at Completion with a Festive Celebration
• Immediate Productivity Improvements
• Pride on the Team and Across the Organization
• Minimum Interruption/Minimum Learning Curve
• Expanded System Wide Recognition
• Reducing the Actual Hassle In Users’ Work
“Much of the
learning happens as
the Project comes to a
close and the software is
working systemwide.
”

Why Is There No Professional Implementation Training?
As we noticed in our first report, there is a vast gap between the training that HR practitioners need and what is
available to them. As software expands its reach and new special service companies emerge, HR is becoming
part execution and part purchasing. Managing the various parts of the purchasing and installation process is
central to the future of the profession.
Our panelists were puzzled by the lack of professional support available to them. Their work responsibilities
are shifting quickly, while the professional association(s) seem mired in the past. Sometimes, it looks like the
disruption of HR is underway already.
The SaaS Paradox: Those Changes
As a group, the panel was concerned about an area that lies just outside of the bounds of traditional
implementation. With Software as a Service, the vendor continues to issue updates and little improvements
which must be incorporated for the software to continue to work. But what’s little for the vendor creates real
work for the customer, especially if an update changes how a function works. One practitioner commented,
“We can’t stay on top of the changes.”
It’s hard to control the configuration of the software because it’s not your software.
This was the tip of the iceberg for a topic that seemed to be much larger just below the surface. Organizational
reality is shaped by the current state of the software the organization uses. If it is incomplete, or not providing
all of the functionality a customer requires, additional workflows and work-arounds begin to emerge.
“We have to get the work done regardless of what the software does,” says a Midwest CHRO. “Knowing
how to forecast the rate at which our ‘temporary processes’ will disappear is a large part of our budget
consideration.” In other words, incomplete or imperfect software causes additional cost that is rarely monitored
and controlled.
The impact on user morale is also a substantial factor in these updates and changes. The latest “improvement”
in the software can undo weeks or months of work-around development. As a result, users’ jobs are often
changed without warning.
“What is little for
the vendor creates real
work for the customer,
especially if an update
changes how a function
works.
”

Mark Berry on Implementations
We asked Mark Berry, a very senior HR Analytics Leader, to tell us about his experience with Implementations.
Mark represents the school of thought that the entire purpose of a department can be something like
continuous Implementation.
As the driving force behind Evidence Based HR, individual software installations were a small part of a much
larger initiative. Mark was uniquely able to consolidate the learning from ongoing Transformation.
Here is what he had to say:
Five years ago, in a company far, far away, I began the process of building an evidence-based capability within
the HR organization of a Fortune 200 company. Although we started small, we had big aspirations and (over
the course of the months and years) were able to lay the groundwork for evidence-based human resources.
Through the course of that journey, I—mentally—referenced what I had read in “Ultramarathon Man” and what
I had experienced in countless ultramarathon events of my own. “Run if you can. Walk if you have to. Crawl if
you must. Just don’t quit.”
Since beginning that journey, the most often-asked question I receive is encapsulated in one simple word,
“How?” People—especially HR peers in organizations that lack capabilities in fact-based decision making,
good self-service on-demand descriptive analytics, workforce planning, and inferential or predictive
analytics—want to know “how”—“how” to obtain the support of senior leadership, “how” to initiate the work,
and “how” to get traction with evidence-based decision making within their respective organization.
Honestly, these are the questions that need to be answered before even considering the journey. Failure to
do so will—at the very least—complicate the journey and—at its worst—virtually guarantee its failure. What I
learned as I embarked on the journey may not be applicable to all organizations, but in many, the steps on the
journey are common, repeatable, and will result in success if followed.
“People want to
know how to obtain
the support of senior
leadership, initiate the
work, and get traction
with evidenced-based
decision making.
”

“Evidenced-based HR” and “HR analytics” are not synonymous terms. Evidence-based HR is really about
changing how HR addresses—using data, metrics, analytics, and insights—decision making regarding critical
business issues affecting people. HR analytics—on the other hand—is a discipline within HR (and an important
one within organizations that aspire to embrace evidence-based HR practices) that helps to support evidence-
based HR practices. “Evidence-based HR”—in the truest sense—is the collective effort of leaders in HR
organizations to transform how HR makes decisions, focusing more on data, analytics, and facts than feelings,
beliefs, and intuition. How do you begin the journey? Here are some practical considerations.
As I noted, no two organizations will—necessarily—follow the same steps in the process of implementing
evidence-based HR, but here are some of the steps I undertook (with lots of running, walking, and crawling
through the process):
• Prepare a compelling story, relevant to the business in which you operate. Paint a panoramic
picture of what “success” will look like—as well as what the more immediate, short-term “wins” will
be.
• Get senior leadership sponsorship...or don’t move forward. Recognize that—initially—“support”
does not equal full comprehension.
• Don’t neglect the critical, foundational issues—customers, data, technology, and acumen. Due
diligence must be done to ensure that you understand your customer
• Solve for the immediate needs of the organization. It’s great to be aspirational—but don’t allow your
failure to focus on the immediate opportunities cause you to be perceived as delusional.
• Minimize major investments in consultants or technology. Yes, consultants are smart and the
technologies are cool, but you don’t need them to succeed short-term (and they may—in fact—
adversely affect your success).
• Leverage good will from solving for the immediate needs to expand the work being undertaken.
Addressing pressing issues that are easy to solve will be “equity” for your practice and good will with
your stakeholders you can use to “fund” future work.
“It’s great to be
aspirational, but don’t
allow your failure to
focus on immediate
opportunities cause
you to be perceived as
delusional.
”

• Look for opportunities where others have feared to tread. Don’t be afraid of going after something
that has derailed others. Just be careful how you do it. It might derail you as well.
• Recognize that there are no “islands of excellence” in an “ocean of incapability.” Workforce
analytics “centers of expertise” are cool, but you’ll never drive significant, sustainable organizational
change if you don’t engage the broader “network of expertise”—others in HR who “get it.”
• Continue to tell the story—and stories—of how evidence-based decision making drives relevance
and results in HR. Your role is not only as a purveyor of workforce analytics, but as the “PT Barnum”
of analytics. Learn to approach this as the business approaches product marketing—leverage the
capabilities of your marketing folks to build your team’s brand equity.
• Grow as you go. What’s important is not a PhD in I/O, statistics or mathematics—it’s about passion,
purpose, and perspective. You don’t need to be a master of workforce analytics or planning to begin to
build your practice. You simply need to be one step ahead of your smartest customer.
“What’s important is
not a PhD in statistics or
mathematics—it’s about
passion, purpose, and
perspective.
”

Data Points

Overview
• 87% of Implementations affected the entire workforce (n=824)
• 82% of Implementations were Transformational in nature (n=824)
• Successful Transformations require process redesign 88% of the time. (n=808)
• 17% of companies do not pay for Implementation services (n=806)
• 64% of companies believe that the relationship between a vendor and a company is mostly a form of
negotiation. (n=803)
• 90% of companies believe that a vendor can be a trusted advisor at least sometimes. 51% believe it
without question. (n=804)
Planning
• 95% considered the vendor’s reputation before the purchase (n= 748)
• 82% of respondents met the vendor’s Implementation Team before purchasing (n=748)
• 84% of companies check references before purchasing software. (n=748)
• 20% check vendor supplied references. 16% check independently gathered references. 64% use a
combination of both methods. (n=748)
• The most important factor discussed in reference checking was whether or not the software worked
(81%) (n= 632)
• Whether or not the software worked was significantly more important (95% vs 79%) in reference checks
involving non-transformational Projects. (n=632)
• 47% of companies use external sources to define the scope of Implementation (vendor or 3rd party).
46% define scope themselves based on prior experience. 4% do not estimate Implementation scope in
advance (n=749)
Schedule
• 55% of companies use external sources (vendor or 3rd party) to estimate Implementation schedule.
39% estimated based on experience. 6% did not estimate the Implementation schedule. (n=748)
• 32% of Implementation Projects never go out of control (n=746) In other words, 68% of successful
Implementation Projects go off track at some point.
• The legal department is only called in 3% of the time when Implementation goes off track. (n=500)
Unsurprisingly, Legal is not called in to successful Projects.
“The legal
department is only called
in 3% of the time when
Implementation goes off
track.
”

Tools for Successful Implementation
• 69% of successful Implementation Projects use a Service Level Agreement as a part of the management
process. 58% use a Statement of Work as a part of the management process. 38% use both. 10% use
neither. (n=743)
• In successful Implementations, management is the focus of status reporting. (n=743)
• Successful Implementations use routine meetings more frequently than email for reporting progress and
concerns. (n=743)
Implementation Teams
• Implementation is only rarely (4%) a full time assignment. 47% of Implementation Team members are
assigned for 25% (or less) of their time. (n=807)
• In big companies, 100% Implementation work is unusual. Most Implementation Team members work
50% of their time on the Project (n= 805)
• 3rd parties manage successful Implementations a small percentage of the time (7%). (n=805)
• 70% of the members of the internal Implementation Team are chosen based on their experience.
(n=808)
• The Vendor trained the internal Implementation Team through a combination of on the job training (OJT),
classroom training, and support documentation. OJT was the most significant tool (67% of the time)
used to train the Implementation Teams. (n=806)
• Companies use 3rd party Implementation Teams whether or not the Project is considered
Transformative. (n=805) (The decision to use 3rd party help has more to do with the company than the
Project.)
• 44% always use internal specialists to manage Implementation. 44% use internal specialists on a case
by case basis. (n=805)
• The internal specialists come from HR (44%), IT (42%), or are hired from the vendor (9%) (n=676)
• 97% say that the internal specialists make a difference. (n=676) (Q43)
Data Migration
• The vendor was a part of the process of moving data into the new system 86% of the time. (n=807)
• 85% of all data was moved into the new system in a matter of weeks. (n=808)
“Successful
Implementations use
routine meetings more
frequently than email for
reporting progress and
concerns.
”

Management of the Implementation
• Completion criteria are defined by the vendor 37% of the time. (n=804)
• Only 76% of companies believe that senior management support is critical to Implementation success.
(n=802)
• The primary tools used to manage Implementation are 1- Project management software (49%), 2 -
Office software (Docs, Spreadsheets and Slides) (40%), Checklists (11%) (n=804)
• 66% of companies prefer the Implementation leader to have project management experience. 34%
prefer that the leader have specific experience with the software. (n=804)
Training New Users
• 48% of companies require passing a test of some kind in order to use the new system. 52% do not.
(n=799).
Attributes of a Successful Implementation
• 1- Quality (user satisfaction), 2- Cost and 3- Speed. That’s how companies prioritize the fundamental
aspects of Implementation.) (n=798)
• The number of Implementations a vendor has been involved in is a key driver of Implementation
success. (n=805)
• 85% of companies say that the vendor’s Implementation methodology is a key driver of Implementation
success. (n=805)
• 91% of companies believe that chemistry on the Implementation Team is a key indicator of success.
(n=807)
• While all of these Implementations were successful, 40% of companies were very satisfied with the
results. 56% were simply satisfied. In total, 96% were satisfied or very satisfied. (n=803)
“The number
of Implementations
a vendor has been
involved in is a key
driver of Implementation
success.
”

Myth Busting—Management Support
Management support is often described as critical to the success of an initiative. Our research indicates that
there is a group of practitioners who see it differently. Between 20% and 30% of practitioners (depending on
company size), see management support as irrelevant to Implementation success.
We found that pretty interesting.
1 to 200 201 to
500
501 to 2,500 2,501 to
10,000
10,001+
Not at all
Important
1% 1% 0% 1% 1%
Very Unimportant 3% 4% 4% 4% 7%
Not Important nor
Unimportant
24% 21% 18% 18% 12%
Very Important 72% 74% 78% 77% 80%
Importance of Management Support for Implementation Project Success
It would certainly be predictable to write that off as the naivety of the HR workforce. Given the operation’s low
organizational status and general reputation, it is no surprise that this is the first conclusion that many will
draw.
What most analyses miss is that HR professionals are the savviest social and political players in the
organization. They have to be to survive and be effective. The HR professional is always walking a line between
one set of loyalties and another. Rather than country bumpkins who just fell off the turnip truck, HR
practitioners understand and navigate the universe of “Change Management”.
“Transformational
Implementations are
successful because
they have focused and
enduring support at the
highest levels.
”

The basic role requirements demand that a practitioner be quickly able to tell the boundary of one area from
another. They always hold information that someone is not allowed to know. They fix problems discretely.
They understand the pluses and minuses of management support.
The US Navy has a colloquial term for a famous consequence of being managed. “Seagull Management” is
what happens when a high ranking muckity muck comes into the office. “They poop on everything and then
leave, just like a seagull.” Practitioners are well aware of what happens when management ‘gets involved.’
One view of the ideal level of management support is unlimited resources. Any project that has unlimited
access to money, people and materials will get done. A reasonable measure of management support is the
friction (or lack of it) required to acquire resources.
Anyone who has run a large-scale internal campaign of any sort understands that management has a
notoriously short attention span. Because HR is central to the company’s function, practitioners have
‘seen it all.’
This is why Transformational Implementations are successful. They have focused and enduring support at the
highest levels. They are projects that are about the company first and only incidentally about HR. They are
about changing things not maintaining the status quo.
The level of executive involvement required to transform a company is not a variable thing. You either want the
transformation or you do not. The best level of commitment comes when the project is tied into the executive’s
compensation.
Without that level of support, the fate of the project is in the hands of political variables. As the priority of
the project shifts, the likelihood that it will be successful declines. Transformational Implementations always
involve variables that are different from and larger than a pure technical problem.
That said, there are some classic circumstances (documented in Dilbert) in which the transformation is more
likely to succeed if the executive is not involved.
M
anagement support is a two edged
sword. The very things that can
make a project succeed can make
it fail. Because executive attention is always
tied to a single champion, that person’s
success or failure has a large influence on
outcomes.
In our last report, we showcased three
executives who are changing their
organizations with data and processes
that cross organizational boundaries. Their
work succeeds because they diligently
pay attention to the flow of praise and
attribution. By making sure that their efforts
make other people successful, they get
things done quietly.
People involved in transformational projects
understand that management support is
like any other tool. You want to use it as
little as possible so that you don’t become
dependent on it.

Notables
In each of our surveys, we ask practitioners to name vendors who are ‘Notable” in specific areas. The question
uses a blank, fill in the box, format. No prompts are offered. The practitioner must answer the question based on unaided
recall.
This is our second attempt to portray the practitioner view of the marketplace. We know that it will be vastly different from
the vendor’s perspective. Like two sides of the same coin, the two vantage points are radically different while describing the
same reality.
From the vendor’s perspective, the market is composed of the other people who go to the same trade shows and engage the
same demographic. At KeyInterval, we have a list of 1,000 vendor names that we generally expect will show up on that list.
The vendor perspective is largely about direct competitors in the same niche.
Most other analyst firms present a picture of the vendor landscape that resembles the vendor point of view.
The practitioner perspective is different.
Formed from a combination of marketing inputs and direct experience, practitioners are more interested in the tools that
they use than an analyst’s view of what matters. Name recognition and reputation are built from the grassroots. In the
practitioner’s view, the buyer and the vendor can be somewhat indistinguishable (depending on how far removed they are
from the process).
That is why vendors who might be perceived as smaller made it to the top of our first list. Practitioners can only tell us about
their experience. There is no incentive for them to have or maintain the analyst/vendor’s view of the universe.
There is a second dimension to the question.
Every single HRTech vendor works in some sort of niche. They only serve customers that have a certain size and complexity.
They fare better in one industry or another. They have deeper reach in some geographies. Their audiences are limited.
The practitioner audience is not niche specific.
None of the companies paid to be mentioned in this report.
In each of the following sections, the word cloud and Top 10 list reflect the practitioner’s perspective on the subject.

Notable for Administration
T
he ten most notable vendors in
administration are:
1. Oracle
2. IBM
3. ADP
4. SAP
5. PeopleSoft
6. Kronos
7. Lockton
8. SalesForce
9. Workday
10. Cornerstone

Notable for Implementation
T
Implementation are:
1. Oracle
2. IBM
3. ADP
4. Kronos
5. PeopleSoft
6. SAP
7. SalesForce
8. HR (Internal)
9. HPWorkday
10. Lockton

Notable for Training
T
training are:
1. ADP
2. Oracle
3. IBM
4. Kronos
5. SAP
6. PeopleSoft
7. BambooHR
8. SalesForce
9. Ceridian
10. OPM (Government)

Vendor I Would Most Like to Work With
T
he ten most notable vendors
respondents would most like to work
with are:
1. IBM
2. ADP
3. Oracle
4. SalesForce
5. Kronos
6. SAP
7. Mercer
8. HPWorkday
9. Halogen
10. BambooHR

Methodology
KeyInterval is an experiment. It is our goal to stay experimental for the life of the company. With each new
report, we are experimenting with survey methodology, data sourcing, data screening, the mix of qualitative and
quantitative information, and the edges of HR Technology practice.
It is a search for standard practices. We are more interested in what practitioners do that what some self-
appointed guru thinks they should do. Our goal is to understand the actual experience of the people who use
HR Technology. Then, we want to reflect it back to practitioners as a toolset.
The Story of the Data
This report, is the first time we ventured into terrain where none of the KeyInterval team has direct experience.
John Sumser spent many years on hardware/software implementations in military environments. William
Tincup is a master of the evolving message delivery project. Neither have direct, hands-on experience in HR
Technology Implementation.
That meant that the data had to be really, really strong.
We included 824 responses in our final survey group. We sifted and sorted through 2,407 fully completed
surveys to find this final group. We discovered that a large number of earnest people wanted to respond to the
surveys but that their answers disqualified them.
We selected for Implementation success and recognizable names of HR Technology providers. We limited the
success stories to those that covered one of the top 1,000 brands in HR Technology.
The report synthesizes the experience of 824 practitioners who played a role in a Successful Implementation.
As far as we can tell, this is the largest collection of data from Successful Implementations ever collected. If you
listen to the industry’s water-cooler chatter, Implementations are complicated and they do not usually go very
well.
824 success stories is an impressive number. The group includes a representative sample of American
geography, industry company size, and practitioner role. The details are spelled out in the following sections.
S
ince the data is exclusively focused
on success, there are some things
we could not do in our analysis. We
cannot provide you with cautionary tales.
We cannot warn you about the things that
guarantee a project’s failure. We cannot
wag our fingers and tell you what you
should not do.
This report describes the standard
practices in a Successful Implementation.

Position: Distribution by Function by Company Size

Company Size 1 to
10
11 to
50
51 to
200
201 to
500
501 to
1,000
1,001 to
2,500
2,501 to
5,000
5,001 to
10,000
10,001+ Total
Benefits 4 28 71 67 67 60 50 30 31 408
Business Partner 1 10 23 30 28 24 22 10 7 155
Compensation 4 29 46 49 47 38 31 20 27 291
Compliance 7 19 47 53 47 36 32 17 21 279
Diversity 1 17 38 37 37 28 21 15 14 208
Employee
Relations
9 32 75 81 70 55 51 34 31 438
Generalist 2 12 25 36 39 30 30 10 9 193
OD 7 16 40 47 42 42 34 22 18 268
Payroll 6 29 48 47 42 51 31 19 17 290
Recruitment 2 26 52 56 52 62 39 30 28 347
Safety 2 12 31 27 29 18 16 12 7 154
Talent
Management
2 17 29 46 40 34 32 23 26 249
Training/
Development
8 26 75 64 69 60 54 33 34 423
University Relations 1 3 8 18 14 10 11 3 8 76
Other 3 2 4 2 3 3 1 1 5 24
Total 16 48 141 130 131 110 85 57 75 793

Role: Distribution by Role by Company Size
Company
Size
1 to 10 11 to 50 51 to
200
201 to
500
501 to
1,000
1,001 to
2,500
2,501 to
5,000
5,001 to
10,000
10,001+ Total
CHRO 1 3 7 2 5 3 8 10 3 42
SVP 1 0 2 4 5 8 5 4 2 31
VP 1 2 8 11 11 21 15 5 5 79
Director 3 6 37 37 40 35 22 9 17 206
Manager 8 26 63 52 58 34 25 21 32 319
Business
Partner
1 3 7 4 4 3 2 1 4 29
Recruiter 0 3 8 7 1 3 1 1 4 28
Other 1 5 9 13 7 3 7 6 8 59
Total 16 48 141 130 131 110 85 57 75 793
H
ow We Collected Data
We used a variety of methods to acquire
responses.
• Email to our in-house panel
• Social Media Outreach
• Response Purchases
Quantitative responses were captured in an
online survey (89 Questions) using software
from Qualtrics.
31 Respondents (2%) did not disclose their
demographic information, which is why the
charts below say 793 instead of 824.

Geographical Distribution of Responses

Accounting 5
Airlines/Aviation 2
Alternative Dispute Resolution 1
Apparel Fashion 3
Architecture Planning 15
Arts Crafts 2
Automotive 6
Aviation Aerospace 4
Banking 35
Biotechnology 8
Broadcast Media 4
Building Materials 5
Business Supplies Equipment 22
Capital Markets 2
Chemicals 10
Civic Social Organization 1
Civil Engineering 6
Commercial Real Estate 1
Computer Network Security 2
Computer Games 1
Computer Hardware 4
Computer Networking 7
Computer Software 18
Construction 36
Consumer Electronics 1
Consumer Goods 22
Consumer Services 11
Cosmetics 1
Dairy 1
Design 1
Education Management 58
E-learning 2
Electrical Electronic Mfg 3
Entertainment 5
Environmental Services 3
Executive Office 3
Facilities Services 1
Farming 3
Financial Services 24
Food Beverages 4
Food Production 4
Gambling Casinos 2
Government Administration 21
Government Relations 3
Graphic Design 2
Health, Wellness Fitness 15
Higher Education 5
Hospital Health Care 41
Hospitality 3
Human Resources 78
Import Export 1
Individual Family Services 1
Industrial Automation 4
Information Services 6
Information Technology Svcs 23
Insurance 10
Internet 5
Law Enforcement 2
Law Practice 3
Legal Services 10
Logistics Supply Chain 2
Machinery 16
Management Consulting 3
Marketing Advertising 3
Mechanical or Indust Engineering 4
Media Production 1
Medical Device 6
Medical Practice 1
Mental Health Care 1
Military 3
Mining Metals 4
Music 1
Nanotechnology 1
Nonprofit Organization Mgt 16
Oil Energy 3
Package/Freight Delivery 1
Packaging Containers 3
Paper Forest Products 1
Pharmaceuticals 3
Photography 1
Plastics 1
Primary/Secondary 1
Printing 4
Professional Training 3
Program Development 1
Public Relations 2
Public Safety 1
Real Estate 11
Recreational 1
Facilities Services 1
Restaurants 1
Retail 61
Sporting Goods 1
Sports 1
Staffing Recruiting 6
Telecommunications 9
Textiles 1
Transportation/Trucking/Railroad 11
Utilities 4
Warehousing 3
Wholesale 11
Total 793
Responses by Industry

Pocket Guide: Successful Implementation Checklist

1. Project Mission
The project mission drives success. Transformational Implementation
Projects make up the lion’s share of success stories. The transformation of
your organization is an inside job.
• Have a very clear mission for the Implementation Project. Don’t just
install software; change the company.
• Build support in management ranks for the change. Never say, “We’re
upgrading our software.” Always say, “We are improving the way we do
business.”
• When your executive team publicly acknowledges the importance of
your project to the company’s work and future, they are much more
likely to provide needed resources and support.
2. Contract
Implementation begins before the contract is signed.
• Every Implementation contract can benefit from having both a Service
Level Agreement (SLA) and Statement of Work (SOW). The SOW
describes the scope and scale of activities, while the SLA describes
specific measurable performance requirements.
• Check references carefully before engaging a vendor. Use a combination
of customers the vendor puts forward, but also find some without
vendor input. Ask references what it was like to work with the
vendor.
• Include the measurement of User Satisfaction as a performance metric
in the SLA.
• Make sure that training results, measured in usage growth, are included
in the SLA.
• Members of the Implementation Team (on both the vendor and
practitioner sides) must be a part of the Evaluation process before the
contract is awarded.
3. Implementation Team(s)
Both the vendor and the practitioner should have at least one
Implementation Team.
• Meet with the vendor’s Implementation Team before the contract is
signed
• Make sure that the vendor’s Implementation Team understands and
supports your larger mission.
• Review your Implementation plan in detail with the vendor’s team as
soon as the contract begins.
• Develop a detailed Implementation plan that includes Schedule,
Budget (both internal and external) and Scope. Add an additional 20%
contingency for both cost and time after the plan is complete.
4. Management Involvement
Every successful Implementation Project has some level of management
support. It ranges from a passive reporting relationship to hands on day to
day involvement.
• Recognize that active executive involvement comes at a cost in time and
resources.
• It’s better to have your senior leadership committed in a way that
guarantees their support in a crisis, but without requiring their active
routine involvement.
• Develop a set of guidelines that describe when to ask for intervention
and how to optimize its impact.

5. Implementation Project
This includes configuring, customizing, installing, testing, modifying, and
updating the software. When the project is Transformative it also includes
other elements of workflow modification and organization redesign.
• Use project management software to stay on top of the activity flow.
• Identify key areas where cultural change is required. Highlight them
and make the cultural improvement milestones a part of every status
update.
• Measure user satisfaction as a part of ongoing Implementation Project
efforts.
6. Training
Once the software is in place, the primary interaction between the
Implementation Teams and the community of users (practitioners, their
managers and company employees) is instruction (to varying degrees) in
the use and maintenance of the system.
• Test any suggestion that the system is “intuitive” and users don’t need
training. System usage and usage improvements are key indicators of
satisfaction. If the system naturally generates more and more use, good.
This is not usually the case.
• Make an informed decision about whether to test users for basic
competence before they get access to the new software or system. This
guarantees a level of training, but is not always necessary.
7. The Inevitable Disaster
Most successful Implementations go through a period when the project
goes awry. A significant subset, about 32%, don’t have major problems, but
68% do. So, smart planning should include how to deal with likely delays
and problems.
• Add a 20% pad to any budget or schedule estimate. Maintaining this
reserve allows for one or two setbacks.
8. Acceptance (Sign Off)
In theory, Implementation is complete when the requirements of the
vendor’s contract have been met.
• Make a sign off checklist that includes all of the essential elements of the
SOW and SLA
9. User Satisfaction
There is a bit of disconnect between software buyers and their
management. Both users and executives see User Satisfaction as a better
indicator of project completion. There is generally a lag between the
Acceptance and optimal system performance.
• Make final acceptance of the Implementation Project contingent on a
level of user satisfaction about six months after project completion.

Research Calendar
KeyInterval Research is mapping the complexities of practitioner experience in the HR Tech universe. We help
HR understand what’s possible and what fits best. We do disciplined, pragmatic research to help practitioners
separate fact from anecdote.
Here is our 2015 research calendar.
January: What Is The Ideal Vendor Relationship? Purchase Report
There is a diverse range of possible ways to build a relationship with a vendor. We’re eager
to discover what works and what doesn’t. As we map the area, we expect to find amazing
success stories and examples.
February: Why Do Implementations Succeed?
We are going to seek and discover exemplary success stories. We are really curious about
the factors that create memorable successes. What are those drivers? Is there a difference
between a great success story and something merely adequate? What’s the difference?
March: What Is The Optimal Technology Stack?
The HR Stack is all the software, data and apps in a company’s HR Department. No two are
the same. Every instance is truly unique... like a cultural fingerprint. We will map what’s being
purchased and by whom.
April: Is There a Best Data Strategy?
The future of HR is anchored to its ability to harness data. We aim to map the optimal data
model and its critical components. These are the early days of HR data mastery. We can't
wait to report what we learn.
May: Do Users Love Your Software Purchases? (Software Engagement)
Enterprise HR software users can LOVE the software you purchase. They can also hate those
purchasing decisions. What makes an optimal environment for love of enterprise software?
We are on it.
A
cknowledgements
William Tincup: Principal Analyst
John Sumser: Principal Analyst
Heather Bussing: Copy Editor and Keeper of the
Peace
Michal Grisset Tincup: Smoother and Keeper of
the Peace
Anne Hill: Production
Julian Seery Gude: Web Tech and Focus Group
Reinhard Joelli: Market Research Counsel
Ray Sumser: Art
D. Mark Hornung: Advisory/Focus Group
Dwane Lay: Advisory/ Focus Group
Tim O’Shea: Advisory/ Focus Group
Mark Berry: Case and Counsel
And a host of others.

June: How Does This Go Together?
We’ll summarize the data and try to understand and explain how each variable can make for
a better HR department. We will also include MA and Transaction data. We review new ideas
and products.
July: What Is The Model Purchasing Process?
Most companies have a sophisticated way to buy software. We want to understand the
Purchasing Process. Changes are afoot. We’re excited about staying on top of the evolution
as it happens.
August: What Is The Perfect HR Budget?
The further we look into HR’s budget, the more we understand that this is the best way to
explore the overall organization’s commitment to HR and its issues. The budget is a good way
to understand what matters.
September: Do Employees Use The Software? (Adoption)
We are researching how much, how often and why employees use HR Enterprise Software.
We think that organizations that get optimal User Adoption also achieve the maximum ROI.
October: Which Metrics and Analytics Are Useful?
We research which HR metrics and analytics are working under what conditions. We
are fascinated with the emergence of HR as a quantified discipline. This area will grow
significantly in the coming years.
November: Are HR Processes Effective?
Exploring the relationship between HR and its customers has our attention. We’re pretty
sure that increased accountability is a part of HR’s immediate future. We are excited to see it
unfold.
December: What Happened This Year? What Did We Learn? What’s Coming?
We hold ourselves accountable and examine the cumulative understanding for a year of
research. Throughout the year, we will be soliciting questions to be answered in the year end
research report.

Successful Implementations Report

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Successful Implementations Report

Semelhante a Successful Implementations Report (20)

Mais de Tincup & Co.

Mais de Tincup & Co. (20)

Successful Implementations Report