IJIS Institute_ Change Management-Best Practices in PS Data Sharing Projects (Nov 2014)

IJIS Institute
IJIS Public Safety Technical Standards
Committee (IPSTSC)
November 2014
Principal Author: Becky Ward
Communications International
CHANGE MANAGEMENT: BEST PRACTICES IN PUBLIC
SAFETY DATA SHARING PROJECTS

Change Management: Best Practices in Public Safety Data Sharing Projects
IJIS Institute, IPSTSC Committee Page i
Acknowledgements
The IJIS Institute would like to thank the following contributors and their sponsoring companies
for supporting the creation of this document:
 Principal Contributors:
o Bill Hobgood – City of Richmond (Virginia)
o Jeannine Thompson – Lake County (Illinois)
o Becky Ward – Communications International
o Mike Weins – RCC Consultants, Inc.
o Kathy Wendt – SRA International
 Contributors:
o Nate Daniels – Northrop Grumman
o Tom Dewey – Advanced Justice Systems
o Barbara Falcaro – CODY Systems
o John Hollywood – RAND Corporation
o Steve Hoggard – Spillman Technologies
The IJIS Institute would also like to thank the U.S. Department of Justice (DOJ), Office of
Justice Programs (OJP), Bureau of Justice Assistance (BJA) for their comments and feedback on
this white paper.

IJIS Institute, IPSTSC Committee Page ii
CONTENTS
ACKNOWLEDGEMENTS......................................................................................................................................... I
INTRODUCTION...................................................................................................................................................... 1
Intended Audience.............................................................................................................................................1
Purpose.................................................................................................................................................................1
Methodology........................................................................................................................................................3
SYNOPSIS .................................................................................................................................................................. 4
CAN YOU PREDICT PROJECT SUCCESS?.......................................................................................................... 5
WHAT IS CHANGE MANAGEMENT AND WHY IS IT IMPORTANT?......................................................... 6
Why People Resist Change..............................................................................................................................7
Approach to Change..........................................................................................................................................7
Common Illusions..............................................................................................................................................8
Change Management in Data Sharing Projects.......................................................................................9
KOTTER’S CHANGE MANAGEMENT MODEL.................................................................................................. 9
Kotter’s Principles.............................................................................................................................................9
Set the Stage........................................................................................................................................................................................... 9
Decide What to Do.............................................................................................................................................................................10
Make it Happen...................................................................................................................................................................................10
Make it Stick.........................................................................................................................................................................................11
TOP 10 BEST PRACTICES BY ROLE ................................................................................................................12
Best Practices from a Subject Matter Expert (SME) Perspective ......................................................12
Best Practices from a Practitioner Perspective .....................................................................................13
Best Practices from Project Management Perspective........................................................................15
Best Practices from a Consultant Perspective........................................................................................16
Best Practices from an IT Perspective.......................................................................................................17
REAL WORLD SITUATIONS FOR BEST PRACTICES APPLICATION......................................................18
Mini Case Study 1.............................................................................................................................................18
Project Challenges.............................................................................................................................................................................18
Lessons Learned.................................................................................................................................................................................18
Mini Case Study 2.............................................................................................................................................19
Lessons Learned.................................................................................................................................................................................19
Mini Case Study 3.............................................................................................................................................19
Lessons Learned.................................................................................................................................................................................20
CONCLUSIONS........................................................................................................................................................20
REFERENCES..........................................................................................................................................................21

IJIS Institute, IPSTSC Committee Page iii
Articles and Documents.................................................................................................................................21
Informational Sources ...................................................................................................................................22
RECOMMENDED READING................................................................................................................................23
ABOUT THE IJIS INSTITUTE .............................................................................................................................24
About the IJIS Public Safety Technology Standards Committee........................................................24

IJIS Institute, IPSTSC Committee Page 1
INTRODUCTION
This paper is a follow-on to the IJIS Institute white paper
Critical Decision Criteria for Data Sharing that provides
guidance to practitioners on planning to implement a data
sharing solution.
Practitioners asked for information about best practices in data
sharing projects and how they can increase the odds that their
project will be successful. They also asked how they can
manage employee resistance and apathy to change, both
prevalent in data sharing projects and, oddly enough, even at
the executive levels where the benefits should be most evident.
This paper is crafted specifically for Computer Aided Dispatch
(CAD) and Records Management Systems (RMS) data sharing
projects, such as CAD-to-CAD and RMS-to-RMS, but the
concepts are universal. It details guiding principles founded in
change and project management and provides mini case studies on
projects that struggled. These mini studies and the accompanying lessons learned were
volunteered by a variety of people associated with these projects, from consultants, project
managers, executive sponsors as well as users of the systems. The ‘what went right, what went
wrong and what could have been done better’ can be distilled into best practice concepts.
Intended Audience
Practitioners in leadership positions, individuals in information technology roles, consultants,
and system integrators can benefit from the best practices in public safety data sharing detailed
herein to help improve their projects’ successes.
Purpose
With the high rates of failure in IT projects that are evident today, it has become critically
important to get a project started on the right path using those best practices learned from both
successful and unsuccessful projects. The Standish Group reported in a 2009 article that 68% of
projects failed or were challenged.1
The 2014 report was even more alarming, with 52%
challenged, 42% failed, and 6% successful.2
As agencies strive to deliver successful projects the
ability to manage change is a critically important factor, and the purpose of this paper is to
provide best practices information from both industry and the public sector in change
management and project delivery.
1
The Standish Group, CHAOS Summary 2009
2
The Standish Group, CHAOS Summary 2014

The purpose of this paper is to:
 Educate the reader on the importance of change management in data sharing projects
 Share insights provided by practitioners, subject matter experts, solutions architects,
business analysts, consultants, and project managers
 Present predictors of success to assist practitioners and consultants in planning for project
