New Installation, Looking for Implementation advice

skipmackenna · ‎01-26-2017

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.

jnovack · ‎01-27-2017

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.

View solution in original post

lks · ‎01-27-2017

These are very generic question Mac and a bit difficult to answer here. I am expecting you might have attended ServiceNow Implementation Boot camp which explains some best practices in this regard and covers all the topics you mentioned above.

Chuck Tomasi · ‎01-27-2017

FYI -

Training: Implementation Bootcamp

skipmackenna · ‎01-27-2017

Thanks for the reply. The most important question is 'what can become a big issue during implementation?', which all of those questions are a subset of. All the training that will be purchased, has been purchased. So, I am looking for answers here, one at a time. From your answer I glean that these are best practices and assume a 'Yes' would be appropriate on each.

lks · ‎01-27-2017

I am sorry Mac, it's difficult for me to give you any further advice because people and requirements differ customer to customer. Some times it is functional requirements which keep on changing and causing issues/delays irrespective of technical capabilities. So, what max I can say is that you better categorize your work/requirements (give preference to SCRUM) and stay focused on actual requirements so that you can complete them on time.