Redefining Work Types and Customer Intake

[JR Laprime]

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

[Riya Verma]

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. 

[JR Laprime]

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.

[Timothy F1 · Accepted solution]

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.

[JR Laprime]

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.