.svg){kind=logo}
White Paper
Five Rules: Optimizing Requirements Gathering for Core System Replacements
Summary
Our healthcare consulting team has developed five helpful rules to help your health plan streamline and optimize the requirements-collection process of a core system replacement or upgrade.
Learn how your health plan can optimize the gathering of requirements for a core system replacement with the help of healthcare consulting services.
By: Andy St. Remy Senior Consultant, Change Healthcare Consulting Services
Thomas Ruwald, PMP Consulting Senior Manager, Change Healthcare Consulting Services
A core system is a large-scale software package that supports all major functions within a health plan, including member enrollment, premium billing, benefits, providers, contracts, claims adjudication, and claims payment. Most health plans will undertake a core-system replacement project once every decade or so to take advantage of increased functionality available through evolving, modernized technologies.
Because core-system replacements are pursued so infrequently, the required subject matter expertise may not be available in-house. At Change Healthcare Consulting, our team of experts has worked on hundreds of core-system projects over the past decade. From these experiences, we’ve developed recommendations that can help you execute your replacement project in a timely and successful fashion.
A Broad Spectrum of Requirements
Business requirements must be documented to describe the capabilities the proposed solution should provide to support the business model. Functional requirements represent the next level of detail and define each of the steps necessary to deliver the prescribed functionality for each business requirement.
During the life cycle of a core-system replacement project, you’ll discover that requirements gathering can take place before the project starts as well as throughout various phases of the implementation itself. If this timing seems counterintuitive, it’s important to remember that many different types of requirements must be collected.
Project requirements, business requirements, functional requirements, technical requirements, testing requirements, and configuration requirements are just some of the specifications that need to be defined and documented, and a portion of these are best identified once the project is underway.
Change Healthcare Consulting has developed five general rules that can help streamline and optimize the requirements-collection process. These recommendations reflect lessons we’ve learned over the course of multiple successful implementations over the past decade:
- Focus on Business. During implementation, it’s important to keep current and future system functionality out of mind. Instead, focus on gathering requirements specific to the needs of the business.
- Engage Stakeholders. Gathering requirements by involving key stakeholders can help avoid changes or new requirements being identified late in the project, which can cause delays and add to project costs. Block out time with stakeholders to discuss their specific business need. Doing so will help commit stakeholders to participating in the process.
- Avoid Ambiguity. Most stakeholders have a high-level idea of what’s needed. It is critical that requirements gathering include facilitated sessions where all stakeholders are walked through developing process flows that align with business functionality. These discussions can illuminate the actual business need and should lead to the evolution of a detailed requirement. Business process flows also are valuable tools for mapping the business need to help ensure no requirements are missed.
- Follow Documentation Standards. Developing a consistent approach to documentation standards will be important for requirements gathering. All requirements should be captured in a manner that will allow traceability through configuration development and testing. This will enable tracking back to test cases, coding/development items, and business process alignment needs. Business and Technical Design documents are good tools for documenting how requirements will be implemented, as well as for confirming that identified requirements are included in the design.
- Follow the Change-Control Process. The change-control process is designed to capture any requirements that were missed during the requirement-gathering phase. Its purpose is to document impacts of a missed requirement. It is critical to establish a timeframe for completing the requirement-gathering phase. A procedure should simultaneously be implemented that requires any subsequent revision—including adds, changes, or deletions—to undergo a structured, disciplined change-control process that takes into account cost and benefit. Each organization’s culture will determine where approval authority ultimately resides and whether a team or certain individuals should have this authority.
A core system replacement project can be overwhelming, stressful, and relentlessly challenging. However, we’ve learned over the past decade that by properly documenting requirements before the design solution begins and by keeping the right people involved, you’ll create a solid foundation on which to build your new core system. If you are planning to undertake a core-system replacement project, feel free to reach out to Change Healthcare Consulting so we can share what we’ve learned.
