Kelly's PPM Blog Post #2

[kellykaufmann]

SN Blog post 2

We all survived meeting-palooza for our ServiceNow (SN) planning sessions. Last week I posted the meeting itinerary - 3 complete working days of sessions in one week. I was happy to see that our organization gave this project the respect it deserves by flying some of our employees in for these sessions to make sure the right areas were represented (which took a lot of coordinating, to ensure we had representation from each IT area within the main company + the new acquisitions), and at the same time we made sure we were cautious to keep the group size small enough to get decisions made.

Monday was our full-day 'assessment' session with just the 'core' group of 7 IT directors, plus the SVP of IT, our SN admin, myself, and our 2 consultants from AOS.   In that meeting, our objective was to make sure our core group had a solid enough understanding of SN's modules to make a final decision on which SN modules we would implement in which phases. When the session began, we had a general idea of what would be implemented when, but after a little bit of shuffling back & forth, we added a few modules to our original Phase 1 list. Here's the plan:

• Phase 1: Incident Mgmt, Problem Mgmt, Service Catalogue & Request Mgmt, Knowledge Mgmt, Timecards, and 'Project Lite'.
• Phase 2: Change Mgmt, Asset Mgmt, Config Mgmt (CMDB)
• Phase 3: SDLC, Project, Resource Mgmt, Release Mgmt

Of course, I'm excited that my friendly pleading was appeased and that I'll get at least 'Project Lite', since they weren't planning on doing ANYTHING with Project or SDLC until Phase 3. 'Project Lite' in SN will really just be the Project module showing only the project name, short description, start date, planned go-live date, and end date. None of this requires any customizations, or really any complicated setup. It's actually just removing most of the content in the Project module now so as to not overwhelm or confuse our team, and let me start using it (this means no experimenting with creation of projects in this env't, or otherwise I'll just have to pay attention to which play projects are created, and will ask AOS to migrate this setup — minus the play stuff - over when going live).   Our SN Admin will get her feet wet with SN by setting up these fields, with the helping-hand of AOS as needed. This will give me a tool to organize in-flight projects, will allow me to start demonstrating value of the Project module to my peers & leadership, and I figured as the team or leadership is hungry to use more functionality, the request to expand 'Project Lite' will get strong enough that I'll be given the blessing to ask our SN Admin to work on adding those fields/functionality. Knock on wood that that happens soon! Ok I'll calm down now & get back to the other 99% of the focus for the week.

Highly integrated into our discussions on day 1 was our future-state centralized service desk (for which discussions had initiated maybe 2 weeks earlier, and is obviously not yet very far in planning), which had not yet been communicated to the department. And would need to be communicated prior to continuing discussions the rest of the week, as further discussions would rely on the assumption of this high-level plan. It didn't seem respectful (or time conscious) to kick off sessions by surprising new session attendees with the idea of a centralized help desk, while leaving the rest of the department in the dark. We weighed the challenge of not really having details to communicate and thus communication triggering speculation & possibly panic, with the fact that we need to communicate at least SOMETHING so everyone would have that same equal amount of limited plans created thus far and allow us to effectively continue our week's planning sessions. So at the end of Day 1, our SVP of IT sent an email to the department announcing that we're going to a centralized help desk (details pending) and had made progress on planning out SN.

In the other 2 days of planning sessions, AOS went through round after round of describing SN functionality, asking us about our needs, guiding us in making decisions (or in logging decisions that still need to be made), and reviewing with us our decisions.   We think we would have made more decisions if we didn't have such a massive group of people in some of the sessions — some of the decisions were really in-the-weeds eyes-crossing technical, but would really impact the level of effort for our consultants to implement the product but we didn't want to have a 30-minute technical discussion with everyone in the room, and some of the decisions were quite grand and not realistic/appropriate to corral a group of 20 people to make the decisions.

Here's how we handled the sessions: One of the AOS consultants led the session conversations, the other documented requirements & design impacts, and I documented decisions as they were identified (some of which had decisions to-be-made but not made yet). In the end, we ended up documenting ~ 115 decisions, and ended up making ~ 80 decisions. We agreed that, to save time & consulting $, I would organize sessions with our core team to discuss & make the ~35 remaining decisions. Our goal was to complete some decisions by the time AOS would need info to complete their SOW (in 2 weeks), and all the decisions within 3 weeks — in hopes that we would have a quick turnaround time for the SOW, and that AOS would be able to start the project in 3 weeks or so. So now I'll start planning the decision meetings, feeding decisions to AOS so they can finalize their SOW, and get back to my other projects!

For now, the team is a bit exhausted but is also excited about the decisions made and anxious to fast-forward two weeks to when the SOW is presented, signed, and we can get moving.