success
 Provide best practice recommendations
 Offer reference material that shows the correlation between change management and
meeting project objectives, timelines, and budget
The paper begins with the assumption that data sharing is a viable goal with valuable benefits,
and has been shifting from a nice-to-have to a need-to-have for public safety. The bottom line is
that data sharing saves lives. The key benefits of data sharing most often articulated were:
 Reduced response times
 More informed decisions with better, richer, and faster information
 Situational awareness of nearby potentially impactful events
 Enhanced officer, responder, and citizen safety
 Improved outcomes with improved citizen service and satisfaction
 Increased productivity with reduce costs or cost avoidance
 Increase transparency with increased communications and collaboration
 Efficient use of resources with lessened duplication of effort
Project management, while overlapping change management in many areas and ideas, is not a
focus of this paper.
Successful = Delivered on time, on budget,
with required features and
functions
Challenged = Delivered late, over-budget
and/or with less than the
required features and
functions
Failed = Cancelled prior to completion
or delivered and never used
FIGURE 1: STANDISH GROUP DATA FROM 2014

Methodology
The approach employed in gathering the data for this paper was to interview as many people as
possible who were associated with data sharing projects. The interviews were not formally
structured, yet all posed three key questions to the person being interviewed:
1. What did you do right?
2. What did you do wrong?
3. If you had a do-over, what would you do differently?
The IJIS Institute Public Safety Technical Standards Committee (IPSTSC) members also
interviewed each other. Collectively, the committee members interviewed have more than 250
years of involvement with data sharing projects, including implementing and supporting large-
scale, mission-critical public safety systems. These implementations range in size from a small
agency with one service, to major metropolitan areas serving multiple jurisdictions and multiple
agencies, to statewide and national systems.
In addition, the committee read several books and reviewed a number of articles on change
management and discussed the insights while conversing on the interviews obtained. These
books are listed in the References section.
Within the last 12 years or so, agencies have begun to share public safety data (e.g., CAD-to-
CAD) for situational awareness and enhanced mutual or automatic aid and records data (e.g.,
RMS-to-RMS) for enhanced intelligence and predictive policing. The interviewees all had
experience with public safety data sharing projects that involved change at the stakeholder level
in order to achieve success. Interviews were documented, and then evaluated for common
patterns and themes.
Our collective lessons learned fit into patterns strongly associated with change management
principles and, therefore, we believe the conclusions are beneficial.

Synopsis
Based on interviews with practitioners, solutions
architects, business analysts, consultants and project
managers, the IPSTSC Committee found that strong
governance of the data sharing project plus knowledge of
change management substantially improves a data sharing
project’s success. These two fundamental elements each
constitute a best practice.
The IJIS Institute white paper Governance Agreements in
Public Safety Information Sharing Projects discusses best
practices for crafting data sharing agreements, and reviews
the components of modern information and resource
sharing agreements. Strong governance establishes a
platform from which strategies can be effectively executed
and is a significant foundational component of any data
sharing project. Governance should be in place before the
data sharing project begins.
Change management addresses the people side of change.
It is a process or approach to transition people to a desired
future state. Change management helps stakeholders to accept and embrace change, such as a
new data sharing initiative. Many project managers incorporate change management as part of
project planning. Many of the project challenges discovered in the interviews had to do with
disregarding change management principles. These will be explored in the pages that follow.

CAN YOU PREDICT PROJECT SUCCESS?
Yes, according to the Harvard Business School in an article published in the Harvard Business
Review titled The Hard Side of Change Management.3
The authors state that while culture,
leadership and motivation are important, managing these aspects is not sufficient in
transformational projects. The so-called hard factors which can be measured, communicated,
and influenced are actually predictive of success.
The paper presents the best predictive factors for
project success and use the acronym DICE.
Duration: The duration of time until the project is
completed. A short life span is better than an
extended one, and, if not short, then the amount of
time between reviews of milestones must be more
frequent.
Integrity: The project team’s performance
integrity. Essentially, it is the team’s ability to
complete the initiative on time, and this depends on
team members’ skills and traits relative to the
project’s requirements.
Commitment: The commitment to change that top
and middle management (C1) and employees
affected by the change (C2) display.
Effort: The effort over and above the usual work
that the change initiative demands of employees.
The paper goes on to convey how to rate each of the
factors and offers an empirical formula that anyone can use to assess the likelihood of success of
their project:
DICE Score = D + (2 x I) + (2 x C1) + C2 + E
Interestingly, this formula indicates that duration, employees understanding and belief in the
value of the change, and the level of employee’s efforts beyond daily duties have less weight
than the implementation team’s ability and the executive leadership team’s communication of
belief in the value of the project.
So what does this mean for public safety data sharing projects? Since data sharing always
involves two or more agencies, the competence of each organization impacts the sharing project
as a whole. If one agency is weak – either in leadership, distracted by other priorities, or
overwhelmed implementers – this impacts not only their organization but the entire project.
3
http://hbr.org/2005/10/the-hard-side-of-change-management/ar/1
“…a short project led by a skilled,
motivated, and cohesive team,
championed by top management and
implemented in a department that is
receptive to the change and has to
put in very little additional effort, is
bound to succeed. At the other
extreme, a long, drawn-out project
executed by an inexpert,
unenthusiastic, and disjointed team,
without any top-level sponsors and
targeted at a function that dislikes the
change and has to do a lot of extra
work, will fail.”
The Hard Side of Change Management
By Harold L. Sirkin, Perry Keenan,
and Alan Jackson

Key points:
 A longer project managed well and reviewed frequently has a greater chance of success
than a shorter project with insufficient oversight.
o Pay particular attention to service provider’s project management timelines,
milestones, and communication plans. If timelines are extended this could be a
warning to executive sponsors.
 The agency project team is arguably more important than the service provider’s team.
