Skip to Main Content

insightsarticles

Getting millennial with it: How state and local governments can recruit and retain a new generation of workers

By: Doug Rowe
09.06.17

As more state and local government workers enter retirement, state and local agencies are becoming more dependent on millennial workers — the largest and most educated generation of workers in American history. But there is a serious gap between supply and demand.

As noted in a 2016 report by the Bureau of Labor Statistics titled 
Household Data Annual Averages 15, only 25.6% of current
government workers are between the ages of 18 and 35.

This trend isn’t necessarily shocking; many millennials choose higher-paying jobs in the private sector over lower-paying jobs in the public sector, especially when the days of a lifelong government career, and generous pensions, are dwindling. But it is a serious labor problem for government agencies — one that requires creative solutions. To entice these new workers, state and local governments need to adopt new recruiting and retaining methods.

Recruiting Methods

While money matters to millennials, they also want to live a life of adventure, try new things, embrace trailblazing technology, pursue meaningful goals, and gain a sense of both personal and civic accomplishment. In short, these new workers have values that differ from previous generations. You can help entice them by:

  • Highlighting your state and local agency’s mission and greater purpose. Many millennials want to affect change and find careers consistent with their values. Include information in your job descriptions about the positive environmental and social impact your agency makes.

  • Updating your technology. Millennials have grown up with technology (literally at their fingertips), can adapt to change as no other generation before them, and often strive to remain on the “cutting edge.” By updating your agency’s technology, you will not only improve your organization and benefit the public you serve, but also have a better chance of recruiting the best and brightest millennials.

  • Providing them with a work-life balance. Life outside of work is just as important to millennials as their careers. They don’t plan to wait for retirement to finally pursue their interests, so providing them with a level of flexibility is key to recruitment. Consider offering flexible workdays, remote working capabilities, extended parental leave, sabbatical opportunities, and “mental health days.” The more flexibility state and local agencies provide, the more incentive there is for millennials.

Retaining Methods

Recruiting millennials for government jobs is challenging enough, and retaining them can prove even harder, as job hopping is standard practice for many members of this generation. Nevertheless, there are certain methods your agency can adopt to prevent millennial turnover. We suggest:

  • Investing in employee development and training. Training and creating opportunities for promotion and career advancement are motivating incentives to millennials. Professional development excites millennials and investing in them will pay off for the agency — and the employees will be more engaged and likely to stay.

  • Showing employees they are valued. Recognition is the biggest motivator besides money — millennials want acknowledgement for the good work that they do. Communicate achievements and provide awards to recipients in front of their peers. This not only gives them credit, but also motivates others. Continuing to communicate to your employees how their work supports their values reminds them they made the right decision in joining the public sector in the first place.

Make Your Move

Millennials are worthy of your attention! To compete with the private sector — to recruit and retain them — your government agency has to take an innovative approach to capitalize on this ever-growing demographic. If your state or local agency needs help refreshing your technology, reviewing current policies and procedures, or taking a fresh look at your processes, contact BerryDunn. We would love to talk about your commitment to your future!

You may also be interested in: CFOs for Hire; How to Attract and Retain Workers in a Seller's Market

Related Industries

Read this if you are a division of motor vehicles, or interested in mDLs.

It can be challenging to learn about the technical specifications that must be met to safely acquire, implement, and use emerging technologies. And why wouldn’t it be? Technical specifications are full of jargon only a technical expert can understand, and seem to appear out of thin air. Well, BerryDunn is here to help. When it comes to mobile driver’s licenses (mDLs), we’ve got the scoop.

Technical standards are developed by a few large international organizations. The International Organization for Standardization (ISO) is a Swiss-based organization responsible for the development of international standards for technical, industrial, and commercial industries in 165 countries. The International Electrotechnical Commission (IEC) is an international standards organization that develops and publishes standards for electronic technologies. The ISO and IEC have been collaborating on international technical standards for mDL technology. Recently, the ISO/IEC finalized and published these standards, which can be purchased on ISO’s website for $198 Swiss francs (about $213 US).

These technical standards cover three key components: 

  • Data exchanged during an mDL transaction
  • Security during online and offline mDL transaction scenarios
  • mDL data model to ensure mDL interoperability 

Data exchange/transaction

Data exchange is the process by which an mDL device is used to provide credentials (e.g., verify age or identity) to an mDL reader. Broadly speaking, data exchange consists of three phases: initialization (activating your device at a store to confirm your identity), device engagement (the mDL device creates a connection with the mDL reader), and data retrieval (the mDL reader requests the appropriate data to continue a transaction). The process can occur when the mDL has an internet connection (online retrieval) or when it does not have an internet connection (offline retrieval). Offline data retrieval can be conducted using a combination of Bluetooth Low Energy (BLE), Near-Field Communication (NFC), or Wi-Fi Aware technologies. These are all methods by which an mDL can connect to mDL readers at short ranges, functionally similar to Apple Pay. Online Data retrieval can be conducted using a web-based application programming interface (WebAPI) or OpenID Connect (OIDC). These are methods by which mDLs connect with the mDL issuer, confirm the mDL holder’s identity, and allow the mDL issuer to transfer data to the mDL reader. In short, an mDL transaction might look something like this:

  1. Initialization: An mDL holder attempts to purchase alcohol from a local store. The mDL holder opens their device, enters their mDL application using a PIN or biometric security feature, and uses NFC or a QR code to initiate a connection between the mDL and mDL reader.
  2. Device engagement: The mDL and mDL reader connect using NFC or a QR code.
  3. Data retrieval: The mDL reader either asks the mDL for data to confirm the holder’s age, or asks the mDL issuer to confirm the mDL holder’s age. Either the mDL or mDL issuer sends appropriate data to the mDL reader to confirm the holder’s age. Once validated, the mDL-reading establishment and mDL holder are free to complete the transaction. 

