Collaborating with MES to leverage funding for public health innovation

We’ve all heard stories about organizations spending thousands on software projects, such as Enterprise Resource Planning (ERP), Electronic Health Record (EHR), or Student Information Systems (SIS) that take longer than expected to implement and exceed original budgets. One of the reasons this occurs is that organizations often don’t realize that purchasing a large, Commercial Off-The-Shelf (COTS) enterprise system is a significant undertaking. If the needs aren’t sufficiently defined, there can be many roadblocks, including implementation delays, increased cost, scope creep, and ultimately, unsatisfactory results (delayed or unfinished projects and cost overruns).

These systems are complex, and implementation efforts impact both internal and external stakeholders. Procurement often requires participation from different departments, each with unique goals and perspectives. Ignore these perspectives at your own peril. Here are key questions to consider for making the best buying decision:

1. Should we purchase software that similar organizations have purchased?
   As vendor consolidation has diminished the number of distinct COTS systems available, this question is increasingly common. Following this approach is similar to deciding to buy the car that your neighbor did, because they seem satisfied. How can you be sure that the systems purchased by similar organizations will meet your needs, particularly if your needs are undefined? One way to identify your organization’s needs—and to avoid costly mistakes down the road—is to identify requirements during the procurement process.

2. What are the functional and technical requirements of the system?Requirements are details that help describe a software system. There are two types of requirements and you need to understand and review both:
   
   Functional requirements. These define specific functions of a system to meet day-to-day needs of an organization or department. They describe the necessary system capabilities that allow users to perform their jobs. For example, “The vendor file must provide a minimum of four (4) remit-to addresses.” Functional requirements may also define the mandated state or federal capabilities required of a system, such as the ability to produce W-2 or 1099 forms.
   
   Technical requirements. These requirements identify criteria used to judge the operation of a system, rather than specific behaviors. They can be requirements that define what database the system must support. For example, “The system must support use of the client preferred database.” They may also describe security capabilities of the system, the ability to import or export data, or the ease of use and overall end-user interface.

3. Who should help define and document requirements for the new enterprise system?
   
   When it comes to documenting and revising requirements, work with your IT staff; incorporating technology standards into a set of requirements is a best practice. Yet it is also necessary to seek input from non-IT individuals, or business process owners from multiple departments, those who will use and/or be affected by the new software system.
   
   Help these individuals or groups understand the capabilities of modern software systems by having them visit the sites of other organizations, or attend software industry conferences. You should also have them document the current system’s deficiencies. As for those in your organization who want to keep the current system, encourage their buy-in by asking them to highlight the system’s most valuable capabilities. Perspectives from both new system supporters and those not so eager to change will help build the best system.
    
4. When do you revise enterprise system requirements? 
   It is always important to begin the software procurement process with a documented set of requirements; you need them to identify the best solution. The same goes for the implementation process where vendors use the requirements to guide the setup and configuration of the new system. But be prepared to revise and enhance requirements when a vendor solution offers an improved capability or a better method to achieve the results. The best way to approach it is to plan to revise requirements constantly. This enables the software to better meet current needs, and often delivers enhanced capabilities.

Be sure to document system requirements for an efficient process

There may be thousands of requirements for an enterprise system. To make the procurement process as efficient as possible, continually define and refine requirements. While this takes time and resources, there are clear benefits:

• Having requirements defined in an RFP helps vendors match the capabilities of their software systems to your organization’s needs and functional expectations. Without requirements, the software procurement and selection process has little framework, and from a vendor perspective becomes a subjective process — making it hard to get consistent information from all vendors.
• Requirements help determine specific tasks and activities to address during the implementation process. While applications can’t always meet 100% of the requested functionalities, it’s important to emphasize the requirements that are most important to users, to help find the system that best meets the needs of your organization.
• Requirements prove valuable even after implementation has begun, as they can help you test your system to make sure the software meets your organization’s particular needs before production use of the new system.

Our experienced consultants have led many software procurement projects and have firsthand knowledge about the challenges and opportunities associated with purchasing and implementing systems large and small. BerryDunn maintains an active database of requirements that we continually enhance, based on work performed for various clients and on technological advancements in the marketplace. Please contact us and we can help you define your requirements for large software system purchases.

