Stop me if you have heard this before…you put a lot of time and effort into convincing your organization to purchase access to the ServiceNow PaaS. In your business case, you stressed the rapid improvement and gained efficiencies for some or many of the internal processes when enabling them on ServiceNow. The license agreement has finally been signed with ServiceNow and you have also agreed to bring in a ServiceNow Partner as a Third-Party Implementer. Then over the next 60-90 days, you find you will not have enough licenses – the Process Owners want wholesale changes made before going live – no one thought about making sure training was included – there is a wide list of perceptions for what will be in place at go-live with only some being true – how could such chaos have been prevented?

As much effort is required to stand up and make “live” a ServiceNow instance, the work that should be done before endorsing an agreement for ServiceNow licenses or Third-Party Partner Implementation is crucial to the platform’s perceived success, flexibility and usefulness. Once the agreements are signed (particularly the license agreements), the clock is already ticking down and any re-work or rationalization that must be done will cost valuable time and place a higher risk on making any committed go-live dates 

While you may be fighting the battle to get an organization to make the financial commitment for ServiceNow, your perceived success will be much more likely if you ensure the agreements are structured carefully. All vendors start with a template agreement. Here are some points that should be considered before signing on that dotted line:

• Define the Implementation Scope and Success Criteria for initial “go-live”. All elements of the ServiceNow and Implementer agreements must be measured against these before agreeing to them. It helps set expectations before the project kick off.
• Ensure every process or workflow that is to be enabled on ServiceNow has a defined Process Owner. More than a few organizations have tried to define these Process Owners in parallel with or even after the platform is live leading to incomplete, broken or useless processes. These Process Owners should drive all minimal required configurations and customizations for the platform to be considered live. All agreements should then be defined based on these requirements.
• Define the full User base and their expected interaction with the platform. Have a defined and documented matrix of number of Users who will require basic access (through a Portal) versus full access (requiring read/write/query to ServiceNow records). The tool has strictly defined platform User capabilities tied to the licenses. All considerations should be conservative while also taking growth into account. It is rare that a ServiceNow platform has too few licenses. If the proper number is not projected before the agreement is in place, it could lead to unplanned budget variances or a cut back on committed functionality and access.
• Map all minimal process requirements with those in the Third-Party Agreement deliverables. Will they match and if they do not, there must be a defined approach for who and how the gaps will be addressed. A typical “Template Implementation” will deliver something like 5 workflows of “medium complexity”. Many times, at least one workflow enabled is high complexity.
• Consider some often-neglected required work critical to the success of the platform go-live such as Testing and Training. Many Implementers have defined assumptions and expectations for Testing by the customer as part of their agreement to a timeline or expected deliverable. Implementers also sometimes include some basic Training materials as part of their deliverables. These should be measured against expectations for the entire User base and if it would fit the needs before the platform goes live (many Implementers address Training last in their timeline). 

The work done before pen is put to paper on the agreements is equally (and sometimes critically) important as the actual work to stand up the platform. Promises you define are promises you can keep.

About John Sheehan:

John.Sheehan@morristechnologysolutions.com