Three steps to

outcomes-based

certification

If you’ve been tasked with leading a high-impact project for your organization, you may find managing the scope, budget and schedule is not enough to ensure project success—especially when you encounter resistance to change. When embarking on large-scale change projects spanning people, processes and technology, appointing staff as “coaches” to help support stakeholders through the change—and to manage resistance to the change—can help increase adoption and buy-in for a new way of doing things.

The first step is to identify candidates for the coaching role. These candidates are often supervisory staff who have credibility in the organization—whether as a subject matter expert, through internal leadership, or from having a history of client satisfaction. Next, you need a work plan to orient them to this role. One critical component is making sure the coaches themselves understand what the change means for their role, and have fully committed before asking them to coach others. They may exhibit initial resistance to the change you will need to manage before they can be effective coaches. According to research done by Prosci®, a leading change management research organization, some of the most common reasons for supervisor resistance in large-scale change projects are:

• Lack of awareness about and involvement in the change
• Loss of control or negative impact on job role
• Increased work load (i.e., lack of time)
• Culture of change resistance and past failures
• Impact to their team

You should anticipate encountering these and other types of resistance from staff while preparing them to be coaches. Once coaches buy into the change, they will need ongoing support and guidance to fulfill their role. This support will vary by individual, but may be correlated to what managerial skills they already possess, or don’t. How can you focus on developing coaching skills among your staff for purposes of the project? Prosci® recommends a successful change coach take on the following roles:

• Communicator—communicate with direct reports about the change
• Liaison—engage and liaise with the project team
• Advocate—advocate and champion the change
• Resistance manager—identify and manage resistance
• Coach—coach employees through the change

One of the initial tasks for your coaches will be to assess the existing level of change resistance and evaluate what resistance you may encounter. Prosci® identifies three types of resistance management work for your coaches to begin engaging in as they meet with their employees about the change:

• Resistance prevention―by providing engagement opportunities for stakeholders throughout the project, building awareness about the change early on, and reinforcing executive-level support, coaches can often head off expected resistance.
• Proactive resistance management―this approach requires coaches to anticipate the needs and understand the characteristics of their staff, and assess how they might react to change in light of these attributes. Coaches can then plan for likely forms of resistance in advance, with a structured mitigation approach.
• Reactive resistance management―this focuses on resistance that has not been mitigated with the previous two types of resistance management, but instead persists or endures for an extended amount of time. This type of management may require more analysis and planning, particularly as the project nears its completion date.

Do you have candidates in your organization who may need support transitioning into coaching roles? Do you anticipate change resistance among your stakeholders? Contact us and we can help you develop a plan to address your specific challenges.

Writing a Request for Proposal (RFP) for a new software system can be complex, time-consuming, and—let’s face it—frustrating, especially if you don’t often write RFPs. The process seems dogged by endless questions, such as:

• How specific should the problem statement and system requirements be?
• How can the RFP solicit a response that proves the vendor is qualified?
• Should the RFP include legal terms and conditions? If so, which ones? 
• Is there another strategy that can help cut down on size without forfeiting a quality response?

The public RFP process can be onerous for both the issuer and the respondents, as they can reach lengths upwards of 100 pages. And, while your procurement department would probably never let you get away with developing an RFP that is only one page, we know a smaller document requires less labor and time devoted to writing and reading. What if you could create a lean, mean, and focused RFP? Here are some tips for creating such a document: 

Describe the problem as simply as possible. At its core, an RFP is a problem statement—your organization has a particular problem, and it needs the right solution. To get the right solution, keep your RFP laser-focused: adequately but briefly convey your problem and desired outcomes, provide simple rules and guidelines for respondents to submit their proposed solutions, and clarify how you will evaluate responses to make a selection. Additional information can be white noise, making it harder for respondents to give you what you want: easy-to-read and evaluate proposals. Use bullet points and keep the narrative to a minimum.

Be creative and open about how vendors must respond. RFPs often have pages of directions on how vendors need to write responses or describe their products. The most important component is to emphasize vendor qualifications. Do you want to know if the vendor can deliver a quality product? Request sample deliverables from past projects. Also ask for the number of successful past projects, with statistics on the percent deviation to client schedule, budget, including explanations for large variances. Does your new system need to keep audit trails and product billing reports? Rely on a list of pass/fail requirements and then a separate table for nice-to-have or desired functionalities.