Read this if your organization is planning on upgrading or replacing an enterprise technology system.

It can be challenging and stressful to plan for technology initiatives, especially those that involve and impact every area of your organization. Common initiatives include software upgrades or replacements for:

• Financial management, such as Enterprise Resource Planning (ERP) systems
• Asset management systems
• Electronic health records (EHR) systems
• Permitting and inspections systems

Though the number of considerations when planning enterprise technology projects can be daunting, the greatest mistake you can make is not planning at all. By addressing just a few key areas, you can avoid some of the most common pitfalls, such as exceeding budget and schedule targets, experiencing scope creep, and losing buy-in among stakeholders. Here are some tips to help you navigate your next project:

Identify your IT project roles and resources

While most organizations understand the importance of identifying project stakeholder groups, it is often an afterthought. Defining these roles at the outset of your project helps you accurately estimate the work effort.

Your stakeholder groups may include:

• An executive sponsor
• A steering committee
• A project manager
• Functional leads
• A technical team

Once you’ve established the necessary roles, you can begin reviewing your organization’s resources to determine the people who will be available to fill them. Planning for resource availability will help you avoid delays, minimize impact to regular business processes, and reduce the likelihood of burnout. But this plan won’t remain static—you can expect to make updates throughout the project.

Establish clear goals and objectives to keep your technology project on track

It’s important that an enterprise technology project has established goals and objectives statements. These statements will help inform decision-making, provide benchmarks for progress, and measure your project’s success. They can then be referenced when key stakeholders have differing perspectives on the direction to take with a pending decision. For example, if the objective of your project is to reduce paper-based processes, you may plan for additional computer workstations and focus technical resources on provisioning them. You’ll also be able to measure your success in the reduction of paper-based tasks.

Estimate your IT project budget accurately

Project funding is hardly ever overlooked, but can be complex with project budgets that are either underestimated or estimated without sufficient rationale to withstand approval processes and subsequent budget analysis. You may find that breaking down estimates to a lower level of detail helps address these challenges. Most technology projects incur costs in three key areas:

• Vendor cost: This could include both one-time software implementation costs as well as recurring costs for maintenance and ongoing support.
• Infrastructure cost: Consider the cost of any investments needed to support your project, such as data center hardware, networking components, or computing devices.
• Supplemental resource cost: Don’t forget to include the cost of any additional resources needed for their specialized knowledge or to simply backfill project staff. This could include contracted resources or the additional cost of existing resources (i.e., overtime).

A good technology project budget also includes a contingency amount. This amount will depend on your organization’s standards, the relative level of confidence in your estimates, and the relative risk.

Anticipate the need for change management

Depending on the project, staff in many areas of your organization will be impacted by some level of change during a technology implementation. External stakeholders, such as vendors and the public, may also be affected. You can effectively manage this change by proactively identifying areas of likely change resistance and creating strategies to address them.

In any technology implementation, you will encounter change resistance you did not predict. Having strategies in place will help you react quickly and effectively. Some proven change management strategies include communicating throughout your project, involving stakeholders to get their buy-in, and helping ensure management has the right amount of information to share with their employees.

Maintain focus and stay flexible as you manage your IT project

Even with the most thought-out planning, unforeseen events and external factors may impact your technology project. Establish mechanisms to regularly and proactively monitor project status so that you can address material risks and issues before their impact to the project grows. Reacting to these items as they arise requires key project stakeholders to be flexible. Key stakeholders must recognize that new information does not necessarily mean previous decisions were made in error, and that it is better to adapt than to stick to the initial direction.

Whether you’re implementing an ERP, an EHR, or enterprise human resources or asset management systems, any enterprise technology project is a massive undertaking, involving significant investment and a coordinated effort with individuals across multiple areas of an organization. Common mistakes can be costly, but having a structured approach to your planning can help avoid pitfalls. Our experienced, objective advisors have worked with public and private organizations across the country to oversee large enterprise projects from inception to successful completion.

Contact our software consulting team with any questions.

Editor’s note: If you are a higher education CFO, CIO, CTO or other C-suite leader, this blog is for you.

The Gramm-Leach-Bliley Act (GLBA) has been in the news recently as the Federal Trade Commission (FTC) has agreed to extend a deadline for public comment regarding proposed changes to the Safeguards Rule. Here’s what you need to know.