Security for mobile driver’s licenses 

mDL security aims to protect against four primary threats.

  1. mDL forgery/forgery of data elements
  2. mDL cloning/cloning of data elements
  3. mDL communication eavesdropping
  4. Unauthorized mDL access 

mDL security needs to cover online scenarios, in which an mDL-holder’s device is connected to the internet, as well as offline scenarios, when an mDL holder’s device does not have internet connectivity. Potential mDL security options include: 

  • Authentication of mDL data to protect against data cloning
  • Authentication of the legitimacy of the mDL reader to prevent alteration of communications between the mDL and mDL reader 
  • Session encryption to preserve mDL data confidentiality and prevent mDL data alteration or unauthorized data access
  • Issuer data authentication to ensure the mDL data originates at a legitimate issuing authority

During online retrieval scenarios, mDLs can employ transport layer security (TLS) to preserve the confidentiality of mDL data, or use a JavaScript Object Notation (JSON) Web Token (JWT) to authenticate mDL data origin.  

mDL technical specifications: Key terms and definitions

Technical specifications are an important, yet confusing aspect of IT system implementations, particularly for emerging technologies where expertise has not yet been established within the market. The same holds true for mDLs. Understanding mDL technical specifications requires understanding the specific terms used to describe the technical specifications along with general mDL terminology. Here’s a list of mDL-related and technical specification terms and definitions.

Key terms and definitions
 

Terms Definitions
Bluetooth Low Energy (BLE) A form of Bluetooth that provides a wireless connectivity of similar range to traditional Bluetooth at reduced device power consumption.
IEC International Electrotechnical Commission
ISO International Organization for Standardization
JavaScript Object Notation (JSON)  An open standard file format and data interchange format that uses human-readable text to store and transmit data objects.
JSON Web Token (JWT) An object used to transfer information between two parties over the web.
mDL issuer  The department of motor vehicles or bureau of motor vehicles responsible for administering rights to, and overseeing distribution of, mDL data to mDL holders.
mDL holder The person whose data is contained in, and represented by, the mDL.
mDL reader The hardware technology used to consume mDL data from an mDL holder’s device.
mDL-reading establishment The institution consuming mDL data via an mDL reader (e.g., law enforcement, liquor store, Transportation Safety Administration).  
Near-Field Communication (NFC) Communication protocols that allow electronic devices to communicate over distances of 1.5 inches or less (e.g., Apple Pay).
Offline retrieval The mDL holder’s device is not directly connected to an internet network via Wi-Fi or cellular data, requiring the mDL device to hold some mDL data—behind security features (e.g., PIN, or biometric lock)—and, at a minimum, confirm holder identity, driving privileges, age, and residence.
Online retrieval  The mDL holder’s device is connected to an internet network via Wi-Fi or cellular data. Upon request, the mDL holder can initiate a transfer of mDL data using a QR code or web token to approve the sharing of mDL data between the mDL issuer and mDL reader. 
OpenID Connect (OIDC) OpenID Connect is an authentication protocol that allows for the verification of end user identity.
Transport Layer Security (TLS) A cryptographic protocol that provides communication security over a computer network (e.g., between an mDL reader and mDL issuer).
Web Application Programming Interface (API)   An interface for a web server or web browser.
Wi-Fi Aware A Wi-Fi capability that allows devices to discover potential Wi-Fi connections nearby without connecting to them. Wi-Fi Aware runs in the background, and does not require users to have current Wi-Fi or cellular connections.


If you have any questions regarding mDLs and technical requirements, please contact us. We’re here to help. 

Article
mDL technical specifications: Background, terms, and topics

Read this if you are a division of motor vehicles, or interested in mDLs.

Successful acquisition and implementation of a mobile driver’s license (mDL) program requires knowledge of the specific functional needs mDLs must satisfy to help ensure mDL programs provide security and convenience to mDL holders. These functional needs span mDL-reading equipment, issuing authorities (e.g., departments of motor vehicles), law enforcement and other mDL-reading establishments, and mDLs themselves.  

Per the American Association of Motor Vehicle Administrators (AAMVA) Functional Needs White Paper, functional needs span eight broad categories: operations, trust, identity, cross-jurisdictional/vendor use, data privacy, remote management, ease of use, and other. The table below organizes these categories, briefly explains associated functional needs, and assigns a level of criticality to each functional need. Critical functionality must be accommodated by mDL programs in some manner. Desired functionality is optional, but heavily encouraged.

