Sorry, that's not in scope (and it's going to be okay)!

As ServiceNow Engagement Managers (EMs), we constantly battle the balance of delivering maximum value for our customers on our projects, while striving to stay within restricted timelines and often tight budgets. 

The teams that got through the sales process are all too often not the same teams that are in the workshops. This creates challenges for us as EMs who have to routinely reference back the approved scope in the SOW and the requirements we gather from the business users. 

As we know, ServiceNow projects are transformative by nature, often touching multiple departments and workflows across an enterprise. Trying to boil everything down to MVP can feel at times impossible, however there are some key tricks I find helpful in my day-to-day practice. 

Whether implementing ITSM, HRSD, CSM, or custom applications, success usually hinges on managing three critical pillars: scope, budget, and timeline. These elements are deeply interconnected, and misalignment among them can lead to delays, cost overruns, or unmet expectations.

Defining What Success Looks Like

Scope refers to the specific features, functionalities, and outcomes the project aims to deliver. In ServiceNow, scope can range from out-of-the-box module deployments to complex integrations and custom workflows. When balancing the team's wants vs needs, the more proactive we can be as EMs, the more time we save for our budgets. Setting the ground rules with teams clearly and staying consistent will help us immensely when we need to draw the lines of what gets into our scope and what must go into our backlog. 

Key Considerations:

• Business Objectives: Align scope with strategic goals, not just technical requirements.
• Minimum Viable Product (MVP): Focus on delivering core value early, then iterate.
• Change Control: Establish a governance model to manage scope creep effectively.

Pro Tip: It is perfectly okay to say (and say often) “that is not in our scope of this project”. When possible, simply capture the requirement/idea, and begin building a backlog for future enhancements. 

This is usually an excellent opportunity to remind our customers that the idea of CRAWL>WALK>RUN>FLY is a best practice for a reason.