SPM Implementation Overview
About 2% of the CIS-SPM exam — see all 10 domains.
High-level implementation lifecycle and methodology: scoping the SPM rollout, the recommended crawl-walk-run adoption (e.g., start with Project/Demand, then Resource, then Financials, then Agile/Strategic Planning), plugin/store-app activation order and dependencies, persona/role setup, and Now Create implementation guidance. Understand prerequisites (e.g., installing Project Workspace and Resource Management Workspace before strategic capacity planning).
Sample questions from this domain
Three of the 6 in this domain, with the reasoning. The full set is in the question bank.
During a ServiceNow SPM implementation, which activity best aligns with the Now Create methodology phase that occurs before any configuration begins?
- A. Configuring time sheet policies and the project time approver
- B. Loading historical projects and time cards into the new tables
- C. Defining the project's scope, stakeholders, and success criteria ✓
- D. Building cost plans and labor rate cards for each active project
Why: Now Create front-loads scoping and alignment, so defining the project's scope, stakeholders, and success criteria comes before any configuration begins. Configuring time sheet policies and approvers, loading historical projects and time cards, and building cost plans and labor rate cards are downstream build, configure, and data migration activities, not pre-configuration alignment work.
An implementation specialist needs to enable the core Strategic Portfolio Management capabilities (Project, Demand, Resource, and Portfolio management) on a new instance. What is the recommended approach?
- A. Activate the relevant SPM plugins/store applications, which install the baseline data model and modules ✓
- B. Clone a production instance that already runs SPM, then reuse its tables and modules as the baseline
- C. Import update sets exported from another customer instance to create the SPM tables and modules
- D. Build the project, demand, and resource tables in a custom scoped app with Studio, then add modules
Why: SPM capabilities are delivered as plugins and store applications that install the baseline tables, modules, and configuration, so activating the relevant applications is the supported enablement path. Cloning a production instance, importing update sets from another customer's instance, and hand-building the tables in a custom scoped app all bypass the supported installation and leave you with an unsupported, hard-to-upgrade data model.
Which two considerations are most important when sequencing the activation of SPM applications during an implementation? (Choose two)
- A. Dependent applications (e.g., Resource Management Workspace on top of PPM Standard) should be activated in dependency order ✓
- B. Activation order has no functional impact, because each SPM plugin installs its own copy of any shared tables
- C. Activating a plugin on production is irreversible, so plan and test in a sub-production instance first ✓
- D. Activate the full set of SPM plugins together in production so the shared tables are created in a single transaction
- E. Raise a ServiceNow Support case for each SPM plugin, since customers are not permitted to activate store applications
Why: Application dependencies dictate activation order (for example, Resource Management Workspace needs its required applications installed first), and because plugin activation generally cannot be undone, you validate in a sub-production instance first. Order does matter, because SPM plugins share and depend on one another's tables rather than each installing a private copy. There is no requirement to activate the whole set together in production (doing so skips sub-production testing), and customers can self-activate most plugins and store applications without a Support case.