Table 1: Key Terms and Definitions
mDL Functional Needs Breakdown
Category Description Required/Desired
Operation – Online and Offline mDL holders must be able to validate their identity when either the mDL holder, the mDL reader, or both lack access to the internet.  At a minimum, offline use must allow citizens to confirm their identities, driving privileges, age, and residence. Critical
Operation – Attended mDL holders and mDL-reading establishments must be physically present when an mDL holder’s identity is established as credible, typically using the mDL portrait image. Critical
Operation – Unattended mDLs must function when the mDL-reading establishment is not present during a transaction with an mDL holder. Desired
Trust mDL holders must be able to establish that data comprising the mDL was issued by the relevant issuer and that information has not been changed, unless via an update through the relevant issuer. Critical
Trust mDL-reading establishments must employ readers they trust to obtain and validate information from mDLs. Critical
Identity – Portrait Image mDLs must have portrait image of the mDL holder. Critical
Identity – Portrait Image mDLs must have the ability to retrieve the portrait image from the issuing jurisdiction using a one-time token. Critical
Identity – Portrait Image mDL readers must read portrait images from mDLs, retrieve it from the issuing jurisdiction, and display the image. Critical
Identity – Portrait Image Law enforcement must have mobile mDL readers in order to review the mDL portrait image and mDL holder simultaneously. Desired
Identity – Biometric mDL-reading establishments must have trusted equipment to obtain the mDL holder’s biometric information. Desired
Identity – Biometric mDLs and readers must support a one-to-one  comparison of the mDL and holder biometric information, executed by the mDL-reading establishment or mDL issuer. Desired
Identity – PIN mDLs must support the use of a personal identification number (PIN) to authenticate the legitimacy of an mDL and its holder. Critical
Identity – PIN mDL holders must trust that mDL readers will not compromise their PIN when entering it.

mDL readers must trust that the PIN accurately validates mDL holder information when the authentication process occurs on the mDL holder’s device.
Critical
Cross-Jurisdictional & Vendor Use mDL readers must be able to read mDLs from multiple issuing jurisdictions and multiple vendors. Critical
Cross-Jurisdictional & Vendor Use mDLs require interfacing with the relevant issuer, with the ability to control how mDL data is uploaded to holder devices and updated. Critical
Cross-Jurisdictional & Vendor Use mDLs require in-real-time interfacing with the holder’s device and the reader. Critical
Data Privacy As with physical DLs, mDLs require a process for granting holder consent prior to information release. Critical
Data Privacy mDL holders must be able to release selective information (e.g., age, driving credentials) without releasing all personal information stored on the mDL (data minimization). Critical
Data Privacy Issuing authorities must be able to allow unrestricted access to an mDL, without the holder’s consent, in cases where the holder is unconscious, nonresponsive, etc., e.g., following a major car accident, law enforcement might need to verify whether an individual is an organ donor. Desired
Data Privacy mDLs must be linkable to the government-related transactions they are used for (e.g., interacting with the DMV, law enforcement), allowing local and state officials to review the history of transactions related to a specific mDL. Desired
Data Privacy mDLs must be unlinkable from the private-industry transactions they are used for, preventing mDL-reading establishments from tying mDL holders to specific transactions. Desired
Data Privacy The mDL should grant the mDL holder visibility into all personal data contained in the mDL. Critical
Remote mDL Management1 mDL issuing authorities must have the ability to perform the following actions to mDLs remotely:
  • Add, update, and revoke (temporarily and permanently) driving privileges.
  • Update the application storing the mDL.
  • Revoke the mDL entirely (in the case of suspected fraud)
Critical
Remote mDL Management mDL holders must have the ability to remotely update their mDL data, including revoking their mDL in the case of a lost or stolen mDL. Critical
Remote mDL Management mDLs with combined offline/online functionality must expire should the mDL holder not connect their mDL to issuer’s system within a defined period of time. Critical
Remote mDL Management mDLs must support the ability to be returned to the issuer prior to the issue of a new mDL to a holder.

mDLs must support the ability to be returned to the issuer, marked as void, and returned to the holder prior to the issue of a new mDL to the holder.
Optional
Remote mDL Management mDLs must allow law enforcement officers from a holder’s home jurisdiction to suspend a holder’s mDL under specified circumstances. Critical
Remote mDL Management mDLs must support the ability for issuing authorities to change mDLs to IDs (in the case of driving privilege revocation) and change IDs to mDLs (when driving privileges are gained). Desired
Remote mDL Management mDLs must support the ability to transfer devices, either online (desired) or by visiting issuing authorities in person (critical). Desired/Critical
Ease of Use mDLs must not require mDL-reading establishments to handle the mDL holder’s device during a transaction. Critical
Ease of Use mDLs must operate during different weather conditions (rain, snow, intense sunlight, etc.) Desired
Ease of Use mDLs must function at all times, regardless of the level of ambient light. Critical
Ease of Use mDLs must function in various environments (office, traffic stop, etc.) Critical
Ease of Use mDLs must minimize the amount and cost of additional equipment that law enforcement and other mDL-reading establishments require when processing mDL transactions. Desired
Other – Processing     Time mDL readers must be able to process an mDL transaction with comparable time to physical DL transactions. Critical
Other – Non-reliance on Device Security by Consumer mDL readers must be able to authenticate mDL data without relying on the security of an mDL holder’s device (e.g., biometric readers). Critical

1Remote mDL management assumes at least a partial level of online mDL functionality. mDLs cannot be remotely managed in offline scenarios.

If you have questions about mDLs or about your specific agency, please contact the team. We’re here to help.      

Article
Functional needs for a successful mobile Driver's License (mDL) program

Read this if you are a division of motor vehicles, or interested in mDLs.

