question Redefining Work Types and Customer Intake in Healthcare Special Interest Group

Redefining Work Types and Customer Intake

JR Laprime — Fri, 21 Jul 2023 18:22:48 GMT

Good afternoon,

My organization is working to redefine our current IT work intake processes which all starts with a standard definition of IT work: projects, enhancements (non-standard IT requests), service requests, and incidents.

While the latter two we have clear definitions, it's the differentiation between projects and enhancements (non-standard, sub project level efforts) to which we are hoping to improve for both internal IT users and our external customers.

Attached is our current state definitions between IT work types. Our definition of project is conditional largely on IT resource needs (> 120 total IT hours or 3+ distinct teams/resource groups). As you can tell, this definition can be quite confusing to an operational customer and even within our IT department.

Looking for input from other Healthcare Organizations (academic medical centers, hospital networks, etc) as to how you define Projects and non-standard, sub-project (Enhancements or other Agile record type) with your customers? Any lessons learned on how to create clear delineations between these types of requests at the point of intake (Service Portal) to effectively route Demands?

As always, thanks for your help and feedback!

JR Laprime

Re: Redefining Work Types and Customer Intake

Riya Verma — Fri, 21 Jul 2023 20:02:07 GMT

Hi @JR Laprime ,

Hope you are doing great.

To create clear delineations between these types of requests at the point of intake, we can implement custom fields and conditions on the Service Portal.

Step 1: Define Custom Fields We will add custom fields to the IT work intake form, such as "Nature of Request" and "Effort Level." The "Nature of Request" field will have options like "Project" and "Enhancement," while the "Effort Level" field will capture the estimated IT resource needs in hours.

Step 2: Implement Conditions Based on the values entered in the "Nature of Request" and "Effort Level" fields, we can set up conditions to distinguish between projects and enhancements. For example, if the "Nature of Request" is marked as "Project," we can check if the "Effort Level" is greater than 120 IT hours or involves 3+ distinct teams/resource groups. If both conditions are met, the request will be classified as a project; otherwise, it will be categorized as an enhancement.

Step 3: Routing Demands Once the nature of the request is determined, we can create routing rules to direct demands appropriately within the IT department based on the classification as a project or enhancement.

Step 4: Collaboration and Learning To ensure the effectiveness of this approach, we can collaborate with other Healthcare Organizations, academic medical centers, and hospital networks.

Re: Redefining Work Types and Customer Intake

Timothy F1 — Fri, 21 Jul 2023 20:29:47 GMT

I believe those project definitions are common. We've run into this problem and are still working through how to solve it.

Two principles we're trying to apply are:

Don't ask the submitter for information that they don't know
Make the choices in the portal clear

This would mean that both "project" requests and "enhancement" requests go to the same bucket. Instead of initially separating the buckets of work by size/the form used to submit them, separate them by something like "business application". e.g. Epic/Cerner, ERP system, ServiceNow, etc. + other. The teams that would normally handle enhancements would look at the list, identify project candidates, and mark them as such to include in the project process.

Re: Redefining Work Types and Customer Intake

JR Laprime — Fri, 21 Jul 2023 20:40:38 GMT

Agree with keeping it simple for the customer. Today in our Service Portal we have two separate request forms (record producers) for projects and enhancements. Both produce Demands in the backend, but with a Type set as Project or Enhancement depending on the initiating form.

However, given that our user base submitting these requests are non-IT, clinical or administrative leaders they would have no means of delineating between IT estimates (hours nor teams).

We have considered using Business Applications, but even that can result in a long list of applications for a customer to have to sift through. Another thought might be to focus on Clinical/Business Service Lines (Business Units).

Great feedback and welcome any additional thoughts you may have.

Re: Redefining Work Types and Customer Intake

JR Laprime — Fri, 21 Jul 2023 20:45:32 GMT

Thanks for your perspective. Unfortunately one of the keys will be to simplify the front end for the submitting customer. Adding additional custom fields would add complexity for them and additional technical debt for IT to support (thinking of regression testing needed for workflows based on customizations during upgrades).

Our customers are clinical and administrative leaders across the hospitals, they would not be able to accurately articulate the prospective IT estimates/resources needed to fulfill their request. This estimation would fall to the Demand Managers to confirm.

Similar to @Timothy F1 comment, one opportunity may be to route all requests through a single form and let the Demand Managers make the project or enhancement determination. Thereby the customers would search our Service Catalog for our routine services and if they can't find what they need (such as implementing a new solution) then default them to a single source Demand form.

Re: Redefining Work Types and Customer Intake

amyfrye — Mon, 24 Jul 2023 12:49:32 GMT

Hi JR,

We also attempted to have 2 record producers (one for Project and one for Enhancement) with definitions in the description but customers still didn't know what to submit/when. Both record producers also resulted in a demand. We decided to simplify and have one record producer called IT Proposal with definitions on when to submit as part of the description that results in a demand. It is up to the demand manager to work with the customer to gather more information to further determine the level of effort, scope, etc. We have the demand route to the appropriate demand manager based on business service/line. We have had it in place for about 6 months and it is going pretty well.

Re: Redefining Work Types and Customer Intake

Ralph Hand — Mon, 24 Jul 2023 13:32:16 GMT

We are going the opposite direction. We currently have intakes for service requests and incidents where they can submit ideas of any size or flavour. We were asked the question, why does the customer have to know the difference between an incident and a request, why have two intakes. The answer is, they don't. To the customer it's all just work that needs to be done. We are going down to one intake and the analyst decides if it is an incident or request based on the definition. If's its longer term it heads to CSI or idea. Our customers have enough to do taking care of patients without having to learn IT lingo or definitions. They need something they ask. We file into the structure that we need it to be in.

Re: Redefining Work Types and Customer Intake

Tracy Hardman — Tue, 25 Jul 2023 12:26:06 GMT

Ralph - we have struggled with our users knowing if it is a request or incident as well. I'm curious what record type you are bringing the request in as before you send it to the final destination. Did you create a new table? Thanks, Tracy

Re: Redefining Work Types and Customer Intake

Ralph Hand — Tue, 25 Jul 2023 12:51:00 GMT

We are using the incident table and having the analyst tag them with a category of incident or request. That makes it easy for the analyst to switch it as necessary. The goal for frequently asked requests is to add them to the catalog, long term.

Re: Redefining Work Types and Customer Intake

Gina_NJ — Tue, 25 Jul 2023 12:57:19 GMT

If it turns out to be a Request, do you convert it or does it remain in the INC table?

Re: Redefining Work Types and Customer Intake

Ralph Hand — Tue, 25 Jul 2023 14:34:33 GMT

We're just going to leave it in the incident table, analyze the frequent items and build catalog items as required. They are all pieces of work that need to be done, the requests just have a lower priority.

Re: Redefining Work Types and Customer Intake

Mark113 — Tue, 08 Aug 2023 12:04:57 GMT

would universal request work as a single intake for all ticket types - then someone triages accordingly ? I guess it simplifies for the customer but adds more effort into the triage process.