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
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
^ Agree with Jack.
There are many ways to split work, and Jack team's approach is sensible.
Ah, the joy of knowledge work!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.