Skip to Main Content

insightsarticles

SaaS: Is it right for you? Making SaaS determinations a snap.

By:
Clark Lathrum is a Senior Consultant in BerryDunn’s Government Consulting Group. As a member of the Local Government Practice Area, his primary areas of focus are systems planning, selection, and implementation services for financial and human resource systems.
Clark Lathrum
04.24.18

While new software applications help you speed up processes and operations, deciding which ones will work best for your organization can quickly evolve into analysis paralysis, as there are so many considerations.

Case in point: Software as a Service (SaaS) model
The benefits of the SaaS model, in which a vendor remotely hosts an organization’s applications, are fairly well known: your organization doesn’t have to shell out for costly hardware, the vendor tackles upgrades, backups, data recovery, and security, and you have more time and money to focus on your business goals.

There are multiple factors to look at when determining whether a SaaS solution is right for you. We’ve compiled a list of the top three SaaS considerations:

1. Infrastructure and capacity
Your organization should consider your own people, processes, and tools when determining whether SaaS makes sense. While an on-site solution may require purchasing new technologies, hiring new staff, and realigning current roles and responsibilities to maintain the system, maintaining a SaaS solution may also require infrastructure updates, such as increased bandwidth to sufficiently connect to the vendor's hosting site.

Needless to say, it’s one thing to maintain a solution; it’s an entirely different thing to keep it secure. An on-site hosting solution requires constant security upgrades, internal audits, and a backup system—all of which takes time and money. A SaaS model requires trust in your vendor to provide security. Make sure your potential vendor uses the latest security measures and standards to keep your critical business data safe and secure.

2. Expense
When you purchase major assets—for example, hardware to host its applications—it incurs capital expenses. Conversely, when you spend money on day-to-day operations (SaaS subscriptions), it incurs operating expenses.

You should weigh the pros and cons of each type of expense when considering a SaaS model. On-site upfront capital expenses for hosting hardware are generally high, and expenses can spike overtime when you update the technology, which can be difficult to predict. And don’t forget about ongoing costs for maintenance, software upgrades, and security patches.

In the SaaS model, you spread out operating costs over time and can predict costs because you are paying via subscription—which generally includes costs for maintenance, software upgrades, and security patches. However, remember you can depreciate capital expenses over time, whereas the deductibility of operating expenses are generally for the year you use them.

3. Vendor viability
Finally, you need to conduct due diligence and vet SaaS vendors before closing the deal. Because SaaS vendors assume the responsibility for vital processes, such as data recovery and security, you need to make sure the potential vendor is financially stable and has a sustainable business model. To help ensure you receive the best possible service, select a vendor considered a leader in its market sector. Prepare a viable exit strategy beforehand so you can migrate your business processes and data easily in case you have any issues with the SaaS provider.

You must read—and understand—the fine print. This is especially important when it comes to the vendor’s policies toward data ownership and future migrations to other service providers, should that become necessary. In other words: Make sure you have final say and control over your data.

Every organization has different aspects of their situation to consider when making a SaaS determination. Want to learn more? It’s a snap! Contact the authors: Clark Lathrum and Matthew Tremblay

Related Services

Consulting

Information Systems

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?

The American Public Health Association annual conference’s thematic focus on preventing violence provided an illustration of the extent of the overwhelming demands on state public health agencies right now. Not only do you need to face the daily challenges of responding to the COVID-19 pandemic, you also need to address ongoing, complex issues like violence prevention.

The sheer breadth of sessions available at APHA shows the broad scope of public health’s reach and the need for multi-level, multi-sector interventions, all with a shrinking public health workforce. The conference’s sessions painted clear pictures of the critical public health issues our country currently faces, but did not showcase many solutions, perhaps leaving state health agency leaders wondering how to tackle these taxing demands coming from every direction with no end in sight.

BerryDunn has a suggestion: practice organizational self-care! It might seem antithetical to focus maxed-out resources on strengthening systems and infrastructure right now, but state public health agencies have little choice. You have to be healthy yourself in order to effectively protect the public’s health. Organizational health is driven by high-functioning systems, from disease surveillance and case investigation to performance management, and quality improvement to data-informed decision-making.  

State health agencies can use COVID-19 funding to support organizational self-care, prioritizing three areas: workforce, technology, and processes. Leveraging this funding to build organizational capacity can increase human resources, replace legacy data systems, and purchase equipment and supplies. 

  1. Funding new positions with COVID sources can create upward paths for existing staff as well as expanding the workforce
  2. Assessing the current functioning of public health data systems identifies and clarifies gaps that can be addressed by adopting new technology platforms, which can also be done with COVID funding.
  3. Examining the processes used for major functions like surveillance or case investigation can eliminate unproductive steps and introduce efficiencies. 

So what now? Where to start? BerryDunn brings expertise in process analysis and redesign, an accreditation readiness tool, and an approach to data systems planning and procurement―all of which are paths forward toward organizational self-care. 

  1. Process analysis and redesign can be applied to data systems or other areas of focus to prioritize incremental changes. Conduct process redesign on a broad or narrow scale to improve efficiency and effectiveness of your projects. 

  2. Accreditation readiness provides a lens to examine state health agency operations against best practices to focus development in areas with the most significant gaps. Evaluate gaps in your agency’s readiness for Public Health Accreditation Board (PHAB) review and track every piece of documentation needed to meet PHAB standards.
  3. Data system planning and procurement assistance incorporates process analysis to assess your current system functioning, define your desired future state, and address the gaps, and then find, source, and implement faster, more effective systems. 

Pursuing any of these three paths allows state health agency leaders to engage in organizational self-care in a realistic, productive manner so that the agency can meet the seemingly unceasing demands for public health action now and into the future.

Article
Three paths to organizational self-care for state public health agency survival

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

Read this if your agency is planning to procure a services vendor. 

Every published request for services aims to acquire the highest-quality services for the best value. Requests may be as simple as an email to a qualified vendor list or as formal as a request for proposal (RFP) published on a state’s procurement website. However big or small the request, upon receiving it, we, or a potential vendor, triages it using the following primary criteria:

  1. Scope of services―Are these services or solutions we can provide? If we can’t provide the entire scope of services, do we have partners that can?
    As a potential responding vendor, we review the scope of services to see if it is clearly defined and provides enough detail to help us make a decision to pursue the proposal. Part of this review is to check if there are specific requests for products or solutions, and if the requests are for products or solutions that we provide or that we can easily procure to support the scope of work. 
  2. Qualifications―What are the requirements and can we meet them?
    We verify that we can supply proofs of concept to validate experience and qualification requirements. We check to see if the requirements and required services/solutions are clearly defined and we confirm that we have the proof of experience to show the client. Strict or inflexible requirements may mean a new vendor is unable to propose new and innovative services and may not be the right fit.
  3. Value―Is this a service request that we can add value to? Will it provide fair compensation?
    We look to see if we can perform the services or provide the solution at a rate that meets the client’s budget. Sometimes, depending upon the scope of services, we can provide services at a rate typically lower than our competitors. Or, conversely, though we can perform the scope of services, the software/hardware we would have to purchase might make our cost lower in value to the client than a well-positioned competitor.

An answer of “no” on any of the above questions typically means that we will pass on responding to the opportunity. 

The above questions are primary considerations. There are other factors when we consider an opportunity, such as where the work is located in comparison to our available resources and if there is an incumbent vendor with a solid and successful history. We will consider these and other factors in our next article. If you would like to learn more about our process, or have specific questions, please contact the Medicaid Consulting team.
 

Article
What vendors want: Vendor decision process in answering requests for services

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)