Save the legal stuff until the end. Consider including legal terms and conditions as an attachment instead of in the body of an RFP. If you’re worried about compliance, you can require respondents to attest in writing that they found, read, and understand your terms and conditions, or state that by responding to the RFP they have read and agreed to them. State that any requested deviations can be negotiated later to save space in the RFP. You can also decrease length by attaching a glossary of terms. What’s more, if you find yourself including language from your state’s procurement manual, provide a link to the manual itself instead.

Create a quality template to save time later. Chances are your organization has at least one RFP template you use to save time, but are you using that template because it gets you the best responses, or because you’re in the habit of using it? If your answer is the latter, it may be to time review and revise those old templates to reflect your current business needs. Maybe the writing style can be clearer and more concise, or sections combined or reordered to make the RFP more intuitive.

Qualify providers in advance and reduce the scope. Another time-saver is a pre-qualification, where solution providers propose on an RFP focused primarily on their experience and qualifications. Smaller statements of work are then issued to the qualified providers, allowing for shorter drafting, response, and award timelines. If procurement rules allow, break the procurement up into a requests for information (RFI) and then a smaller RFP.

Need additional RFP assistance?
A simplified RFP can reduce long hours needed to develop and evaluate responses to RFPs, while vendors have more flexibility to propose the solutions you need. To learn more about how BerryDunn’s extensive procurement experience can help your organization develop effective RFPs.
 

Truly effective preventive health interventions require starting early, as evidenced by the large body of research and the growing federal focus on the role of Medicaid in addressing Social Determinants of Health (SDoH) and Adverse Childhood Experiences (ACEs).

Focusing on early identification of SDoH and ACEs, CMS recently announced its Integrated Care for Kids (InCK) model and will release the related Notice of Funding Opportunity this fall.

CMS describes InCK as a child-centered approach that uses community-based service delivery and alternative payment models (APMs) to improve and expand early identification, prevention, and treatment of priority health concerns, including behavioral health issues. The model’s goals are to improve child health, reduce avoidable inpatient stays and out-of-home placement, and create sustainable APMs. Such APMs would align payment with care quality and support provider/payer accountability for improved child health outcomes by using care coordination, case management, and mobile crisis response and stabilization services.

State Medicaid agencies have many things to consider when evaluating this funding opportunity. Building on current efforts and innovations, building or leveraging strong partnerships with community organizations, incentivizing evidence-based interventions, and creating risk stratification of the target population are critical parts of the InCK model. Here are three additional areas to consider:

1. Data. States will need information for early identification of children in the target population. State agencies?like housing, justice, child welfare, education, and public health have this information?and external organizations—such as childcare, faith-based, and recreation groups—are also good sources of early identification. It is immensely complicated to access data from these disparate sources. State Medicaid agencies will be required to support local implementation by providing population-level data for the targeted geographic service area.

• Data collection challenges include a lack of standardized measures for SDoH and ACEs, common data field definitions, or consistent approaches to data classification; security and privacy of protected health information; and IT development costs.
• Data-sharing agreements with internal and external sources will be critical for state Medicaid agencies to develop, while remaining mindful of protected health information regulations.
• Once data-sharing agreements are in place, these disparate data sources, with differing file structures and nomenclature, will require integration. The integrated data must then be able to identify and risk-stratify the target population.

For any evaluative approach or any APM to be effective, clear quality and outcome measures must be developed and adopted across all relevant partner organizations.

2. Eligibility. Reliable, integrated eligibility and enrollment systems are crucial points of identification and make it easier to connect to needed services.

• Applicants for one-benefit programs should be screened for eligibility for all programs they may need to achieve positive health outcomes.
• Any agency at which potential beneficiaries appear should also have enrollment capability, so it is easier to access services.

3. Payment models. State Medicaid agencies may cover case management services and/or targeted case management as well as health homes; leverage Early and Periodic Screening, Diagnostic, and Treatment (EPSDT) services; and modify managed care organization contract language to encourage, incent, and in some cases, require services related to the InCK model and SDoH. Value-based payment models, already under exploration in numerous states, include four basic approaches:

• Pay for performance—provider payments are tied directly to specific quality or efficiency indicators, including health outcomes under the provider organization’s control. 
• Shared savings/risk—some portion of the organization’s compensation depends on the managed care entity achieving cost savings for the targeted patient population, while realizing specific health outcomes or quality improvement.
• Pay for success—payment is dependent upon achieving desired outcomes rather than underlying services.
• Capitated or bundled payments—managed care entities pay an upfront per member per month lump sum payment to an organization for community care coordination activities and link that with fee-for-service reimbursement for delivering value-added services.

By focusing on upstream prevention, comprehensive service delivery, and alternative payment models, the InCK model is a promising vehicle to positively impact children’s health. Though its components require significant thought, strategy, coordination, and commitment from state Medicaid agencies and partners, there are early innovators providing helpful examples and entities with vast Section 1115 waiver development and Medicaid innovation experience available to assist.

As state Medicaid agencies develop and implement primary and secondary prevention, cost savings can be achieved while meaningful improvements are made in children’s lives.

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.

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. 

Most of us have been (or should have been) instructed to avoid using clichés in our writing. These overstated phrases and expressions add little value, and often only increase sentence length. We should also avoid clichés in our thinking, for what we think can often influence how we act.

Consider, for example, “death by committee.” This cliché has greatly — and negatively — skewed views on the benefits of committees in managing projects. Sure, sometimes committee members have difficulty agreeing with one another, which can lead to delays and other issues. In most cases, though, an individual can’t possibly oversee all aspects of a project, or represent all interests in an organization. Committees are vital for project success — and arguably the most important project committee is the steering committee.

What Exactly is a Steering Committee?
It is a group of high-level stakeholders that provides strategic direction for a project, and supports the project manager. Ideally, the group increases the chances for project success by closely aligning project goals to organizational goals. However, it is important to point out that the group’s top priority is project success.

The committee should represent the different departments and agencies affected by the project, but remain relatively small in size, chaired by someone who is not an executive sponsor of the project (in order to avoid conflicts of interest). While the project manager should serve on the steering committee, they should not participate in decision-making; the project manager’s role is to update members on the project’s progress, areas of concern, current issues, and options for addressing these issues.

Overall, the main responsibilities of a steering committee include:

1. Approving the Project Charter
2. Resolving conflicts between stakeholder groups
3. Monitoring project progress against the project management plan
4. Fostering positive communicating about the project within the organization
5. Addressing external threats and issues emerging outside of the project that could impact it
6. Reviewing and approving changes made to the project resource plan, scope, schedules, cost estimates, etc.

What Are the Pros and Cons of Utilizing a Steering Committee?
A group of executive stakeholders providing strategic direction should benefit any project. Because steering committee members are organizational decision-makers, they have the access and credibility to address tough issues that can put the project at a risk, and have the best opportunities to negotiate positive outcomes. In addition, steering committees can engage executive management, and make sure the project meshes with executive management’s vision, mission, and long-range strategic plan. Steering committees can empower project managers, and ensure that all departments and agencies are on the same page in regards to project status, goals, and expectations. In a 2009 article in Project Management Journal, authors Thomas G. Lechler and Martin Cohen concluded that steering committees are important to implementing and maintaining project management standards on an operational level — not only do steering committees directly support project success, they are instrumental in deriving value from an organization's investments in its project management system.

A steering committee is only as effective as it’s allowed to be. A poorly structured steering committee that lacks formal authority, clear roles, and clear responsibilities can impede the success of a project by being slow to respond to project issues. A proactive project manager can help the organization avoid this major pitfall by helping develop project documents, such as the governance document or project plan that clearly define the steering committee structure, roles, responsibilities and authority.

Steer Toward Success!
Steering committees can benefit your organization and its major projects. Yet understanding the roles and responsibilities — and pros and cons — is only a preliminary step in creating a steering committee. Need some advice on how to organize a steering committee? Want to learn more about steering committee best practices? Together, we can steer your project toward success.

The relationship between people, processes, and technology is as elemental as earth—and older than civilization. From the first sharpened rock to the Internet of Things, the three have been crucially intertwined and interdependent. There would have been no Industrial Revolution, for instance, without entrepreneurs who developed new tools to facilitate new manufacturing methods.

Of course, the increasing complexity of processes and the rapid innovations in technology tend to eclipse the present role that people play in progress. On the surface the trend seems understandable, even reasonable, when it comes to implementing a new Enterprise Resource Planning (ERP) system. Implementing a new ERP system is one of the most daunting projects an institution can undertake. Some sobering statistics—over 70% of all implementations take longer than planned, while over 50% go over budget—illustrate why many institutions focus on selecting the right ERP model and purchasing the right software. This is important, yet there are two excellent and connected reasons why your institution should focus on the “people component” of an ERP implementation.