You drive to the airport, and are pulled over by law enforcement. They check your driver’s license. You arrive at the airport, and rush through the TSA checkpoint. They check your driver’s license. You buy a drink in the airport bar to calm your nerves. They check your driver’s license. You board your plane, take off, land in your destination, and rent a car. They check your driver’s license. You drive to the hotel and check yourself in. They check your driver’s license. From run-ins with law enforcement, to traveling, to purchasing alcohol, driver’s licenses are necessary and versatile parts of every citizen’s identification arsenal—and soon, they will be mobile. But this new frontier of electronic identification—despite widespread applicability and increased holder convenience—brings challenges for mDL issuers and mDL-reading establishments.

The mDLs must function in a range of scenarios, each of which with distinct business processes, differing levels of holder data control, and various levels of online functionality. The widespread applicability of mDLs mean that state, county, and local issuing authorities need to simultaneously anticipate the range of mDL holder scenarios, identify the functionality required to meet these scenarios, and anticipate implementation challenges.     

Additionally, understanding mDL functionality requires understanding the specific terms used to describe that functionality, and these terms vary. From the participants in mDL transactions, to the kinds of transactions occurring, to the various screens and data validation methods, this terminology quickly becomes complicated. 

Table 1, Key Terms and Definitions below contains a list of mDL-related terms and definitions used within this blog, and accompanying future functional needs blogs.

Table 1: Key Terms and Definitions
Terms Definitions
mDL issuer The department of motor vehicles or bureau of motor vehicles responsible for administering rights to, and overseeing distribution of, mDL data to mDL holders.
mDL holder The person whose data is contained in, and represented by, the mDL.
mDL reader The hardware technology used to consume mDL data from an mDL holder's device.
mDL-reading establishment The institution consuming mDL data via an mDL reader, e.g., law enforcement, liquor store, Transportation Safety Administration.
Portrait image The image of the mDL holder used to verify the holder's ownership of the mDL by visual means.
Attended operation The mDL-reading establishment is physically present when the mDL holder is certified as the owner of the mDL data. E.g., checking in at a hotel, buying alcohol at a liquor store, verifying ID during a traffic stop scenario.
Unattended operation The mDL-reading establishment is not physically present when the mDL holder is certified as the owner of the mDL data. E.g., verifying age during an internet transaction.
Personal Identification Number (PIN) A number (usually 4 digits) created by an mDL holder and used to validate their identity during transactions.
Use Case A situation in which a holder will rely upon an mDL to convey their data to mDL-reading establishments, for a defined purpose.


Table 2, mDL Use Cases below lists situations in which mDL transactions are common, called use cases, and marks them as primary or future mDL use cases. Table 2 also categorizes whether the transactions occur with online/offline functionality (or both); and whether the transactions require both parties to be present during the transaction (attended), do not require both parties to be present during the transaction (unattended), or both. 

Note that mDL use cases are ever evolving, as is the functionality required to complete them. For the most up-to-date content, consider reviewing resources developed by the American Association of Motor Vehicle Administrators (AAMVA) or the International Organization for Standardization (ISO).

Table 2: Standard mDL Use Cases
Use Case Online/Offline Functionality Attended v. Unattended Operation
Primary Use Cases
mDL holder is involved in a traffic stop with law enforcement. Both Both
mDL holder goes through a Transportation Security Administration (TSA) checkpoint at an airport. Both Attended
mDL holder purchases alcohol in person. Both Attended
mDL holder rents a car. Both Both
mDL holder checks into a hotel. Both Both
mDL holder confirms identity with financial institutions. E.g., banks. Both Attended
mDL holder obtains social services. Both Both
mDL holder confirms identity when voting. Note: This use case might not be required in all jurisdictions. Both Attended
mDL holder confirms identity to gain access to federal facilities (if appropriate). Both Attended
Future Use Cases
mDL holder proves age for age-restricted purchases via the internet. Online Unattended
mDL holder signs a document electronically.  Online Unattended
mDL holder opens a bank account online.  Online Unattended


If you have questions about mDLs or about your specific agency, please contact the team. We’re here to help. 

Article
Mobile Driver's License (mDL) functional needs: Definitions and use cases

Read this if you are a division of motor vehicles, or interested in mDLs.

What is a mobile driver’s license?

A mobile driver’s license (mDL) is a solution that allows citizens to access, update, and use their driver’s license via a smart phone or other internet-accessible device (e.g., laptop, tablet, smart watch). An mDL is a form of electronic identification (eID), but where eIDs include other forms of licensure like hunting/fishing/gaming licenses or military IDs, mDLs are used to designate driving privileges and, in some cases, to designate age-based/identity privileges for citizens who cannot drive (e.g., buying alcohol, TSA PreCheck®).

Why should you care?

Technology has replaced physical product functionality within various areas of modern life. Many people have transitioned to electronic credit/debit card payments (e.g., Apple Pay), making paying for everyday items faster, easier, and cleaner, while also introducing risks to consumer data security. Similar functionality will soon exist within the eID space, starting with mDLs. This provides challenges for departments of motor vehicles (DMVs), businesses, and consumers; however, the benefits of adopting mDL functionality outweigh the growing pains of establishing the programs.

How does it work and when will it be implemented?

The mDL will function similarly to electronic credit cards and mobile payment applications: an mDL user loads their mDL to their mobile device using a mobile application and can use it to verify their age and driving credentials at mDL-reading establishments and with law enforcement. Relevant establishments will require both hardware and software solutions to read mDLs. 

