通过

定义项目范围

  • 项目
  • 适用于:
    Microsoft Teams

升级旅程关系图，其中突出显示了“项目定义”阶段。

本文是升级旅程的“项目定义”阶段的一部分，在创建赞助联盟和已确定的利益干系人的项目团队后完成的活动是项目成功的关键。 在继续之前，请确认已经完成了以下活动:

花时间定义项目愿景、范围、目标和治理将有助于确保所有项目利益干系人保持一致，并朝着相同的最终结果努力。 鉴于技术就绪团队和用户就绪团队将独立工作，以将各自的部分拉到一起，这一点尤其重要。 完成本部分后，请在整个项目中参考它，以确保你有望实现所需的最终状态。 使用下面确定的目标来衡量你的结果，并根据需要进行缓解。

   
描述决策点的图标。
决策点
  • 换句话说，你想用这个项目 (完成什么，为什么) 呢？
  • 成功是什么样子的？
  • 风险是什么，你有什么计划来缓解这些风险？
描述后续步骤的图标。
后续步骤
  • 与项目团队和发起人讨论以下部分。
  • 记录此项目的愿景、范围、目标和风险。
  • 重新访问项目团队，验证你是否与合适的团队进行了互动。

项目愿景

你的愿景是回答“我们为什么要做这个项目”的问题的“大局”或最终的最终状态？理想愿景适用于组织的业务驱动因素和用户增值视角，如以下示例所示：

  • 组织业务驱动因素：Microsoft Teams 上的标准化与我们的数字工作场所转型保持一致，使我们能够提高运营效率、消除冗余解决方案并节省 500 万美元。
  • 用户增值：Microsoft Teams (1) 通过为项目笔记、Office 文档、团队成员、对话和会议提供单个位置来节省时间; (2) 通过使用集中式联系人列表和持久聊天跟踪来快速访问对话来简化通信， (3) 缓解了在一个位置存储和访问文件来尝试查找丢失的电子邮件附件的挫折感。

请考虑以下讨论要点来帮助优化愿景：

  • 当前业务流程的说明

  • 现有业务流程的挑战

  • 技术如何帮助克服这些挑战

  • 克服了这些挑战的情况下预期的可衡量业务成果

提示

确定用例和角色以进一步优化项目愿景。

项目范围

你的愿景可能只会随着时间推移而通过不同的阶段实现。 项目范围定义了 此时 项目的重点，并有助于使项目团队专注于其当前任务，使你能够实现你的长期愿景。 例如，你的范围可能会要求你运行试点、部署特定的工作负载（如语音或会议），或者在你计划升级时启用 Teams 和Skype for Business。 作为项目范围的一部分，应评估：

  • 各种共存模式，最适合你的组织。
  • 在迁移到 Teams 之前，Skype for Business和 Teams 共存的最佳方式。
  • 是否应进行 试点 以验证组织中的技术和用户就绪情况。

项目目标

目标定义所需的结果，并使你能够衡量项目的成功。 目标可以定义为 (OKR) 的目标和关键结果 ，项目成功的度量值可以定义为关键 成功指标 (KSIs) 。 项目利益干系人必须充分参与定义 OKR 和 KCI，以帮助确保他们感受到所有权，并将这些成功度量值与定义的项目任务保持一致。 目标应包括技术成功和以用户为中心的成功。

  • OKR 包含你在项目开始时设置的目标，以及你根据定义的节奏 (测量的关键结果，例如每月或每季度) 。 通过查看关键结果，可以确保项目可交付结果按计划进行，或者识别和缓解问题，使项目回到正轨。OKR 通常归类为“已实现”或“未实现”。
  • KSIs 衡量关键结果的质量和成功率，并通过详细说明好和/或坏结果来补充 OKR 的二元性质。 定义 KIS 时，建议使用“特定、可衡量、可分配、现实、时间相关” (SMART) 条件：
    • 特定：针对特定的改进领域
    • 可衡量：量化或至少建议进度的指标
    • 可分配：指定谁将执行此操作
    • 现实：在给定可用资源的情况下，说明可以实际实现的结果
    • 时间相关：指定何时可以实现结果

下表显示了Skype for Business Teams 升级项目的初始阶段的 OKR 和 KCI 示例。

