Skip to Main Content

insightsarticles

The pros and cons of
pre-contract
gap analyses

05.21.18

When an organization wants to select and implement a new software solution, the following process typically occurs:

  1. The organization compiles a list of requirements for essential and non-essential (but helpful) functions.
  2. The organization incorporates the requirements into an RFP to solicit solutions from vendors.
  3. The organization selects finalist vendors to provide presentations and demonstrations.
  4. The organization selects one preferred vendor based on various qualifications, including how well the vendor’s solution meets the requirements listed in the RFP. A contract between the organization and vendor is executed for delivery of the solution.
  5. The preferred vendor conducts a gap analysis to see if there are gaps between the requirements and its solution—and discloses those gaps.
  6. The preferred vendor resolves the gaps, which often results in change orders, cost adjustments, and delays.

Sound painful? It can be. Step #5—the gap analysis, and its post-contract timing—is the main culprit. However, without it, an organization will be unaware of solution shortcomings, which can lead to countless problems down the road. So what’s an organization to do?

A Possible Solution
One suggestion: Don’t wait until you choose the preferred vendor for a gap analysis. Have finalist vendors conduct pre-contract gap analyses for you.

You read that right. Pay each finalist vendor to visit your organization for a week to learn about your current and desired software needs. Then pay them to develop and present a report, based on both the RFP and on-site discussions, which outlines how their solution will meet your current and desired software needs—as well as how they will meet any gaps. Among other things, a pre-contract gap analysis will help finalist vendors determine:

  • Whether programming changes are necessary to meet requirements
  • Whether functions can be provided through configuration setup, changes in database tables, or some other non-customized solution
  • What workarounds will be necessary
  • What functionalities they can't, or won't, provide

Select a preferred vendor based on both their initial proposal and solution report.
Of course, to save time and money, you could select only one finalist vendor for the pre-contract gap analysis. But having multiple finalist vendors creates a competitive environment that can benefit your organization, and can prevent your organization from having to go back to other vendors if you’re dissatisfied with the single finalist vendor’s proposal and solution report, or if contract negotiations prove unsuccessful.

Pros
You can set realistic expectations. By having finalist vendors conduct gap analyses during the selection process, they will gain a better understanding of your organization, and both your essential and nonessential software needs. In turn, your organization gets a better understanding of the functionality and limitations of the proposed solutions. This allows your organization to pinpoint costs for system essentials, including costs to address identified gaps. Your organization can also explore the benefits and costs of optional functions. Knowing the price breakdowns ahead of time will allow your organization to adjust its system requirements list.

You can reduce the need for, or pressure to accept, scope changes and change orders. Adding to, or deleting from, the scope of work after solution implementation is underway can create project delays and frustration. Nailing down gaps—and the preferred vendor’s solutions to meet those gaps—on the front end increases efficiency, helps to ensure best use of project resources, and minimizes unnecessary work or rework. It may also save you expense later on in the process.

Cons
You will incur additional up-front costs. Obviously, your organization will have to pay to bring finalist vendors on-site so they can learn the intricacies of your business and technical environment, and demonstrate their proposed solutions. Expenses will include vendors’ time, costs for transportation, lodging, and meals. These costs will need to be less than those typically incurred in the usual approach, or else any advantage to the modified gap analysis is minimized.

You might encounter resistance. Some finalist vendors might not be willing to invest the time and effort required to travel and conduct gap analyses for a system they may not be selected to implement. They will be more interested in the larger paycheck. Likewise, stakeholders in your own organization might feel that the required costs and time investments are impractical or unrealistic. Remind staff of the upfront investment and take note of which vendors are willing to do the same.

Related Services