They must embrace ownership of their project and not abdicate responsibility to outside
parties.
o Project teams must excel at communications, have problem-solving skills, be
results-oriented, be methodical yet flexible, and detail-oriented and cohesive.
 Commitment of two groups within each agency is critical: by senior executives/leaders
and by the employees who ultimately must use the new system.
o If employees don’t see real, visible commitment and backing of a project by
agency leaders, they won’t accept the change and the project will struggle and
likely fail. Commitment must be communicated, and leaders should know it has to
be at a level more than twice what they think is needed. If management’s voice is
missing from a project, it is often viewed as not supported.
 People will resist change, and not give full effort to a project, if they are already fully
consumed with daily responsibilities. Ideally, no one’s workload with the new project
should increase more than 10% say the paper’s authors.
o Agency leaders must be cognizant of this fact and must looks for ways to adjust
the regular workload for the key project team if needed.
This paper has briefly explored an objective method to access the likelihood of project success,
and it contains many of the elements of change management. What follows digs a little deeper
into change management.
WHAT IS CHANGE MANAGEMENT AND WHY IS IT IMPORTANT?
There is a lot of information about change management available! If you Google change
management you will get about 105,000,000 returns. If you search change management books on
Amazon, you will find over 18,000 returns. The first return from Google, as well as the easiest to
read, is from Wikipedia.
Wikipedia states, “Change management is an approach to transitioning individuals, teams, and
organizations to a desired future state.”4
This is exactly what a data sharing project entails –
changing people, operational units, and organizations from stovepipe, manual operations to
automated processes that use technology to increase efficiency and effectiveness.
4
http://en.wikipedia.org/wiki/Change_management

As referenced at the beginning of this paper, when many projects fail to deliver on expectations,
it is imperative to know how to overcome the risks so your project will succeed. Reading a few
good books will benefit any public safety manager, both at the office and with projects outside of
work.
Why People Resist Change
Almost all people resist change. Very few people enjoy its turmoil and challenges. If you want
your project to succeed it is key to understand this resistance reflex and how to overcome it. Our
interviews uncovered the following top reasons for change resistance:
1. Poor communication
2. Misunderstanding the need for change
3. Fear of the unknown
4. Change in the status quo and loss of power
5. Fear of lack of competence
6. Connected to or invested in the old way
7. Low trust of leaders and their motives
8. Change thought to be temporary fad
9. Resentment at not being consulted
10. Changes to routines
11. Exhaustion/saturation
12. Benefits and rewards insufficient to overcome any of the above
Surprisingly, the committee’s interviews uncovered more apathy than outright resistance. We
hypothesize that, other than consolidation as a way to share data, most data sharing projects
involve automation that is largely invisible to the end users – if done correctly with the right
service provider. It is incumbent upon project and team leaders to recognize resistance and
apathy, and have multiple approaches in place to overcome this type of roadblock.
Approach to Change
Essentially this involves assessing five factors and tailoring your message to various stakeholders
accordingly. Critical factors are: the time frame needed to make the change, the extent of the
change, the benefits of the change, the amount of resistance to the change, and what’s at stake.
In data sharing projects, there is usually no timeframe that dictates project completion unless it is
grant expenditure related. However, the chosen architecture of the data exchange will dictate
many of the outcomes, from how difficult the implementation will be, to how much work it will
be for everyone involved (as well as how functional and scalable it will be). It follows that what
is usually lacking is information – communicated to all stakeholders at all levels with more
frequency than thought needed – about the benefits of making the change to sharing data,
whether it be CAD-to-CAD, CAD-to RMS, or RMS data sharing.
Table 1 reflects different approaches and communications to affecting change. Many authors
have different terminology for what they term a change style. One site calls these approaches
“Collaborative, Consultative, Directive and Coercive” for example. What is important is that not

one style, by itself, might be perfect for you and your data sharing project. Your approach may
have to change over time and a combination of approaches may have to be employed for
different stakeholder groups. Different approaches can be used during different phases of a
project.
TABLE 1: CHANGE MANAGEMENT STRATEGIES
Approach Style Works Best When
Rational: Assumes that people are
reasonable and rational
Communicate the benefits and get
buy-in; use persuasion.
Timelines are not tight and there is
little resistance to change.
Normal: Assumes that people want
to fit in with an organization.
Encourage conformity to values
and norms of the organization.
Deadlines are loose and there is
low resistance to change.
Adaptive: Assumes that people can
adapt quickly to change.
Leave it to people to adapt to
change…or face consequences.
Whoever doesn’t adapt is out.
Change is radical and there is
strong resistance.
Coercive: Assumes that people will
do what they are told, and that
they expect to be told.
Use power of authority to force
compliance and impose sanctions.
Timelines are tight and the stakes
are high. A good choice when
resistance is high and people are
discontented.
Adapted from Four Change Management Strategies by Fred Nickols
Several sites are referenced at the end of this paper for those seeking more information on styles
of change management.
Common Illusions
During the committee’s interviews, one project manager stated, “It was amazing the number of
illusions that (my) agencies were operating under. Before this project started, a systems
integrator came in and told them that all they had to do was two things: sign the contract and sign
the check, and everything would be done for them. Shame on any company for saying that, and
shame on them for believing it.” People hold to illusions because they give (false) hope, avoid
responsibility, and dodge conflict.
Illusions common to data sharing projects are:
 We have a vision.
 We know our priorities.
 We know what quality is.
 We know what we need.
 Everyone wants consensus.
 Everyone understands the expectations.
 Everyone understands the consequences.
 Everyone wants the project to be a success.
When getting stakeholders identified and involved and planning communications, it is essential
to (gently) expose these illusions and replace them with reality. You must also do a reality check

