How to handle requests that are projects?

[Lindsay Siurna]

Hi, 

I'm hoping to get some feedback from the community on how to handle service requests that are actually projects.  For example, we received a request to change the name of a hospital.  One of our applications contains a list of hospitals which requires a code change to update.  We are starting a project to make it so a code change is not longer required and to turn this into a standard change going forward but a question arose about what to do with the initial service request ticket?  Do we close it and open a change request? 

Another example - we have a ticket open to make a change to an environment that is scheduled to happen in January. Should that be converted to a change request?  

How do other people handle requests that get assessed and then a decision is made to put them into a project?

We are having trouble knowing what to do with things that are kind of like "to dos"...i.e. this needs to be done and it will be done as part of X project.  Do we just close the ticket and make sure it is added to project scope?

We are fairly new to ITIL and have implemented RF, IM and PM but do not really have a change management process.  As I write this I am beginning to think maybe these are changes and we should implement change management next!

Thanks for your help!

Lindsay

[Jack Brickey]

So we have an IT group and we handle IT tickets using JSD. When we come across IT projects we use JSW. We will create an Epic (e.g. move ERP to the cloud) and create stories/tasks under that Epic. We do not tackle "projects" in JSD. It simply is not designed to any lengthy activities IMO. If a ticket comes into JSD that should be a project I would place the ticket into a Development status (pausing SLAs) and link it to the Epic.

[Jack Brickey]

The customer would open a ticket and the ticket would enter a new status, e.g. “Development”. The customer’s ticket would stay open until the development was done and the change delivered.

[Dave Liao]

@Lindsay Siurna - Whatever process you decide on, ensure that process is documented, and shared with the support team and the customer for transparency and to set expectations.

[Lindsay Siurna]

Thank you both.  So you wouldn't create a change request for these?

What about requests that are kind of like "to dos"...i.e. this needs to be done and it will be done as part of X project.  Do we just close the ticket, inform the user that it will be addressed as part of X project and make sure it is added to project scope?

[Dave Liao]

^ Agree with Jack.

There are many ways to split work, and Jack team's approach is sensible.

Ah, the joy of knowledge work!