Using SLAs to track Project Cost Consumption in ServiceNow SPM – does it make sense?

[jordimsant]

Hello ServiceNow Community,

I’m currently working on an SPM implementation and one of the requirements is to enable SLA-like monitoring for project cost consumption, in a similar way to how SLAs are used today to track (for instance) incident duration.

The idea would be something like:

• Define thresholds based on project budget consumption (e.g. 50%, 75%, 100%)

• Trigger notifications when those thresholds are reached

• Use the SLA framework (or a similar mechanism) to report and analyze projects that did not “meet” the defined cost SLA (e.g. exceeded budget without approval)

Conceptually, this would treat cost consumption as the measured condition instead of time, but with similar needs around notifications, breach tracking, and analytics.

Before going too far down this path, I wanted to ask the community:

• Does it make sense to model this using the SLA framework in ServiceNow?

• Has anyone implemented something similar for project cost or budget control?

• Would you recommend an alternative approach instead of SLAs?

Any experience, best practices, or lessons learned would be greatly appreciated.

Thanks in advance!

[Uncle Rob]

I'd advise against for something you already mentioned:  SLA's are engineered for TIME progression.  That's its VITAL ESSENCE.... the core around which all other SLA functionality was built.
To build an alternative vital essence is going to cost you MORE than simply building a custom solution.
1)  You have to back-engineer SLAs
2)  You have to build your own SLA logic and interfaces
3)  You have to ensure you didn't compromise how all other SLAs function.

4)  You have to ensure people who come after you know SLA's have been altered in this fashion (I'd wager less than 10% of customers document things of such gravity)

It would be better to build out a different solution specific to this use case since the vital essences differ so greatly.   It doesn't seem that difficult with Flow Designer.

[AndersBGS]

Hi @jordimsant ,

I completely agree with @Uncle Rob @and would also advise against it. The OOTB SLA is about time logic / time consumption - no matter if we talk about OLA, SLA or underpinning contracts. Rather design the solution to a fit for purpose instead of trying to make an OOTB solution work for something it isn’t meant to work for.