with the use of the terms we and everyone, as it is likely that there is no common definition or
expectation. Remember that people hear what they want to hear, so verbal communications must
ALWAYS be joined with clear, complete, and concise written communications.
There are various forms for stakeholder communication, such as email, newsletters, intranet,
social media, etc. No one method works the best and covers all stakeholders. Many
communication methods should be used.
Change Management in Data Sharing Projects
Key ideas kept repeating in the interviews conducted: the lack of buy-in at multiple levels within
the organization, lack of governance, underestimating the amount of involvement required, poor
communications, lack of clearly defined goals and objectives and more. Practitioners should ask
their service provider about their change management expertise, guidance, and training.
Kotter’s Change Management Model
It is recommended that the reader assemble a modest library of change management books and
peruse them for insights. A few books are highlighted as references at the end of this paper but
there are many more.
Harvard professor John Kotter’s work really struck a chord with the writers of this paper. Not
only was it easy to read, but it also seemed to speak to our experience with projects involving
public safety. While reading these change management principles it was impossible not to think
of past projects where illustrative examples of things done right as well as things that could have
been done better were plentiful.
Kotter’s Principles
The following key principles are taken from several of Kotter’s books, as listed in the References
section. Key ideas are synopsized below.
Set the Stage
This two-part section encompasses getting ready for change by helping others see both the need
for change and the importance of acting sooner rather than later (or doing nothing at all).
Presenting information clearly and logically helps convince people of the need for change and
the better results that will associate with the change.
Create a sense of urgency
Kotter recommends that data should be collected, analyzed, and presented clearly to help shape
opinion and consensus. You are building your case to make the change imperative.
In public safety data sharing projects, there is increasingly a penalty associated with not sharing
information whether between RMS systems or CAD systems (CAD-to-CAD). There are many
published examples (newspaper stories) where tragic events occurred due to the lack of data

sharing, most notably those involving failure to dispatch the closest unit in fire and EMS calls.
As a side note, having this information at hand can aid in your funding justification in grant
applications.
Assemble a leadership team
Kotter suggests that the leadership group must be carefully selected before being placed in
charge of guiding the change. They must embrace the sense of urgency and have strong
leadership skills. These skills include good communications skills, as well as credibility and
authority.
In public safety data sharing projects, visible and vocal leadership support is essential. More
projects than not have struggled due to missing support at the highest levels and poor
communications among all stakeholder groups.
Decide What to Do
This section details creating a vision of the future.
Develop vision and strategy to clarify how the future will be different
Kotter says that the leadership team should clarify how the future will be different and how
people can help make that future a reality.
In public safety data sharing projects, the vision must have a firm foundation in stark reality.
This means very careful vendor due diligence and a detailed Statement of Work (SOW). The
vision of the future must be realistic and goals must be SMART (specific, measurable,
achievable, relevant, and time-based.)
Make it Happen
This section details the core of the project and involves communications, empowerment,
publicizing short-term wins, and actively pushing the change.
Communicate for understanding and buy-in
Kotter instructs that leaders need to ensure that all stakeholders understand and accept the vision
and strategy. If there is resistance or apathy, you need to gather the additional facts to address the
underlying concerns.
There are a lot of stakeholders in public safety data sharing projects. These include people within
the organization(s), the political leadership, the funding source, the entire community, and the
media. Plan your communications to these stakeholders so that their perception of the project is
not only positive (detailing the benefits) but also aligns with reality.

Empower others to act
Kotter says that leaders should remove as many barriers as possible so that those who want to
implement the vision can succeed.
In public safety data sharing projects, this can mean a variety of things, from endorsing the
project as well as the project leader, to providing the tools needed for daily operations. It may
even entail involvement in addressing those resistant to change forcefully.
Produce short-term wins
Kotter advises that leaders are to create (publicize) tangible successes as soon as possible.
In public safety data sharing projects, this is fairly easy as successes are rampant… yet most
remain unpublicized. Remember the tip about communicating much more than you think you
need? The same rule applies to publicizing successes. This is the easiest way to prove the value
of the data sharing project. You can also involve your vendor who will likely be delighted to
craft a press release detailing the success.
Don’t let up
Kotter urges not to let up until the vision is a reality. Keep up momentum with proper messaging
and letting stakeholders know the urgency still exists. Use this phase to further reduce or
eliminate unnecessary work. Look at everyday work as well and ask if it is still necessary and
adds value.
In public safety data sharing projects, this phase can include the opportunity to review
workflows. The fact that we’ve always done it this way should be reassessed in light of the
automation provided and unnecessary labor eliminated. This is a great time to use automated
reports and reduce the length of routine reports.
Make it Stick
Kotter indicates that change is fragile and it is easy to slide back into the past. People yearn for
their old comfort zone with the comfort and stability it provided. Change must be supported by a
real change in the organizational culture.
Create a new culture
A new culture, strong and supportive of the change, must be vigilant to ensure that the change
becomes the new way of life within the organization. Organizational change often loses
momentum and can revert to the old way once the champions (the leadership team) either moves
on or lightens up (declares victory too soon). The new way of doing business must become a
habit for each individual.
In public safety data sharing projects, examples abound of projects that fail this ultimate test –
the change is not engrained and does not become a way of life to individuals within the
organization. An indisputable warning sign is when anonymous individuals within the