Reason #1: The Technology is Tenable

Companies have improved and vetted ERP systems over time, so that today there’s little chance your institution will purchase poorly designed ERP software. And you have multiple options. For example, you could pursue a hosted ERP model in which a data center houses your ERP system, or a Software as a Service (SaaS) model, in which a third party administers your ERP software. These options help minimize hardware implementation, maintenance, and incomplete attempts at full system utilization—which in turn saves you time, money, and headaches.

In short: You won’t have to bear the full brunt of the tech burden, and the software and hardware you purchase should work. This enables you to concentrate on the people component of the system.

Reason #2: People Propel the Processes

A higher education institution can optimize an ERP system to complete countless processes: automating registration, onboarding staff, processing financial aid, improving self-service capabilities, simplifying record-keeping, etc. Yet a system can’t do all this on its own (not yet, at least). People—both functional and IT staff—propel these processes. For this to happen, your institution needs to secure buy-in and equip people with vision, training, and resources.

People are wary of ERP projects, for good reason. When an institution decides to tackle an ERP implementation the onus often falls on already busy staff, some of whom may rather find a new career than manage a new system implementation. Your staff and their institutional knowledge are your greatest assets. It is important to empower staff to define how future-state business processes should work—and for you to remember that a common reason for ERP implementation failure is lack of engagement. Sometimes, those at the executive level make decisions without adequate input from the people who actually do the work. You will need to sharpen your “people skills” in order to educate stakeholders on the value of a new ERP system, and how the software will make their day-to-day roles and responsibilities more efficient and effective. To ensure that staff have the bandwidth to engage in this change, it is advisable to provide backfill for key administrative functions.

Designing business processes of a future-state system is arguably the most challenging part of an ERP implementation. Often, stakeholders don’t understand the new functionality that a future system can offer because they have only used the prior system. It is important to engage the ERP vendor early and educate your staff to ensure that they understand the possibilities when designing future-state processes.

Once you have designed processes, training should take center stage. And once again, people play a pivotal role in this process. Modern ERP systems usually require staff to fundamentally conduct business differently; this can require training not only on the new system, but also on other foundational technologies (e.g., the office suite) not relied upon before. It is important to identify these needs and incorporate them into your institution’s training plan up front.

An effective training plan needs to balance multiple types of training, ranging from formal classroom sessions to online learning and train-the-trainer sessions. Tech-savvy staff will be able to train other staff in using the new ERP system, which will not only increase the skill sets of said staff, but will also help them better understand how their roles fit within the larger picture of the institution. This, in turn, will organically improve communication and workflow, as well as lead to more collaboration and teamwork. The result: positive institution-wide change.

Moving Forward

Think about your institution’s focus when implementing a new ERP system—and be aware of the benefits that it could have for your staff, your students, and your bottom line. You will face other ERP-related challenges, such as selecting the right third-party vendor and facilitating change management. If you’d like to discuss some strategies for tackling these challenges, this process is easy—just send me an email.

A year ago, CMS released the Medicaid Enterprise Certification Toolkit (MECT) 2.1: a new Medicaid Management Information Systems (MMIS) Certification approach that aligns milestone reviews with the systems development life cycle (SDLC) to provide feedback at key points throughout design, development, and implementation (DDI).

The MECT (recently updated to version 2.2) incorporates lessons learned from pilot certifications in several states, including the successful West Virginia pilot that BerryDunn supported. MECT updates have a direct impact on E&E systems—an impact that may increase in the near future. Here is what you need to know:         

Then: Initial Release

In February 2017, CMS introduced six Eligibility & Enrollment (E&E) checklists. Five were leveraged from the MECT, while the sixth checklist contained unique E&E system functionality criteria and provided a new E&E SDLC that—like the MECT—depicted three milestone reviews and increased the Independent Verification and Validation (IV&V) vendor’s involvement in the checklists completion process.

Now: Getting Started

Completing the E&E checklists will help states ensure the integrity of their E&E systems and help CMS guide future funding. This exercise is no easy task, particularly when a project is already in progress. Completion of the E&E checklists involves many stakeholders, including:

• The state (likely more than one agency)
• CMS
• IV&V
• Project Management Office (PMO)
• System vendor(s)

As with any new processes, there are challenges with E&E checklists completion. Some early challenges include:

• Completing the E&E checklists with limited state project resources
• Determining applicable criteria for E&E systems, especially for checklists shared with the MMIS
• Identifying and collecting evidence for iterative projects where criteria may not fall cleanly into one milestone review phase
• Completing the E&E checklists with limited state project resources
• Working with the system vendor(s) to produce evidence

What’s Next?

Additionally, working with system vendors may prove tricky for projects that already have contracts with E&E vendors, as E&E systems are not currently subject to certification (unlike the MMIS). This may lead to instances where E&E vendors are not contractually obligated to provide the evidence that would best satisfy CMS criteria. To handle this and other challenges, states should communicate risks and issues to CMS and work together to resolve or mitigate them.

As CMS partners with states to implement the E&E checklists, some questions are expected to be asked. For example, how much information can be leveraged from the MECT, and how much of the checklists completion process must be E&E-specific? Might certification be required in the near future for E&E systems?

While there will be more to learn and challenges to overcome, the first states completing the E&E checklists have an opportunity to lead the way on working with CMS to successfully build and implement E&E systems that benefit all stakeholders.

On July 31, 2017, CMS released the MECT 2.2 as an update to the MECT 2.1.1. As the recent changes continue to be analyzed, what will the impact be to current and future MMIS and E&E projects?

Check back here at BerryDunn Briefings in the coming weeks and we will help you sort it out.

We all know them. In fact, you might be one of them — people who worry the words “go live” will lead to job loss (theirs). This feeling is not entirely irrational. When an organization is ready to go live from an existing legacy system to a new enterprise system, stress levels rise and doubts emerge: What can go wrong? How much time will be lost? Are we really ready for this?

We’re here to help. Here is a list of go-live essentials to help you mitigate stress and assess your readiness. While not all-encompassing, it’s a good place to start. Here’s what you need:

1. A detailed project plan which specifies all of the implementation tasks
   A project plan is one of the most important parts of an implementation. A detailed plan that identifies all of the implementation tasks along with an assigned resource for each task is critical to success. The implementation vendor and the organization should develop this plan together to get buy-in from both teams.

2. A completed system configuration
   New system configuration is one of the most time-consuming aspects of a technology implementation. If you don’t complete the implementation in a timely manner, it will impact your go-live date. Configure the new system based upon the best practices of the system — not how the existing system was — for timely implementation.

3. External system interface identification
   While replacement of some external systems may be a goal of an implementation, there may be situations where external systems are not replaced or the organization has to send and/or receive data from external organizations. And while new systems have advanced interface technology capabilities, the external systems may not share these capabilities. Therefore it is imperative that you identify external system interfaces to avoid gaps in functionality.

4. Testing, testing, testing
   End-to-end testing or User Acceptance Testing (UAT) is often overlooked. It involves completing testing scenarios for each module to ensure appropriate system configuration. While the timing of UAT may vary, allow adequate time to identify solutions to issues that may result from UAT.

5. Data conversion validation
   When you begin using a new system, it’s best to ensure you’re working with clean, up-to-date data. Identify data conversion tasks in the project plan and include multiple data conversion passes. You must also determine if the existing data is actually worth converting. When you complete the data conversion, check for accuracy.

6. End user training
   You must train all end users to ensure proper utilization across the organization. Don’t underestimate the amount of time needed for end user training. It is also important to provide a feedback mechanism for end users to determine if the training was successful.

7. A go-live cutover plan
   The overall project plan may indicate go-live as an activity. List specific activities to complete as part of go-live. You can build these tasks into the project plan or maintain them as a separate checklist to promote a smooth transition.

8. Support structure
   Establish an internal support structure when preparing for go-live to help address issues that may arise. Most organizations take time to configure and test the system and provide training to end users prior to go-live. Questions will arise as part of this process — establish a process to track and address these questions.

Technology implementations can significantly impact your organization, and it’s common for stress levels to rise during the go-live process. But with the right assessment and preparation, you can lessen their impact and reduce staff stress. Our experienced, objective advisors work with public and private sector organizations across the country to oversee large enterprise projects from inception to successful completion. Please reach out to us to learn more about preparing for your next big project.