GLBA, also known as the Financial Modernization Act, is a 1999 federal law providing rules to financial institutions for protecting consumer information. Colleges and universities fall under this act because they conduct financial activities (e.g., administration of financial aid, loans, and other financial services).

Under the Safeguards Rule financial Institutions must develop, implement, and maintain a comprehensive information security program that consists of safeguards to handle customer information.

Proposed changes

The FTC is proposing five modifications to the Safeguards Rule. The new act will:

• Provide more detailed guidance to impacted institutions regarding how to develop and implement specific aspects of an overall information security program.
• Improve the accountability of an institution’s information security programs.
• Exempt small business from certain requirements.
• Expand the definition of “financial institutions” to include entities engaged in activities that the Federal Reserve Board determines to be incidental to financial activities.
• Propose to include the definition of “financial institutions” and related examples in the rule itself rather than cross-reference them from a related FTC rule (Privacy of Consumer Financial Information Rule).

Potential impacts for your institution

The Federal Register, Volume 84, Number 65, published the notice of proposed changes that once approved by the FTC would add more prescriptive rules that could have significant impact on your institution. For example, these rules would require institutions to:

1. Expand existing security programs with additional resources.
2. Produce additional documentation.
3. Create and implement additional policies and procedures.
4. Offer various forms of training and education for security personnel.

The proposed rules could require institutions to increase their commitment in time and staffing, and may create hardships for institutions with limited or challenging resources.

Prepare now

While these changes are not final and the FTC is requesting public comment, here are some things you can do to prepare for these potential changes:

• Evaluate whether your institution is compliant to the current Safeguards Rule.
• Identify gaps between current status and proposed changes.
• Perform a risk assessment.
• Ensure there is an employee designated to lead the information security program.
• Monitor the FTC site for final Safeguard Rules updates.

In the meantime, reach out to us if you would like to discuss the impact GLBA will have on your institution or if you would like assistance with any of the recommendations above. You can view a comprehensive list of potential changes here.

Source: Federal Trade Commission. Safeguards Rule. Federal Register, Vol. 84, No. 65. FTC.gov. April 4, 2019. https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/safeguards-rule

Read this if you are a State Medicaid Director, State Medicaid Chief Information Officer, State Medicaid Project Manager, or State Procurement Officer—or if you work on a State Medicaid Enterprise System (MES) certification effort.

Measuring performance of Medicaid Enterprise Systems (MES) is emerging as the next logical step in moving Medicaid programs toward modularity. As CMS continues to refine and implement outcomes-based modular certification, it is critical that states adapt to this next step in order to continue to meet CMS funding requirements.

This measurement, in terms of program outcomes, presents a unique set of challenges, many of which a state may not have considered before. A significant challenge is determining how and where to begin measuring program outcomes―to meet it, states can leverage a trusted, independent partner as they undertake an outcomes-based effort.

Outcomes-based planning can be thought of as a three-step process. First, and perhaps most fundamental, is to define outcomes. Second, you need to determine what measurements will demonstrate progress toward achieving those outcomes. And the final step is to create reporting measurements and their frequency. Your independent partner can help you answer these critical questions and meet CMS requirements efficiently by objectively guiding you toward realizing your goals.

1. Defining Outcomes
   When defining an outcome, it is important to understand what it is and what it isn’t. An outcome is a benefit or added value to the Medicaid program. It is not an output, which is a new or enhanced function of a new MES module. An output is the product that supports the outcome. For example, the functionality of a new Program Integrity (PI) module represents an output. The outcome of the new PI module could be that the Medicaid program continuously improves based on data available because of the new PI module. Some outcomes may be intuitive or obvious. Others may not be as easy to articulate. Regardless, you need to direct the focus of your state and solution vendor teams on the outcome to uncover what the underlying goal of your Medicaid program is.
    
2. Determining Measurements
   The second step is to measure progress. Well-defined Key Performance Indicators (KPIs) will accurately capture progress toward these newly defined outcomes. Your independent partner can play a key role by posing questions to help ensure the measurements you consider align with CMS’ goals and objectives. Additionally, they can validate the quality of the data to ensure accuracy of all measurements, again helping to meet CMS requirements.
    