State governments regularly negotiate contracts with vendors. Unfortunately, these negotiations are often prolonged, which can have major downstream effects on projects, procurements, and implementations—including skewed timelines, delayed milestones, and increased costs. Here are five suggestions for shortening contract negotiations. 

  1. Limit project scope. Leaner project scope equals shorter contract negotiations. Conversely, the sheer number of requirements, terms, and conditions for larger projects naturally inflate negotiations. Limiting scope means being conservative in what you are looking to achieve. Planning a core systems modernization? They can cost tens of millions of dollars. Limit scope (and cost) to just certain modules. If, for example, you have an ERP modernization, limit projects and procurements to key modules and milestones. 
  2. Use project management techniques. Treat the negotiation like a small project. For example, compile a list of tasks and deadlines, as well as names for necessary signatures. Develop a project plan and hold weekly check-ins to keep things on track. Assign someone in your organization as a single point of contact to help shepherd the contract through the process. 
  3. Make the vendor’s proposal part of the contract?verbatim. Some states still require copying the proposal response into a contract document, and that often requires modification of proposal language, which slows things down. Attach the solution proposal to the contract cover pages(s) so that the proposal is there, word for word. 
  4. Have vendors define deliverables, except for the minimum deliverables you must have. Vendors should know how to deliver their product and services and should include items they expect to be paid for, such as completion of a development cycle, software licenses, and a gap analysis report. Rather than define what deliverables you need, let the vendors define them, except for any mandatory ones, such as a training or testing plan. Ask for interim or draft versions of training or testing plans as part of proposal submission. 
  5. Tell vendors ahead of time what the payment constraints are. As a state government, you are bound by budget cycles and authority to spend. You also want working product tied to payment. With both factors in mind, tell vendors up front how much of the contract can be paid in a certain year and how much you are willing to tie to what deliverables. Don’t want to pay more than, say 40% of the project cost for non-software deliverables? Say so. Vendors can then plan their paydays and deliverable sequence accordingly. 

    You can also save time and effort by not negotiating at all. States often assume there will be, or allow for, negotiation periods. Yet states can make clear that no negotiation will occur after contract award—or limit what can be negotiated to a small, finite number of items. To prepare for this approach, states should gleam vendor stipulations ahead of time, and perhaps even score vendors on the number or type of stipulations. Use a pre-award proposal clarification period to clarify any terms or demands that are unfavorable to the state and consider ranking or evaluating proposals on the number of objections to terms/conditions raised. 

States should feel empowered to shorten (or, when appropriate, even eliminate) contract negotiations. After all, state time is state money.

Article
Meet deadlines and cut costs: Five steps to faster contract negotiations

The day-to-day work of providing government services involves collecting, using, and storing large amounts of data. The data that government agencies accumulate is a critical asset — it holds answers about which programs perform best, which interventions are most effective, and how to improve service delivery. Data can also be a liability when it falls into the wrong hands or is misused, even unintentionally. Data governance is a great place to start gaining control of your data.

Establishing data governance can be intimidating. Between resource constraints, multiple and different data policies within large organizations, cultural reluctance to change, and lack of knowledge, it can be difficult to even know where to begin. Start with the fundamentals: understand what data governance is, and why it is so important.

These initial guidelines will help you validate the need for data governance at your organization, and recognize the correlation between reaching your strategic goals and governing data.

So, what is it?
Data governance is an ongoing, evolutionary process driven by business leaders where they establish principles, policies, business rules, and metrics for data sharing. They manage priorities and resources such as data stewards and technologists to acquire, harmonize, summarize, and produce data-rich analyses of data assets required to meet agency goals.

At a high-level, data governance has two main components: 

Data Governance Components

