Managing ServiceNow Demand

[chuckn]

Hi all,

I'm curious: how do you manage your ServiceNow demand, whether that's for new catalog items, enhancements to processes, altogether new functionality...all of the above? Do you have catalog items with the requisite variables for the information you need? Do you track how long it takes to complete different types of work, such as developing a new item or modifying something existing? Do you use ITBM/SPM idea and demand?

Thanks!

-Chuck

[Steve Vaughan]

Here at First Solar, we utilize the Continual Improvement part of SN to capture the whole IT demand.  They evaluate the end platform that it will be built in, Oracle, ServiceNow, or K2.   The CIM process does all the gathering of requirements and wire framing ending with a CR to the SN team.

If it is already a part of SN, we focus on a more Agile way of tracking them.  We have an enhancement form that users can fill out to get to our queue where a Sprint is Assigned.   We typically do a FIFO.  Our Sprints are not on a set schedule so the promotion to PROD can be done anytime. 

Our ServiceDesk has the ability to update and create Catalog Items that they can bind to our Common Flows/Workflows that pull info like assignment group, priority, task instructions right from the Catalog Item.  Some as simple as Create a Single Task, where others get manager approval, or even a variable base approval based on what the user picks when filling out the form.  If one of the common flows does not fit the needs entirely, they can run with it until the enhancement is in to get a new process mapped.  

We also permit our HR team to go in and make modification to the Onboarding Notifications directly in PROD. 

Beyond that, we are a super agile company where we perform actions directly in PROD in accordance with our Change Strategy Document that are logged as a PROD Update.

Some examples of things we do that are below.

I highlighted Flow Designer as we use that heavily in PROD.  One example was a manager wanted a notification for when a certain type of change was assigned to his team.  Instead of opening the Change Workflow and updating it there, we created a flow to watch for the triggers defined and send the email from there.  

Happy to speak at the next SNUG on this topic!!

[Ryan S]

Hi Steve,

Using CIM is an interesting approach which prompts a lot of questions. Here are a few. It seems like all demand would then have to be tied to a specific improvement initiative and have defined goals/measurements for success. Do you have pre-defined CIM records that new demand may be attached to? Or do you create a new CIM for each new demand? How do you then decide to close out an improvement initiative?

[Steve Vaughan]

For our CIMs, we are manually tracking the success of them. I would need to get with the team that manages that side to see how they measure success.  

When it comes to a new CIM, we create a new one for each demand.  The business can input them directly through a record producer on the portal.  

They are closed out when a Change Request is created (or multiple).  There are also some that close out not requiring an IT change request as we have an MES team that tackles production tool updates through separate processes. In either case they are closed when it is time to implement.  There are numerous approvals that happen.  We have implemented a Business Process approval path where they can rotate through various groups to gain their approvals.  This can be either before or after the CIM itself is approved. 

[Ryan S]

I had the same thought as dklimas...use metrics to track the durations of the stories. PA would be good with breakdowns for request types and to see trends over time, but you could use standard reports too.

[chuckn]

Thanks for the great conversation, everyone!

Appreciate the suggestions about tracking STRY metrics. I don't see that in our instance even with the Agile 2.0 plugin installed. But I see a Scrum Common (sn_scrum_common) plugin that we don't have installed, oddly.

Using metrics would definitely help with calculating time in states along the way. I think the one I'm most focused on at the moment would be how long a request/story has been in the backlog before we picked it up to work on...and then how long we worked on it before it was complete.

But...considering the video Jace shared...perhaps we set all that aside and just think about delivering working software without worrying about point estimation and sprint planning. In that world, what communication would you all do to requestors and/or management regarding expected turnaround time?