3. Reporting Measurements
   Finally, your state must decide how―and how often―to report on outcomes-based measurements. Your independent partner can collaborate with both your state and CMS by facilitating conversations to determine how you should report, based on a Medicaid program’s nuances and CMS’ goals. This can help ensure the measurements (and support information) you present to CMS are useful and reliable, giving you the best chance for attaining modular certification.

Are you considering an outcomes-based CMS modular certification, or do you have questions about how to best leverage an independent partner to succeed with your outcomes-based modular certification effort? BerryDunn’s extensive experience as an independent IV&V and Project Management Office (PMO) partner includes the first pilot outcomes-based certification effort with CMS. Please visit our IV&V and certification experts at our booth at MESC 2019 or contact our team now.

Focus on the people: How higher ed institutions can successfully make an ERP system change

The enterprise resource planning (ERP) system is the heart of an institution’s business, maintaining all aspects of day-to-day operations, from student registration to staff payroll. Many institutions have used the same ERP systems for decades and face challenges to meet the changing demands of staff and students. As new ERP vendors enter the marketplace with new features and functionality, institutions are considering a change. Some things to consider:

1. Don’t just focus on the technology and make change management an afterthought. Transitioning to a new ERP system takes considerable effort, and has the potential to go horribly wrong if sponsorship, good planning, and communication channels are not in place. The new technology is the easy part of a transition—the primary challenge is often rooted in people’s natural resistance to change.  
2. Overcoming resistance to change requires a thoughtful and intentional approach that focuses on change at the individual level. Understanding this helps leadership focus their attention and energy to best raise awareness and desire for the change.
3. One effective tool that provides a good framework for successful change is the Prosci ADKAR^® model. This framework has five distinct phases that align with ERP change:

These phases provide an approach for developing activities for change management, preparing leadership to lead and sponsor change and supporting employees through the implementation of the change.

The three essential steps to leveraging this framework:

1. Perform a baseline assessment to establish an understanding of how ready the organization is for an ERP change
2. Provide sponsorship, training, and communication to drive employee adoption
3. Prepare and support activities to implement, celebrate, and sustain participation throughout the ERP transition

Following this approach with a change management framework such as the Prosci ADKAR^® model can help an organization prepare, guide, and adopt ERP change more easily and successfully. 

If you’re considering a change, but need to prepare your institution for a healthy ERP transition using change management, chart yourself on this ADKAR framework—what is your organization’s change readiness? Do you have appropriate buy-in? What problems will you face?

You now know that this framework can help your changes stick, and have an idea of where you might face resistance. We’re certified Prosci ADKAR^® practitioners and have experience guiding Higher Ed leaders like you through these steps. Get in touch—we’re happy to help and have the experience and training to back it up. Please contact the team with any questions you may have.

¹Prosci ADKAR^®from http://www.prosci.com

Law enforcement, courts, prosecutors, and corrections personnel provide many complex, seemingly limitless services. Seemingly is the key word here, for in reality these personnel provide a set number of incredibly important services.

Therefore, it should surprise no one that justice and public safety (J&PS) IT departments should also provide a well-defined set of services. However, these departments are often viewed as parking lots for all technical problems. The disconnect between IT and other J&PS business units often stems from differences in organizational culture and structure, and differing department objectives and goals. As a result, J&PS organizations often experience misperception between business units and IT. The solution to this disconnect and misperception? Defining IT department services.

The benefits of defined IT services

1. Increased business customer satisfaction. Once IT services align with customer needs, and expectations are established (e.g., service costs and service level agreements), customers can expect to receive the services they agreed to, and the IT department can align staff and skill levels to successfully meet those needs.
2. Improved IT personnel morale. With clear definition of the services they provide to their customers, including clearly defined processes for customers to request those services, IT personnel will no longer be subject to “rogue” questions or requests, and customers won’t be inclined to circumvent the process. This decreases IT staff stress and enables them to focus on their roles in providing the defined services. 
3. Better alignment of IT services to organizational needs. Through collaboration between the business and IT organizations, the business is able to clearly articulate the IT services that are, and aren’t, required. IT can help define realistic service levels and associated services costs, and can align IT staff and skills to the agreed-upon services. This results in increased IT effectiveness and reduced confusion regarding what services the business can expect from IT.
4. More collaboration between IT and the organization. The collaboration between the IT and business units in defining services results in an enhanced relationship between these organizations, increasing trust and clarifying expectations. This collaborative model continues as the services required by the business evolve, and IT evolves to support them.
5. Reduced costs. J&PS organizations that fail to strategically align IT and business strategy face increasing financial costs, as the organization is unable to invest IT dollars wisely. When a business doesn’t see IT as an enabler of business strategy, IT is no longer the provider of choice—and ultimately risks IT services being outsourced to a third-party vendor.

