This is not an official U.S. federal government website.
The Federal Modernization Workbook is independent technical analysis. It does not represent the position of,
and has not been reviewed or endorsed by, any federal agency.
Projects
Projects
Sample project plans for the modernization program: work breakdown, schedule network, critical path, decision points and gates, ready to adapt and baseline
Sample PMP-style project plans for the Federal Modernization Program: the program’s integrated master schedule and one plan per complementary project, each with a work breakdown, a computed critical path, the decision points that hold it, gates with approvers and criteria, and downloads for Microsoft Project and Excel.
The books say what to do and in what order. These plans turn that order into schedules a project manager can baseline: every task with a duration, an owner and its dependencies, the critical path computed from the network rather than asserted, and the decisions that have to be made, by whom and by when, for the path to hold.
NoteSamples, not commitments
Every plan here is an illustrative sample built from the books. The durations are sized so the gates land on the weeks Book 01, Chapter 12 gives; they aren’t estimates for any agency. Replace them with the agency’s own numbers from its Phase 0 assessment, then baseline the result. The plans name roles, not people, and no specific agency.
The plans
| Title | Type | Built from | Weeks | Description |
|---|---|---|---|---|
| Program Master Schedule: Phases 0 to 5 and Gates G0 to G5 | Program | Books 00 and 01 | 48 | A sample PMP-style integrated master schedule for the Federal Modernization Program, built from Book 00, Chapters 05 and 09 and Book 01, Chapter 12: a work breakdown by phase and workstream, a computed critical path, every gate with its approver and criteria, and the intermediate decisions that hold the path, each with an owner, a decide-by week and the cost of deciding late. |
| Attribute-Driven Migration: The Cross-Track Attribute Foundation | Project | Books 01, 02, 03, 04, 05 and 07; the companion guide | 40 | A sample PMP-style project plan for the cross-track foundation of the Attribute-Driven Migration companion guide and its two technical deep-dive decks: reading the OU tree, the attribute schema and AD-to-Entra mapping, the coded extension-attribute slots, proving the attributes, sync, the dynamic group library with its guards, administrative units, Conditional Access personas, device and server targeting conventions, PIV and CAC binding, the mover proof, cut-over and the OU tree’s retirement, and drift. Handoffs to the track plans and the program’s gates are linked milestones with computed margins; every decision has an owner and a decide-by week. |
| Content Delivery Modernization: Distribution Point Consolidation | Project | Book 09, Chapter 11; Book 05 | 55 | A sample PMP-style project plan for the Content Delivery Modernization project, built from the Distribution Point Consolidation decision and implementation guides and Book 09, Chapter 11: Phase 0 analysis of the existing estate and decomposition of the funding ask, Stage 1 in a test hierarchy, a decision gate before money moves, a hub tier of pull distribution points, peer cache and boundary groups, office waves that retire branch distribution points, packaging on one standard wrapper, the content workloads moved to Intune, Connected Cache at the hubs, the five retirement gates and the cleanup of the last site roles, with owners and decide-by weeks for every decision and each task linked to its implementation step. |
| Continuous Monitoring & Evidence Fabric: Evidence From the Systems | Project | Book 13, with Books 14 and 15 | 23 | A sample PMP-style project plan for the Continuous Monitoring & Evidence Fabric project, built from Book 13, Chapter 12: a work breakdown by project phase, a computed critical path timed against the program gates measured from data, every gate with its approver and criteria, and the decisions (repository, severity, actuation ceiling, engine, cadence, reciprocity) with owners and decide-by weeks. |
| Data Platform Identity Transformation: SQL Server from Windows Authentication to Entra ID | Project | Book 06 | 48 | A sample PMP-style project plan for the Data Platform Identity Transformation project, built from Book 06 and its runbooks: a work breakdown by runbook phase, a computed critical path from the pilot instance to estate closure, every gate with its approver and criteria, and the intermediate decisions (consolidation verdicts, authentication standard, NTLM phase moves, connection-string cutover) with owners and decide-by weeks. |
| Endpoint & Device Modernization: Group Policy to Intune and Azure Arc | Project | Book 05 | 48 | A sample PMP-style project plan for the Endpoint & Device Modernization project, built from Book 05, Chapters 04 to 10: a work breakdown from observation to formal GPO retirement, with servers under Azure Arc as a phase of their own (onboarding waves, the tag taxonomy, the policy baseline and Update Manager), a computed critical path through the policy library and the four workload waves, a gate per phase with its approver and criteria, and the decisions (path, Windows 10 posture, cut dates, Arc onboarding method) with owners and decide-by weeks. |
| Identity Lifecycle & Provisioning: HR-Driven Identity | Project | Book 03 | 26 | A sample PMP-style project plan for the Identity Lifecycle & Provisioning project, built from Book 03, Chapter 12: a work breakdown by Book 03 phase, a computed critical path that shows why the HR feed is among the program’s most compressed tracks, every gate with its approver and criteria, and the intermediate decisions (enterprise identifier, contractor source, cutover populations) with owners and decide-by weeks. |
| Network & Access Modernization: Naming Plane, Governed Transport and Edge Enforcement | Project | Books 08 and 09 | 46 | A sample PMP-style project plan for the Network & Access Modernization project, built from Books 08 and 09: a work breakdown by project phase, a computed critical path tied to the program’s own DNS tasks, every gate with its approver and criteria, and the intermediate decisions (DDI platform, resolver path, egress pattern, boundary change, fabric go-live, NAC platform) with owners and decide-by weeks. |
| Non-Person Identity Modernization: Service Accounts, Workload Identities and AI Agents | Project | Books 02, 04, 06 and 17 | 34 | A sample PMP-style project plan for the Non-Person Identity Modernization project, built from Book 02, Chapters 09 and 10, Book 04, Chapter 05, Book 06, Book 17 and the companion guide’s non-person identity track: a work breakdown from the inventory to steady state, a computed critical path, a gate per phase with its approver and criteria, and the decisions (source of record, orphan rule, disposition per account, Workload ID Premium scope, enforcement, AI identity capabilities) with owners and decide-by weeks. |
| Privileged Access & Administrative Identity: Just-in-Time by Tier | Project | Book 04 | 39 | A sample PMP-style project plan for the Privileged Access & Administrative Identity project, built from Book 04, Chapters 04 to 10 and Appendix B: a work breakdown from the privilege inventory to every tier under just-in-time elevation, a computed critical path, a gate per phase with its approver and criteria, and the decisions (tier model, approvers, break-glass custody, PAW enforcement, review cadence) with owners and decide-by weeks. |
| Supply Chain & Software Bill of Materials: From Inventory to Proof | Project | Book 14 | 11 | A sample PMP-style project plan for the Supply Chain & Software Bill of Materials project, built from Book 14, Chapter 07: a work breakdown by the chapter’s five steps, a computed critical path from the product inventory to one finding closed with proof, every gate with its approver and criteria, and the decisions (charter, remediation timelines, SBOM format, certification class, contract clauses) with owners and decide-by weeks. |
| Chapter 01 — The Writer Register as Code | Keep the lifecycle rows of the writer register as reviewed JSON, one writer and a backstop for every account-state transition and HR-mastered value, check the register’s shape, then scan the Microsoft Entra directory audit log for second writers and write the saved audit queries Gate 7 runs, starting from Learn’s directoryAudits API and its audit activity list and adding what they leave to you: who is allowed to write what, the test that says so for every record, and evidence the ISSO can file, with labs against fixtures and a test tenant. | |||
| Chapter 02 — Contractor Sources and Enforced End Dates | Run contractors from a source other than HR with an end date that can’t be left open: compute each contractor’s earliest end from the contract, the completion date, suitability, the card and the sponsor, write the records as an extract the HR middleware sends through API-driven inbound provisioning, reconcile the register, the card system and the directory read-only, and build the sponsor review that removes access when no one responds, starting from Learn’s bulkUpload API and access package review settings and adding what they leave to you, with labs against fixtures and a test tenant. | |||
| Chapter 03 — Joiner Workflows as Code and the Temporary Access Pass Bridge | Keep the Lifecycle Workflows definitions as reviewed v1.0 request bodies, lint them against Learn’s limits and the program’s rules (scope by code, the Temporary Access Pass’s lifetime and one-time use, access by package rather than group add, delete apart from disable, an execution limit for every scheduled workflow, the 50-workflow budget), plan each change as a new workflow or a new version against what the tenant holds, and measure day-one readiness, starting from Learn’s Create workflow, createNewVersion and built-in task pages, with labs against fixtures and a test tenant. | |||
| Chapter 04 — Access from Attributes and the Mover’s Residual Review | Keep access package assignment policies as reviewed v1.0 bodies and lint them before they reach the tenant (the memberOf rules quarantined from November 3, 2026, two automatic policies on one package that a user can match at once, Learn’s 15,000-identity limit, rules on the coded slots, create and remove both on, a bounded grace period, privileged access kept out of rules, requests routed to the manager with a fallback), scan an export for memberOf policies, and list what a move leaves behind for the mover’s residual review with the transfer-to-review interval, starting from Learn’s automatic assignment policy page and its Create assignmentPolicies example, with labs against fixtures and a test tenant. | |||
| Chapter 05 — Certificate-Based Authentication Checks | Check the certificate-based authentication configuration behind PIV and CAC sign-in as code, starting from Learn’s CRL page and the PKI trust store and X.509 method APIs, and adding what they leave to you: a measurement of every CRL against the cloud’s own size and download limits, a check of the trusted issuing CAs, the multifactor mapping of the PIV policy OIDs, CRL validation and its exemptions, low-affinity bindings and a Conditional Access policy that requires a phishing-resistant authentication strength, with labs against fixtures and a test tenant. | |||
| Chapter 06 — Separation Timing from the Logs | Measure every separation from the logs as code, starting from Learn’s audit activity list, the Lifecycle Workflows user processing results and the three-day catch-up window, and adding what they leave to you: the separation-to-block and separation-to-revocation intervals per leaver against the agency’s thresholds, the late separations the scheduled trigger skipped, uncollected cards revoked past 18 hours, re-enables after a disable, failed leaver runs, privileged leavers and deletes before device retirement, with labs against fixtures and a test tenant. | |||
| Chapter 07 — Lifecycle Drift, Metrics and Evidence | Find the six lifecycle drift classes (missing identity, stale access, orphan account, unauthorized write, credential drift and contractor credential drift), compute the six lifecycle metrics from the other chapters’ outputs, write them as one read-only run that records the SHA-256 of every input it read, and hand it to the first workbook’s drift pipeline, which packages each run with a SHA-256 per file, the tenant ID and a hash chain and assembles the period the ISSO signs for the guide’s Gate 7, with labs against fixtures and a test tenant. | |||
| Chapter 08 — Deploying to a Test Tenant, Then to Production | The runbook that takes the kit from each chapter’s non-production step to a live test environment (an Oracle HCM test pod with synthetic workers and an Entra test tenant), then to the production HR feed and tenant: one settings file per environment with no secrets, a pre-flight check of licenses, PIM roles, the writer register and the provisioning apps, a staged enable with scoping filters and workflows on demand, a smoke test with a synthetic joiner, mover and leaver, the evidence the ISSO keeps, go/no-go criteria, first-week monitoring and a rehearsed rollback, every step a command block linked to the guide’s gate. | |||
| Chapter 01 — Non-Person Identity Inventory as Code | Read every non-person identity into one register as code, starting from Learn’s own commands for finding service accounts and service principals and its script for exporting app registrations’ secrets and certificates (pinned in the repository), and adding what they leave to you: one read of Active Directory’s user-based service accounts, MSAs, gMSAs and dMSAs, app registrations, service principals by type, managed identities and their federated credentials, Graph application permissions and consent grants, each row with an owner count, credential kind, risk, candidate target and stale lead, SQL Server accounts handed to the Data Platform plan, and a manifest with a SHA-256 per file and the tenant ID, with labs against fixtures and a test tenant. | |||
| Chapter 02 — Ownership and the Orphan Rule | Check every identity in Chapter 01’s register against the program’s ownership rule as code, starting from Learn’s own Graph samples for finding ownerless service principals, assigning owners and setting serviceManagementReference (pinned in the repository), and adding what they leave to you: two enabled human members as owners, not service principals or guests, a service-management reference that names an active record, an application owner for every Active Directory account, findings with stable IDs, AI sponsor fields recorded for Chapter 09, and the orphan rule (D-NP2) as a dry-run plan that disables and never deletes, applied only through a separate, delegated, reviewed write path, with labs against fixtures and a test tenant. | |||
| Chapter 03 — The Migration Path Matrix as Code | Turn Book 02’s migration path matrix into reviewed data and code, starting from Learn’s own decision tables for choosing an on-premises service account, a cloud service account and Workload ID Premium (pinned in the repository), and adding what they leave to you: a proposed target for every identity in Chapter 01’s register, read with Chapter 02’s ownership run; the application owner’s disposition (retire, re-platform, keep, or keep on Kerberos with an SPN owner and an end date the authorizing official accepts) checked against it; conversion waves with HIGH-risk accounts first and a rollback recorded per wave; the Workload ID Premium scope (D-NP4) as a decision file checked against the tenant’s subscriptions; and Gate 2 as a check, with labs against fixtures and a test tenant. | |||
| Chapter 04 — App Management Policies and Certificate Rotation | Hold the tenant’s app management policy as reviewed JSON and rotate app registration certificates through Key Vault as code, starting from Microsoft’s own samples for the tenant default policy, app-specific policies, adding a certificate to an app and creating a Key Vault certificate (pinned in the repository), and adding what they leave to you: new client secrets and symmetric keys blocked and certificates capped at 180 days for new apps on both application and service principal objects, exceptions with a record and an end date, the app instance property lock on every app registration, a diff that never loosens or drops a restriction, a dry run and -Apply through a delegated, reviewed write path; then credentials near expiry found from Chapter 01’s register, a rotation raised before expiry and approved by an owner, the new certificate created in Key Vault and added beside the old one, verified, and the old one removed only after the overlap, with labs against fixtures and a test tenant. | |||
| Chapter 05 — Workload Identity Federation and Managed Identities | Convert non-person identities wave by wave in the plan’s order (managed identity, then federated credential, then certificate), starting from Learn’s own samples for federated identity credentials on an app registration and on a user-assigned managed identity, the Graph create sample and the Managed Identity REST examples (all pinned in the repository), and adding what they leave to you: federated credentials held as reviewed JSON with a diff, a dry run and an approved plan hash, a pre-cutover check that each credential’s issuer and subject match what the workload’s issuer will present, a token exchange test against a fake token endpoint, managed identities created or recorded with their role assignments, and the 30-day parallel run tracked from sign-in evidence before the legacy account is disabled, never deleted, with labs against fixtures and a test tenant. | |||
| Chapter 06 — gMSAs, dMSAs and the Kerberos Island | Move the Kerberos-only workloads in Chapter 01’s register as reviewed code, starting from Learn’s own gMSA, dMSA and KDS root key procedures (pinned in the repository): MSAs upgraded to gMSAs; traditional accounts, IIS application pools and scheduled tasks moved to a gMSA or a Windows Server 2025 dMSA through a dry-run plan applied only with -Apply, which never deletes the old account; the KDS root key checked read-only; the principals allowed to retrieve each managed password held as reviewed data; the accounts that stay on Kerberos recorded with an SPN owner and an end date within the program’s D08 and exported for its SPN retirement; and every gMSA and dMSA reconciled with the provisional end state before AD is retired, with labs against fixtures and a test domain. | |||
| Chapter 07 — Least Privilege for Service Principals | Sweep every service principal in Chapter 01’s register for its application permissions, delegated grants, directory roles and, for managed identities, Azure role assignments, starting from Learn’s own review-and-revoke script and Graph requests (pinned in the repository), and add what they leave to you: a reviewed list of broad tenant-wide permissions with a recorded, dated justification per exception, Learn’s narrower replacement for each (resource-specific permissions, Sites.Selected, RBAC for Applications in Exchange Online, a resource scope in Azure), privileged service principals handed to the Privileged Access plan (A3.4), the first quarterly owner review as a packet, and a dry-run plan that removes one app role assignment through its resource service principal or narrows one delegated grant, never deletes an app, and is applied only through a separate, delegated, reviewed write path, with labs against fixtures and a test tenant. | |||
| Chapter 08 — Conditional Access for Workload Identities | Hold Conditional Access for workload identities as reviewed data and code, starting from Learn’s own Graph JSON sample for a workload identity policy (pinned in the repository) and adding what it leaves to you: the scope as a reviewed file (Tier 1 single-tenant service principals assigned directly by object ID, never through a group; the workload egress ranges as a named location; managed identities, multitenant and SaaS apps recorded out of scope with the control that covers each), the program’s CA015 location restriction and CA037 high-risk block rendered ring by ring and always created report-only, a pre-merge check, a tenant check, a reader for the service principal sign-in logs (Graph beta) that summarizes the report-only results per principal, enforcement only with -AllowEnforce after decision D-NP5, and an alert definition for block events, with labs against fixtures and a test tenant. | |||
| Chapter 09 — AI Agent Identities | Govern AI agent identities as code, starting from Learn’s own Microsoft Entra Agent ID samples (pinned in the repository) for creating a blueprint and its credentials, inheritable permissions, the agent Conditional Access policies and the Graph list requests, and adding what they leave to you: creation closed and read back, the production handshake as a reviewed record, no secret on a production blueprint, no allAllowed role inheritance and no standing privileged role, the sponsor fields Chapter 02 recorded filled and checked, the ten-business-day sponsor confirmation rule, agent block policies in report-only through a separate reviewed write path, the AI drift checks, and decision D-NP6 as data, with service principals and managed identities under the same governance where agent identities aren’t available. | |||
| Chapter 10 — Drift and Evidence for the ISSO | Run Chapter 01’s register and Chapter 02’s ownership check on a schedule, compare the register with the last approved baseline by fingerprint, and raise the drift the plan names (ownerless, unused or expiring registrations, passwords that never expire, credentials added outside the pipeline, new consent grants), starting from the Sentinel rule Learn links for added credentials (pinned in the repository) and run offline; then read the review cycle’s records from Chapters 07 and 09, take Chapters 03 to 09’s findings through a small documented contract, compare the AI use-case inventory vintages, and package each run with a SHA-256 per file, the tenant ID and a hash chain into the period evidence for AC-2, AC-6(5), IA-4, IA-5, IA-9 and M-25-21, with labs against fixtures and a test tenant. | |||
| Chapter 11 — Deploying to Test and Production | A deployment runbook that takes the kit from the non-production environment of each chapter’s second lab to a live test environment (an Entra test tenant, an Azure test subscription and an Active Directory test forest), then to production: one environment settings file with no secrets, a read-only preflight with the licenses, roles and VK-NPI baseline, a safe deployment order (inventory and owners, the app management policy scoped to a pilot, a federated credential and managed identity run in parallel with the old secret, a gMSA on a test host, Conditional Access for workload identities report-only), a smoke test with a synthetic service principal and service account, the evidence, a rehearsed rollback, the promotion go/no-go criteria, then production with a change record, a staged enable by ring, first-week drift monitoring and a rollback, every step a copy-paste command linked to the implementation guide’s gate. Nobody has run it against a live tenant. | |||
| Chapter 01 — Privileged Inventory as Code | Read every privileged assignment in the estate as code, starting from Learn’s own samples for listing Microsoft Entra role assignments (pinned in the repository) and adding what they leave to you: eligible as well as active assignments, role-assignable groups expanded to their members, Azure role assignment and eligibility schedules through Resource Manager, a tier for every row, findings for standing privilege, and a manifest the ISSO can check, with labs against fixtures and a test tenant. | |||
| Chapter 02 — Emergency Access Accounts as Code | Check the emergency access accounts against Learn’s standard as code, and write the alert on their use as a reviewed ARM template, starting from Learn’s own emergency access page and its sample alert queries (pinned in the repository) and adding what they leave to you: a check of every account, its methods, its Global Administrator assignment, the exclusion group and every enforced Conditional Access policy, and an alert that also sees non-interactive sign-ins and audit events, with labs against fixtures and a test tenant. | |||
| Chapter 03 — Conditional Access for Administrators and the Activation Gate | Hold the Conditional Access policies for administrators as reviewed JSON, starting from Microsoft’s own template for administrators as Graph returns it (pinned in the repository) and adding what it leaves to you: the emergency access exclusion, the phishing-resistant authentication strength, the PIM activation gate through authentication context c1, a pre-merge check, a diff against the tenant and a dry run, with every new policy created report-only, with labs against fixtures and a test tenant. | |||
| Chapter 04 — PIM for Microsoft Entra Roles as Code | Hold PIM role settings for Microsoft Entra roles as one reviewed JSON file per role, starting from Learn’s own samples for updating PIM rules and assigning eligibility (pinned in the repository) and adding what they leave to you: the authentication context, approver groups, a diff against the tenant, a dry run before any write, the least-privileged permission for each read and write, eligibility for the PRV groups, the conversion of standing assignments, a guard against the documented lockout, and the plan’s order of one role class first, then every tier, with labs against fixtures and a test tenant. | |||
| Chapter 05 — PIM for Groups and the PRV Groups | Hold the PRV role-assignable groups, their PIM for Groups member and owner schedules and their two role management policies as reviewed JSON, starting from Microsoft’s own PIM for Groups request samples (pinned in the repository) and adding what they leave to you: a read of the tenant first, checks against Learn’s limits and the program’s tiers, a plan with a diff, a dry run by default, guards that refuse unsafe changes, and least privilege per call, with labs against fixtures and a test tenant. | |||
| Chapter 06 — PIM for Azure Resources | Hold PIM for Azure resources as reviewed code through the Resource Manager API, starting from Learn’s REST walkthroughs and Microsoft’s own request and response examples (pinned in the repository) and adding what they leave to you: role management policies set by tier at every management group, subscription and resource group, eligible assignments as reviewed JSON with a diff, a dry run and an explicit apply, and standing Owner, Contributor and User Access Administrator found and converted to eligible, with labs against fixtures and a test tenant. | |||
| Chapter 07 — Access Reviews of Privileged Roles | Hold the access reviews of privileged roles as reviewed JSON and apply them through Microsoft Graph and Resource Manager, starting from Learn’s own access reviews tutorial for administrative roles (pinned in the repository) and adding what it leaves to you: one series per Microsoft Entra role, PIM for Groups group and Azure role, reviewer groups with fallbacks, the program’s cadence, auto-apply and no-response default with a guard against removing the emergency accounts, a dry run and diff before an explicit -Apply, least privilege per call, and the review results read back as evidence, with labs against fixtures and a test tenant. | |||
| Chapter 08 — Evidence and Drift for the ISSO | Run the privileged inventory and the emergency access check on a schedule with the PIM activation and audit evidence, compare each run with the last by fingerprint so no names reach the tracker, treat Tier 0 drift as an incident, and package each run with a SHA-256 per file, the tenant ID and a hash chain, then assemble the period the identity governance officer signs and the ISSO receives for the plan’s Phase 4 gate. It starts from Learn’s PIM audit queries (pinned in the repository), runs them offline, and builds on the first workbook’s drift pipeline for what they leave out, with labs against fixtures and a test tenant. | |||
| Chapter 09 — Deploying to Test and Production | A runbook that takes the kit from the labs to a live test tenant and subscription, then to production, with the same commands and one settings file per environment: roles, approvals and the change record; a settings file with no secrets; pre-flight checks that verify the emergency access accounts and their exclusion from every Conditional Access policy before anything else; a stage order that prevents lockout; a smoke test with a synthetic administrator; go/no-go criteria; production waves; first-week monitoring with drift; rollback; and the evidence the ISSO keeps. Every step is a command or an exact portal path. Nobody has run it against a live tenant yet. | |||
| Chapter 01 — The Notice Record and Azure Service Health | The one record every provider’s notice becomes, and the first collector that fills it: Azure Service Health read through Azure Resource Graph with Learn’s own sample queries, every event type mapped to a kind, retirements and security advisories made action required by a stated rule, impacted resources joined by tracking ID, a fingerprint that changes when the provider changes the notice and not when the kit reads it again, and Service Health alerts at scale through the built-in Azure Policy definition as a plan that applies only with its approved SHA-256. Labs against fixtures and an Azure test subscription. | |||
| Chapter 02 — Microsoft 365 Message Center and Service Health | Microsoft 365’s Message center posts and service health issues read through the Microsoft Graph service communications API, on the tenant’s own Graph host (GCC on the worldwide endpoint, GCC High and DoD on their own), with the two read permissions Learn names: posts tagged Retirement as retirements, plan-for-change and prevent-or-fix posts as changes, the provider’s action-required date kept as the provider’s, the kit’s own rule labeled as a rule, paging that refuses a next link on another host, and a session guard that refuses another cloud or tenant. Labs against fixtures and a Microsoft 365 test tenant. | |||
| Chapter 03 — Oracle Cloud Infrastructure Announcements | Oracle Cloud Infrastructure announcements read with Oracle’s own CLI and the one policy statement Oracle documents for reading them: the latest announcement in each chain, the details call for affected resources, announcement types mapped to the record’s kinds, Oracle’s own ACTION_REQUIRED and ACTION_REQUIRED_BY kept as the provider’s word, a rescheduled maintenance window replacing the original, and a realm guard that knows the US Government Cloud (OC2) endpoints and refuses OC3, whose endpoint is not yet specified. For an agency whose HR platform runs on OCI, this is how platform maintenance reaches the HR system’s owners first. Labs against fixtures and a test tenancy. | |||
| Chapter 04 — AWS Health | AWS Health events read through the AWS Health API with a customer managed policy holding three read actions (AWS publishes no read-only managed policy for Health): open and upcoming events, then descriptions and affected entities ten events at a time, event categories mapped to the record’s kinds, AWS’s own actionability kept as the provider’s word, retirements recognized by a stated kit rule, the support-plan requirement and its error, and a partition guard that sends GovCloud (US) reads only to the single endpoint in us-gov-west-1. Labs against fixtures and a test account. | |||
| Chapter 05 — Google Cloud Personalized Service Health | Google Cloud’s Personalized Service Health read for a project (or an organization) with the viewer role Google documents: every event an incident, because the API has one category and no planned maintenance; products and locations from the event’s impacts; a summary from the latest update; and two gaps recorded honestly, the missing maintenance and the product’s absence from the Assured Workloads FedRAMP Moderate, FedRAMP High, IL4 and IL5 packages, plus an organization-level call the kit runs only when told it is unverified. Labs against fixtures and a test project. | |||
| Chapter 06 — Routing to Owners and Ticket-to-Machine Tasks | Turning notices into work: a routing file the agency writes at work, checked before it runs; rules tried in order, first match wins; a ServiceNow-shaped Ticket-to-Machine typed task for each notice that needs one, with the finding contract’s severity, priority and response window, the provider’s own date kept apart, a de-duplication key and the five clauses of the request chain; state across runs, so an unchanged notice never makes a second task and a notice the provider stops listing asks for the re-read; contingency plan reviews flagged for retirements and maintenance; and sending only from the scheduled run, only when the settings allow it. Labs against fixtures and a ServiceNow developer instance. | |||
| Chapter 07 — The Weekly Digest and Evidence | What the owners read and what the ISSO keeps: a weekly digest in five sections (open notices by provider and kind, action required soonest first with the owner the routing named, maintenance and changes starting soon, what is new and what closed), and an evidence chain in which every run folder is checked against its manifest, copied, hashed and recorded with the steps it covers and their NIST SP 800-53 controls and FedRAMP 20x KSIs, each record carrying the hash of the one before, with a SHA256SUMS file the ISSO can check and a stage check that says which steps still lack a passing record. Labs against fixtures and a test run folder. | |||
| Chapter 08 — Deploying to Test and Production | A deployment runbook that takes the provider notices kit from the labs to a live test environment, then to production, with the same commands and one settings file per environment: a settings file with no secrets, a read-only pre-flight (PF-01 to PF-07), Stage 1 in a test environment with a staged enable (one provider at a time, each cross-checked against the provider’s own command), a smoke test (ST-01 to ST-04), the Service Health alert policy applied with its approved hash, the weekly run on a schedule, the evidence and a rehearsed rollback; the go/no-go criteria; and Stage 2 in production, with routing as a dry run for the first week before sending, the alert policy at the management group, first-week monitoring and a rollback. Every step is a copy-paste command; the deploy scripts each have a dry run. Nobody has run it against a live tenant. | |||
| Chapter 01 — The Loop and the Typed Task | Where the kit sits in Book 13’s five-step loop, and the one record every step writes or reads: the typed identity finding. Check the data contract on a laptop before anything reaches ServiceNow, with the drift classes, severities, systems, subject rules, tempo and de-duplication key mirrored from the Scripted REST script by a test, and a warning when an intended state gives the re-read nothing to check; with labs against fixtures and a ServiceNow developer instance. | |||
| Chapter 02 — The ServiceNow Client and Least Privilege | The ServiceNow half of the kit’s shared client: OAuth client-credentials tokens at oauth_token.do, Table API paging, the Attachment API and retries on 429 and 503. Declare every HTTP call the clients make, with the task that makes it and its least privilege, in one reviewed file; fail a test when a client makes a call that isn’t declared; and split the ServiceNow roles by task so the evidence reader can’t close a finding; with labs against fixtures and a ServiceNow developer instance. | |||
| Chapter 03 — The SailPoint Client and Its Scopes | The SailPoint half of the kit’s shared client: ISC tokens by client credentials or a personal access token, Search with searchAfter paging, the Accounts API with limit and offset, and the Microsoft Graph reads the re-read and drift clients make. Declare the ISC and Graph calls with their least-privileged scope or permission, compare an API client’s granted scopes with what each task needs, and keep the workflow-creation scope off the clients that read; with labs against fixtures and a SailPoint sandbox tenant. | |||
| Chapter 04 — Drift to a Typed Task | Build 1 of the kit: SailPoint event triggers start ISC workflows whose HTTP Request step posts a typed identity finding to the ServiceNow Scripted REST resource. Resolve each workflow’s request body against a sample trigger input on a laptop, derive the intended state the script will store, check it against the data contract, and list the input fields the workflow drops. Two fixes follow from it: multivalued attribute changes are now reverted like any other, and the attribute is part of the de-duplication key; with labs against fixtures and a SailPoint sandbox. | |||
| Chapter 05 — The Re-read Rule | Build 2 of the kit and its answer to Gap 1: a ServiceNow business rule turns any close into Awaiting verification, and a client re-reads the account, identity or user from its system of record and closes the finding only with the evidence, or reopens it. Run the same decisions offline from saved records and saved reads, judge ISC’s aggregation lag against a fixed clock, and add the guard that an intended state naming nothing a re-read can check is skipped, never verified; with labs against fixtures and a ServiceNow developer instance. | |||
| Chapter 06 — Drift Reconciliation | Build 3 of the kit: a read-only client joins the HR extract, Microsoft Graph and SailPoint ISC on employeeId and reports Book 03’s drift classes with stable finding IDs. Run it twice, a day apart, and compare the runs by finding ID into new, persisting and resolved findings, refusing to compare runs that computed different classes, so a class one run skipped can’t look fixed; resolved findings are leads for the re-read, not closures; with labs against fixtures and a test tenant. | |||
| Chapter 07 — Evidence Records for Book 13 and the ISSO | The ServiceNow half of Pass 2’s evidence export: read closed and cancelled identity findings and write one record per finding in Book 13’s evidence shape (origin, owner and clock, approval, executing identity, what ran, result, closure), with the Pass 1 gaps written as null and the reason, never invented. Check each record’s evidence against its hash, its closure against the business rule, and its finish against its response window, and package the period with a manifest and a hash chain an ISSO can verify; with labs against fixtures and a ServiceNow developer instance. | |||
| Chapter 08 — One Writer per Attribute | Gap 4 of the Ticket-to-Machine example and an item planned for the kit’s Pass 2: if Entra inbound provisioning from HR and SailPoint’s Entra source both write the same user attribute, each overwrites the other and drift never settles. Compare the inbound provisioning job’s synchronization schema from Microsoft Graph with the ISC source’s provisioning policies, offline, and report every attribute with two writers by how each writes it, update or create only; with labs against fixtures and exports from a test tenant and a SailPoint sandbox. | |||
| Chapter 09 — Deploying to Test and Production | The deployment runbook: take the kit from a developer instance to a ServiceNow sub-production instance and a SailPoint sandbox tenant, then to the production instance in ServiceNow’s Government Community Cloud and the production ISC tenant. One settings file per environment and no secret in it; pre-flight checks for Gate 1, OAuth client credentials and least privilege; the application installed by the vendor’s documented method; the ISC workflows created disabled, test-run and enabled in stages; a smoke test with a synthetic worker and the expected result of each step; promotion criteria, first-week monitoring and rollback; and for each step the federal requirement it serves, the FedRAMP 20x KSI it aligns to, and the hash-chained evidence record the scripts write for the ISSO. Every step is a command or an exact menu path, and nobody has yet run it against a live tenant. |
No matching items
Developer workbooks
The plans have code-first companions for the developers who build each project’s software. The first, for the Attribute-Driven Migration plan, is Book 19, Building the Attribute-Driven Migration. The others are the developer workbooks here under Projects; one per project track is planned.
The program master schedule is the integrated plan, and the project plans link to it in both directions:
- A project waits for the program. The Data Platform plan can’t start its pilot until the program’s pilot servers are under Arc, so it takes that date from the program and shows how far it can slip.
- The program waits for a project. The program’s Gate G1 waits on the Identity Lifecycle plan’s HR feed, so the program takes that date and shows the float between them.
- A project must finish before a program gate. The program’s G1 needs the Intune policy design from the Endpoint plan, and its drift-clean criteria need evidence from the Continuous Monitoring plan. Each project plan carries those program gates as fixed deadlines and computes its margin against them, and the program plan lists every margin under Links to other plans. The tightest is the Endpoint plan’s policy library, one working day before G1.
Where the Attribute-Driven Migration plan sits. The guide’s four tracks each have their own plan: HR in Identity Lifecycle & Provisioning, end-user devices and Arc servers in Endpoint & Device Modernization (Arc is its Phase 4), and service accounts, workload identities and AI agents in Non-Person Identity Modernization. The Attribute-Driven Migration plan sits across them and under the program. It owns only what they share: the schema and slots, the proof of the attributes, sync, the group library and units, the personas and targeting conventions, PIV binding, the mover proof, the OU tree’s retirement and drift. Each handoff to a track plan or a program gate is a linked milestone with its margin.
How to read a plan
Each plan has the same sections, in the order a project manager reviews them.
| Section | What it tells you |
|---|---|
| Plan at a glance | Type, sponsor, plan manager, computed duration, and how much of the work sits on the critical path |
| Schedule | A Gantt chart: critical-path tasks in red, other tasks in blue with their float, gates and decisions as diamonds |
| Critical path | The chain of tasks with zero float, in order, and the near-critical tasks that join it once their float is spent |
| Decision points | Each decision with its owner, what it unblocks, the last week it can be made without moving the finish, and what a late decision costs |
| Gates | Each gate’s approver and criteria; a gate opens the work that names it as a predecessor, which is usually the next phase but not always |
| Work breakdown and schedule | Every task by phase: owner, duration, predecessors, weeks and float, each linked to the chapter it comes from |
| Responsibility, assumptions, risks | One owner per row, what the dates assume, and the risks that would move them |
| Baseline and change control | When to baseline, how to report, and how a change to a date gets made |
Three terms carry most of the meaning:
- Critical path. The longest chain of dependent tasks through the plan. Its length is the plan’s duration, and a day lost on it is a day lost at the finish. It’s computed with the critical path method: a forward pass for the earliest dates and a backward pass for the latest.
- Total float. How many working days a task can slip before it moves the finish. Critical tasks have none. Reporting float, rather than percent complete, shows where the schedule can still absorb trouble.
- Decide by. A decision’s late finish: the last week it can be made without moving the finish. A decision with zero float is on the critical path, and the meeting that makes it belongs on the calendar before the plan is baselined.
Using a plan
Each plan downloads as a Microsoft Project file (XML), a CSV for Excel, and import files for Azure Boards and Jira, with every dependency, owner and float. Each also has a YAML source in the repository. To adapt one in the repository, edit its durations, owners and dependencies, then run:
python scripts/project_plans/build.pyThe script recomputes the critical path and regenerates the page, the chart and the downloads; --check reports any output that no longer matches its source.