律所已批准客户门户，但管理员也做受理，审核指引的合伙人下周有听证。实用计划应先考虑这些承诺再许诺上线日期。本示例说明如何设现实范围。
描述首个可用版本
决定首个版本纳入哪些客户和事项。本例目标是参与客户能安全返还所需文件，指定团队能识别未完成项目。迁入所有历史事项可另行决定。
明确批准范围的合伙人和管理交付的人，用双方都理解的语言写验收测试。仅功能清单无法证明客户能完成任务。
- 列出试点用户及获批测试材料。
- 明确谁接受客户指示及访问设置。
- 说明哪些功能和记录不属于首个版本。
- 记录邀请客户前所需条件。
把审核决定纳入日程
文件请求流程仍变化时，培训不能定稿；权限测试依赖获批员工角色。应梳理依赖并预留审核时间。
PMI 2026 年研究说明相互依赖如何增加复杂性，并强调发起人一致性。小律所中，发起人须先解决决定，依赖它的人才能继续。把决定和期限放在受影响工作旁，而非埋在会议记录里。
考虑可能打断项目的客户工作
询问每位参与者实际能为项目投入多少时间。如紧急事项优先，应决定哪些安排调整。默默保留所有期限，只会让交付团队承担冲突。
简短的发起人审查应聚焦会改变计划的决定。应说明延误的影响，而不仅是红色状态标记。
| 问题 | 需要记录的决定 |
|---|---|
| 审核人员无法参与 | 谁可替代，或哪个日期需要调整？ |
| 试点范围扩大 | 哪些额外工作已获批，哪些暂缓？ |
| 访问测试失败 | 谁修复，谁确认复测？ |
| 交付成果已就绪 | 由谁接受，带有哪些未决事项？ |
让项目之外的人尝试
请未配置门户且获授权的客户服务同事完成试点步骤。观察其能否找到请求、识别缺失附件及找到求助联系人。扩大使用前记录缺陷。
结项时，将设置记录和员工指引交给长期管理员，逐项分配剩余问题。在首批真实事项使用门户后安排审核，以区分一次性培训问题和反复设计问题。项目完成应使该人员能够维护服务。