Redefining Work Types and Customer Intake

JR Laprime
Giga Guru

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

1 ACCEPTED SOLUTION

Timothy F1
Tera Guru

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.

View solution in original post

11 REPLIES 11

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.

Mark113
Tera Contributor

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.