New Installation, Looking for Implementation advice

[skipmackenna]

Hi All,

I am a PM implementing ServiceNow for the state of SC.   It seems fairly straight forward, I am always looking for the 'unknown' issues.   I am wondering if you could tell me from your experience:

• What did you do for testing when you first implemented?   (not just story tests)
• Did you do Business Use Cases and a repeatable Regression Test?
• Did you have issues populating the configuration data (i.e. Categories and Sub Categories)?
• Did you purchase the Database encryption?
• Did you implement in phases?
• Has your use matured in iterations?
• Did you have any costly mistakes you could give me a head-up on?

I appreciate your responses, thanks.

[skipmackenna]

That is the kind of advice I am looking for.   See my role is a Project Manager, I don't actually do the work, I just track the progress ( I do get somewhat technical ) and try to make sure all the requirements are captured, and implemented, and work as intended...   Thanks for this reply.

[jnovack · Accepted solution]

We are a local casino finishing up our implementation.   We have implemented Incident Management, and to lesser percentages, Problem, Change, Knowledge and CMDB.

> What did you do for testing when you first implemented?   (not just story tests)

Story tests were not useful for us.   We had an "idea" how people would use it, based on their use of other systems.   Our implementation changed plans many times because once we got INTO the system, we realized it wasn't LIKE the other systems, so we needed to drop that idea framework.

We brute forced through it because we could afford the resources to do so.   We got teams in it, we made mistakes, we corrected them.   All before going live.   Plan flew right out the window.

> Did you do Business Use Cases and a repeatable Regression Test?

A what, a what and a what?

> Did you have issues populating the configuration data (i.e. Categories and Sub Categories)?

YES.   Every section/department thinks they are important and need 10+ different sub-categories.   We were implementing primarily Incident Management, which is primarily an Operations role, so Categorization was from the "user's standpoint" not from "solution standpoint".   You will get burned at the stake for picking either method by the other 50%.   It's like Republican vs Democrat.

Categories were "user perceived issues".   Performance (Limited, Down), Functionality (Error Message, Didn't Work), Data (Missing, Wrong), Access (Was Denied, Password Change).   We wanted to track WHY people were calling, not categorize the incident based on the solution that was provided (i.e "Database -> Needed Indexing").   How was a user supposed to know that?

To appease the other side of the aisle, under the "Closure Information" section, we gave them their plethora of lists so they can run their reports.

> Did you purchase the Database encryption?

Negative.

> Did you implement in phases?

Our "implementation" to the non-IT teams was all-at-once.   We phased the IT deployment internally on the test-instance.   We started with our SysAdmins, as they were the most "nimble", then Help Desk, then Technicians, then peripheral support teams (Security, Development) etc.   I did not deploy to the "less technical savvy" IT departments until we had the implementation 90+% complete.

> Has your use matured in iterations?

YES.   As I teach a new section or department how to use it, I have found better ways to do things.   As I found efficiencies and The Right Way(tm) to do it, our forms and workflows have changed with it.

> Did you have any costly mistakes you could give me a head-up on?

Planning was a mistake. We spent a lot of time developing use cases and planning based on older systems.   ServiceNow is different.   We USE it differently than we used a ticketing system. I'm not suggesting you don't plan. It just didn't work for us.

Have -3- instances AT A MINIMUM!   And be VIGILANT on Update Set Management.   PROD, TEST, and DEV.   PROD should clone down to TEST every 1-2 weeks (depending on the vigor and fervor of your development team).   PROD should(tm) clone down to DEV after every major revision and release of application or development.   Cloning means changes are lost, so make sure your Devs save their update sets down before clone, and push up after.   This keeps it CLEAN.   Only your hardcore devs should be on the DEV box (as it's costly), and only the IT group should be in TEST.

[skipmackenna]

Hey Justin,

Thanks for taking the time to document your journey - that was the kind of response I was looking for.   Great heads up.   We are planning, but with flexibility and not too much time in the 'rigor', so you eased my mind there.   The Technical users defined the Stories for use, and only our IT department help desk will use our first implementation.   So, I think your answer gives me a lot of useful information.   DEV, TEST and PROD, and Cloning back down, we are using as our best practice.

The categories and sub-categories are coming from a history of our prior/legacy system - sorted, categorized and analyzed for over 30k tickets.   We will remain flexible and plan to implement the other modules in phases.   Similar but different implementation, but your info is very useful, THANKS!

[victoriarb]

The aforementioned Implementation Boot Camp is scheduled in Atalanta on June 19th - 23rd which may be extremely useful. I will be attending June's Boot Camp. Perhaps I will meet you there.

There is also a video on YouTube that I found to be informative at [Webinar] How to drive a successful ServiceNow implementation? - YouTube .

Good luck with your implementation.