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.
Project plan · Sample · Project
Identity Lifecycle & Provisioning: HR-Driven Identity
A sample project plan for Book 03’s pipeline: from the integration-point inventory to cloud-mastered populations, with the decisions that hold the HR feed’s critical path
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.
NoteA sample plan, not a commitment
This is an illustrative plan built from the workbook’s books, in the form a project manager would baseline: a work breakdown, a schedule network, a computed critical path, decision points, gates and risks. The durations are illustrative, sized to the books’ roadmap weeks. Replace them with the agency’s own estimates, then baseline the result. The plan names roles, not people, and no specific agency.
Plan at a glance
| Plan type | Project: Book 03 Phases 0 to 5 (Phase 6 is sustained posture) |
| Built from | Book 03 |
| Sponsor | Executive sponsor and CIO; HR leadership |
| Plan manager | Identity engineering lead, with the agency HR 2.0 integrated project team point of contact |
| Duration | 26 weeks (130 working days), computed from the network |
| Work | 27 tasks, 6 gates, 5 decision points |
| Critical path | 20 of 38 items; 13 more within 5 days of it |
| Calendar | Week 1 = the program’s Phase 0 approval; five working days a week |
This plan builds Book 03’s pipeline: HR as the source of authority, a middleware in the agency’s boundary, provisioning into Active Directory or Entra ID, and Lifecycle Workflows acting on the accounts. It follows Book 03’s phase model gate for gate, and it feeds the program master schedule: the program’s Gate G1 needs this plan’s Gate 3, the HR feed live for the foundation scope. The implementation guide for Oracle Fusion Cloud HCM shows the same pipeline on named products, and HR-Driven Identity: An Implementation Guide runs the lifecycle on it as gates, naming the tasks of this plan each gate carries out.
Schedule
Critical path
The computed path runs through the integration-point inventory, the crosswalk, the authority map and schema, the middleware build, the end-to-end test and the shadow-mode observation. It is among the most compressed tracks in the program: it has only a few days of float against the program’s G1, so a week lost here is a week lost at G1. The privacy basis is the task to watch. It is a Phase 1 gate item, so Gate 1 won’t sign without it, and many privacy offices need longer than this sample allows, so it starts on day one. If the agency’s PIA update takes longer, re-baseline here first.
The critical path, in order. Each item has zero total float: a day lost on any of them is a day lost at the finish.
| # | ID | Item | Owner or approver | When |
|---|---|---|---|---|
| 1 | I0.4 | Privacy basis: routine use, PIA update, minimized attribute set | Privacy officer | wk 1–5 |
| 2 | IG1 | Gate 1 — Authority and schema signed | ISSO | end of wk 5 |
| 3 | I2.4 | End-to-end proof in the test tenant, including device retire and test-CA revocation | Identity engineering | wk 6 |
| 4 | IG2 | Gate 2 — Pipeline proven end to end | ISSO | end of wk 6 |
| 5 | I3.2 | Initial full sync with scoping filters; mismatches reconciled | Identity engineering | wk 6–7 |
| 6 | I3.3 | Shadow mode on the pilot cohort; every difference explained | Identity engineering | wk 7–8 |
| 7 | D-I4 | Let the pipeline act on the pilot cohort | ISSO | end of wk 8 |
| 8 | I3.4 | Delta feeds live; first joiner/mover/leaver cycle closes with evidence | Identity engineering | wk 8 |
| 9 | IG3 | Gate 3 — HR feed live for the foundation scope | ISSO | end of wk 8 |
| 10 | I4.1 | Leaver automation on for covered populations; block and revocation intervals measured | Identity engineering | wk 9–10 |
| 11 | I4.4 | Hand-kept groups converted to rules, shadow-compared one by one | Platform teams | wk 10–14 |
| 12 | I4.3 | Joiner and mover automation; rehire and conversion matching validated | Identity engineering | wk 11–12 |
| 13 | I4.5 | Access packages re-based on the supervisor of record | Identity engineering | wk 13–14 |
| 14 | I4.6 | A full pay-period cycle with zero missed leavers; test reorganization | ISSO | wk 15–16 |
| 15 | IG4 | Gate 4 — Lifecycle automated | ISSO | end of wk 16 |
| 16 | D-I5 | Order of populations to cut over, aligned to the Core HCM onboarding | Executive sponsor and CIO | end of wk 16 |
| 17 | I5.1 | Employee populations retargeted to the Entra app, one by one, evidence-gated | Identity engineering | wk 17–24 |
| 18 | I5.2 | Contractor populations onboarded from their decided source and retargeted | Identity engineering | wk 19–24 |
| 19 | I5.3 | OU-bound policy retired; rollback path tested once | Platform teams | wk 25–26 |
| 20 | IG5 | Gate 5 — Populations cloud-mastered | ISSO | end of wk 26 |
Near-critical. These items have 5 working days of float or less. Track them weekly: once their float is spent, they join the critical path.
| ID | Item | Float | When |
|---|---|---|---|
| I0.1 | Integration-point inventory, naming the HR-driven identity feed | 2 d | wk 1 |
| I0.2 | Entra migration plan names HR as the source for each population | 2 d | wk 1 |
| IG0 | Gate 0 — Inventory signed and submitted | 2 d | end of wk 1 |
| I1.1 | Standard-attribute crosswalk and nature-of-action trigger table | 2 d | wk 2 |
| I1.2 | Attribute authority map signed (HR’s part is program decision D02) | 2 d | wk 3 |
| I1.3 | Canonical schema finalized and validated against a sandbox extract | 2 d | wk 3–4 |
| I2.1 | Workforce identity service (middleware) built in-boundary | 2 d | wk 4–5 |
| I3.1 | Two provisioning agents under a gMSA with OU-scoped rights | 2 d | wk 6 |
| I0.3 | Legacy identity data to retain identified | 3 d | wk 1 |
| D-I2 | Worker-type taxonomy and the three access-attribute code lists | 3 d | end of wk 3 |
| I1.4 | UPN, sAMAccountName, OU placement and scoping rules | 3 d | wk 3–4 |
| I2.3 | Joiner, mover and leaver workflows and custom task extensions | 3 d | wk 4–5 |
| I2.2 | API-driven provisioning apps; least-privilege permissions; throttling sized | 5 d | wk 4 |
Decision points
Each decision is a zero-duration milestone in the network. Decide by is its late finish: the last week it can be made without moving the plan’s finish. A decision with zero float sits on the critical path, so the meeting that makes it should be booked before the plan is baselined. Decision rights follow Book 01, Chapter 09.
| ID | Decision | Decides | Needed by | Decide by | Float | Options | If it’s late |
|---|---|---|---|---|---|---|---|
| D-I1 | Enterprise person key, and how source keys map to it | ICAM governance body, with HR and identity engineering | I1.2 | end of wk 3 | 7 d | The HCM person number; another HR key; a minted enterprise key | The authority map can’t be signed; the critical path waits |
| D-I2 | Worker-type taxonomy and the three access-attribute code lists | HR | I1.4 | end of wk 4 | 3 d | Employee, contractor, intern, volunteer, vendor, external, each with a license, access ceiling and retention | Naming, placement and scoping rules wait |
| D-I4 | Let the pipeline act on the pilot cohort | ISSO | I3.4 | end of wk 8 | 0 (critical) | Act; extend shadow mode | The go-live waits, and with it the program’s G1 |
| D-I5 | Order of populations to cut over, aligned to the Core HCM onboarding | Executive sponsor and CIO | I5.1 | end of wk 16 | 0 (critical) | Follow the program’s waves; follow the agency’s Core HCM go-live | Retargeting can’t be scheduled |
| D-I3 | Source of authority for contractors and other non-employees | ICAM governance body | I5.2 | end of wk 18 | 65 d | Core HCM contingent workers; the PIV sponsorship system; the contractor suitability register; a combination with one authority per fact | Contractors stay on COR spreadsheets; their cutover can’t be planned |
Gates
A gate opens the work that names it as a predecessor, which is usually the next phase but not always. The approver signs it against the criteria, from evidence in the repository.
| Gate | When | Approver | Criteria |
|---|---|---|---|
| Gate 0 — Inventory signed and submitted | end of wk 1 | ISSO | The integration-point inventory is signed by the ISSO and submitted to the agency’s HR 2.0 team |
| Gate 1 — Authority and schema signed | end of wk 5 | ISSO | Identifier decision, authority map and schema signed; privacy basis (routine use, PIA update, minimized attribute set) in place; correlation measured on the pilot cohort (the threshold itself is decided and tested at Gate 2 of the Attribute-Driven Migration plan, ATG2); every enabled account correlated or on a dated exception list |
| Gate 2 — Pipeline proven end to end | end of wk 6 | ISSO | Joiner, mover and leaver each run end to end in the test tenant with a provenance record and a workflow run |
| Gate 3 — HR feed live for the foundation scope | end of wk 8 | ISSO | The observation period’s differences explained and fixed; a full joiner/mover/leaver cycle on the pilot cohort closed with evidence; zero unmatched-record creations |
| Gate 4 — Lifecycle automated | end of wk 16 | ISSO | Zero missed leavers across a pay period; block within threshold; account-creation tickets retired for covered populations; a test reorganization propagates with zero manual changes |
| Gate 5 — Populations cloud-mastered | end of wk 26 | ISSO | Cloud-mastered populations run the full lifecycle cloud-native with evidence; no AD writes for migrated populations; rollback tested once |
Links to other plans
Other plans that take a date from this one. Waits for it: that plan can’t move until this item finishes, and its float says how far this item can slip before it moves that plan. Must finish by it: that plan’s work has to be done before this item, and the margin says by how much.
| This plan’s item | When | Linked plan | Relationship | Float or margin |
|---|---|---|---|---|
| D-I1 Enterprise person key, and how source keys map to it | end of wk 1 | Attribute-Driven Migration (X-DI1) | Waits for it | 3 d |
| I1.2 Attribute authority map signed (HR’s part is program decision D02) | wk 3 | Attribute-Driven Migration (X-I12) | Waits for it | 2 d |
| I1.5 HR data baselined; employeeId populated; orphan candidates owned | wk 2–4 | Attribute-Driven Migration (X-I15) | Waits for it | 20 d |
| IG3 Gate 3 — HR feed live for the foundation scope | end of wk 8 | Attribute-Driven Migration (X-IG3) | Waits for it | 2 d |
| IG3 Gate 3 — HR feed live for the foundation scope | end of wk 8 | Program master schedule (X-IDL) | Waits for it | 0 |
| I4.3 Joiner and mover automation; rehire and conversion matching validated | wk 11–12 | Attribute-Driven Migration (X-I43) | Waits for it | 12 d |
| IG4 Gate 4 — Lifecycle automated | end of wk 16 | Non-Person Identity Modernization (X-IG4) | Waits for it | 58 d |
| IG5 Gate 5 — Populations cloud-mastered | end of wk 26 | Attribute-Driven Migration (X-IG5) | Reference only | — |
Work breakdown and schedule
Every row, by phase. Float is total float in working days; bold rows are on the critical path. Each row links to the chapter it comes from.
Phase 0 — Program alignment
| ID | Item | Type | Owner or approver | Days | Predecessors | When | Float |
|---|---|---|---|---|---|---|---|
| I0.1 | Integration-point inventory, naming the HR-driven identity feed | Task | HR 2.0 project team point of contact | 5 | — | wk 1 | 2 d |
| I0.2 | Entra migration plan names HR as the source for each population | Task | Program office | 3 | I0.1 (SS) +2 d | wk 1 | 2 d |
| I0.3 | Legacy identity data to retain identified | Task | Records officer | 4 | — | wk 1 | 3 d |
| I0.4 | Privacy basis: routine use, PIA update, minimized attribute set | Task | Privacy officer | 25 | — | wk 1–5 | 0 |
| IG0 | Gate 0 — Inventory signed and submitted | Gate | ISSO | — | I0.1, I0.2, I0.3 | end of wk 1 | 2 d |
Phase 2 — Pipeline build and test
| ID | Item | Type | Owner or approver | Days | Predecessors | When | Float |
|---|---|---|---|---|---|---|---|
| I2.1 | Workforce identity service (middleware) built in-boundary | Task | Identity engineering | 6 | I1.3 | wk 4–5 | 2 d |
| I2.2 | API-driven provisioning apps; least-privilege permissions; throttling sized | Task | Identity engineering | 3 | I1.3 | wk 4 | 5 d |
| I2.3 | Joiner, mover and leaver workflows and custom task extensions | Task | Identity engineering | 6 | I1.4 | wk 4–5 | 3 d |
| I2.4 | End-to-end proof in the test tenant, including device retire and test-CA revocation | Task | Identity engineering | 4 | I2.1, I2.2, I2.3, IG1 | wk 6 | 0 |
| IG2 | Gate 2 — Pipeline proven end to end | Gate | ISSO | — | I2.4 | end of wk 6 | 0 |
Phase 3 — Hybrid go-live (pilot)
| ID | Item | Type | Owner or approver | Days | Predecessors | When | Float |
|---|---|---|---|---|---|---|---|
| I3.1 | Two provisioning agents under a gMSA with OU-scoped rights | Task | Platform teams | 2 | IG1 | wk 6 | 2 d |
| I3.2 | Initial full sync with scoping filters; mismatches reconciled | Task | Identity engineering | 3 | IG2, I3.1, I0.4 | wk 6–7 | 0 |
| I3.3 | Shadow mode on the pilot cohort; every difference explained | Task | Identity engineering | 5 | I3.2 | wk 7–8 | 0 |
| D-I4 | Let the pipeline act on the pilot cohort | Decision | ISSO | — | I3.3 | end of wk 8 | 0 |
| I3.4 | Delta feeds live; first joiner/mover/leaver cycle closes with evidence | Task | Identity engineering | 3 | D-I4 | wk 8 | 0 |
| IG3 | Gate 3 — HR feed live for the foundation scope | Gate | ISSO | — | I3.4 | end of wk 8 | 0 |
Phase 4 — Lifecycle automation and derived access
| ID | Item | Type | Owner or approver | Days | Predecessors | When | Float |
|---|---|---|---|---|---|---|---|
| I4.1 | Leaver automation on for covered populations; block and revocation intervals measured | Task | Identity engineering | 10 | IG3 | wk 9–10 | 0 |
| I4.2 | Exception routes: emergency terminations, litigation holds | Task | Help desk | 5 | IG3 | wk 9 | 25 d |
| I4.3 | Joiner and mover automation; rehire and conversion matching validated | Task | Identity engineering | 10 | I4.1 | wk 11–12 | 0 |
| I4.4 | Hand-kept groups converted to rules, shadow-compared one by one | Task | Platform teams | 25 | I4.1 (SS) +5 d | wk 10–14 | 0 |
| I4.5 | Access packages re-based on the supervisor of record | Task | Identity engineering | 10 | I4.3 | wk 13–14 | 0 |
| I4.6 | A full pay-period cycle with zero missed leavers; test reorganization | Task | ISSO | 10 | I4.3, I4.4, I4.5, I4.2 | wk 15–16 | 0 |
| IG4 | Gate 4 — Lifecycle automated | Gate | ISSO | — | I4.6 | end of wk 16 | 0 |
Phase 5 — Cutover, population by population
| ID | Item | Type | Owner or approver | Days | Predecessors | When | Float |
|---|---|---|---|---|---|---|---|
| D-I3 | Source of authority for contractors and other non-employees | Decision | ICAM governance body | — | IG1 | end of wk 5 | 65 d |
| D-I5 | Order of populations to cut over, aligned to the Core HCM onboarding | Decision | Executive sponsor and CIO | — | IG4 | end of wk 16 | 0 |
| I5.1 | Employee populations retargeted to the Entra app, one by one, evidence-gated | Task | Identity engineering | 40 | D-I5 | wk 17–24 | 0 |
| I5.2 | Contractor populations onboarded from their decided source and retargeted | Task | Identity engineering | 30 | D-I3, I5.1 (SS) +10 d | wk 19–24 | 0 |
| I5.3 | OU-bound policy retired; rollback path tested once | Task | Platform teams | 10 | I5.1, I5.2 | wk 25–26 | 0 |
| IG5 | Gate 5 — Populations cloud-mastered | Gate | ISSO | — | I5.3 | end of wk 26 | 0 |
Responsibility
Who owns what in this plan. Each row has one owner; consulted and informed parties follow the decision matrix.
| Owner or approver | Tasks | Decisions | Gates |
|---|---|---|---|
| Identity engineering | 15 | — | — |
| ISSO | 1 | 1 | 6 |
| Platform teams | 3 | — | — |
| HR | 1 | 1 | — |
| ICAM governance body | 1 | 1 | — |
| Executive sponsor and CIO | — | 1 | — |
| HR 2.0 project team point of contact | 1 | — | — |
| Help desk | 1 | — | — |
| ICAM governance body, with HR and identity engineering | — | 1 | — |
| PIV credentialing office | 1 | — | — |
| Privacy officer | 1 | — | — |
| Program office | 1 | — | — |
| Records officer | 1 | — | — |
Assumptions
- The foundation scope is the pilot cohort, employees only; contractors join when their source is decided (D-I3).
- Book 03’s thresholds (for example 99% correlation on the pilot cohort) are proposed starting criteria, approved or replaced by the agency’s risk governance (Book 03, Chapter 12).
- Lifecycle Workflows needs Entra ID Governance or Entra Suite licenses (Book 03, Chapter 12).
- Durations are illustrative. Phases 4 and 5 run per population, so their length follows the program’s waves.
Schedule risks
| Risk | Effect on the schedule | Response |
|---|---|---|
| The privacy basis (routine use, PIA update) isn’t ready by Gate 1 | Gate 1 can’t be signed, and no production data can flow; G1 slips week for week | Start it on day one; agree the minimized attribute set first (Book 03, Appendix B) |
| HR data is wrong at the source | The pipeline provisions drifted access faster than tickets did | Baseline and fix HR data in Phase 1, before automation (Book 03, Chapter 12) |
| The correlation threshold isn’t met on the pilot cohort | Gate 1 fails; the critical path waits | Start correlation work in week 2 and report the rate weekly |
| The contractor source stays undecided | Contractors stay on COR spreadsheets past wave 2 | Put D-I3 on the ICAM governance body’s agenda before G2 |
Baseline and change control
- Baseline the plan when its first gate is approved: the YAML file, as merged, is the baseline.
- Report weekly, green, yellow or red, against the baseline (Book 01, Chapter 12). Report float, not percent complete: a task’s float says how much slip the plan can still absorb.
- Change the plan only through a reviewed pull request that edits the YAML and regenerates this page, so every change to a date or a dependency has an author, a reviewer and a reason.
- Re-baseline at each gate, after the approver signs it, and whenever a critical-path decision is made late.
Download and adapt
| File | Use it for |
|---|---|
| identity-lifecycle.xml | Microsoft Project desktop (open the XML file; it keeps the dependencies, milestones and owners). The dates start on a placeholder Monday: change the project start date. |
| identity-lifecycle.csv | Excel or any other scheduling tool: every row with its dependencies, early and late dates and float |
| identity-lifecycle-azure-boards.csv | Azure DevOps Boards: an Epic per phase and a Feature per task, gate and decision, with dates and tags (see below) |
| identity-lifecycle-dependencies.csv · add-azure-boards-links.ps1 | The plan’s predecessor links, and a script that adds them in Azure Boards after the import |
| identity-lifecycle-jira.csv | Jira: an Epic per phase and a Task per task, gate and decision, with dates, labels and Blocks links (see below) |
| identity-lifecycle.yaml | The source. Edit the durations, owners and dependencies, then run python scripts/project_plans/build.py to recompute the critical path and regenerate this page, the chart and the downloads. |
TipImporting this plan into Azure DevOps Boards
- In the project, select Boards > Queries > Import work items, choose identity-lifecycle-azure-boards.csv, check the results and select Save items. It creates one Epic per phase with a Feature under it for each task, gate and decision, with start and target dates, which is what Delivery Plans show. Epic and Feature exist in the Agile, Scrum and CMMI processes; in the Basic process, change Feature to Issue in the file first.
- The import can’t create dependency links or assign people. To add the predecessor links, sign in with
az login, add the CLI extension withaz extension add --name azure-devops, and run./add-azure-boards-links.ps1 -Organization https://dev.azure.com/<org> -Project <project> -Plan identity-lifecyclebeside identity-lifecycle-dependencies.csv. It finds the imported items by theirfmw-id-tags and links each one to its predecessors. - Assign people in Boards: each item carries its owner role as an Owner - … tag, and critical-path items carry Critical path. Azure Boards links don’t hold lag or start-to-start timing; each item’s description keeps them.
The dates count from the plan’s placeholder start; shift them when you set the real start. The script hasn’t been run against a live organization yet: test it on a scratch project first.
TipImporting this plan into Jira
- Run the CSV importer (in Jira Cloud, Settings > System > External system import > CSV) with identity-lifecycle-jira.csv. On the second step, set Date format in import file to
yyyy-MM-dd. - Map the columns: Work item ID to Work item ID, Work type to Work type, Parent to Parent, Summary, Description and every Labels column to their fields, Start date to the Start date field, Due date to Due date, and every Blocks column to the Blocks link type. Each phase becomes an Epic with a Task under it for each task, gate and decision; each Blocks column makes that row’s item block the item it names, which carries the plan’s dependencies.
- Assign people in Jira: each item carries its owner role as an
owner-…label, and critical-path items carrycritical-path. Jira links don’t hold lag or start-to-start timing; each description keeps them.
Test the import on a scratch project with a few rows first: the importer doesn’t remove duplicate links and Jira has no bulk delete for them. If the Blocks links don’t come through on your site, import the items first and add the links from the plan’s dependency list in a second pass, as Atlassian recommends. The dates count from the plan’s placeholder start.
TipOpening this plan in Project or Planner
- Microsoft Project desktop opens the XML file directly, with every dependency, milestone and owner.
- Microsoft Planner has no file import of its own: it doesn’t read XML, CSV or Excel. To bring this plan into a Planner premium plan, open the XML file in Project desktop, save it as an
.mppfile, and import that through the Project Power App. Tasks, durations, dependencies and milestones come across; resources and baselines don’t, so assign owners again in Planner. - Without Project desktop, the CSV can feed a Power Automate flow that creates the tasks one by one, but dependencies in a premium plan need Microsoft’s Project schedule APIs, so that’s a build, not an import.
- In a government cloud tenant, check that premium plans are available before relying on Planner for this schedule: Microsoft notes that converting a basic plan to a premium plan isn’t available in GCC.
Project for the web was retired on August 1, 2025, and Project Online on September 30, 2026; Planner is their successor. Project desktop is unaffected.