里程碑用产出定义
排期表写「完成权限设计」没有意义，要写成「角色清单评审通过，覆盖首批四个系统」。为什么强调产出？因为产出可核对，延期时能定位到具体环节，而不是笼统说进度落后，向管理层解释时也更站得住。
身份源质量定前段
头两周往往卡在人事数据：岗位名称不统一、离职状态滞后、外包与实习人员归属不清。这些问题怎么处理，直接决定建模能否开始；先抽样看一版真实花名册，再按清洗量估时间，比凭经验拍工期可靠得多。
试点只接一个系统
首个系统要选账号结构简单、接口文档齐全的，目的是跑通链路而不是覆盖最多用户。为什么不能贪多？链路未通就并行接入，联调问题混在一起无法定位；跑通后复制，第二个系统的接入时间通常能压缩。
复核演练不能省
上线前要做一次完整的权限复核与回收演练：导出全量授权、按岗位比对、撤销异常账号、留下记录。不演练就上线，第一次真实审计会暴露大量历史遗留授权，责任边界说不清，整改时还容易打断正常业务。
适用与不适用
适合谁
- 需要在季度内拿出可验收进度的项目组
- 涉及多系统接入、希望分批交付的企业
- 有明确审计或评审时间点的合规项目
不适合谁
- 要求一次性覆盖全部系统且周期被压到极短的项目
典型场景
某制造企业要在年度审计前完成权限收口，只剩十一周。项目组把里程碑压成盘点三周、建模两周、单系统试点三周、复核演练两周、移交一周，并提前把两个无接口的老系统排除在首批之外。审计前一周完成演练，遗留授权清单随报告一并提交。
可执行步骤
- 抽样一版真实花名册，评估身份源质量与清洗所需的工作量
- 把五个里程碑写成可验收的产出，并为每个里程碑指定判定人
- 按接口完备度给系统排序，只让最简单的一个先进入试点
- 把复核与回收演练排在上线之前，并预留整改的变更窗口
常见坑
- 按系统数量线性外推工期，忽略身份源清洗，前段拖延直接吃掉试点时间，最后只能砍掉演练环节。
- 里程碑只写「完成开发」，没有判定人与交付物，评审时双方各说各话，进度长期停在九成。
- 把复核演练排在上线之后，第一次真实审计暴露历史授权，责任归属扯不清，整改被迫中断业务。
自检与验收清单
- 每个里程碑是否有可验收产出与判定人
- 身份源清洗的工作量是否已抽样估算
- 试点系统是否按接口完备度选定并说明理由
- 复核与回收演练是否排在上线之前并留窗口
常见问题
整体要排多久？
取决于系统数量与身份源质量。单系统试点通常三到四周，每增加一个结构类似的系统可压缩到一到两周，老系统改造另计。建议对外只承诺里程碑，不承诺总工期，否则一次延期就会推翻全部计划。
能不能先上线再补审计？
技术上可以，但风险不对称：没有审计的系统一旦出现越权访问，事后无法举证。若业务确实等不及，至少先把登录、授权变更、敏感数据导出三类事件接入，其余按季度补齐并写明计划。
评审时间点固定，怎么排？
从评审日倒推，先锁定复核演练与整改窗口，再压缩建模与试点；宁可缩小首批系统范围，也不要压缩演练。范围可以在确认单里写明分期，演练缺失则是难以补救的质量缺口。