Your project does not necessarily need to cover all possible scenarios or features. Once you’ve evaluated your process, you should have identified the biggest pain points and what data is currently available relative to the scenarios that are most challenging to claimants.
Scoping should determine which elements of claims status should be addressed now versus later. Breaking the work up into different milestones is highly encouraged. It allows you to change your strategy as new data becomes available.
Defining the scope upfront will help ensure that clear requirements are documented for your vendor or technology teams to avoid unnecessary cost overruns.
Recommendations
Keep track of scope decisions. Detailed written requirements provide documentation and direction for your team and help ensure stakeholders are aligned on the project outputs.
A project management tool can help document your work, especially for larger and more complicated projects, but it is not required. Organized text documents or spreadsheets can also be suitable so long as stakeholders agree on the source of truth.
Ideally, scoping discussions will be grounded in data. For example, the first version of your claims status tool might only address the three most common issues that claimants struggle with based on data about call volume and the time it takes to resolve a claim.
If critical data is unavailable and is possible to get with some investment, consider adding it to the project scope. Be aware that data collection is also an investment of time, so it is crucial to plan for this extra time in the project timeline.
Similarly, you should include technological considerations in scope discussions to be able to do some initial cost-benefit analysis. Depending on your software system, some interventions, like adding visual elements to an online user experience, could be easy to implement, even if their expected return is not the highest. Alternatively, the highest priority challenge might also take the most work to address in the system. If that is the case, you may want to only focus on that and exclude other scopes from the project. If you have a technical lead familiar with the software system, they will be crucial during this step to start the technical evaluation.
One scope decision you should make early on is selecting an approach to build your claims status tool. Would you like to integrate functionality into an existing claimant portal or build a standalone tool?
The approach that makes sense for you will depend on the state of your current systems, your procurement processes, vendor relationships, and any time or staffing constraints you may have.
The table below illustrates a sample evaluation of the pros and cons of building a standalone claims status tool.
|
Pros |
Cons |
|
Doesn’t require an existing claimant portal. |
Can create a fragmented experience if a claimant portal exists. Claimants would need to access multiple tools to manage their claim. |
|
Can be faster to build, depending on the state of the existing user portal.
|
Does not allow for direct user interaction like uploading documents or scheduling appointments. It would need to re-route users to another place for identity proofing. |
|
Does not need to handle identity proofing, can be stood up with a simple claim number as the access criteria. |
Less secure than a log-in portal. The data shown in a standalone tool should be limited to non-sensitive information. |
|
Does not require a legacy vendor or consortium approval, can be built by any contractor. |
A new vendor may take longer to learn how to integrate with the required data and will need more oversight with product requirements. |
Interested in addressing claims status? Email the UI Modernization Team
Was this page helpful? Fill out a short survey