Making the Business Case for Mobile Patient Engagement

Not long ago, we shared some insights from a report released by the consulting group Huron about the evolving landscape of digital health. In the blog post, we listed out the factors that still stand as barriers to adoption, including a poor selection process. We’ve noticed this topic and the general topic around technology governance have been having a moment. 

Last year, one of our customers announced that they were focused on significantly reducing and streamlining their overall tech stack. They were evaluating duplicate solutions and looking at how to maximize solutions and vendor integrations. The goal was to go from somewhere near 300 solutions to closer to 100. We asked if they would share the process they are now using to vet technology and increase their tech governance. They kindly obliged. 

Since a poor selection process is one of the reasons technology purchases fail, consider using a process to make the business case. A large project like a mobile engagement platform or digital front door is a great example of a project that can benefit from this process. Drafting a business case allows you to gather important information about the benefits and value of a project. It should describe how the purchase will improve the business. The business case also serves as the guide to ensure the business leader who is developing it has considered all areas of the project to include scope, costs, return on investment, and how workflow will change. The goal isn’t to provide a deep technical overview but to give information that can help a leader make an informed decision.

Your business case should include the following elements according to our client:

1. 1. Project Overview: Describe the background context, opportunities, and the goals for the project. Identify operational and/or clinical value of the work being performed.
   2. The ‘Why’: What problem is this project trying to solve? What does the future look like if this project is successful?
   3. Scope Overview: Define the logical boundaries of the project. Scope statements are used to define not only what is within but also what is outside the boundaries of the project. Examples of areas that could be examined are people, data, processes, applications, and business areas. This section should also include major workflow, operations and product functions.
   4. Financial Summary & Resource Overview: This section should provide a high-level summary of the required capital and operating costs associated with the delivery of the defined project scope within the specified implementation timeline as well as any funding limitations.
      1. Capital Costs (e.g., Hardware, Professional Fees, Perpetual Licenses (one-time fee), IS Labor)
      2. Operating Costs (e.g., Software Licenses, Software/Hardware Maintenance, IS Labor)
      3. Funding Limitations: Comparing the planned expenditure of project funds against any limits on the commitment of funds for the project.
   5. Return on Investment (ROI) Assessment: What is the total cost to implement and maintain and what is the monetary benefit? ROI is used as a predictive tool with expected profits and costs to inform future decisions and should include hard and soft assets as well as labor.
   6. Integration Considerations: This section identifies the coordination of system dependencies needed (e.g., integration points, or considerations, with other solutions, interfaces, legacy applications, technical areas, etc.)
   7. Facility / Space Considerations: This section identifies any needs related to the physical space of the project (e.g., Network, Power, HVAC, Electrical, Lighting, Move-in/out timelines, Asset removal/installation, cosmetic/finishes).
   8. Transformation Impacts: This section identifies any transformational, or process based, changes that will impact or affect any of the defined stakeholders. This includes definition of new, or revised processes, policies, or other workflow related impacts.
   9. Assumptions: Project assumptions are circumstances and events that need to occur and/or are considered true for the project to be successful.
   10. Impacts of Not Implementing / Pursuing the Business Case?
   11. High Level Milestones: List any known milestone dates that have been established by the business owner or vendor. Identify time sensitive events, contractual obligations, facility openings, regulatory requirements, etc. 
   12. Estimated Time to Implement: This is a high-level estimate that includes all phases of a project–design, develop, test, train, go-live, and optimization.
   13. Stakeholders: An individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project.

Our client also looks at a few other considerations, including: 

• Have they had experience successfully executing similar projects?
• Will this project directly impact patient satisfaction?
• Will this project directly impact employee satisfaction?
• Will this project directly improve physician engagement and satisfaction? 
• Will this project directly impact patient safety?
• Will this project directly impact revenue?
• Doe this demand directly reduce cost?
• Does this demand directly improve operational efficiency? 
• Is there an existing product Baptist Health has that can meet this need?

Using a tool like this helps ensure that all aspects of the project have been considered, including the resources needed and return on investment. The more prepared you are to “sell” your project to the decision makers, the better chance you have of being successful. You can download this business user case for technology purchases template to help you get started.