Please write a case analysis on Health Reform Case by including the answers from below questions

Case Study Questions 1. What ERP Implementation strategy was used in this case study and why?

2. Pre-built Enterprise Architecture software like the one used in this case, Enterprise Architect, are used to facilitate implementation projects. In which way was Enterprise Architect used in different phases of the project? Give examples

3. What ES implementation lifecycle or methodology was used in this case study? why

4. What are some of the main take aways/ lesson learned from your perspective related to ES implementation methodology or strategy?

PDF Screenshot: Please follow the materials below to write the analysis

How one American state implemented successful health-insurance reform The Mission In 2010 the U.S. federal government passed legislation intended to provide affordable medical insurance to vast numbers of uninsured or underinsured American citizens. The legislation empowered state governments to implement solutions that were built and managed locally - at the state level. That is the focus of this study. One of the things the legislation does to extend health insurance coverage is create new government-operated insurance exchanges that provide consumers with access to individual medical-insurance policies. These exchanges are essentially closed, controlled marketplaces where consumers shop for policies and, depending on income eligibility, apply individual tax credits to offset the cost of their insurance premiums. The business model is designed to encourage competition between insurance vendors. Before setting up the exchanges, the project teams in each jurisdiction needed to create the internal infrastructure for building the program and the delivery system. They needed to identify and define requirements; determine processes, protocols and standards; create mechanisms for collaboration, planning building, and testing and select the tool(s) necessary to support all of this work. The Requirement and Implementation This case study looks at one of 14 states that chose to build and operate its own exchange. This exchange adhered to federal standards, but the federal government was not directly involved in either its development or its management. The state-operated exchanges have very little visibility outside their own jurisdiction. Across the United States, the largest, highest-profile exchange has always been the federal operation - which today provides direct exchange services in most American states. One of Sparx' Global Partners - a major international consulting firm - was principal contractor during the final 27 months of planning, design and development of this state-level exchange. Their team was led by senior partners from the firm's highly specialized enterprise architecture practice - supplemented by a couple of trusted outside experts from the Sparx Global Network. The initial nine-month engagement while the project was still in planning and high level design - started in 2011, less than three years before launch. During that first phase the consulting team was responsible for several core elements: - strategic planning; - the IT gap analysis; - the implementation roadmap; - the budget for the exchange and the application for federal funding assistance; and - the identification and flagging of any functional and technical gaps between the state government's current program architecture and the evolving, newly-developed federal standards [1]. Once the planning project - the enterprise-architecture transformation - had run its course the state government re-engaged the same consulting team for the next phase. At this point, with just 18 months left until launch deadline, the clock was ticking even louder. The original consulting team was now part of a larger consortium responsible for full lifecycle support during development and deployment. The new deliverables list included: - Refining plans and developing detailed business and software specifications for: - The entire business model - Staffing - Systems (ensuring that all these specifications complied with federal standards) - Assisting with a process to ensure any new systems developed for the exchange were aligned with policies and business practices already in place elsewhere within the state government - Providing Quality Assurance/Oversight while monitoring the development and implementation of IT infrastructure for the exchange - Developing a reporting infrastructure capable of meeting the needs of all exchange stakeholders - including consumer groups, insurance carriers and the federal government - Managing the entire User Acceptance Testing (UAT) process: - Defining UAT scenarios and creating detailed scripts for those scenarios - Planning all UAT activities - Providing oversight for all testing - Reporting on defects encountered during testing (including an informed Arriving with a calibrated reference framework already in place provided several benefits. Not only did it give the planning and development team a running start - it also mandated a culture of best practices based on model-driven frameworks. In a note to Sparx, one of the lead consultants said: "Architectural modelling imposes a structured methodology on the planning and development process. It constantly forces the team to align architectural design and resource allocation to the underlying business requirements. It keeps everyone on the path." The planning team used the pre-built reference framework and model as a starting point - as an initial platform for the project. With the model in place they worked with senior health officials from the state to identify all the key business requirements and all the key systems requirements for the new exchange. With these requirements in hand (and stored within the model in a project repository) the team then designed the higher-level integrated business processes for the new exchange. All this new design work was also captured in the project repository and integrated into the evolving model of the exchange. At the same time the team also worked with the project's designated Systems Integrator, who was charged with designing the detailed systems functions for the new exchange. As with the business processes, this output was captured in the model and stored in the shared project repository. The business requirements and use-case stories were all written using Sparx Enterprise Architect - the same software environment that was used to create the original, pre-built reference framework. The Sparx software actually served the project in a variety of ways. The development team also used it to manage the shared repository that held all project-related information: the framework, the model, the documentation and all the related artifacts. Sparx Enterprise Architect software also provided individual team members with access to the repository directly from their computer desktops. Any changes to the model or to documentation made during this desktop access is traced and tracked automatically on the fly. As an aside, when the consulting firm first discovered Sparx Enterprise Architect they used it strictly as an in-house tool. They chose Sparx only after vigorous due diligence examined all the competing software in the sector. As staff and partners became more familiar with Enterprise Architect, the software earned its way into client-based projects Enterprise Architect's strong tracking features were increasingly useful as the team grew in size, models of the exchange became more complex, and multi-tasking acquired more threads. Although team-members from the consulting firm were already familiar with Sparx Enterprise Architect from its increasing use within their home practice, the tool was new to project team members from outside the firm - personnel from the state government and from other contractors. The consultants selected Millar - a Practice Leader at consulting firm integrate iT because of his strong background working with development teams on project readiness and his extensive experience using Sparx Enterprise Architect for business modelling, software engineering and TOGAF. (TOGAF - an acronym for The Open Group Architecture Framework - is a standardized approach for managing enterprise-architecture transformation planning and implementation; and for governing an enterprise architecture capability.) Once everyone had mastered a common notation, common methods of architecture, common roadmaps and common ways to use a shared project repository, the team turned its focus to Business Requirements Definition (BRD). Following guidelines set down by the state and the federal governments, they used Sparx Enterprise Architect software to organize the BRD into four distinct value streams: - insurance issuers; - individuals and families; - employers and employees; - health-exchange management. Within each of these streams the consultants defined the detailed business processes, organizational roles, responsibilities and accountabilities required to support all the client-centric interactions necessary for a fully-functioning health insurance exchange. It is not unusual for IT projects as complex as this one to respond to tight deadlines by multi-tracking several worker streams. This kind of multi-tracking must be well managed, or it will cost more time than it saves when the streams are eventually stitched together and managers discover unintended consequences. Lesson Learned The health-insurance exchange project avoided the kind of catastrophic launch-day seen at many of the other exchanges across the United States because: - the development team was able to tap into the reusable knowledge stored in the prebuilt health insurance exchange framework and reuse the model; - modelling in Sparx Enterprise Architect is robust enough to accommodate a complex ecosystem of live data links between the state-exchange, the policy holder's account, several federal databases and several distinct insurance vendors; - the tools included in Sparx Enterprise Architect software supported a disciplined approach based on a shared, testable model of the project; - the shared reusable model and Sparx Enterprise Architect software enabled the consultants to accelerate development of the exchange, and this created the breathing room necessary for thorough testing and quality control; - the client's management team rose to the challenge with flexibility and a realistic sense of practical limitations. There are always lessons learned in a project of this scope, and the consulting team does have a list of things they will do differently next time. However, the list is largely focussed on tactical and logistical details. The core strategy - their basic approach to the project - did work as expected and did work well: this exchange, after all, was one of a small handful across the United States that actually met its business requirements from the very first day. Project-readiness consultant Ramsay Millar has his own perspective on the success factors in this project. "Every project develops its own culture," he said. "In this project the culture