organization speak to the media decrying the new program/application/change and in so many
words state that the old way was better. Leaders must be vigilant and dig deep to determine the
reason for the resistant – real or imagined – and fix it.
Top 10 Best Practices by Role
Interviews conducted for this paper provided a wealth of detailed information, perspectives, and
project snapshots. What follows is the substance of the interviews, edited only for clarity and
removal of jargon. The identified best practices are influenced by job function but share common
themes, such as the need to manage change. The lists of best practices have been grouped based
on perspectives from five different roles: subject matter expert, practitioner, project manager,
consultant, and information technology manager.
Best Practices from a Subject Matter Expert (SME) Perspective
The following section was written by a SME with 40 years of combined experience in law
enforcement, public safety applications including CAD and Records systems, mobile data
applications, geographic applications, Automatic Vehicle Location (AVL) systems, and data-
sharing projects.
1. Start planning early. Learn all you can about change management by reading books or
taking a class; talk to your peers as well for their lessons learned. Identify all
stakeholders, both inside and outside the agency, and don’t overlook the value of
participation, involvement, or concern for the impact of change among these groups.
Communicating with your stakeholder groups is vitally important.
2. Plan for strong, frequent, and targeted communications.
Know your stakeholders and how to communicate with
them using a variety of methods (e.g., status meetings, in-
person briefings, video infomercials, email, ride-alongs,
bulletin boards, status reports, social media, etc.) so that all
stakeholder groups are kept informed. As indicated in the
table to the right, the content of communications must
change depending on where the project is in its lifecycle.
To reinforce communications, provide stakeholders with
three times the communication you think they need.
3. Devise a winning strategy. Be sure to make a compelling
and urgent case for change (i.e., implementing data sharing)
and how things will be better with this change. Have a defined end point and measure of
success. Plan for the long haul; achieving fundamental change in an organization is at
least a three- to five-year process.
4. Plan your approach to change. Assess time frame, extent of change, benefits, and
resistance to change. Be able to articulate what is important and at stake. Remember that
before you can get buy-in, people need to feel the problem and aren’t going to consider
anything until they are convinced there is a problem that truly needs to be addressed.

(Coincidentally, identifying and articulating the problem area will also help you prepare
for grant applications.) Don’t announce your go-live date, but, rather, announce the
quarter/year you expect to go live. Having a firm date pressures you to meet the date and
this often means cutting corners or simply missing the target completely, along with the
associated perception of failure.
5. Deal with resistance or indifference, which is harder yet. Expect that there will be
resistance to change and be prepared to manage it. It’s far better to anticipate and deal
with objections early than to spend your time putting out fires.
6. Assess your organizational culture. Don’t expect that everyone’s reaction will be even
remotely like yours. Organizations usually have networks and coalitions of people, not
visible on the formal organization chart, that help shape opinion and they can either
accelerate or retard change. Ignoring these groups can result in actual resistance. Plan
your messaging and communications accordingly.
7. Involve employees. Leaders must actively involve the people most effected by the change
in the project selection, implementation, configuration, training, and after action
assessments. Ensure that employees at all levels of the organization embrace the
proposed changes.
8. Have committed sufficient resources and skills. Remember the DICE formula and the
impact of the work on certain groups. Organizations often simply fail to commit the
necessary time, people, and resources to making change work. Remember the dangers of
a project taking too long –enthusiasm wanes and there is a real danger of other priorities
emerging that take your project’s resources and funding. Consider a phased approach to
data sharing – a situational awareness data sharing followed by true bi-directional CAD-
to-CAD or other data exchange.
9. Continue to publicize successes. This shows value to the stakeholders and positive
feeling about the investment in the change. Small successes will create feelings of
accomplishment and the drive to pursue the next goal. Those heavily involved in the data
sharing project must remember that they see success that others do not, so be sure to
communicate these successes frequently and over the long haul. Remember that the
primary reason for data sharing is to save lives; all the other myriad benefits, while
important, pale to this outcome. Publicize the large as well as the small.
10. Don’t let up. If you declare victory too soon, the focus will be taken away from your
efforts, and all traces of your hard work could soon disappear. People have a tendency to
slip back to the old way of doing things. Remember that it takes a long time to
institutionalize change so that it becomes a way of life. Publically praise the people who
embrace the new way of sharing information so that others will want to do the same.
Best Practices from a Practitioner Perspective
The following section was written by an agency practitioner team leader from a county-wide
implementation involving over 20 agencies. The practitioner’s background includes field

experience as a paramedic, paramedic supervisor, police/fire dispatcher, and director of a county-
wide services governance board. The practitioner holds NENA’s Emergency Number
Professional (ENP) certification as well as APCO’s Registered Public Safety Leader (RPL)
certificate, and is heavily involved with statewide legislative action.
1. Start planning your project by investigating possible solutions and capable vendors. Get
product demonstrations and invite potential users of the interoperability system to the
demos. This gets people involved and informed early in the process.
2. Don’t underestimate the impact of politics. You have to communicate a lot with the right
message to groups at all levels of the organization to get people accepting the project and
its importance. There may be power-plays and egos involved regardless if the project is
law enforcement or fire driven; sometimes it takes a long time to overcome this mindset.
Keep at it, as your communities and your first responders deserve this life-saving
technology.
3. Work on the governance early as well. This has to include standard operating procedures
(SOPs) and memoranda of understanding (MOUs) specific to automated exchanges of
information. Governance can be discussed when conducting your site surveys.
4. Allocate sufficient budget to handle the project as well as something for contingencies.
5. Gain consensus among departments for the business rules of data exchange. What people
want to see, how they need to see it, when they want to see it is important. It also keeps
them interested in the project and helps them experience ownership and empowerment.
6. You might want to start with a smaller subset and do a pilot (beta or proof-of-concept)
installation.
7. Involve representatives from the information technology department early in the process,
and make sure that there is sufficient staff to handle the extra workload.
8. Don’t assume that if you build it that they will come. It is essential to have solid reasons
for data sharing that will convince people that this is a good thing. That message is that it
saves lives, and that is the most important message you can give. You have to identify all
of the pros of the project for each stakeholder, spreading the correct word to the right
players. You have to communicate a lot!
9. You also need to be flexible and understanding while still keeping the goal in sight. Don’t
give up your timeline and let the project drag out. People will find other priorities.
10. You have to publicize your successes and continue to do so. You can’t assume that all
agencies know about how the system worked to save a life, catch a burglar, or help solve
a case. The public needs to hear about these successes too. Make the system part of your
daily life so that users can’t think of working without it.