mDLs aren’t intended to replace physical licenses—at least not yet. While state and county pilot programs resolve some of the challenges associated with mDLs, physical IDs will remain required for years to come. 

Additionally, the American Association of Motor Vehicle Administrators (AAMVA) created two groups—a Card Design Standard Committee and Electronic Identification Working Group—to develop interoperable standards to assist license issuing authorities (e.g., DMVs) in developing their mDL programs. These standards will ensure that mDLs work using different hardware, software, vendor applications, and within different jurisdictions. 

Benefits and challenges

Benefits

mDLs provide numerous benefits to citizens and DMVs alike, including information security, user convenience, and administrative convenience.

Information security

  • mDLs are harder to fake than physical driver’s licenses due to the mDL’s connection to back-end license data within the DMV system. 

  • mDLs allow users the option to communicate specific data to the receiving party without sharing all of the user’s license information (e.g., confirming the user is over age 21 without sharing their specific age or street address). 

User convenience

  • Users will be able to update their credentials fully online and see in-real-time updates.
  • mDLs will possess single sign-on verification and use for users via a biometric lock or PIN, making them quick to access and easy to use.

Administrative convenience

  • The decline in DMV wait times due to online-update functionality will save DMVs money in administrative costs.

Challenges

As with all technological advancement, there are several challenges around the development of mDLs. The primary challenge is ensuring the protection of user data while also rolling out the complex—and often costly—infrastructure needed to support mDL use across a region. 

Information security 

  • Issuing agencies can choose whether some, none, or all mDL user data is stored on the user’s device and must ensure all data stored this way is done so securely.

  • mDLs must ensure hands-free exchange of information with law enforcement to protect user data when presenting identification.

  • Technological errors are bound to occur: if an mDL-reading establishment is not able to read a citizen's mDL for any reason, a citizen will require a physical license to complete the transaction.

Program rollout

  • States and mDL vendors will need to support interoperable mDL standards to ensure that an mDL works with different vendor software and across jurisdictions.

  • Establishments and law enforcement will need the necessary mDL-reading hardware (smart phone, smart watch, tablet, laptop, point-of-sale terminal) and software (QR code readers, Bluetooth functionality, Wi-Fi Aware, Nearfield Communication, etc.) to read mDLs.

  • mDLs must be able to function in both offline and online scenarios to ensure the security of consumer data and proper functionality.

The future

mDLs are just the beginning of the opportunities eID technology will bring. Once established by DMVs, eID technology can and will be used to find and buy insurance services, check medical prescriptions, apply for social/welfare benefits, open hunting/fishing/gaming accounts and display appropriate credentials, and access pension information. 

The versatility that eID technology provides will streamline American citizens’ identification arsenal, and the advancing mDL technology puts us on the path to get there. The question is not will mDLs become widespread, but when.
 

Article
Introduction to mobile driver's licenses (mDLs): What are they and why are they important?

Read this if you have a responsibility for acquiring and implementing victim notifications for your jurisdiction.

In the first article of this three-part series we explored the challenges and risks associated with utilizing multiple victim notification systems across your state, while the second focused on exploring what the choices are to address these challenges. In this final installment, we demystify the process of developing requirements for a victim notification system. Here are some things to address when developing requirements:

  • Considering all of your victim notification stakeholders and their specific needs
  • “Mining” requirements from your current victim notification system to ensure that your current needs are met in the future system 
  • Determining what the market can support (and what it can’t)
  • Utilizing standards to increase the likelihood that market solutions, designed based on these standards, will meet the needs of your jurisdiction 

Understanding the needs (and wants) of your stakeholder group is critical to defining a successful set of requirements that meets your specific needs. Representative stakeholders may include:

  • Victim advocacy groups (both government run and private sector)
  • Police and sheriff departments
  • Department of Corrections 
  • The courts
  • Probation department
  • Prosecutor offices
  • The victims themselves

Of course the stakeholder group in your jurisdiction may differ, and the needs of these groups will also differ. For example, victims and advocacy groups are concerned about ease of use, accuracy, and timeliness of notifications. Police and sheriff departments may be concerned about ensuring they are meeting their statutory and moral obligations to notify the victims when offenders are released from custody. 

Since these groups have varied needs, it’s important to engage them early and throughout the requirements development process. Talk to them, observe their practices, and review their current systems. It’s possible, for example, that it’s important that sheriff departments can integrate their jail management system to the replacement victim notification system and the integration creates a seamless and timeline notification process when an offender is processed out of jail and into the community. Because the Department of Corrections is designed to hold offenders for a longer period of time, the department may require that their offender management system triggers an alert to victims when pre-release planning activities begin.

Scaling victim notification systems

Utilization of victim notification systems can also include a broad spectrum; from a single jail engaging with a victim notification system vendor to provide specific notification services, to a statewide victim notification system that provides these services for the larger stakeholder group. Because of this, your requirements must reflect that “scale.” Consider the utilization of the system before developing your requirements so that you don’t over (or under) engineer the system for your jurisdiction.

As mentioned in the second article in this series, there are many victim notification system options to consider, from home-grown applications to turnkey software as a service (SaaS) services. Regardless of the path you choose, consider leveraging the victim notification system standards as defined by the Department of Justice (DOJ) Bureau of Justice Assistance (BJA SAVIN Guidelines). These guidelines and standards are terrific sources for victim notification system requirements, and can be thought-provoking as you engage your stakeholder groups. 