Why is data governance so important, and why NOW?

  • Data ownership is a responsibility. Properly governing data is not only important for organizational strategy, it is also important to produce high-quality client outcomes and levels of satisfaction. When you establish proper data policies and procedures, clients receive a better level of service. 
  • The amount of data collected is increasing. Many organizations collect an abundance of data, with no real vision of how to use it. A framework of data governance assists with developing a strategy to take advantage of data and use it effectively. 
  • The demand for data is growing. Organizations, especially in the public sector, are required to analyze and submit data for reporting to funders and oversight bodies. Without data governance, these reports can be inaccurate, contain gaps, or be manipulated improperly to produce false reports. 
  • The concern for security surrounding data is increasing. Mandates across both public and private sectors constantly evolve, because the more technical our world becomes, the more secure our data needs to be. If an organization does not implement foundational data security measures across all jurisdictions, it can become easy to fall behind the curve, and out of compliance. 
  • Organizations miss many opportunities to leverage data more efficiently. Organizations report being unable to provide a high level of confidence to produce accurate data reports, resulting in inefficient resource distribution. A standardized framework for governing data helps produce higher levels of data quality and integrity, and improves report accuracy.

How can your organization start the process?
The first step in a data governance initiative is to assess your organization’s data environment and maturity level. Start by analyzing your organization’s data policies, usage, documentation, and management processes to gain a true understanding of the current data landscape and management maturity level. CMMI’s Data Management Maturity Model (DMMM) and the Data Management Association’s Data Management Body of Knowledge (DMBOK) are great reference resources to assist with understanding the role and definition of data governance.

The time for data governance is now.
BerryDunn’s Government Consulting Group works with state agencies to develop data governance initiatives as well as specific processes and policies to help states take control of data, increase confidence in its quality, and reach strategic goals. 

Article
Data governance: Gain control

In July 2016, we wrote about how the booming microbrewery scene in Maine is shaking up the three-tier system of alcohol distribution, which dates back to the 1930s.

A month later, three Texas microbreweries — Live Oak Brewing Company, Peticolas Brewing, and Revolver Brewing — argued against the three-tier system in district court, seeking to circumvent parts of the system and allow craft breweries in Texas to sell their distribution and territorial rights. The State countered that assertion, and claimed that the three-tier system was necessary because it allowed the Texas Alcoholic Beverage Commission to easily monitor the distribution of products, and have a greater sense of the inventory of retailers, restaurants, and bars.

A few weeks following the initial court appearance, the presiding judge ruled in favor of the three Texas microbreweries, granting them the right to distribute their own product — and, as a result, allowing these and other Texas microbreweries to maximize their profits. This ruling opined that the three-tier system unfairly benefits distributors at the expense of microbreweries.

One could argue that microbreweries wouldn’t exist in such force today if not for the three-tier system, which allows for competition and the creation of new producers. On the other hand, the three-tier system imposes burdens on microbreweries, as the Texas suit demonstrates. Yes, the number of microbreweries is growing—but because microbreweries are forced to sell directly to a shrinking number of distributors, the former tend to suffer slow revenue growth, while the latter tend to enjoy steady or increased sales.

The co-existence of microbreweries and the three-tier system in the United States merits observation. It will be equally fascinating to see if the methods for producing and distributing alcohol will drastically change. Is it time for a modified regulatory model that will better accommodate the growing craft beer landscape? Or do the tried-and-true policies dating back to before World War II still serve their original intent? It’s too soon to know, but we’ll see what ferments in the months to come.

Editor's note: this article was co-written with Amanda Findlay. 

Article
Untapped potential: Microbreweries use legal scrutiny to erode the three-tier system

There is plenty of media coverage of Maine’s, and specifically Portland’s, burgeoning microbrew scene. It’s good economic development and complements the already established “foodie” scene Portland is renowned for. What’s more, microbrewers are increasingly avoiding the middle man, and offering tastings directly to consumers, onsite at their breweries. All who sell beer by the glass in Maine need a license, just as with other states. But the licensing cost for breweries and their tasting rooms is much less expensive than it is for bars and taverns, earning a charge of unfairness from those entities that have to go through a more stringent and expensive process of getting a liquor license. Read here for more detail. As you read, you may enjoy the irony of Maine being the first state to prohibit the sale of alcohol in 1851.

