kellykaufmann
Mega Guru

Kelly's SN implementation Blog Post #8

PPM Setup Updates — Week 2 of 2 for getting Demand Management & a bit of Project set up

Friday was the deadline to have our PPM functionality set up in the Demand Management module and Project module, to have our Demands & Projects imported, our charts working, some reports run, the CIO's homepage set up, and a 'cheat sheet' created for the CIO to pull up the illustrations himself. Just a few things to do in two weeks

The modules were set up in Dev, tested, and moved to Prod. We collected & imported 90% of the Demand information for our requested projects — some of the ROI's simply couldn't be identified so quickly.

Demand Backlog Setup

One challenge we encountered was that the Demand Backlog (the Guitar-Hero type illustration) plots the Demands based on end date (or for us we're plotting by go-live date)…. But the team doesn't yet know many of the dates beyond just that it will be done in a certain half of the year or quarter of next year. This created anxiety in having a date thrown out and possibly leadership writing down that date as a set-in-stone date. To address that, we added a field below the date titled "% confidence in go-live date", that way leadership can tell if the date is really known or if it's just a 'swag'. That's great, but when the Demand is plotted on the Demand Backlog you don't have this context — it's just a Demand plotted at a certain date. What I'm thinking of doing is changing the header color of the squares plotted on the Demand Backlog to be a certain color for that % (for example, make it red if it's 0-40%; make it yellow if it's 41-79%; make it green if it's 80%+). The default is to have the header color driven by the Demand 'state', but I think we'll only plot Demands in the 'Qualified' state anyway.

find_real_file.png

Onto my cherished Bubble Charts for plotting Demands. The romance stage of these Bubble Charts has come & gone and we were not on speaking terms for a few days. Late last week, we defined the axes and captured & imported all this criteria for the x, y, and z axes (btw, knowing how to pronounce the plural of axis will come in very handy in these discussions!) for all our Demands. And then….we took a look at how it plots. It plotted ugly. Was it plotting ugly because of issues in how we set up our calculations in the Demand Management module, or was it ugly because our Demands simply plot that way based on the values we selected? Last Friday afternoon, we fixed a few easy errors in calculations for plotting, but it still didn't seem to be plotting right. I was stuck. Woaaaah Nelly it was a pain to figure out the weights / logic for how the bubbles are plotted on the bubble chart. I looked at the demo charts, dug into their criteria & weights, and put all this into a spreadsheet to try to figure it out. I figured the complexity had to do with the relative weighting, and that that math was beyond my brain's abilities. Finally our implementation consultants was able to understand it & explain it to me. It wasn't me. It was that the logic was very complicated. Overly complicated. I spoke with Ryan at ServiceNow, and he's hoping to get this simplified and to get a guide created for future companies in setting this up.

Task Board to Rank Projects

To make up for my Bubble Chart frustrations….our AOS consultants configured the Task Boards typically meant to rank stories to be scrummed and made it so we could use the drag-n-drop feature to rank Demands. They also created several Task Boards so ranking can be done different ways — by Business Division (so each business division leader can rank their business division's Demands), by Priority (puts the focus on the top priority Demands to rank), and overall. Ranking is as easy as grabbing a 'card' and sliding it up or down, and the ranking number will be automatically updated. Cool! I'm still working on what content should be displayed on each of the cards, and am thinking of doing a ranking # by business division and an overall ranking #.

  find_real_file.png

We got a few charts created pretty quickly, created a dashboard for the CIO, and added these charts to the dashboard. We titled 'Demands' as 'Open project requests', since the group of senior leaders he will be presenting this information to won't know what a 'Demand' is. Here's the reports we set up:

      • Demands by Priority — pie chart and bar chart
      • Table of Demands by Priority, of which I exported the Demands which were in the two highest priorities
      • Demands by Business Division
      • Demands by Project Driver
      • Projects by Level of Effort
      • Projects by Priority
      • Table of Projects by Priority, of which I exported the Projects which were in the two highest priorities

A reporting challenge we encountered is that a project can have multiple selections for 'Project Driver' (it is checkboxes). When reporting against Project Driver (and any other category based on checkboxes), therefore, there will be a category on the chart titled 'empty' that you'll have to explain to leadership.

This was our organization's first time collecting & centralizing project information across all I.T. groups. One interesting statistic we found is that 70% of our in-flight projects are of a duration of a month or longer.

So, now that the CIO has these charts, knows how to use the PPM Visualizations and has a cheat-sheet (attached) for accessing these visualizations, he is set for his leadership meeting in a few days. I also gave the CIO an export of all the Demands for him to have in his back pocket. We're not sure if they will have the time to dig in and do some prioritization, but the information is ready & available if they are ready!

UAT:

UAT is finished for Incident & Problem, but next week we'll be kicking off a brief second round of UAT to test the fixed functionality. This time, I'll include some education on what is UAT, what is a bug, and how Knowledge works.


Creative Incident module Rollout Plan:

Since we know it will take longer to roll out our new Centralized Service Desk than it will take to set up our Phase 1 modules in ServiceNow, and we're anxious for a few I.T. teams to start using some functionality, we decided that 3 of our I.T. teams will start using the SN functionality (basically Incidents, and ServiceCatalogue items that only have workflow within I.T.) when we're ready for Phase 1 modules to go live. This will only be used internally in I.T. — our end users will not be impacted yet.   We're happy at least a few I.T. groups will get to start using ServiceNow while we're waiting for the new Centralized Service Desk to be set up!

Administrative Changes:

We are now having our internal SN Admin manage granting access in our SN instance, and she is now also doing the minor field changes for the Demand & Problem module. She reaches out to our implementation consultants when she needs training/assistance.

3 Comments