Principles of Technology Solution Delivery: How a Healthcare Tech Company Amplified its Technology Solutions

"Think left and think right and think low and think high. Oh, the thinks you can think up if only you try!" ― Dr. Seuss, "Oh, the Thinks You Can Think"

We completely agree with Dr. Seuss because we do a lot of thinking here at Kenway. Sometimes it's strategic thinking, and other times it’s contemplating new ideas around technology. It’s thinking about our clients’ challenges and identifying the right capabilities and services to resolve them.

We also kicked off our previous blog post with a Dr. Seuss quote about the importance of staying curious and keep learning. We shared how Kenway Consulting is helping a healthcare patient engagement company and our key learnings from the project around Enterprise Program Leadership.

Now we’ll build on those learnings and turn to the technology side of the project - considerations made and lessons learned while building the technology platform itself (pictured below). And as Dr. Seuss says, this one gave us a lot to think about, and we believe it will give you a lot to think about too.

 

Healthcare Data Transformation

IMPLEMENTING A NEW ENGAGEMENT PLATFORM

The healthcare technology company we will be diving into in this blog partners with leading health insurance companies. It supports them by growing health plan members’ engagement to reduce healthcare costs, improve quality measures, and increase overall health outcomes. The company decided to re-platform its engagement product and scale its user base to achieve these goals.

The client was challenged to implement an improved, automated platform that would scale with it as it grew and needed it done quickly. Given the accelerated timeline and complexity of the project, the company turned to Kenway for its capabilities around Enterprise Program Leadership, Technology Solution Delivery, and Information Insight.

The healthcare company’s technology issues were just as challenging as its Enterprise Program Management difficulties. The client used an inefficient, costly legacy platform and required manual efforts to perform basic, repeatable activities. Kenway worked with the client to move them to the Salesforce platform to better meet the needs of their business processes.

Salesforce allows the client to interact with health plan members in more than 25 languages via SMS, email, phone call, and direct mail. This two-way communication occurs through a series of multimodal touchpoints comprising “pathways.” Each pathway has a unique objective, such as helping a member schedule an annual wellness visit.

THINKING ABOUT TECHNOLOGY SOLUTIONS FOR PRESENT AND FUTURE NEEDS

Kenway’s Technology Solution Delivery capabilities guide and support organizations on their technology transformation journey. We design and deliver a customized approach across these four core services:

Kenway leveraged these core services to ensure the healthcare company was driving business benefits to support immediate needs while also providing the flexibility to scale to future demands. Here we dive deeper into two of those needs, including the lessons learned that could apply to your enterprise.

BUILD VERSUS BUY

In our previous blog post, we shared the importance of doing your due diligence on vendors to ensure they have the capabilities to meet your immediate and long-term needs for software. But there is an essential step before vendor selection where enterprises must decide whether they need a vendor or if they can accomplish their goals internally.

Healthcare organizations often confront a fork in the road where they must decide whether to take the path toward building or buying. The decision can have ramifications from a perspective of costs, ROI, and scalability. At Kenway, we advise our clients that when the software solution is very custom or has a high volume of complex requirements, then that is a case for building.

Let’s take an example of build versus buy from our healthcare company. The company conducts outreach to its members via snail mail and works with a direct mail partner to send out mailers. This was a decision where the company chose to buy because the vendor had more expertise with the mail system than the company had available internally.

Another type of outreach to members is a health risk assessment survey. The healthcare company partners with a vendor to send these surveys electronically to members. It chose to buy this service because the vendor can send the surveys at scale and populate them with specific data requirements based on members’ attributes.

As a follow-up to the survey, the member, their primary care physician, and the healthcare plan provider each receive a summary by mail of the survey results and an individualized care plan with actions to take based on health issues or risks. However, most healthcare plans do not want snail mail and prefer a Word document in editable format. The hitch is that most direct mail vendors do not support Word docs.

So, this would be a case for building out a system internally since the Word doc capability is likely unavailable via a vendor. By keeping ‘the build,’ the healthcare company could leverage the skillsets of its internal teams and maintain control, make changes quickly, and lessen its risks.

These are questions to ask when weighing the pros and cons of build versus buy:

AUTOMATION VERSUS MANUAL PROCESSES

Our healthcare company client was struggling with a classic case of manual process woes. It uses an internal call center with agents to route its member cases. But there was a limit on the number of cases the agents could route automatically. This resulted in the necessary intervention of two call center operating managers who had to take 10 hours per week (520 hours per year!) to manually click and drag to assign cases to the call center agents.

The lesson learned was that organizations should work towards minimizing the amount of repeatable, non-value-adding manual work by their employees. By switching more tasks to automation, companies can allow their teams to use their unique skillsets on tasks that require a human touch.

Taking the time upfront to prioritize automating as much of the business as possible will help enterprises with scalability and profitability. Because if organizations don’t identify the inefficiencies of manual processes existing at launch, those inefficiencies will only greatly magnify as the business scales. The issues will reach a point where they will become much harder to fix and lead to increased costs to rein them in.

Take, for example, the community health guides that the healthcare company uses. The guides communicate with members via phone, text, and email. Some of these interactions are done manually, and others with Salesforce automation. In the case of phone calls, the guide would read from a script and click through a series of screens in Salesforce based on the member’s responses. The quicker the guide can wrap up the call, the more efficient the system. At launch, the system was designed to handle future surges in call volume to prevent any limitations that may arise.

