Direct navigation: 12/12 documented All > ... paths linked to this ServiceNow instance.

SPM — Professional Implementation from Scratch to Production

Release baseline: ServiceNow Australia (current GA · Sep 2026)
Audience: Professional Implementers · Platform Admins · Developers · Product Owners · Test Leads
Instance token: {BASE} = https://YOUR_INSTANCE.service-now.com
Related module encyclopedia: ../SPM.md
All implementation guides: INDEX.md

0. Outcome and guardrails

Strategic Portfolio Management: Translate strategy into funded demands, portfolios, programs, projects, resources, costs, benefits, roadmaps, and measurable outcomes.

• Confirm product entitlement before plugin activation.
• Build and test in sub-production/PDI; never activate major plugins first in production.
• Prefer out-of-box process/configuration before custom scripts.
• Use Flow Designer for new automation; maintain legacy Workflow only when required.
• Protect data with roles, ACLs, groups, criteria, and persona-based tests.
• Australia is the deployment baseline; Brazil preview/EA is not the production baseline unless your organization explicitly validates it.

1. End-to-end operating model

Discover → Design → Configure → Integrate → Secure → Test → Deploy → Operate → Improve

Module lifecycle: Strategy / Goal → Idea → Demand scoring/approval → Project / Epic → Program / Portfolio → Resource & Cost Plans → Delivery → Benefits / Outcome tracking

2. Discovery workshops and scope

Run these workshops before configuration:

3. Licensing, plugins, and release readiness

Expected products/plugins: Strategic Portfolio Management; Demand Management; Project Portfolio Management; Resource Management; Financial Planning; Agile Development; Strategic Planning (licensed)

1. Open Plugins.
2. Confirm entitlement with ServiceNow account/product owner.
3. Activate in a non-production instance.
4. Review activation logs and newly created roles/modules.
5. Capture configuration in a named Update Set where supported.
6. Confirm Australia release/build at System Stats.

4. Roles, groups, and security model

Typical roles: sn_ppm_read, it_project_manager, demand_manager, portfolio_manager, resource_manager, timecard_user, financial_admin

Professional rules:

• Roles → Groups → Users; avoid direct role grants.
• Separate admin/configurer, manager, fulfiller/agent, requester, auditor, and integration personas.
• Test table, row, and field access with impersonation.
• Never treat UI visibility as security; enforce ACL/criteria.
• Record privileged access and quarterly access review.

5. Foundation configuration sequence

1. Create reference data and ownership groups.
2. Configure states/models/templates before automation.
3. Configure assignment/routing and schedules.
4. Configure SLAs/entitlements where applicable.
5. Configure notifications and knowledge.
6. Configure workspace/portal/mobile experience.
7. Configure integrations and system properties.
8. Build reports and dashboards.
9. Build ATF and UAT packs.
10. Complete deployment/rollback runbook.

6. All component pages and direct URLs

Enter your instance once in the HTML header; every {BASE} link then opens the correct page in that instance.

7. Module configuration tutorial

1. Open each component in the order shown in §6.
2. Create minimum viable reference data and one happy-path record.
3. Configure state transitions, assignment, approvals, notifications, and SLAs.
4. Validate agent and requester experiences using different personas.
5. Add exception paths: rejection, reassignment, cancellation, timeout, integration failure.
6. Keep customization decisions in an OOTB-vs-config-vs-custom register.

7.1 Complete settings and configuration control matrix

Use this as the minimum configuration workbook. Add product-specific rows discovered during workshops; do not leave a changed setting without an owner and test.

Configuration rule for SPM: record OOTB default, approved value, owner, rationale, environment, transport method, and test case for every changed setting.

7.2 Component-by-component hands-on labs

Complete every lab below in a non-production instance. These labs cover every module-specific page listed in §6.

Component Lab 1 — Ideas

Purpose: Capture innovation
Navigator: All > Innovation Management > Ideas — Open direct
Direct: Open Ideas

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-01 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Capture innovation.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 2 — Demands

Purpose: Evaluate and fund work
Navigator: All > Demand > Demands — Open direct
Direct: Open Demands

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-02 where the component supports records.
4. Configure ownership, dates, scoring/status, financial/resource data, approvals, and dependencies.
5. Reconcile schedule, resource, cost, and benefit rollups.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 3 — Projects

