Kelly's SN implementation Blog Post #7

kellykaufmann · ‎08-26-2014

PPM Setup Updates

We just finished week 1 of 2 of our big scramble to get some PPM functionality set up (in what must be record time) to empower leadership to have more involvement in ranking the requested projects and to give them more transparency into the company's requested & in-flight I.T. projects.

Here's the activities we identified last Friday that would be necessary to set up Demand for prioritization & Project for showing high-level what's in flight (we listed this in the change order to move some of this scope from Phase 3 to now):

Set up Demand module for directly entering projects (I'll be the one to dump projects into there to start off with; we don't have time to train on filling out the survey & wait for the surveys to be filled out)
Identify DMND screen fields
Identify & set up criteria to populate the bubble chart
Identify bubble chart quadrants, etc. & set up bubble chart
Ability to have these 'ideas' turn into PRJ projects, with info from DMND to populate the PRJ
Set up CIO roadmap
Identify different categories to illustrate the projects
Guidance on leveraging SN's functionality to prioritize projects
Guidance on best use of SN's functionality to document project cost estimates at an individual level, and how to roll these costs up by a certain category
Teach our CIO & others from leadership on how to pull up & use bubble charts & the CIO roadmap for meetings
Set up the CIO's homepage, and some standard reports he might need

Our implementation consultant lead whipped up a Change Order & it was signed by the CIO end of day Friday. Talk about fast moving! The lead got me directly in touch with one of their developers who would be dedicated to helping us get Demand & Project set up these next 2 weeks for prioritizing projects. Haha they unleashed me. That poor developer didn't know what was about to hit him.

First thing Monday we met with the CIO & some directors and reviewed possibilities for criteria to plot requested projects (Demands) on the Bubble Chart. We had to do this ASAP so the teams had as much time as we could give them to gather this information for all their requested projects. We took a look at ServiceNow's built-in demo criteria (see attached spreadsheet for how I mapped this out) as well as Info-Tech's project prioritization tool, but recognized that that was a lot of criteria to gather in such a short amount of time. If we were going to capture information quickly for all our requested projects (about 60), we were going to have to keep it simple. We took that list and crossed out what we didn't think we were ready for yet, knowing that soon we'll take the next step in maturing and gather more information about each project request. It would be duplicate work, but it would allow us to meet our deadline and give us breathing room to take progressive steps. We ended up with an x-axis of 'Financial Return', a y-axis of 'Priority', and a bubble-size (z-axis) of 'Project Cost'. Hey, it's a starting point. We'll see where we end up once the bubbles are plotted! We also looked at what other information we need to capture about Demands & Projects for teams & leadership to do filtering for their areas, reporting, etc. Below is the information we decided to capture for all Demands & Projects. We had to define what would go in the Demand Management module vs the Project module. We decided that a Demand would be any requested effort not yet started, and a Project is an effort that is in-flight. Simple enough.

