In my role as a Tech Lead here at Aptris, I work on projects for a large variety of customers, essentially overseeing the technical aspect of the solution we deliver.
Having been through a multitude of projects for customers large and small, and even using different platforms (I did have a life before ServiceNow! ?), I’ve learned that there are some technical/architectural aspects of projects which, if neglected, can negatively influence the project outcome.
With ServiceNow’s London release, if you don’t already have a project on your hands, you’re likely to have one very soon. Whatever your very next ServiceNow release is, consider these five tips to avoid the pitfalls and help ensure its (and your) success.
1. Get PermissionIf your organization doesn’t have a Change Management process that governs ServiceNow, be sure to seek permission from the affected stakeholder(s). Doing so helps ensure the right level of oversight and will minimize the risk of failure or re-work.
2. Set Your Sights on the TargetTry to understand exactly what you are asked to build. Keep asking questions until you fully understand the boundaries of your project. Not knowing the boundaries means you may not know the full functionality you’re expected to deliver, or where to draw the line on new requests for functionality.
3. Leverage the Standard ConfigurationAs much as possible, take advantage of what ServiceNow provides out-of-the-box. Before taking any design direction, ask yourself: “is there any way to make this less complex?” Remember that complexity increases the level of effort needed to maintain the system. Also, consider solutions that don’t involve as much configuration. For example, instead of adding a ton of fields to the Incident form for the Service Desk to fill-in and then creating UI policies to show/hide, consider using a pre-populated Description field. Better yet, consider using checklists. Here is some great documentation on ServiceNow checklists from the London release.
4. Be Wary of Scope CreepAn important skill to bring to any project is the ability to say “no” to some new feature requests. This may initially seem counter-intuitive, and it is not as easy as it sounds. Not being able to limit requests will negatively impact both your budget and the level of effort needed to administer the system afterward.
Remember: Simpler is Better.
From my experience, controlling what gets into a project increases my ability to deliver the features and value my customers really need, while giving project stakeholders the information they need to reject or redirect new feature requests. Ultimately, it’s all about keeping costs and complexity in line.
5. Don't Be Too Haughty to Ask for HelpDespite my role as Tech Lead in most of my projects, I never assume I know more than the developers I work with. Of course, I need to try to understand the key concepts in many areas, but I’m always open to hearing different views and opinions, even if I have the final say in the end. I have no problem asking “stupid” questions if it helps solidify my understanding and increases the quality of my delivery.