There is another facet to the boom in tasting room sales that is higher up the legal food chain than licensing fees: the three-tier system. First, a quick primer: the three-tier system was instituted at the time of the repeal of Prohibition (December 1933) to remove the problem of a “tied house”. Prior to Prohibition, a tied house was not an uncommon occurrence, where one regional entity had entire control of brewing or distilling, distribution, and retail sale of intoxicating beverages. This resulted in, it was argued, excessive alcoholic beverage sales by larger manufacturers and thus excessive consumption of alcohol. Following Prohibition, states instituted laws establishing a three-tier system whereby manufacturers, distributors and retailers are required to have separate licenses. This separation was designed to prevent dominance of one tier over the others. Gone are the days of saloons that were associated with drinking excess and loyalty to only one regionally dominant brand.

The three-tier system, by many opinions, works well. The National Alcoholic Beverage Control Association (NABCA) has published a paper on the virtues of the system. The Supreme Court, in the landmark case Granholm vs. Heald, declared that the three-tier system was “unquestionably legitimate”[1]. The Alabama Brewers Guild supports the three-tier system, but feels exceptions should be made, notably direct sales (presumably to include both on-premise and off-premise sales, the latter occurring when a consumer takes beer to go, just like a grocery or package store).

In Portland’s microbreweries (and distilleries, too), direct sales are over the counter, just like a bar. Is it reasonable to make exceptions to the three-tier system and let manufacturers become retailers at a certain level? Probably. A brewery in Portland making under 50,000 gallons of beer a year is no corporate monolith. Neither are craft distillers in North Carolina, where a state senate bill was under consideration recently to allow purchase of one bottle of spirits per year from distilleries[2]. But it does blur the lines of the three-tier system and its original reason for being. In addition to making those in the industry who pay for a full license upset, the spirit of the three-tier system may be challenged as breweries grow larger. The situation is certainly worth keeping an eye on as the microbrewery revolution continues.

[1] http://repository.law.umich.edu/cgi/viewcontent.cgi?article=1127&context=mlr&sei-redir=1&referer=http%3A%2F%2Fwww.bing.com%2Fsearch%3Fq%3Dargument%2Bagainst%2Bthe%2Bthree%2Btier%2Bsystem%26src%3DIE-SearchBox%26FORM%3DIENTTR%26conversationid%3D#search=%22argument%20against%20three%20tier%20system%22 , page 822.
[2] http://www.wral.com/distilleries-could-sell-more-bottles-direct-to-tourists/15760834/

Article
Microbreweries and the debate on the three-tier system

Read this if you are a director or manager at a Health and Human Services agency in charge of modernizing your state's Health and Human Services systems.

With stream-lined applications, online portals, text updates, and one-stop offices serving programs like Medicaid, SNAP, and Child Welfare, states are rapidly adopting integrated systems serving multiple programs. As state leaders collaborate on system design and functionality to meet federal and state requirements, it is equally important to create a human-centered design built for the whole family.

We know families are comprised of a variety of people with various levels of need, and blended families ranging from grandparents to infants may qualify for a variety of programs. We may connect with families who are on Medicaid, aged and disabled or SNAP, but also have cases within child support or with child welfare. 

If your state is considering updating a current system, or procuring for an innovative design, there are key strategies and concepts to consider when creating a fully integrated system for our most vulnerable populations. Below are a few advantages for building a human-centric system:

  • The sharing of demographic, contact, and financial information reduces duplication and improves communication between state entities and families seeking services
  • Improvement of business services and expedited eligibility determinations, as a human-centric model gathers information upfront to reduce a stream of verification requests
  • The cost of ownership decreases when multiple programs share design costs
  • Client portals and services align as a family-focused model

Collaboration and integrated design

How many states use a separate application for Medicaid and SNAP? More specifically, is the application process time consuming? Is the same information requested over and over for each program? 

How efficient (and wonderful) would it be for clients to complete task-based questions, and then each program could review the information separately for case-based eligibility? How can you design an integrated system that aligns with business and federal rules, and state policy?