目的 关键结果 要执行的操作
在仅协作模式下，将 Teams 与Skype for Business一起试点 FY19Q2：500 名用户试点已进行并完成
  • 确定试点用户
  • 创建试点测试计划
  • 在 Teams 上启用试点用户
  • 实现试点
  • 执行试点反馈调查
  • 衡量试点成功率
为组织中的所有用户成功运行仅协作模式，同时Skype for Business
  • 60% Skype for Business用户在推出后的 30 天内使用 Teams
  • 用户对 Teams 的满意度≥ 80%
  • 设计和执行广泛的通信和培训计划
  • 在仅协作模式下为 Teams 启用所有用户
  • 每月跟踪使用情况
  • 收集用户反馈
  • 监视网络运行状况/质量
  • 根据需要缓解
类型 关键成功指示器 衡量方式 成功标准 衡量时间
网络和质量 不良音频呼叫的百分比应为最小值 呼叫质量仪表板 (CQD) <3% 的不良 Teams 通话 每周，然后每月
使用情况和认知 聊天、会议和通话体验等于或优于Skype for Business 调查 80% 同意或强烈同意 每周通过试点，推出后
使用情况和采用 用户主动使用解决方案 Microsoft 365 报表或 CQD 90% 的试点用户参与，优于当前解决方案 每周，然后每月
用法和培训 我有足够的培训/帮助资源来成功使用 Teams 试点后调查 80% 同意或强烈同意 试点后、推出后
用户满意度 我会向其他人推荐 Teams 通过试点后调查 (NPS) 的净推广器分数 NPS > 0 试点后、推出后
业务驱动因素 成本节约 应付账款 $X第三方解决方案中的成本支出 六个月，然后是一年，然后是五年后推出

提示

为了帮助确保项目保持正轨，除了定义更大的长期目标外，还考虑定义较小的短期里程碑。 这可以包括作为用户试点的一部分捕获的指标。 考虑时间线时，如果正在等待 Teams 中尚不可用的功能，请使用 Microsoft 365 路线图。

风险和缓解

对于任何项目，都可能出现不可预见的事件或其他因素，使项目偏离正轨。必须主动评估潜在风险，并定义缓解计划以克服可能出现的问题，以便项目可以继续实现目标。 风险寄存器是跟踪项目风险及其潜在影响以及捕获缓解计划的绝佳工具。 下表显示了示例风险寄存器。

风险 可能性 影响 整体 缓解计划
网络质量 中型 高 高 执行网络规划练习。
用户采用率低 高 高 高 在试点和部署阶段主动与用户合作;实施有针对性的意识和培训活动，以创造愿望。

时间表

在确定升级旅程范围时，请务必为关键里程碑设置时间线 (例如，除了完成日期外，) 所有用户启用 Teams 和Skype for Business。 定义的时间线可帮助项目团队实现一致的结束状态，并告知正确的返工计划，从而帮助确保项目保持正轨。请考虑一个速度不太快的时间线， (其中任务可能会被忽视) 或过于遥远 () 可能会失去动力。 理想的时间线考虑：

  • 符合合规性和用户方案要求的产品就绪情况：请参阅 产品路线图 ，以衡量 Teams 何时为组织做好准备。
  • 升级组：确定是启用 Teams 还是按升级组升级用户，这可能会影响整个升级旅程的时间线。
  • 组织因素（如变更冻结、财政年度结束、部署生命周期）：讨论并考虑可能影响升级时间线的任何内部流程。
  • 同时或左右发生的其他更改：考虑捆绑更改或间隔更改，以促进积极的用户体验，并将对工作效率的任何影响降到最低。
  • 资源：与项目利益干系人确认资源分配，以确保你汇集在一起的项目团队有足够的带宽来完成所有必要的任务。

作为参考点，为 Upgrade Pro 旅程的升级前、升级和升级后阶段提供了示例时间线，我们鼓励你根据需要进行调整，以符合组织的特定需求。

完成上述活动后，应该为项目打下坚实的基础。 继续执行技术准备和组织就绪性规划活动。

Skype for Business Online 已于 2021 年 7 月 31 日停用。 为了最大限度地实现权益并确保你的组织有适当的时间完成升级，我们建议你立即开始使用 Microsoft Teams 之旅。