By skyforbes 
Continuing the multi-part series highlighting my work as an Entrepreneur-in-Residence with the Center for Medicaid and Chip Services (CMCS). Would love to hear from others that have experience in similar stints with the Federal Government or within the State Medicaid space. As state Medicaid agencies were struggling with antiquated systems and changing Medicaid policy and implementation environments — charge towards more and more managed care, ACA requirements, waivers and demonstrations — the need to embrace tenets of Agile development were greater than ever.
While writing this piece Microsoft Word highlighted the word “Agile” above in green to indicate that I had incorrectly capitalized the ‘A’ in the word because it understands agile to be a common English dictionary word. This made me chuckle, I actually did mean to spell with the capital ‘A’ to specify its usage as a system development methodology. I remember feeling exactly like this many times during Medicaid systems forum discussions wherein the term “Agile” was commonly tossed around but without understanding its true meaning grounded in systems development. It was true, states needed to change how they had been used to doing things to overcome the challenges facing them on all fronts — data integrity, TMSIS export, managed care proliferation, Medicaid expansion, waivers and demonstrations — as the systems were built in an era of mainframes and then progressively patched together over the next 30 years.
As archaic as the systems that the states operated were in their software architecture, the processes around SDLC were from an era gone by. In my previous post I had explored work that I did towards bringing some changes to that through tools similar to goal mapping, business model canvas and portfolio and risk management. The concept of Agile development was discussed often and the general sense I got was that most if not all states liked the idea but faced organizational inertia too great to be able to adopt it. There were pilots here and there (with 18F and the state of Alaska), but the leap from where they were to the world of Agile development was too far. They were relegated to discussing merits of being agile. My mentors at CMCS had asked me to work on a playbook that new vendors could use to understand how to work within Medicaid. While, that was certainly something that was missing (Business of Medicaid 101), I thought about this problem broadly. All constituents within this ecosystem would face change and change would be a journey that they have to commit to. It wasn’t just about new entrants, as incumbents also faced change from status quo. So after much deliberation I broadened the scope of the playbook to include new entrants and incumbents, divided it into parallel sections for states and vendors and focused on change that all constituents would have to undertake.
Organizational change is a tough process to undertake but it is especially tougher in a risk averse and resource constrained environment such as state Medicaid. In an environment where there might be multiple concurrent implementations and release cycles, any processes from an era of “big bang” development do not apply. More so, simply carving one large development into some number of smaller procurements alone will not achieve any better results. In fact it might produce worse outcomes in terms of cost and time. Unfortunately, most states that had carved up their systems for modular procurement had done just that without really looking at the implications of how staggered development and delivery would be achieved to give best results. The “modules” often didn’t fit canonical criteria for good software modules as per scalability, open interfaces and interoperability readiness. While I have covered other work that I was involved in that address some of these challenges the focus of the playbook for the states was on how to adhere to the principles of Agile development within Medicaid.
We started out acknowledging that some states had already started on their journey towards modular systems and Agile was not the only way. However, given what the rest of the software industry had learned over the last 20 years about the benefits of Agile, we chose to be bullish about it. The state part of the playbook focused on establishing a Project Portfolio Management (PPM) approach. This is counter to locking in dedicated resources at the outside of the project and suffering from low utilization for functions that are common across projects. In addition, employing methodology from SAFE (scaled Agile or any other variant) is important to strike a balance with emergent design and intentional architecture especially in environments that have legacy systems that need to operate alongside updated modules. Identifying functions within the organization that take responsibility for enterprise architecture becomes important. Similarly there is need for diligence in assigning product (or process even) ownership so there is accountability for delivery. A project portfolio, similar to enterprise architecture, represents an always-evolving picture. Set of work items drawn from multiple projects and management of development and delivery (think CI/CD) of these within sprints is how continuous user feedback and value is generated. Identifying what status quo is and how this vision of a project portfolio and Agile development will be achieved is the responsibility of the portfolio owner or the steering committee that owns it collectively. Change agents are required to introduce and pilot these concepts top to bottom within an organization.
In addition to the focus on PPM and Agile methodology, the state side playbook calls for agility in procurement and contract management. As I had mentioned in a previous post, among corridors of change, state procurement was often mentioned as an immovable object that limited how RFPs were issued out. Within this environment we wanted states to issue smaller scope RFPs, decouple products and services contracts that allow things like tier 2 and tier 3 support services to be put in place across the enterprise. Such scalable services and products should be procured under SaaS licensing. Modules should be procured separately only when it makes sense (within this context modules are thought of as pieces of functionality that need to be built in addition to the COTS/SaaS products). It is also important to break-up the delivery of these modules into milestones to de-risk the procurement and project risk. Lastly, the contract management function within states needs to be established or shored up to allow for staggered delivery, independent scaling of products and services contracts and management of a multi-vendor environment. This may also include managing update cycles, security patches, enterprise wide protocols for identity management, disaster recovery and data-backup.
For the vendors, there was special focus on understanding the Medicaid systems environment. This included the funding sources, various state and federal initiatives that may trigger implementations, the APD process, the system certification process and lastly the various ways in which a particular state can procure. While a state may have historically relied upon a one-size fits all procurement methodology, as the state side playbook emphasizes, there might be need to broaden and learn from other enterprise procurements at the state-level or across states. The vendors should be prepared to engage with states with the often used Request for Information (RFI) process. This can provide the vendor community an excellent channel to inform states about how to structure their RFPs — siding towards type of scope and procurement methodology that allows more states to compete.
With the initial impetus for the playbook towards informing and encouraging new vendors it was important to dedicate a few plays for them. However, most of the plays were meant to be applicable to all vendors. As states move towards procurement of COTs/SaaS point solutions and services these should be offered by the vendor community where applicable without hard coupling with other functionality or vendor specific enterprise base layer services. There has been a love-affair with customizing COTs solutions to the point where the customer loses the benefit of COTs, and I was surprised to hear this even at the Medicaid Enterprise Systems Conference at a plenary session with two former Medicaid directors. This needs to stop and RFPs should strictly ask for configurable solutions (which a lot of SaaS vendors are used to) that states can self manage. For vendors coming from outside of Medicaid this is business as usual however for incumbent vendors this would represent significant investment into their offering. This is especially important to prevent vendor lock-in. Of course for this vision to come to fruition, something like Poplin needed to be widely adopted by the vendors and states alike.
It is important to emphasize that playing within this ecosystem would require everyone to adapt — states, old vendors and new vendors. New vendors that come from outside of healthcare or Medicaid may need to expand their offering to be able to offer stronger integration support and have the bandwidth to interact with other administrative and management functions. They would also need to evaluate that are aligned with their service offering and their vision to adapt. Part of this vision, also has to be for all vendors to move towards developing and sharing their product roadmap with the states. This can be done as part of the RFI process if available or even post launch so that the state side is aware of the dependencies that they may need to manage with other vendors.
This article first appeared on my LinkedIn blog — https://www.linkedin.com/pulse/playbook-change-call-arms-vendors-states-anshuman-sharma/