Purpose: Plan and deliver
Navigator: All > Project > Projects — Open direct
Direct: Open Projects

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-03 where the component supports records.
4. Configure ownership, dates, scoring/status, financial/resource data, approvals, and dependencies.
5. Reconcile schedule, resource, cost, and benefit rollups.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 4 — Project Tasks

Purpose: WBS execution
Navigator: All > Project > Tasks — Open direct
Direct: Open Project Tasks

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-04 where the component supports records.
4. Configure ownership, dates, scoring/status, financial/resource data, approvals, and dependencies.
5. Reconcile schedule, resource, cost, and benefit rollups.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 5 — Programs

Purpose: Coordinate projects
Navigator: All > Program > Programs — Open direct
Direct: Open Programs

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-05 where the component supports records.
4. Configure ownership, dates, scoring/status, financial/resource data, approvals, and dependencies.
5. Reconcile schedule, resource, cost, and benefit rollups.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 6 — Portfolios

Purpose: Govern investments
Navigator: All > Portfolio > Portfolios — Open direct
Direct: Open Portfolios

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-06 where the component supports records.
4. Configure ownership, dates, scoring/status, financial/resource data, approvals, and dependencies.
5. Reconcile schedule, resource, cost, and benefit rollups.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 7 — Resource Plans

Purpose: Capacity demand
Navigator: All > Resource Management > Resource Plans — Open direct
Direct: Open Resource Plans

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-07 where the component supports records.
4. Configure ownership, dates, scoring/status, financial/resource data, approvals, and dependencies.
5. Reconcile schedule, resource, cost, and benefit rollups.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 8 — Allocations

Purpose: Committed capacity
Navigator: All > Resource Management > Allocations — Open direct
Direct: Open Allocations

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-08 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Committed capacity.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 9 — Time Cards

Purpose: Actual effort
Navigator: All > Time Sheet > Timecards — Open direct
Direct: Open Time Cards

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-09 where the component supports records.
4. Configure ownership, dates, scoring/status, financial/resource data, approvals, and dependencies.
5. Reconcile schedule, resource, cost, and benefit rollups.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 10 — Cost Plans

Purpose: Planned/actual costs
Navigator: All > Financial Management > Cost Plans — Open direct
Direct: Open Cost Plans

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-10 where the component supports records.
4. Configure ownership, dates, scoring/status, financial/resource data, approvals, and dependencies.
5. Reconcile schedule, resource, cost, and benefit rollups.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 11 — Agile Stories

Purpose: Agile delivery
Navigator: All > Agile Development > Stories — Open direct
Direct: Open Agile Stories

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-11 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Agile delivery.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 12 — Strategic Planning

Purpose: Roadmaps and outcomes
Navigator: All > Strategic Planning — Open direct
Direct: Open Strategic Planning

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-12 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Roadmaps and outcomes.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

8. Integration architecture

Finance/ERP actuals; HR resource master; Agile/DevOps delivery; ITSM change/release; enterprise architecture; procurement/vendor costs.

For every interface define:

Direct: Scripted REST · REST Messages · Connections

9. Reporting and Performance Analytics

KPIs: Strategic alignment, demand cycle time, funded vs requested, on-time/on-budget, resource utilization, forecast accuracy, benefit realization, portfolio health.

1. Build operational reports first.
2. Create role-based dashboard.
3. Add PA indicators/targets only when licensed and historical trend is required.
4. Validate report sharing and underlying ACLs.

Direct: Create Report · Reports · Dashboards · PA Indicators

10. Testing strategy

Direct: ATF Tests · ATF Suites

11. Deployment from development to production

1. Freeze scope and configuration.
2. Peer-review Update Set/App Repo contents.
3. Promote to test; Preview before Commit.
4. Resolve collisions deliberately.
5. Run ATF, security, integration, and UAT evidence.
6. Prepare data migration/cutover and communications.
7. Approve change record and rollback plan.
8. Deploy in agreed window.
9. Execute smoke tests and monitor.
10. Handover support ownership/runbooks.

Direct: Local Update Sets · Retrieved Update Sets · Upgrade History

12. Hands-on implementation lab

This full lab program covers platform readiness, security, all settings, module configuration, exception handling, experience, integration, data, reporting, testing, deployment, and operations.

Lab 0 — Instance and release readiness