Best Practices from Project Management Perspective
The following section was written by a project manager (PM) with more than 15 years of
experience in data exchange and software development projects. The PM has a Master of
Science in Computer Science, has been a PMI® Project Management Professional (PMP®), and
has managed dozens of data sharing exchanges including a project sharing more than 30 million
person records to 60,000 users nationwide.
1. Change management should not be an afterthought. Allocate a portion of the project
budget to fund, plan, and build change management into your project. Think of it as the
primary marketing campaign for your project. A fast food restaurant doesn’t bring out a
new burger without a marketing campaign and you shouldn’t bring out a new project
without a similar campaign.
2. Assume you have only one chance to get it right. With most users, this will be the case
as they easily get discouraged with delays and mismanaged expectations. Get user buy-in
as early and as often as possible.
3. Make sure you include representatives from all user groups. Missing user requirements
can mean failure for your project.
4. Plan for and build into your schedule time for the improbable. Your schedule is too tight
if any delay dooms your project to failure. If a key staff member or resource becomes
unavailable, you will need time to replace them/it. Those unlikely risks you identify
occur far too often.
5. Timing is everything. Plan your schedule so that change management activities do not
occur when it is busy or staff is swamped. Otherwise you could be sabotaging the success
of your project.
6. Think big and long term. Don’t be afraid to ask your vendor if something is possible. If
you don’t ask, you will never know. With all the new technology and new processes, it
might be.
7. Market the benefits. Users need to understand the benefits of the changes as they
specifically relate to them as well as to the entire organization. Don’t forget that peoples’
reactions to changes often reflect how the changes are presented to them.
8. Evaluate a large-enough sample of data to be sure you have covered all possible data
values. Communicate with your users and vendors to be sure that there are no data
exchange surprises later when it will be costly to make changes.
9. Document, document, document! Have a project charter. Develop and maintain a
communications plan. Formalize the data exchange goals and the data to be exchanged.
You really can’t take too many notes. Take minutes at all meetings, formal or informal.
Tape the meetings if you can.

10. Don’t expect to know everything at the beginning. Build a reserve into your project
budget and schedule to handle needed changes that may be uncovered or revealed during
the life of the project.
Best Practices from a Consultant Perspective
The following section was compiled by a consultant with more than 30 years of experience in
project management and system engineering, with over 20 years in the public safety domain. He
is a certified PMP and ENP. With expertise in public safety systems, he has provided consulting
services in needs assessment, specification development, proposal evaluation, contract
negotiations, implementation, and project management.
1. Obtain executive commitment. Top-down approval is critical to the success of the
project. If the goals and objectives are clear, and management support is behind the
project, the likelihood of success is increased.
2. Avoid extensive customization. The more customization that is performed on a new
system or interface, the more risk that is introduced into the project, resulting in increased
costs and longer implementation timeframes. Configuration, rather than customization, is
preferred, but be sure that the requirements and outcomes are clearly defined.
3. Over communicate. Keeping everyone informed on the project status pays benefits in
several ways. In addition to keeping the project team up to date, stakeholders, users, and
management need to be aware of the status throughout the project. This is critical for user
buy-in, and also allows for sharing of lessons learned throughout the project so that the
same mistakes are not repeated.
4. Establish clear objectives. A successful project is the result of a clear goal. Clarity in the
end result, the goals, and the objectives of the project increase the probability of success.
It is important to know how to measure success in order to understand how you achieve
your objectives, and when you have achieved them.
5. Avoid scope creep. One of the biggest challenges during project implementation is
staying on task and avoiding scope creep. There may be numerous opportunities to add
new features, but it is important to stay in scope and follow proper change order
management procedures. Otherwise, the project cost and schedule will increase, and user
satisfaction will suffer.
6. Involve users. Users who are involved in the project from the beginning are usually more
satisfied with the end result. Involving users allows them to be actively involved in
defining the requirements. Decisions made throughout the project should be
communicated so that users understand why decisions were made. Allowing all levels of
agency personnel to participate is important to project success.
7. Consider a phased implementation. A risk for any project is doing too much, too quickly.
It is important to size the project appropriately, making sure to take on a manageable
amount of work. The more complex the project, the greater the risk of failure. Successful

projects are frequently performed with an initial pilot or subset of functionality, testing a
single system or interface first, learning from the process, and then expanding to include
additional systems or interfaces only after the initial project has been successfully tested.
8. Have dedicated team/key personnel. Rarely is the staff required to perform the project
able to be dedicated to the project. As a result, realistic timeframes and commitments
must be established so that personnel can also perform their day job. Additional staffing
is often needed, or else extended project schedules will be likely.
9. Agency and team cooperation. While it may be obvious that cooperation among team
members is important, experience shows that cooperation between participating agencies
and departments, both internal and external, is just as critical. The various skill sets that
are vital to success need to work closely with the project team and the end users from all
participating agencies.
10. Vendor cooperation. Data sharing projects imply cooperation between agencies, but also
between vendors. If the project involves multiple solutions, there is a risk of proprietary
information issues which must be overcome. Vendor issues and concerns will need to be
addressed for the project to be successful.
Best Practices from an IT Perspective
This section was developed by an IT manager of a major city with over 40 years managing IT
projects. Currently, his duties include supervision of a very large IT staff that supports city
technology initiatives.
1. Obtain key stakeholder buy-in and active support up front.
2. Proper planning is critical, and needs to be performed jointly by the stakeholders and key
project personnel, with IT included from the start. IT staff must understand the user’s
business and what the project seeks to accomplish.
3. Sufficient funding is needed to cover not only the scoped project, but should also include
a contingency budget of 15-20%.
4. The importance of following a project management methodology cannot be overstated.
This includes developing the appropriate documentation (project charter, project scope,
risk assessment, communications plan, project justification worksheet, change control
plan, quality control plan, and project schedule). Note that the change control plan refers
to managing scope and contract change orders, and not the process of managing the user
experience as an old system is replaced (traditional change management).
5. Develop scheduled assessments and sign offs. Have a process for stage gates and sign-
offs that occur throughout the project. These include: documented customer
requirements, functional requirements, and design documentation all with the appropriate
signatures.
6. Adequate funding, time, and resources need to be committed to the project in advance.