Once your state has decided a human-centered design would be most beneficial, you can narrow your focus—whether you are already in the RFP process, or within requirements sessions. You can stop extraneous efforts, and change your perspective by asking the question: How can we build this for the entire family? The first step is to see beyond your specific program requirements and consider the families each program serves. 

Integrated design is usually most successful when leaders and subject matter experts from multiple programs can collaborate. If all personnel are engaged in an overarching vision of building a system for the family, the integrated design can be fundamentally successful, and transforming for your entire work environment across agencies and departments.

Begin with combining leadership and subject matter experts from each geographic region. Families in the far corners of our states may have unique needs or challenges only experts from those areas know about. These collaborative sessions provide streamlined communications and ideas, and empower staff to become actively involved and invested in an integrated system design. 

Next, delve into the core information required from each family member and utilize a checklist to determine if the information meets the requirements of the individual programs. Finally, decide which specific data can streamline across programs for benefit determinations. For example, name, address, age, employment, income, disability status, and family composition are standard pieces of information. However, two or more programs may also require documentation on housing, motor vehicle, or retirement accounts.

Maintaining your focus on the families you serve

When designing an integrated system, it is easy to lose focus on the family and return to program-specific requirements. Your leaders and subject matter experts know what their individual programs need, which can lead to debates over final decisions regarding design. It is perfectly normal to develop tunnel vision regarding our programs because we want to meet regulations and maintain funding.

Below are recommendations for maintaining your focus on building for the family, which can start as soon as the RFP. 

  • Emphasize RFP team accountability
    • Everyone should share an array of family household examples who benefit from the various programs (Medicaid, SNAP, TANF, etc.), to help determine how to deliver a full spectrum of services. 
    • Challenge each program with writing their program-specific sections of the RFP and have one person combine the responses for a review session.
  • If the integrated system design is in the requirements phase, brainstorm scenarios, like the benefit example provided in recommendation number one. When information is required by one program, but not another, can the team collaborate and include the information knowing it could benefit an entire family?
  • When considering required tasks, and special requests, always ask: Will this request/change/enhancement help a family, or help staff assist a family?
  • Consider a universal approach to case management. Can staff be cross trained to support multiple programs to reduce transferring clients to additional staff?

We understand adopting a human-centered design can be a challenging approach, but there are options and approaches to help you through the process. Just continue to ask yourself, when it comes to an integrated approach, are you building the system for the program or for the family?

Article
Integrated design and development for state agencies: Building for the family

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 your agency is planning to procure a services vendor.