We also needed consistency in what we are calling a 'Project', so we know what the criteria is for it to be entered in as a Demand, assigned a project manager when approved, reported on, etc. I was really excited to be able to work on this definition as another step to mature the project/portfolio processes. I asked each of the different I.T. areas what their criteria is for something to be considered a 'Project', provided this info to the CIO, and asked him to be the 'tiebreaker'. We ended up with a I.T. 'Project' being an effort with >40-50 I.T. hours (and following PMI's other criteria to be considered a 'project'), and of course the allowance for exceptions. This is a pretty typical starting point.

Business Division: (our divisions)

Project Driver: (can be more than 1; We have each project driver mapped to be either operational or strategic.)

Mandate project
Strategic Initiative
Cost Saving project
Increasing Revenue project
Housekeeping project
Supporting the Business project
Advancing Technology project

Project Customer Type:

Vendor
Internal
Customer

I.T. Project Type:

Break/fix
Enhancement
New Functionality
New Business Setup
Move
Conversion
Acquisition Conversion
End of Support
Disaster Recovery

Priority: We used the priorities our App Dev team was already using, since we're short on time. We will refine our definition of 'priority' to be more objective after these 2 weeks.

Default, lowest priority
Valid request, but not terribly important
Good request of average priority
High priority that needs attention now
Highest priority — should drop everything to do this NOW

Level of Effort: used what they currently have, but we will definitely be changing this!

1 = 1 week of time or less — very easy

2 = 2 weeks or so of time — easy with twist or extra feature

3 = 1 month or so — moderate difficulty

4 = Several months or more — difficult

5 = lengthy project

I sent all these fields to the developer to start setting up, and met with the different I.T. teams to talk through their lists of requested & in-flight projects, sticking with our new 'project' definition, and reviewed all these fields to capture information about for their requested projects (Demands) & in-flight projects (Projects) (this started my education campaign on what's a 'Demand' vs a 'Project'). I put all the fields listed above into a Word doc and brought it to any related discussion so everyone was on the same page. It was really helpful to have this available to everyone in an easily accessible place. The different I.T. teams put these as column names in their spreadsheets where they would log their Demands & Projects so it would be an easy import into ServiceNow. Our developer quickly got this content set up in Demand & Project, and then as the different teams finished their spreadsheet of Demands & Projects with all this info, I sent it to our developer to import into the Demand Management module & Project module.

As we were discussing getting projects into the Guitar Hero-type visualization, I discovered that apparently there are two such visualizations in SN (one for Demands — "Demand Backlog", one for Projects — "CIO Roadmap")!! Our poor developer & I were having a huge misunderstanding about the setup of this visualization because he was talking about 2 different visualizations & I thought it was one visualization for Demands & Projects. Ha! Once we got on the same page, we were able to quickly get that set up. We did rename the CIO roadmap to be 'IT Roadmap' since this is a tool that won't just be used by the CIO, but by leadership of each business area, and by myself as well with different teams.

This was a lot of incredible work for one week. Next, we'll see how the projects were plotted on the Bubble Chart, we'll start running some reports, and will see where the information takes us!

UAT Updates:

Yes, while we had this PPM-mayhem, we had to keep UAT going for our Incident & Problem module setup. We had issues with one of our subsidiaries getting into SN (they are on a different AD). We put a temp solution in place for our UAT testers, but we need to resolve this by the time we go live.

Okay, some UAT lesson learned. I had made some assumptions regarding experience with testing, terminology, etc. That was a failure on my part.

If some of your UAT testers have never conducted UAT before, help them understand that they are testing against the test script, make sure you define what a bug is, and educate that bugs are to be opened against the test script. Either host a brief 15-minute UAT kickoff session to teach this, or define & explain UAT, bugs, etc. thoroughly in an email to the testers.
If some of your UAT members are not used to web-based apps, give them navigation and basic functionality guidance first. Even when you think they shouldn't need it for an intuitive tool. We ended up with a bunch of logged defects because people didn't understand that closing an incident meant selecting the 'closed' dropdown state for an incident and saving it, as opposed to typing 'closed' in a text box and saving it. They also desired to know how to 'save' (right-click & click 'save') vs 'update' (where it will save & bring you back to the prior menu). Secondly, people who aren't familiar with UAT may think they need to know all of the functionality to be able to do UAT, and therefore will feel frustrated not knowing what each of the 'state' dropdown menu items mean and when to use each, and people with more knowledge of SN but not an understanding of doing UAT will put in a bug for functionality not listed on the test script but that they think should be working at this point.
Have the Knowledge article process well defined & understood, and explain the process to the testers. You'll probably have Knowledge set up so when someone submits an article from an Incident, etc., that someone will review & refine it before it's posted in the Knowledge section. People in UAT will likely wonder why the Knowledge article doesn't show up right away when they create one and will probably create bugs for this.

We still don't have our final plan for SN to identify an employee's location or the org chart hierarchy. We're just manually entering this information for now for I.T.

We're quickly resolving any of the bugs the UAT testers documented (which are really features we forgot to enable, filters we accidentally turned on, etc.). We plan on doing a second round of testing once we have these bugs resolved.

Other updates:

We have a target go-live date for Phase 1. Since our Centralized Service Desk won't be stood up, our Directors decided that only a few teams will start using SN before our Centralized Service Desk is stood up. We need to have a few discussions to understand what specifically we can do that won't make us spend hours changing workflows.