Best way to track non-incident type work?

[julieschnepel]

We are looking for an avenue to track non-incident items and would like to see how other organizations are tracking these types of items.   Some may come from the business as something they would like us to do, and some may be internal work that we need to complete.   Here are a few examples of what I am referring to:

-Modify Report to include an additional field in ServiceNow

-Add a configuration item to ServiceNow

-Perform Security Review

-Update disaster recovery documents

-Create RFP for upcoming upgrade

We rely on Task Boards to get a full picture of all items on a team's plate — so tracking these items (even as a 'backlog' item) is important.  

We have gone back and forth between tasks and requests.   We feel as though these are tasks, but aren't sure which 'type' of task would be best?

[Uncle Rob]

Depends what you mean by "Task".

I use Task (capital T) to talk about the superclass of work in ServiceNow.   Everything that you "work" in ServiceNow is a child of Task.   This includes Incident, Problem, Change, Change Task, Idea, Demand, Project, Project Task, Catalog Task, etc.   You'll also hear people use the term "task" to commonly refer to "catalog task" which is a child of a request item (which in turn is a child of request).

I approach Task classification by first breaking my world down into two chunks.   Work that represents me restoring service (in the ITIL sense), and work that involves me fulfilling a service (or "request").   I reserve Incident for the "restoration of service" tacking.   Now, what to do with the left overs?

1) Use OOB For Existing Defined Processes

If my non-incident work is software / product development, I try to use SDLC

If my non-incident work is project related, I try to use PPM

If my non-incident work represents altering a configuration underpinning a service, I try to use Change

2)   What about other structured work?

Your'e going to find massive amounts of work that aren't incident, projects, development, or change.   They're just services we render for people.   The trick is that we know what we have to do.   We know the workflow.   In those cases, its time to build Catalog Items and present them in the Catalog.   Even if the workflow only creates one task in a request item, its worth it, as you'll soon find Workflows often have far more tasks, and involve far more teams than we think.

You can write a book on how to pull off 2, and it takes some prep work defining how the layers of Request Item and SC_Task relate to each other (and how notifications work), but its worth it in my opinion.

[Uncle Rob]

Also, since you use VTB, I'd just base my VTB off Task (capital T) rather than Incident.   That will allow me to see all the work I have to contend with.   I'm going under hte assumption that you're using the free form VTB though.   Task based Guided VTB's are a little more finicky.

[julieschnepel]

Yes, we already had a lesson learned to avoid writing to the Task (capital T) table and are looking at which child table fits best.

It looks like SDLC tasks are an option we need to explor a little closer.   Is that included in the base licensing, do you know?

[Uncle Rob]

On paper, no it isn't.   But there's a TON of variation contract to contract, so ask your sales rep.

If it were me, I'd be pushing towards Catalog instead of SDLC anyway.   SDLC is structured very much for medium to heavy agile methodologies and needs some serious customization to break the agile paradigm.