In our previous article, we looked at three primary areas we, or a potential vendor, consider when responding to a request for services. In this follow-up, we look at additional factors that influence the decision-making process on whether a potential vendor decides to respond to a request for services.

  • Relationship with this state/entity―Is this a state or client that we have worked with before? Do we understand their business and their needs?

    A continuing relationship allows us to understand the client’s culture and enables us to perform effectively and efficiently. By establishing a good relationship, we can assure the client that we can perform the services as outlined and at a fair cost.
  • Terms and conditions, performance bonds, or service level agreements―Are any of these items unacceptable? If there are concerns, can we request exceptions or negotiate with the state?

    When we review a request for services our legal and executive teams assess the risk of agreeing to the state’s terms and compare them against our existing contract language. States might consider requesting vendors provide exceptions to terms and conditions in their bid response to open the door for negotiations. Not allowing exceptions can result in vendors assuming that all terms are non-negotiable and may limit the amount of vendor bid responses received or increase the cost of the proposal.

    The inclusion of well-defined service level agreements (SLAs) in requests for proposals (RFPs) can be an effective way to manage resulting contracts. However, SLAs with undefined or punitive performance standards, compliance calculations, and remedies can also cause a vendor to consider whether to submit a bid response.

    RFPs for states that require performance bonds may result in significantly fewer proposals submitted, as the cost of a performance bond may make the total cost of the project too high to be successfully completed. If not required by law that vendors obtain performance bonds, states may want to explore other effective contractual protections that are more impactful than performance bonds, such as SLAs, warranties, and acceptance criteria.
  • Mandatory requirements―Are we able to meet the mandatory requirements? Does the cost of meeting these requirements keep us in a competitive range?

    Understanding the dichotomy between mandatory requirements and terms and conditions can be challenging, because in essence, mandatory requirements are non-negotiable terms and conditions. A state may consider organizing mandatory requirements into categories (e.g., system requirements, project requirements, state and federal regulations). This can help potential vendors determine whether all of the mandatory requirements are truly non-negotiable. Typically, vendors are prepared to meet all regulatory requirements, but not necessarily all project requirements.
  • Onsite/offsite requirements―Can we meet the onsite/offsite requirements? Do we already have nearby resources available? Are any location requirements negotiable?

    Onsite/offsite requirements have a direct impact on the project cost. Factors include accessibility of the onsite location, frequency of required onsite participation, and what positions/roles are required to be onsite or local. These requirements can make the resource pool much smaller when RFPs require staff to be located in the state office or require full-time onsite presence. And as a result, we may decide not to respond to the RFP.

    If the state specifies an onsite presence for general positions (e.g., project managers and business analysts), but is more flexible on onsite requirements for technical niche roles, the state may receive more responses to their request for services and/or more qualified consultants.
  • Due date of the proposal―Do we have the available proposal staff and subject matter experts to complete a quality proposal in the time given?

    We consider several factors when looking at the due date, including scope, the amount of work necessary to complete a quality response, and the proposal’s due date. A proposal with a very short due date that requires significant work presents a challenge and may result in less quality responses received.
  • Vendor available staffing―Do we have qualified staff available for this project? Do we need to work with subcontractors to get a complete team?

    We evaluate when the work is scheduled to begin to ensure we have the ability to provide qualified staff and obtain agreements with subcontractors. Overly strict qualifications that narrow the pool of qualified staff can affect whether we are able to respond. A state might consider whether key staff really needs a specific certification or skill or, instead, the proven ability to do the required work.

    For example, technical staff may not have worked on this particular type of project, but on a similar one with easily transferable skills. We have several long-term relationships with our subcontractors and find they can be an integral part of the services we propose. If carefully managed and vetted, we feel subcontractors can be an added value for the states.
  • Required certifications (e.g., Project Management Professional® (PMP®), Cybersecurity and Infrastructure Security Agency (CISA) certification)―Does our staff have the required certifications that are needed to complete this project?

    Many projects requests require specific certifications. On a small project, maybe other certifications can help ensure that we have the skills required for a successful project. Smaller vendors, particularly, might not have PMP®-certified staff and so may be prohibited from proposing on a project that they could perform with high quality.
  • Project timeline―Is the timeline to complete the project reasonable and is our staff available during the timeframe needed for each position for the length of the project?

    A realistic and reasonable timeline is critical for the success of a project. This is a factor we consider as we identify any clear or potential risks. A qualified vendor will not provide a proposal response to an unrealistic project timeline, without requesting either to negotiate the contract or requesting a change order later in the project. If the timeline is unrealistic, the state also runs the risk that the vendor will create many change requests, leading to a higher cost.

Other things we consider when responding to a request for services include: is there a reasonable published budget, what are the minority/women-owned business (M/WBE) requirements, and are these new services that we are interested in and do they fit within our company's overall business objectives?

Every vendor may have their own checklist and/or process that they go through before making a decision to propose on new services. We are aware that states and their agencies want a wide-variety of high-quality responses from which to choose. Understanding the key areas that a proposer evaluates may help states provide requirements that lead to more high-quality and better value proposals. If you would like to learn more about our process, or have specific questions, please contact the Medicaid Consulting team.

Article
What vendors want: Other factors that influence vendors when considering responding to a request for services