Though these standards are extremely useful, be sure to identify and include any jurisdiction-specific needs in your set of requirements. They may be driven by state statutes or by local policy or process. In defining your unique requirements, just ask, “Why are they important? Were they defined based on processes put in place because you don’t have a strong victim notification system, or are they critical to satisfying statute or policy?”

Stakeholder communication and engagement

Once you develop a preliminary set of requirements, it’s important to meet with the stakeholder groups to refine and prioritize the requirements. This exercise will result in a clear and concise set of requirements that are understandable by victim notification system vendors that may be responding to the resulting solicitation. When defining the requirements themselves, we find it useful to follow the guidelines from the Institute of Electrical and Electronics Engineers, Inc. (IEEE) called “IEEE Recommended Practice for Software Requirements Specifications.” According to the IEEE standard, good software and hardware requirements should be: 

  1. Correct
  2. Unambiguous
  3. Complete
  4. Consistent
  5. Ranked for importance
  6. Verifiable
  7. Modifiable
  8. Traceable

Prioritization of the requirements also helps responding vendors understand which requirements are most important to your jurisdiction. This prioritization model can also be used when scoring the vendors’ responses to the requirements once proposals have been received. 

Conclusion

In summary, it is important your victim notification system requirements reflect the needs of your stakeholders, are realistic, and clear. Vendors will be asked to respond to how they can accommodate the requirements, so using the IEEE method described above can be useful. 

Though this article doesn’t dive deeply into the development of the request for proposals (RFP) for the victim notification system, below are some actions to take to improve your chances for a successful system selection project:

  1. Define a meaningful project scope to scale the vendor market
  2. Assign a balanced evaluation committee with impartial scoring criteria
  3. Craft a structured procurement package that attracts multiple vendors
  4. Design a reasonable and achievable RFP schedule of events
  5. Reduce ambiguity and increasing clarity of RFP terms

If you have questions about your specific situation, please contact our Justice & Public Safety consulting team. We’re here to help. The BerryDunn team has developed a mature methodology for determining victim notification system requirements, and has a rich repository of requirements to start with so that you don’t need to start from scratch.
 

Article
Victim notification system requirements: It's easier (and harder) than you think

Read this if you have a responsibility for acquiring and implementing victim notifications for your jurisdiction.

In the first article of this three-part series we explored the challenges and risks associated with utilizing multiple victim notification systems across your state. In this article we will explore what the choices are to address these challenges. 

System elements to consider

Many jurisdictions are under the impression that there are only one or two choices for victim notification systems. Though there are certainly market leaders in this space, you should select a system model that best meets your jurisdiction’s profile. The profile may include some of these elements:

  • Risk aversion (i.e., How risk averse is your organization regarding system implementations?)
  • Budget (i.e., How will the initial project be funded? Does your jurisdiction prefer an annual subscription model, or a traditional perpetual license with annual maintenance and support fees?)
  • Staff (Who do you need to implement and maintain the operational system?)
  • Time (i.e., Are you already out of compliance with state statutes?)
  • Hosting environment (i.e., Do you want to host in the cloud or on premise?)
  • Victim notification reach (i.e., state-wide, single jurisdiction, multiple justice partners)
  • Victim notification policy and statute complexity
  • Data ownership (i.e., To what degree does your jurisdiction enable the selling of victim notification data outside of the jurisdiction?)

Victim notification solutions range from hosted commercial off the shelf (COTS) solutions, which are typically least expensive; to custom solutions developed to address jurisdiction-specific needs. The latter tend to be more expensive, riskier than turnkey solutions, and take longer to operationalize. However, if your jurisdiction has unique requirements for victim notification, this may be a viable option. Unless you plan to engage the development vendor in a long-term contract for maintenance of this type of system, you must consider the impact on your existing IT staff. “Platform” solutions are a hybrid of COTS and custom development. With these solutions, there is typically a platform (i.e., Customer Relationship Management or CRM) on which the victim notification system is developed. Using a platform de-risks the development of the application’s architecture, may be a slightly less costly approach, and may simplify the maintenance of a system that is addressing unique requirements.

You may also already have licenses for victim notification capabilities, and not even realize it. Some offender management systems (OMS), jail management systems (JMS), and even prosecution systems (that support victim advocacy functions) may have built-in victim notification functionality included for the licensing price you are currently paying, or may include the option to purchase an add-on module. 

Advantages of using victim notification capabilities packaged with an existing system may include:

  • Lower acquisition and maintenance costs
  • Tighter integration with the OMS, JMS, or prosecution system may result in more seamless utilization of offender and victim data
  • You have a single contract, with a single vendor, reducing contract management overhead

A likely disadvantage, however, is the victim notification functionality may not be a robust as a point solution, or custom-built system. Additionally, if the “reach” of the JMS is a single county, then victim notification capabilities built into your JMS may not suffice for statewide use. However, if the built-in functionality meets your needs, then this is certainly a viable path to consider.

As mentioned in the first article, regardless of your approach the integration between your victim notification system and the JMS, OMS, prosecution system, and court system is critical to reducing redundancy and increasing the timeliness with which both offender and victim data is entered into the victim notification system―and used to trigger the notifications themselves.

Determining the best option for your victim notification system

