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

[amyfrye]

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.

[Ralph Hand]

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.

[Tracy Hardman]

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

[Ralph Hand]

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.

[Gina_NJ]

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