Best Practices for recurring / scheduled tasks

[PierreDumoulin]

Hey gang,

I've been doing some reading on other articles pertaining to recurring tasks. Other clients seem to have the same need whereby some team responsibilities, known to be some type recurring maintenance, need to be put on the radar. It also makes sense that these tasks appear in the team's regular workload. In the context of ITSM, any given assignment group or team could be expected to process incidents, requests (catalog tasks), problems (problem tasks), change orders, etc. on a regular basis.

Here's where I feel it gets tricky: requests in general very much imply that they are created spontaneously when a need arises (most likely from a client). Metrics like overall lifetime (time between open and close dates) or SLAs actually encourage some expediency and tickets with short lifetimes, i.e. quickly addressing the client's needs, are praised.

It's not so clear cut for tasks we know will be required at a specific time, which could be weeks or months from now. I've seen people suggesting scheduled templates, which is an interesting option. However, this doesn't work wonders for planning since you don't yet see the tasks that will be created later. Having the actual task on the board asap maximizes visibility and ensures we know what's coming at any given time, however, at the cost of any sense of urgency since there is a specifically expected timeframe or deadline for them (same could be said for a scenario like onboarding a new employee. It's not about how fast it's closed, it's about meeting a deadline). I know that, for example, dedicated request categories with less restrictive SLAs could be an option, but that seems somewhat involved.

Without going into technical details, I'd like to solicit your feedback on any best practices you may have adopted in this regard. Thanks in advance for your attention! looking forward to discussing this with you all!

[Mike_R]

I've built a custom app for a similar scenario at my previous company.

Basically I created a table where teams can manage these "scheduled" or "maintenance" task. They are able to define the type, details, and frequency that the tasks should be generated. Then behind the scenes, I created a couple of business rules, workflows, scheduled jobs, to take care of the logic and autogenerate the tasks (I also extended the task table to create a new task type.)

In the end, it was actually a pretty simple app and it gave them exactly what they were looking for.

[PierreDumoulin]

Thanks for replying Mike. That's an interesting approach and one I'm considering. Some (admittedly manageable) down sides I see though are:

• advance notice is not necessarily maximized (how long ahead of time do you create the tasks?)
• This introduces a whole new type of task assigned to ITSM fulfillers, meaning impact on reporting, etc.

Can you speak to how this was managed? What kind of volume did you produce? Was it just for a specific team or did this become standard across multiple teams?

thanks!!

[Mike_R]

Once they created the schedule and had all the required information filled in, the tasks were automatically created (upon their confirmation).

We had it setup to generate the tasks for the whole calendar year, based on their defined schedule. The reason for this is because they wanted to view all future tasks for the year in a calendar view.

Future tasks would remain in a pending state and a due date was auto-populated, and 7 days before the due date, it would automatically change to work in progress. And we also created a dashboard so they can see past and future tasks trending by month and grouped by state. Plus the calendar view.

We did this specifically for our facilities team (hence the custom task type), but it could've easily been retrofitted for the typical ITSM teams to create requests, and change requests on a scheduled basis.

The volume of tickets were about a few thousand a year.

This was built entirely off their requirements and specific use case, so obviously your process will be a little bit different. 

[PierreDumoulin]

Great stuff, this is the conversation I was hoping to have. You're touching on all the points I've been considering. In a nutshell, here's what I see:

Pros

• Visibility and predictability of all of the year's known upcoming tasks (I imagine you could also roll with a dynamic window, i.e. 200 days into the future, say, as to not be surprised by early year tasks)
• Accurate Due Dates for all tasks allowing for easy planning and confirmation of appropriate resource availability at any given point in time.

Cons

• These tasks are immune to any kind of performance or processing delay evaluation KPIs, they just need to be done.
• It means putting an entirely new task type on the radar for people to do and make sure they're able to report on. If I compare to my own ITSM population, we have a good culture here of consuming reports on incident/request/change volume as well as resolved problems. It would take quite a bit of awareness to introduce a new task type to this reporting culture...

Questions

• Do we know if ServiceNow is actually considering anything like this OOTB within any kind of foreseeable future? Do we know what their current official recommendation is? I'm sure that many clients have some version of this today that will need to be refactored when something native is made available...
• How well or badly did the management of change go for adopting this solution? The audience seems fairly concise, which must've helped. I take it there's a full fledged notification strategy around this to maximize awareness? Did existing dashboard already allow for any assigned task type to be visible or were sweeping changes required?
• Despite their planned nature, do you assign any kind of metrics or SLAs to the types of tasks?