So how do you determine which choice is best for your jurisdiction? The first step is to determine your jurisdiction’s risk profile versus the need to for jurisdiction-specific functionality. 

Mature market-based solutions are typically less risky to implement, since multiple jurisdictions are likely successfully using them to support their victim notification operations. However, these solutions may not be customizable or flexible enough to address your specific needs. 

“Build” models (using platform solutions or other application development models) tend to be a bit more risky (as many “from scratch” development projects can be); however these are more likely to address your specific needs. Here are a few questions that you should ask before making a determination between a COTS solution and a custom-build:

  1. Do we really have jurisdiction-specific victim notification needs?
  2. Can a COTS solution meet the statutes and policies in our jurisdiction?
  3. How risk-averse is our jurisdiction?
  4. Do we have time to develop a customized solution?
  5. Do we have the talent and capacity to maintain a custom solution?

Budget considerations

The next step is to determine your budget. We recommend you assess a budget over a 10-year total cost of ownership. The cost of a traditional, perpetual license-based COTS solution, including initial acquisition and implementation, will be higher in the first few years of use, but the ongoing annual fees will be lower. The cost of a custom-build solution will be even higher in the first few years, but annual maintenance should drop off dramatically. The cost of a subscription-based COTS solution will be relative even year over year. However, if you model these costs over 10 years, you will have a reasonable sense for how these costs trend (i.e., the cost of a subscription-based model will likely be higher over 10 years than the perpetual license model). 

The other consideration is how you plan to fund the system. If there are capital funds in the budget for initial acquisition and implementation, this may benefit the perpetual license model more than the subscription-based model. Regardless of the funding approach, you will likely be using the selected victim notification method for a significant period of time, so don’t settle.

Finally, determine how to acquire the system (or systems integration vendor that will help you develop the system), which is the subject of the third article in our series.

If you have questions about your specific situation, please contact our Justice & Public Safety team. We’re here to help. To learn more about other choices in victim notification procedures and systems, stay tuned for our third article in this series where we explore the process (and pitfalls) of procuring a statewide victim notification system.

Article
Victim notification systems: What choice do you have?

Read this if you have a responsibility for victim notification.

Is your state complying with state and federal victim notification system statutes? How do you know if you are (or aren’t)? The federal government passed the Victims’ Rights and Restitution Act in 1990. This act requires all federal law enforcement officers and employees to make their best efforts to accord victims of crime with the right to be notified of offender status changes (i.e., movement from incarceration to the community). All states have similar statutes; many are more prescriptive and specific to each state.

You may be thinking “we have implemented a victim notification system, we’re all set.” To be sure, it’s best practice to ask yourself these questions:

  • Does my state use multiple victim notification systems, possibly one for the Department of Corrections, and others in use for jails, courts, or by the prosecutor’s office?
  • Do victims understand how to register and use the system(s)?
  • If you have multiple systems in use across your state, do victims know they must register in each (assuming that the offender is nomadic)?
  • Are the systems interfacing with the victim notification system to provide real-time updates regarding offender status changes and movements, or is the data reliant on human entry alone?
  • Is there redundancy in your victim notification approach? Are you relying solely on the victim notification system for statutory compliance, or are there other measures in place?
  • Have you defined the term “victim” in your state? How do you distinguish “known victims” from “interested parties”? Are these two groups treated equally in your victim notification systems and processes?

As we have explored these questions with various corrections clients, we’ve found that states address them in unique ways. In many cases, initial information regarding victims is captured on a pad of paper; in some, that information is never transposed into electronic form. Smaller, rural jails are more inclined to manually reach out to victims in their tight-knit communities, while jails in larger jurisdictions may not have the capacity to do so, and rely much more heavily on automation to comply with victim notification requirements. 

Many states use multiple victim notification systems (jails may use one system, while prisons use another), without integrating them to share data about offender movements and victim registrations. This results in a gap of service to victims likely unaware of the ramifications of having multiple, disparate victim notification systems. Many mature victim notification systems have the ability to interface with systems such as offender management systems (typically managed by the state’s department of corrections), jail management systems (typically managed by each county sheriff’s office), prosecution systems, and others. 

These system integrations are critical to reducing redundancy and increasing the timeliness with which both offender and victim data is entered into the victim notification system and used to trigger the notifications themselves.

So how can you assess your processes? The first step is to determine if your state has a problem with, or compliance gap between current practices and victim notification statutes. Here are some steps you can take to assess your situation:

  1. Review the victim notification statutes in your state
  2. Inventory the victim notification systems in use across your state, including any interfaces that may exist with the systems described earlier
  3. Talk to victim advocates to learn more about how they use the systems to augment their efforts
  4. Connect with representatives within your state department of corrections, sheriff’s offices, prosecutors, courts, probation, and other groups that may be providing some level of victim advocacy and learn more about their concerns

If this is all overwhelming, try and take it one step at a time. You can also engage a professional consulting firm that can help you organize and systematically assess the problem, then collaborate with you to develop a plan to close the gaps. 

If you have questions about your specific situation, please contact our Justice & Public Safety team. We're here to help. To learn more about other choices in victim notification procedures and systems, stay tuned for our second article in this series, where we explore options for acquiring and implementing a statewide victim notification system.

Article
Risky business: Multiple jurisdictional Victim Notification Systems

Read this if you use, manage, or procure public safety and corrections technology.