7. Continued user involvement throughout the project is critical; users should be involved
early.
8. Test plans and test cases for unit and system testing, created in collaboration with the
customer and IT, are needed in order to adequately test and accept the system.
9. Develop a well-thought-out, realistic cutover plan. Include a cutover checklist and
identify responsibilities and contingency plans.
10. After cutover, perform a post-cutover critique and document lessons learned.
Real World Situations for Best Practices Application
Now that we have seen the best practices as viewed from a variety of stakeholder perspectives,
we can look at some real world situations and how things could have been done differently to
make the project outcomes more successful.
Mini Case Study 1
This case study refers to lessons learned from a large regional project to share CAD data. The
end goal of the project was to provide real-time situational awareness to all the participant
agencies through the sharing of CAD data. Large implementations and projects inherently have
different challenges and the resulting lessons-learned, while applicable to all projects, are critical
for large-scale undertakings.
Project Challenges
 There was no governance put in place when the project was initiated and it became
difficult to get all the agencies together as the project moved forward to make project and
funding decisions.
 When the initial funding ran out, the project’s future was in jeopardy as there were no
plans made or no resources set aside to handle the ongoing maintenance costs of the
system or any future enhancements that might be needed or desired.
Lessons Learned
A project manager noted the following lessons learned from this case:
 Having a governance agreement in place before the start of the project would have been
incredibly helpful. The governance agreement could have addressed project leadership,
project sustainability, and project administration.
 There was a great deal of publicizing success once the system was put in place but that
was the only positive messaging that occurred. Stakeholder agencies and citizens did not
get to hear about the value of the system and get involved in supporting it and the
benefits that it brought to the region.

Mini Case Study 2
This case study refers to an effort that involved a large number of agencies and mutual-aid
partners that wanted to share real-time CAD data for situational awareness.
Project Challenges
 The project leaders did not have the commitment of all the agency leaders from the
project outset.
 The project’s value was not proven to all agency participants. Because they did not buy
into the benefits, mid- and top-level leadership did not vocally support the project,
finding other priorities that took precedence.
Lessons Learned
A project leader noted the following lessons learned from this case:
 There should have been an agreed-upon timeline up front. In addition, governance of the
project was not addressed early enough in the process, and it would have helped garner
more support for the project.
 Project leaders should have done a better job in socializing the benefits of the project all
around.
 The project leaders and staff looked at the project in terms of technical issues but failed to
see that in the larger scheme, there were politics involved across the many stakeholder
agencies that were participating. These should have been anticipated and there should
have been a plan of action to deal with them.
 There was not enough messaging and communication throughout the project, which was
realized in hindsight and not during the project timeframes.
Mini Case Study 3
This case study refers to a CAD-to CAD data sharing initiative that was plagued with repeated
delays.
Project Challenges
 In this proof of concept project there were conflicting agendas, poorly written
requirements, a poorly written Statement of Work, and unrealistic expectations by
stakeholders.
 There was also a failure to have clear goals that defined success and identified the end
point of the project.

 Commitment was lacking among agency participants as well as the vendor to dedicate the
people needed to get the job done in a timely manner.
Lessons Learned
A project leader noted the following lessons learned from this case:
 There was an overall need for improved communications.
 The project leadership would have benefitted greatly by talking to others that have gone
through a similar type of project in the past.
 The project team should have identified misperceptions much earlier in the process and
addressed them – a lot of time was wasted from what is now known as scope creep.
Conclusions
The objective of this paper is to provide practitioners with additional information about best
practices in data sharing projects and how they can increase the odds that their data sharing
projects will be successful. A critical component of this is managing employee resistance or
apathy to change. The interviews conducted for this paper revealed that despite a plethora of
experienced, hard-working, dedicated and savvy professionals each project had challenges. It
was determined the projects could have gone more smoothly had change management concepts
been incorporated early in the planning.
Data sharing projects can be implemented using a variety of models or architectures and the
change to the new environment can have a widely varying impact on the users. To be successful,
change management must be part of the planning and must begin early in the process. Waiting to
begin change management planning until after procurement contracts are signed is a mistake as
proven by the research and lessons learned upon which this paper is based.
In addition to good change management practices, having strong governance agreements in place
is also key to project success. Not only does this provide leadership structure and address
sustainability, it also reinforces the desired goal and helps to create the new culture of sharing.
The combination of a strong governance plan coupled with good change management practices
help to ensure a successful project implementation. Together they may be the two most
important best practices in data sharing.

References
Articles and Documents
http://psc.apcointl.org/2011/12/13/asap-makes-a-difference-in-houston-burglary/
This is an automated data exchange using the Automated Secure Alarm Protocol (ASAP) between a
PSAP and an alarm monitoring central station. The automation facilitated several arrests.
http://documents.latimes.com/hooks-family-lawsuit-against-lafd/
http://www.latimes.com/local/lafddata/la-me-lafd-aid-20121021-story.html#page=1
http://www.latimes.com/local/lafddata/
The family of Stephanie Hooks is suing the city of Los Angeles claiming that a slow response by
the Los Angeles Fire Department contributed to her death.
http://latimesblogs.latimes.com/lanow/2012/12/los-angeles-county-fire-departments-911-systems.html
2012 article about linking LA City and LA County Fire Departments
http://pix11.com/2014/08/21/bronx-mom-says-delayed-911-response-led-to-babys-death/
A New York mother said that delayed 911 response led to baby’s death; officials say EMS should have
been ‘patched in’ right away.
http://fox13now.com/2014/02/03/confusion-over-911-call-cost-life-of-draper-man-family-says/
Confusion over 911 call cost life of Draper (UT) man, family says.
http://fox13now.com/2014/07/02/sandy-residents-demand-answers-regarding-slow-emergency-
response-times/
Sandy (UT) residents ask why the response time was so slow, why the closest departments
weren’t the first on scene, and why there was so much confusion from the dispatch centers.