1. Confirm Australia build at System Stats.
2. Verify entitlement/dependencies at Plugins.
3. Create Update Set LAB-MODULE-FOUNDATION.
4. Record baseline screenshots/properties and rollback owner.

Lab 1 — Personas, groups, roles, and security

1. Create requester, fulfiller/agent, manager, admin, auditor, and integration test users.
2. Create functional groups and grant roles to groups.
3. Build the role/access matrix and validate it through impersonation.
4. Test one unauthorized read and one unauthorized update.

Direct: Users · Groups · Roles · ACLs

Lab 2 — Module core happy path

Execute these module-specific steps:

• Create strategic goal and idea; promote to Demand.
• Configure demand scoring and stakeholder assessment.
• Approve demand and create a Project with WBS/milestones.
• Add cost plan, benefit plan, resource plan, and allocations.
• Submit time cards and update project status/risk/issues.
• Place project in Program/Portfolio and publish an executive dashboard.

Lab 3 — Settings and exception paths

1. Complete every row in the settings workbook (§7).
2. Test missing mandatory data, invalid transition, reassignment, cancellation, rejection, timeout, and reopen.
3. Verify fallback assignment and ownership when no rule matches.
4. Confirm system properties differ correctly by environment.

Lab 4 — Automation, SLA, and notifications

1. Create/validate Flow trigger and all branches.
2. Configure approval timeout and escalation.
3. Validate SLA start/pause/resume/stop and breach.
4. Validate event registry, notification conditions, recipients, and email log.

Direct: Flow Designer · SLA · Notifications · Email Log

Lab 5 — Workspace, portal, and mobile

1. Configure persona lists/forms/actions.
2. Publish requester content/service where applicable.
3. Complete one end-to-end transaction as requester and fulfiller.
4. Validate accessibility, empty state, error state, and mobile behavior when licensed.

Lab 6 — Integration and migration

1. Define contract/schema, correlation key, authentication, and ownership.
2. Configure Connection Alias/Credential and environment property.
3. Test success, invalid payload, unauthorized, duplicate, timeout, retry, and replay.
4. Load a small migration file; validate coalesce, rejects, and reconciliation.

Direct: REST Explorer · Scripted REST · REST Messages · Transform Maps

Lab 7 — Reports, dashboard, and PA

1. Build volume, backlog, aging, SLA/target, exception, and trend reports.
2. Build manager/agent/executive dashboard variants.
3. Validate sharing roles and source ACL behavior.
4. If licensed, configure PA indicator source, collector, breakdown, target, and widget.

Lab 8 — ATF, UAT, and regression

1. Create smoke suite for create, route, progress, resolve/close.
2. Add security negative tests and core exception branches.
3. Execute UAT by persona and link defects to scenarios.
4. Export pass evidence and define upgrade regression suite.

Lab 9 — Deployment and hypercare

1. Preview Update Set in test and resolve all collisions.
2. Run ATF/UAT/integration/security checks.
3. Execute approved change and production smoke tests.
4. Monitor 24–72 hours; document defects, owners, SLA, and rollback decision.
5. Handover admin guide, fulfiller guide, dashboard, and support runbook.

Lab evidence: screenshots, record numbers, test-user results, Update Set, ATF result, dashboard, and rollback note.

13. Production operations

• Daily: queue/backlog, failures, SLAs, integration errors.
• Weekly: aging, throughput, exceptions, knowledge gaps.
• Monthly: KPIs, adoption, automation candidates, access exceptions.
• Quarterly: role review, retention, controls, upgrade readiness.

14. Definition of Done

• [ ] Entitlement/plugins and Australia compatibility confirmed
• [ ] Every §6 component lab completed with evidence
• [ ] Every §7 settings row has approved value, owner, transport, and test
• [ ] Signed scope, process, data, security, integration, KPI decisions
• [ ] Roles granted through groups and negative security tests passed
• [ ] Reference data, process, routing, SLA/entitlement configured
• [ ] Workspace/portal/mobile experience validated as applicable
• [ ] Integration controls and failure handling tested
• [ ] Reports/dashboard accepted by product owner
• [ ] ATF smoke + UAT + performance checks passed
• [ ] Deployment, rollback, support, and monitoring runbooks approved
• [ ] Knowledge transfer and operational ownership completed

15. 30/60/90-day maturity roadmap