Next steps
Once a J&PS IT department defines its services to support business needs, it then can align the IT staffing model (i.e., numbers of staff, skill sets, roles and responsibilities), and continue to collaborate with the business to identify evolving services, as well as remove services that are no longer relevant. Contact us for help with this next step and other IT strategies and tactics for justice and public safety organizations.

Are you struggling to improve business outcomes through modifications to your software solutions? If so, then you have no doubt tried — or are trying — traditional software implementation approaches. Yet, these methods can overwhelm staff, require strong project management, and consume countless hours (and dollars).

It may be time for your organization to consider the DevOps (Development and Operations) implementation model — a software implementation approach that uses agile methodologies.

The DevOps implementation model — proven to be effective in upgrading large software solutions such as Integrated Eligibility and Enrollment — increases organizational flexibility with frequent prioritization of business problems.

An alternative approach
In contrast to traditional software implementation approaches, the DevOps implementation model features continuous collaboration by the development and operations teams in breaking down, prioritizing, and implementing solution fixes in small release packages. Positive results include improved business prioritization through collaboration, better management of the backlog of software requests, focused development staff efforts, and high-velocity implementation of each release — leading to an improved software solution.

Here are seven essential implementation steps for adopting the DevOps implementation model:

Step 1: Define your software solution’s backlog of outstanding business problems — Understanding the business problems is the first step towards solving them.

Step 2: Prioritize the business backlog using such factors as:

• Operational impact
• Priority and severity levels
• Development level of effort
• Infrastructure considerations

Step 3: Schedule regular team meetings to address the status, prioritization, and resolution of the software solution’s business backlog — keeping the team focused and coordinated increases your efficiency towards resolution.

Step 4: Group prioritized items into small work packages that you can release through the software development life cycle (SDLC) in two- to three-week efforts —helping to keep work packages in small, organized, and manageable packages.

Step 5: Cycle each release through the various stages of the SDLC, utilizing an implementation approach that is defined, documented, and approved by all key stakeholders —providing a predictable and repeatable process for simultaneous development of multiple work packages.

Step 6: Schedule work package releases for implementation to help coordination and planning activities with stakeholders prior to implementation.

Step 7: Implement and integrate the software solution into operations. Making sure stakeholders are aware of release changes is critical for the success of a release. Be sure staff are trained ahead of the release, and that changes are communicated to all appropriate audiences.

You can pair DevOps with other methodologies. This allows you to address smaller components of functionality through DevOps while leaving larger components of functionality to traditional methodologies.

Other considerations:

• Once you resolve the business problem, monitor the solution to make sure the release did not negatively impact other areas of your software solution.
• Ensure the software solution is supported by management plans (e.g., change, configuration, and issue management plans) that are thorough and approved by the key stakeholders. This will help ensure expectations of processes and procedures are agreed upon.
• Maintain the list of business problems in a location accessible to all key stakeholders for awareness, accessibility, and accountability purposes.
• Communicate, report, and manage the status, definition, and/or resolution of issues and/or defects in a consistent, concise, and clear manner to assist in efficiently prioritizing and addressing your business problems.
• Begin communicating the impact of the issue and/or defect as soon as possible–the sooner the issue and/or defect is known; the quicker the team can begin down the path towards resolution.
• Develop materials to train affected staff. Clear and concise training materials will help educate and communicate updated processes to stakeholders.

Improving your software solution
Finding a way to improve your software solution does not always mean using traditional software implementation approaches. Based on our experience, we’ve learned that collaboration between the development and operations teams, and continuously repeating the seven steps of the DevOps implementation model, allows organizations to efficiently address software solution problems.

Interested in learning more about how the DevOps implementation model could work for your organization? Please contact Zachary Rioux.