Starting a ServiceNow Team – What Should We Get Right Early?

[AdnanB_]

Hi all,

We’ve recently started building a small ServiceNow capability team (7 people, structured roles – BA, admin, TPM, developer), currently in early training and certification phase.

Our goal is to grow into a reliable delivery partner over time.

I’d be interested to hear from more experienced ServiceNow practitioners and partners:

– Where do you typically see the biggest bottlenecks in delivery teams?
– Which roles are hardest to scale or find?
– What do you wish junior teams understood earlier?
– How do smaller or emerging teams typically get their first real exposure to projects or delivery environments?

Appreciate any insights from the community.

[JenniferRah · Accepted solution]

Here are a few things, in brain dump order. 🙂

Make sure your BAs are technical. If they aren't, they will struggle to gather accurate requirements for the developers. Then your developers will have to be heavily involved in requirements gathering and will spend less time doing actual development work.

I'm not sure how many of each role you have, but the longest process is the analysis, so you will need multiple BAs per developer. 

It's best not to have just one developer so that they can back each other up. That might mean your admins double as developers if you don't have staff to have multiple developers at first.

Document things in KB articles for users as much as possible to help with user training and troubleshooting common issues.

If you have the staff to do it, train your users. There is a learning curve to ServiceNow. If you can help users over that learning curve, they will be happier with the tool, and you will have fewer support issues.

Err on the side of keeping things as OOTB as possible. You'll be glad of that when you do upgrades. 

[AdnanB_]

Hi Jennifer,

This is extremely helpful – really appreciate you taking the time to share this.

We’ve initially been structuring roles based on our own assumptions, and our thinking was that BAs wouldn’t necessarily need to be deeply technical. Your point definitely challenges that and gives us a different perspective.

Also, very valuable insight regarding analysis being the longest part – that definitely shifts how we think about team composition early on.

One thing we’re also trying to better understand, especially in the context of everything you mentioned around delivery structure — how do smaller or emerging teams typically get their first real exposure to projects or delivery environments?

Thanks again – this is exactly the kind of practical perspective we were hoping to get.

Adnan B.

[JenniferRah]

Our experience was largely on the job, learning as we went along. Ideally, you would start with at least some people who already have some knowledge of ServiceNow, but we didn't have that luxury.

We did have a few groups that came in as implementers (contracting companies that implemented specific modules), and we tried to get as much information from them as possible, which was helpful.

If you're in that same boat, the ServiceNow online community is invaluable! Having a PDI (Personal Development Instance) and resource of people to ask questions of and search for things that have already been answered has saved me countless hours, personally. 

[AdnanB_]

Hi Jennifer,

This is extremely helpful – really appreciate you taking the time to share this.

We’ve initially been structuring roles based on our own assumptions, and our thinking was that BAs wouldn’t necessarily need to be deeply technical. Your point definitely challenges that and gives us a different perspective.

One thing we’re also trying to better understand, especially in the context of everything you mentioned around delivery structure — how do smaller or emerging teams typically get their first real exposure to projects or delivery environments?

Thanks again – this is exactly the kind of practical perspective we were hoping to get.

Adnan B.