http://www.nytimes.com/2013/06/13/nyregion/mother-to-sue-new-york-city-in-crash-that-killed-
4-year-old-girl.html?_r=0
The mother of a 4-year-old girl who was struck and killed by a car in Manhattan said that she
intends to file a lawsuit against the city, claiming that her daughter’s death could have been
avoided had emergency vehicles not been delayed in their response.
http://www.thedenverchannel.com/news/call7-investigators/larimer-sheriff-admits-12-minute-
delay-to-dispatch-poudre-canyon-fire-protection-dist-for-drownings06202014
Larimer Sheriff admits 12-minute delay to dispatch Poudre Canyon Fire Protection District for
drownings.
Informational Sources
http://www.pmhut.com/the-chaos-report-2009-on-it-project-failure
The CHAOS Report 2009 on IT Project Failure
http://www.indabook.org/d/Big-Bang-Boom-The-Standish-Group.pdf
A 12 page 2014 Standish report about large software and IT projects
http://www.psc.qld.gov.au/publications/subject-specific-publications/assets/change-
management-best-practice-guide.pdf
The Queensland Report
http://mnasq.org/wp-content/uploads/presentations/BestPracticesinChangeManagement.pdf
MNASQ presentation by Azurion consulting.
http://changingminds.org/disciplines/change_management/managing_change/style_change.htm
Changing Minds website detailing the collaboration spectrum.

http://www.sedl.org/change/facilitate/approaches.html
Southwest Educational Development Laboratory (SEDL) discusses the approaches to change and the
different terminology.
http://www.innovation.cc/scholarly-style/classic-theories.pdf
Discussion of the approaches used to guide change and frame change efforts.
http://www.nickols.us/four_strategies.pdf
Four Change Management Strategies by Fred Nickols
Recommended Reading
Leading Change, John P. Kotter
A Sense of Urgency, John P. Kotter
The Heart of Change, John P. Kotter
Our Iceberg is Melting, John P. Kotter
John P. Kotter on What Leaders Really Do, John P. Kotter
A Force for Change, John P. Kotter
Change is Good…You Go First: 21 Ways to Inspire Change, Mac Anderson
Switch: How to Change Things When Change is Hard, Chip Heath and Dan Heath
Who Moved My Cheese?, Spencer Johnson
The Heart of Change Field Guide, Dan Cohen and John P. Kotter
Who Killed Change? Solving the Mystery of Leading People Through Change, Ken Blanchard,
John Britt, Judd Hoekstra, and Pat Zigarmi
Leading Successful Change: 8 Keys to Making Change Work, Gregory P. Shea and Cassie A.
Solomon
The Change Handbook, Peggy Holman and Tom Devane
Managing at the Speed of Change, Daryl R. Conner

Change the Culture, Change the Game: The Breakthrough Strategy for Energizing Your
Organization and Creating Accountability for Results, Roger Connors and Tom Smith
ABOUT THE IJIS INSTITUTE
The IJIS Institute unites the private and public sectors to improve mission-critical information
sharing and safeguarding for those who protect and serve our communities. The IJIS Institute
provides training, technical assistance, national scope issue
management, and program management services to help
government fully realize the power of information sharing.
Founded in 2001 as a 501(c)(3) nonprofit corporation with
national headquarters on The George Washington University
Virginia Science and Technology Campus in Ashburn, Virginia,
the IJIS Institute has grown to nearly 320 member companies
and individual associates from government, nonprofit, and
educational institutions from across the United States.
The IJIS Institute thanks the IJIS Technical Advisory Committee (I-TAC) for their work on this
document. The IJIS Institute also thanks the many companies who have joined as members that
contribute to the work of the Institute and share in the commitment to improving justice, public
safety, and homeland security information sharing.
For more information on the IJIS Institute:
 Visit the website at: http://www.ijis.org/
 Follow the IJIS Institute on Twitter: @ijisinstitute
 Read the IJIS Factor Blog
 Join us on LinkedIn at: Justice and Public Safety Information Sharing
About the IJIS Public Safety Technology Standards Committee
The purpose of the IJIS Public Safety Technology Standards Committee (IPSTSC) is to promote
and contribute to the development of technical and functional standards for public safety IT
components, to provide industry input and policy review on technical matters faced by the public
safety community, and to oversee IJIS Institute projects assigned to the committee.
IPSTSC's functions include to:
 Review, comment, and make recommendations to practitioners on functionality and
technology that will improve the capabilities of public safety IT systems.
 Provide advice, counsel, and support to the IJIS Institute Board of Directors and other
IJIS Institute committees.

 Represent the IJIS Institute and industry at appropriate seminars, meetings, and training
programs to educate practitioners and industry on new trends and technologies for public
safety IT.
 Provide industry representatives to serve on committees and other national working
groups as requested.

IJIS Institute_ Change Management-Best Practices in PS Data Sharing Projects (Nov 2014)

More Related Content

Viewers also liked (12)

Similar to IJIS Institute_ Change Management-Best Practices in PS Data Sharing Projects (Nov 2014) (20)

IJIS Institute_ Change Management-Best Practices in PS Data Sharing Projects (Nov 2014)