Ready to equip you and your team with the knowledge you need to successfully integrate technology solutions into your organization? Get more insight by scrolling through our blog. Or, if you’re ready to talk to one of our experts about reaching company goals, connect with us to learn how we can help with your technology solution needs.

 

 

Glass Houses, Stones, and IT Projects

Over the course of my career, I have spent thousands of hours providing a combination of Program and Project Management Services for all shapes and sizes of IT projects. Over the course of these engagements, I regularly overhear Business resources disparaging their IT counterparts. A few common qualms I can identify are: “They just don’t understand our business,” “IT does not focus on the right things,” and a personal favorite, “They are not strategic enough; they just want to take orders.” When I was a kid, my Mom advised me to, “never cast stones if you live in a glass house.” That is, do not criticize others for faults that you very well may share. In regards to the aforementioned overheard remarks, I let my Business partners vent, but then quickly point out that experience has shown me that issues on IT projects are typically a two-way street—the business and the IT teams share the blame. As this can be construed as confrontational, I quickly turn the conversation in a more productive direction by pointing out four ways in which business organizations can positively impact their IT projects.

Include IT Partners in Strategic Discussions

IT organizations are still seen far too often as operators and executioners instead of strategic partners of the Business. While already a poor approach, its negative effect on productivity is magnified in today’s environment where the growing popularity and necessity of technologies like Cloud Computing and Storage, Big Data, and Mobile Accessibility are at the forefront of business strategy and innovation. An increasing number of successful organizations are realizing the importance of applying technology to solve business problems and to drive strategy formation. These early adopters are reaping real benefits through improved customer satisfaction and increased revenue.

However, this does not happen automatically, nor is it the responsibility of IT to drive the process. I have yet to meet a strong technology resource who thirsts to sit in a dingy back room and run reports. These individuals’ talent goes beyond technical skills, and their understanding of technology mixed with a sense of overall business goals can help bring an organization to a more informed decision. The next time a business person considers disparaging IT for “not being strategic,” they should first ask if they have invited their technology partners to the appropriate meetings, allowing them to participate in strategic discussions.

Have a Plan

If you are a Business leader and do not have a plan for your IT initiatives, create one. If you already have one, share it with your IT partners. Better yet, invite IT partners to participate in your planning process (see previous paragraph) and ask for input and feedback. To clarify, I am defining an IT plan as the combination of a structured project repository, a defined intake and prioritization process, business cases that include plans for benefits realization, and multiple roadmaps for various time horizons that make sense to your business. It is a clear and organized structure—simply requesting one hundred projects with nothing more than project names documented is not planning and could ultimately lead to project failure. Common signs that the Business does not have enough control over their IT projects are: frequently changing priorities, inconsistent resource dedication to a project, and unrealistic timeline expectations. Operating without a strategic plan puts IT behind the proverbial 8-ball from day one, and it is nearly impossible to recover. The team is expected to deliver a project with little to no background information, business sponsorship that is lacking if existent at all, and delivery models so abbreviated that basic project phases are forcibly neglected. The next time there is frustration because IT is “not flexible enough”, consider whether the Business has provided the information necessary to understand priorities, to properly sequence projects, and to confidently align IT resources to meet business needs.

Dedicate an Adequate Amount of Appropriately Skilled Resource Capacity

Business Case documentation, requirements definition, user acceptance testing (UAT), change management, stakeholder communication, and end user training are all responsibilities on IT projects that belong to the Business. Too often, staffing discussions focus only on resources for design, build, and system test. While never formally stated, the idea seems to be that the other software development lifecycle (SDLC) phases will either take care of themselves or can simply be skipped if business resources are not available. This could not be further from the truth. Generally, the Business team owns the budget for projects and must confirm that appropriately skilled resources are available at the right time and in the right capacity to meet overall project milestones. If these resources are not available, then other project drivers (i.e. scope, timeline and budget) must be modified in order to bring the plan back in alignment. For example, if there are not enough properly skilled resources to document requirements, then the date for starting design must be pushed back. Too often, I have seen IT organizations expected to design and build a deliverable based on unfinished or poorly documented requirements. In these situations, the Business should be held accountable if the quality of the end product is not up to par. Furthermore, the IT team should not be blamed if a final product goes unused because there was no change management or communication plan in place to introduce the product and its value to the user community.

Consider the Total Cost of Ownership

It seems like common sense, but IT assets should not be thought of in one year increments. However, Business owners sometimes fail to think far enough ahead, leaving them surprised and disappointed when capital and expense budgets are impacted in subsequent years. Once an application is built, both the IT and the Business organizations will need to consider future changes and enhancements that the application will require in their upcoming budgets. Otherwise, the application can become outdated and unused—a total waste of resources. There is often the need to hire additional resources to manage the asset from a business perspective in order to understand how the application fits into the overall business strategy and to plan, manage, and drive the application forward. I often hear the Business lamenting that IT does not take on the enhancement determination process. While it requires partnering with IT, the Business is ultimately responsible for identifying opportunities for improvement and to drive application changes.

In addition to “never cast stones if you live in a glass house”, my Mom also imparted the following wisdom on me growing up, “If you don’t have anything nice to say, then don’t say anything at all.” While I generally live by this advice outside of work, I could not be more opposed to it when it comes to managing projects. Sometimes things do not go well, and often diplomatic yet direct communication is required to fix the problem and to get the project back on track. That being said, all Business leaders should be living by the guidelines outlined in this blog before casting these stones at their IT partners. Kenway Consulting has a proven track record of bridging the gap between Business and IT organizations in order to drive successful projects and programs. For an assessment of your project governance or advice on struggling projects, please contact us at [email protected].