We at PK want to wish you a happy holiday season. We had some special celebrations this year. You can read about one of them, that we believe embodies the spirit of the season and PK, here.
It was great spending time with our clients at the annual MESC meeting in Denver this week. We enjoyed reconnecting with many state agencies and making new acquaintances as well.
Public Knowledge had great attendance at two of the breakout sessions with our Colorado and Wyoming clients.
MMIS Procurements in Today’s Marketplace
The first session titled ‘Procurements in Today’s Marketplace: Procurement and Evaluation Strategies for Creative Solutions That Encourage Competition’ was a highly interactive session around MMIS procurement, evaluation and protests. The State of Colorado Department of Health Care Policy and Financing’s Deputy Finance Office Director, Chris Underwood, covered several innovations in Colorado’s multiple RFP’s for MMIS, PBMS, and Business Analytics.
This session explored the significant risks for MMIS procurements and the lack of competition. Recent claims processing implementation and operational challenges have led states to explore more modern, innovative, adaptable, and modular solutions. However, states and vendors often rely on traditional RFP, proposal, and evaluation that do not consider modern service delivery models. We discussed how states could produce RFPs with clear requirements while looking for creative solutions that inspire vendors to invest proposal resources, appeal to non-traditional vendors, and encourage competition. We also discussed selecting the best vendor and solution to meet states’ needs as well as evaluation processes that are fair and impartial.
MMIS As Services
The second session titled ‘Challenge: Purchase MMIS Processing as Services Using Federal Match’ opened up a dialog around acquiring MMIS processing as services rather than systems using federal match. Wyoming’s State Medicaid Director, Teri Green opened the dialog with an announcement that Wyoming would be exploring a “services” approach to its upcoming MMIS replacement strategy. Caroline Brown of Covington and Burling covered the supporting language in CFR and other regulations for such an approach.
This session explored alternatives to procuring a traditional MMISs. Medicaid programs continue to grow in complexity while states face evolving regulatory changes. MMISs struggle to keep up with program and technical demands. Many implementations take 3+ years, while experiencing budget and schedule overruns. Consequently, many states are seeking alternatives. This session highlighted Medicaid claims processing and payment management as a service. This represents a paradigm shift in the way systems and services are acquired. We also discussed how federal requirements and contracting rules might apply to this type of framework as it relates to enhanced federal matching funds.
Looking to Continue the Dialogue?
Public Knowledge is currently scheduling meetings with State Medicaid Agencies throughout the country to expand on MMIS procurement and starting down the path of MMIS as services rather than systems.
Our first meetings are occurring in early September and continue through December of this year. If you are a state with an interest in MMIS planning and procurement, we want to meet with you. We will come to you for a brief 30 minute meet and greet or can allocate up to 4 hours to provide an in depth look at where the MMIS market is headed based on real experience drawn from our current projects.
If you are interested, contact Nicole (McNeal) or Jim (Plane) at MESC2014@pubknow.com to schedule a meeting. In return for your time we promise to deliver information of value to you, tailored to your situation. These are not sales calls. These are “let’s get acquainted” meetings to better position each of us for future Medicaid systems and services opportunities.
In the course of our work we have developed a set of eight “best practices” for piloting an information system. This series of posts provides an summary of those practices. In previous posts we discussed the need for Executive Sponsorship, goal setting, and expectation management and communication and project management. Concluding our discussion of piloting, in this post we will discuss setting the pilot boundaries and dealing with what comes out of the pilot.
7. Know what you need to get started and when you’ll be done before you start.
Have a checklist of “entry criteria.” This checklist should ensure staff members are appropriately prepared, have the training they need, equipment they need, and have a means of reporting findings the minute they occur. It should also cover bigger issues such as a means of collecting and reporting findings and a defined project management plan and communication plan that is being executed.
Have a checklist of “exit criteria”. The first item on this list defines what done means. It can be when all features in scope have been exercised (or exercised a defined number of times), or you can time-box your pilot and just say it will be conducted over a month or three weeks.
Have a set of suspension criteria. If a feature of the pilot can’t be tested because it doesn’t work you pull the plug on the whole pilot? Or will you suspend execution of the pilot until the feature can be fixed?
Plan to develop a “close out” or lessons learned report. This serves as a formal endpoint for the pilot and provides a compilation of the findings, conclusions, and recommendations arising from the pilot.
8. Be prepared to deal with what you find.
As previously mentioned, you need a way to capture findings as soon as they occur. Individuals conducting the pilot are under tremendous pressure and unless they stop the moment they have an idea or identify an anomaly, they will not remember it at the end of the day. Web forms or printed worksheets work well for this.
Have a means of collecting, collating and summarizing the findings information. Ideally, this should be done daily and the information obtained shared with appropriate parties as defined in the communication plan.
Have a method of prioritizing findings. Keep it simple. Generally two categories work well. The first are findings that must be resolved before you can go live. These are things without fixing you cannot perform your work – there is no workaround. The second are all other findings. Give those reporting the issue input to the priority, but the sponsor should make the ultimate decision.
Share your findings regularly with the pilot team and stakeholders. On a month-long pilot have standup team meetings – short 15-minute meetings – at least twice a week to review results. Share summarized versions of your findings with stakeholders as appropriate. Never gild the lily – bad news is better delivered early than late.
As part of a broad range of services designed to help you prepare for implementing information systems, Public Knowledge, LLC helps public sector agencies successfully plan and execute information system pilots.
In the course of our work we have developed a set of eight “best practices” for piloting an information system. This series of posts provides an summary of those practices. In previous posts we discussed the need for Executive Sponsorship, and goal setting, and expectation management. In this post we discuss choosing pilot participants, communicating with the world about your pilot, and the planning and management of your pilot.
4. Choose the right people to be “pilots.”
Typically in systems projects 15% of those affected by the system will have a very favorable attitude about it, 15% will have a negative attitude about it. It’s the middle 70%, the ones who just want to get their job done in the most efficient way possible, that should be the core of your pilot group. Choose the best and brightest from this group. They will give you an honest opinion about your pilot and help improve the value of the pilot. The reasoning here? Nay sayers won’t like the system no matter what and vice versa the cheerleaders will overlook flaws that should be noted.
Your instincts will probably serve you well here but novices typically make the mistake of choosing only proponents. It’s the neutral crowd, the ones who will pay the price for a bad system, you want giving you feedback.
Plan to communicate. Develop a written communication plan that defines who you need to communicate to (pilot staff, stakeholders, bosses, staff that will eventually be affected by the system), what they need to know (goals and scope, the project plan, summary status information, detailed status information, closeout report etc.), how you will communicate with them (in person, via phone, by a center, etc.), when you communicate with them (before the pilot begins, daily or weekly during the pilot, and post pilot), and who is responsible for conducting this communication.
Carry out your plan, judiciously tracking each communication that occurs, evaluating the efficacy of that communication, and adjusting your plans accordingly.
Proper planning for communication and carrying out that plan helps ensure the right people are on your side should the need arise.
6. Plan and manage the pilot.
This may seem a bit obvious but you’d be surprised how many pilots we see where the system is thrown into a pilot setting with no real plan for what needs to be done and no individual clearly in charge. Pilots are small projects. However, they are critical projects and deserve all the discipline and attention any project receives. Plan and execute the pilot according to agency or industry (such as Project Management Institute) standards. Develop a work breakdown structure, defining the tasks that need to be completed, who will do them, how much effort each task will take, and when they are expected to be done. Document the plan and communicate it to appropriate parties.
Execute the plan as any other project plan. Monitor tasks, note and mitigate obstacles, and where reality deviates from the plan make adjustments to the plan and communicate associated changes to stakeholders and team members.
Choose an experienced individual to ensure the plan is developed, executed and monitored according to standards. This is, of course, the pilot project manager.
Having a plan and manager in place will avoid having a runaway pilot and the associated costs and headaches.
We’ll wrap up this series about piloting in our next post by discussing preparation and what to do with what you find in your pilot. As part of a broad range of services designed to help you prepare for implementing information systems, Public Knowledge, LLC helps public sector agencies successfully plan and execute information system pilots.
In the course of our work we have developed a set of eight “best practices” for piloting an information system. In a previous post we discussed the need for Executive Sponsorship. In this post we discuss setting pilot goals and scope, and expectation management.
2. Set goals and scope.
At the outset you must decide why you’re doing the pilot and what will be piloted. A pilot is not a scripted test but use of the software in a production environment. The goal of the pilot is not to prove that everything works, but to find out what doesn’t work. The pilot should reveal problems with system and operational processes. If it does not, then it is an indication that your piloting process is bad, not that the system is good.
Goals and scope should include a list of features that will be piloted, and features that won’t be piloted. Remember, many business processes are cyclical; they occur daily, monthly, weekly, or even yearly. You may not test many of these cycles. Be very specific about what is in and out of scope.
The scope should also define duration for the pilot.
3. Manage expectations.
Working with the new system will not be efficient. User learning curve, bugs, and working out the software’s “fit” with your policies and procedures will take effort. Staff piloting the system may have to perform dual entry on the “old” system while using the new system. Staff piloting the system may need backfill or at least some relief from performing regular duties. Things will go wrong. You must define your expectations for those piloting a system communicate those expectations.
Public Knowledge, LLC helps public sector agencies successfully plan and execute information system pilots.
A pilot is a limited use of an information system in a production like environment to help determine the systems and the organizations readiness for use of the system on a larger scale. Pilots are typically limited by geographic location (e.g. It is piloted in one office), by duration (e.g. The pilot occurs over two weeks), by the features piloted (e.g. We’ll only be testing the reporting tools of the information system), or some combination of all of these. The results of the pilot are used to extrapolate how well the information system will work on the larger scale and what needs to change about the system or organization to lower deployment risks.
In the course of our work we have developed a set of eight “best practices” for piloting an information system. Over the course of the next few posts we will discuss these practices. The first of the best practices is to have an Executive Sponsor.
1. Executive Sponsorship
An Executive Sponsor provides leadership, tackles obstacles, makes key decisions and ultimately takes responsibility for the success or failure of the pilot. The sponsor should be a senior executive with authority over the business unit conducting the pilot. This individual must have some “skin in the game”. There’s not a lot more to say about the sponsor other than you would be amazed at the number of pilots that don’t have one. Pilots without sponsorship often meander and fail to really assess the systems readiness for use in production. This in turn leads to, at best, a rocky implementation.
Public Knowledge, LLC helps public sector agencies successfully plan and execute information system pilots.
Let’s face it: public sector programs and projects have “customers” – people who are impacted by or care about the outcome of what you are doing. It doesn’t matter if you are preparing for the Open Enrollment milestone of the Patient Protection and Affordable Care Act (ACA) or building a bridge over a lake you have customers. Poor (or failed) communications with customers can lead to misunderstandings that have serious impacts on the outcome of a program or project. Engaging customers through timely, clear, and consistent communication promotes greater understanding between you and your customers and avoids these misunderstandings. This communication takes thought and planning.
To better communicate with customers use:
- A plan that outlines who you need to communicate with, how frequently (and when) this communication needs to occur, what messages need to be communicated, who is responsible for preparing and delivering the message, and which media (for example, on-line, television, written brochures, etc.) will be used.
- Language that is simple and easily understood by the target audience (for example, avoid the use of industry jargon or terms of art).
- A methodical approach to ensuring key ideas or messages are effectively communicated (for example, identify customers likely position before you communicate with them, what position you want them to hold after you have communicated, and what methods you will use to lead them to that destination).
- A standard template and style guide for written materials to promote consistency of formatting, punctuation, and grammar.
- Knowledge of how customers assimilate information and learn from different kinds of media (for example, when reading on-line content recognize and utilize the “F reading pattern” to structure the format of your communication).
- An active voice in both written and oral communications.
Public Knowledge, LLC helps public sector agencies with stakeholder outreach and communication services, including establishment of communication strategies, tactics, and plans. Some of our more recent work includes helping State agencies reach out to people affected by the ACA.