Recently we discussed the benefits of developing a strong, succinct Request for Proposal (RFP) that attracts Offender Management Systems (OMS) vendors through a competitive solicitation. Conversely, we explored the advantages and disadvantages of leading a non-competitive solicitation. Industry standards and best practices serve as the common thread between competitive and non-competitive solicitations for standard implementations. So, how does an agency prepare to navigate the nuances and avoid the “gotchas” of a non-standard implementation in the corrections realm?

Functional areas in the corrections industry exist in an ever-evolving state. The ongoing functional area refinements serve to overcome potential gaps between standardizing organizations (e.g., CTA, APPA) and your agency’s operations. For example, CTA does not distinguish incidents from disciplines as distinct functional areas. While merging workflows for incidents and disciplines may align with one agency’s practice, your agency may not always correlate the two functions (e.g., disciplinary action might not always result from an incident). Moreover, your agency may not have a need for every functional area, such as community corrections, depending on the scale of your operation.

Your agency should view the industry standards as a guide rather than the source of truth, which helps you cultivate a less parochial approach driven solely by standards and follow instead a more pragmatic plan, comprised of your unique operations and best practices. CTA and APPA specifications alone will result in comprehensive solicitation. For that reason, agencies can enhance an OMS modernization initiative by enhancing solicitation requirements to include jurisdictional specifications resulting from interviews with end-users and policy research. 

Upcoming OMS webinar

On Thursday, November 5, our consulting team will host a webinar on navigating a solicitation for a new OMS. During the webinar, our team will revisit the benefits of an independent third-party on your solicitation and review industry standards, and will discuss:

  1. Crafting requirements that address common OMS functions, as well as jurisdiction-specific functions (i.e., those that address the unique statutes of the state). Crafting requirements helps your agency to ensure a replacement system addresses core business functions, provides a modern technical infrastructure, and complies with local, state, and federal regulations.
  2. Thriving with a collaborative approach when acquiring and implementing an OMS system, helping to ensure all stakeholders not only participate in the project but also buy into the critical success factors.

If you have questions about your specific situation with OMS implementations, or would like to receive more information about the webinar, please contact one of our public safety consultants.
 

Article
Managing non-standard Offender Management System (OMS) implementations

Read this if you use, manage, or procure public safety and corrections technology. 

In our previous post, we discussed the link between developing a technology RFP with meaning, structure, and clarity to enhance the competitive nature of the solicitation. In this article, we ask: How can your agency synthesize and unify existing business processes with industry standards to attract modern OMS providers? The answer? Your agency crosswalks. 

Industry standards, such as those set by the Corrections Technology Association (CTA) and American Probation and Parole Association (APPA), establish the benchmark for modern operations. However, legacy correction software limitations often blur the one-to-one relationship with industry standards. For that reason, crosswalk tools help agencies map current process into industry-wide standards.

CTA Functional Areas

Corrections Technology Association Functional Areas

Agencies crosswalk in preparation for a corrections technology procurement to help align system requirements with commercial-off-the-shelf (COTS) corrections management systems. In revisiting the topics of clarity, meaning, and structure, the crosswalk helps technology vendors understand your current operations, the tools your currently use to support the operations, and the way in which those operations relate to industry functional areas.

In an iterative fashion, the CTA crosswalk first helps you understand your agency’s technology and operational structure, and then communicates system requirements to correction technology providers in an industry-led framework. The approach helps you transition from your legacy processes to your new operational environment.

Although your agency can engage the market with a meaningful, structured, and clear RFP, prequalification and contract vehicles provide a viable alternative of enhancement to procuring a new offender management system. The following advantages and disadvantages can inform your agency’s decision to use a prequalification vehicle.

Advantages:

  1. Non-competitive procurement can often be accomplished more quickly given the absence of the timeframe usually dedicated to the development of the RFP, posting to potential vendors, and evaluation of proposals.
  2. Reduced uncertainties in terms of what a vendor is able to provide since an open dialog starts immediately.
  3. Competitive procurement (secondary competition) under a contract vehicle is limited to the vendors who proposed and were awarded. Only higher performing vendors are likely to be able to respond, particularly if only certain vendors are selected from the list.
  4. Potentially better pricing as a vendor can eliminate unknowns through open communication, so less risk is priced into the proposal.
  5. A better environment around requested changes, as a vendor that has maintained a certain margin in their pricing may be more amenable to no-cost change orders.

Disadvantages:

  1. The agency loses some negotiating advantage when a vendor knows they are the only ones in the procurement conversation. 
  2. A vendor may have less incentive to “put their best foot forward” and offer higher levels of service and functionality.
  3. Competitive cost may not be obtained because the vendor doesn’t have to worry about beating a competitor.
  4. Secondary competition may take a somewhat similar timeframe because the solicitation, evaluation, and award processes take a similar amount of time to an RFP for larger projects.

The trajectory to develop an RFP for new corrections management software spans assessing existing operations and technology to including mapping current operations into industry standards clarity. At the same time your agency should consider the driving and constraining factors for using a prequalification or contract vehicle.

BerryDunn has experience with cross-walking agencies into industry-leading practices, and we also understand the need for non-standard RFPs that extend beyond CTA and APPA guidelines. Reach out to our public safety consultants if you have questions, or look out for our next blog providing insight on adapting to and overlapping challenges in non-standard corrections technology procurements.

Article
Leveraging industry standards to optimize Offender Management Systems (OMS)