Best way to model project lifecycle in ServiceNow SPM

[jordimsant]

Hello everyone,

I’m currently working on an SPM implementation and I’m trying to understand the best way to represent my client’s real project lifecycle in ServiceNow.

At a high level, their projects follow this process:

1. Project requirements are gathered

2. The project is reviewed and approved

3. The project is planned

4. Project execution starts

5. During execution, two things can happen:

   • Everything goes as expected and tasks are completed until project closure

   • The project deviates significantly from the initial requirements, in which case requirements are redefined and the process effectively starts over again

So in practice, the lifecycle is not strictly linear and may loop back to an earlier phase (requirements) if major changes occur.

My questions are:

• How would you model this kind of logic in ServiceNow SPM?

• Would you recommend handling this with project states, stages, governance workflows, change requests, or even creating a new project/program when requirements change significantly?

• Are there any best practices or common patterns for representing this kind of iterative or “restartable” project lifecycle?

Any guidance, examples, or lessons learned would be greatly appreciated.

Thanks in advance!

[Matthew_13 · Accepted solution]

Hi Fellow,

 This is a pretty common situation i have seen in past, and you’re right to pause before trying to force it into a strictly linear model.

In ServiceNow SPM, it usually works best to separate the “normal flow” from the “exception”, rather than trying to literally loop a project back to the beginning.

Most teams model the happy path as a standard lifecycle (requirements → approval → planning → execution → closure) using phases or stages, and keep project “state” simple (in progress, on hold, closed). That keeps things readable and easy to report on.

When things change during execution, the key question becomes how big is the change:

• If it’s a moderate change (scope tweak, timeline shift, resource change), teams usually handle that through formal change control and re-baselining. The project stays the same, but the plan and approvals are updated so there’s a clear audit trail.

• If it’s a major change and the project is effectively starting over, most customers create a new project (or a new major phase/release) rather than rewinding the existing one. That preserves history and avoids one project turning into multiple different initiatives over time.

A lot of organizations also introduce a governance checkpoint during execution (for example, a scope or re-baseline review) where leadership explicitly decides: continue as planned, re-baseline, or stop and restart as a new project.

There isn’t a single “right” answer, but the common best practice is to optimize for:

• clarity for project managers,

• clean reporting at the portfolio level,

• and traceability of what changed and why.

At the end of the Day: don’t try to make the lifecycle loop endlessly. Use change control for iteration, and start a new project when the business outcome or scope fundamentally changes.

@jordimsant - Please mark Accepted Solution and Thumbs Up if you found Helpful!!