プロジェクトの対象範囲を定義する
この記事は、アップグレード体験のプロジェクト定義ステージの一部であり、特定した利害関係者からスポンサーシップ連合とプロジェクト チームを作成した後に完了するアクティビティが、プロジェクトの成功の鍵となります。 先に進む前に、次のアクティビティを完了していることを確認してください。
プロジェクトのビジョン、スコープ、目標、ガバナンスを定義する時間を取ることで、すべてのプロジェクト関係者が同じ最終結果に向けて調整され、作業を行うのに役立ちます。 これは、技術的準備チームとユーザー準備チームが個別に作業し、それぞれの部分をまとめることを考えると、特に重要です。 このセクションを完了したら、プロジェクト全体で参照して、目的の終了状態を達成するために軌道に乗っていることを確認します。 以下で特定した目標を使用して、結果を測定し、必要に応じて軽減します。
 判断ポイント |
|
 次の手順 |
|
Project Vision
あなたのビジョンは、「なぜこのプロジェクトをやっているのか」という質問に答える"全体像"または最終的な最終状態です。理想的なビジョンは、次の例に示すように、organizationのビジネス ドライバーとユーザー付加価値の観点に対応します。
- 組織のビジネス ドライバー: Microsoft Teams での標準化は、デジタル ワークプレースの変革に沿っており、運用効率を向上させ、冗長なソリューションを排除し、500 万米ドルを節約できます。
- ユーザーの付加価値: Microsoft Teams (1) は、プロジェクトノート、Office ドキュメント、チーム メンバー、会話、会議に 1 つの場所を提供することで時間を節約します。(2) 一元化された連絡先リストと永続的なチャット追跡を使用して会話にすばやくアクセスすることでコミュニケーションを簡素化し、(3) ファイルを 1 か所に格納してアクセスすることで、そのメールの添付ファイルを見つけようとするフラストレーションを軽減します。
ビジョンの改善に役立つ次のディスカッション ポイントを検討してください。
現在のビジネス プロセスの説明
既存のビジネス プロセスに関する課題
テクノロジがこれらの課題を克服するのにどのように役立つか
課題を克服したときに予期される測定可能なビジネス成果。
ヒント
ユース ケースとペルソナを特定して、プロジェクト ビジョンをさらに改善します。
プロジェクト スコープ
あなたのビジョンは、さまざまなフェーズを経て、時間の経過と同時に実現される可能性があります。 プロジェクト スコープは、 この時点での プロジェクトの焦点を定義し、プロジェクト チームが現在のタスクに集中し続け、長期的なビジョンを実現できるようにするために役立ちます。 たとえば、スコープでは、パイロットの実行、音声や会議などの特定のワークロードのデプロイ、時間の経過と共にアップグレードを計画する際にSkype for Businessと共に Teams を有効にすることを求める場合があります。 プロジェクト スコープの一部として、次を評価する必要があります。
- さまざまな共存モード。これは、organizationに最適です。
- Teams に移行する前にSkype for Businessと Teams が共存するための最良の方法。
- organizationで技術的およびユーザーの準備状況を検証するためにパイロットを実施する必要があるかどうか。
プロジェクトの目標
目標は目的の結果を定義し、プロジェクトの成功を測定できるようにします。 目標は 目標と主要な結果 (OKR) として定義でき、プロジェクトの成功の尺度は 主要な成功指標 (KSI) として定義できます。 OCR と KSI の定義にプロジェクト関係者から完全に参加して、所有権を感じ、これらの成功の尺度を定義されたプロジェクト タスクに合わせることが不可欠です。 目標には、技術的な成功とユーザー中心の成功の組み合わせを含める必要があります。
- OKR には、プロジェクトの開始時に設定した目標と、定義された間隔で測定する主要な結果 (月単位や四半期単位など) が含まれます。 重要な結果を確認することで、プロジェクト成果物がスケジュールに従っていることを確認したり、問題を特定して軽減してプロジェクトを軌道に乗せるしたりできます。OKR は通常、"達成済み" または "達成されていない" に分類されます。
- KSIs は 、主要な結果の品質と成功を測定し、良い結果や悪い結果を詳細に示すことによって、OKR のバイナリの性質を補完します。 KSI を定義するときは、"特定、測定可能、割り当て可能、現実的、時間関連" (SMART) 条件を使用することをお勧めします。
- 特定: 改善のために特定の領域を対象とする
- 測定可能: 進行状況の指標を定量化するか、少なくとも提案する
- 割り当て可能: 実行するユーザーを指定する
- リアリスティック: 使用可能なリソースを指定して、現実的に達成できる結果を示します
- 時間関連: 結果を達成できるタイミングを指定する
次の表は、Skype for Businessから Teams へのアップグレード プロジェクトの初期フェーズの OKR と KSI の例を示しています。
| 目的 | キーの結果 | 実行するには |
|---|---|---|
| コラボレーション専用モードで、Skype for Businessと共に Teams をパイロットする | 19Q2: 500 人のユーザー パイロットが実施され、完了しました |
|
| Skype for Businessと共に、organization内のすべてのユーザーに対してコラボレーション専用モードを正常に実行する |
|
|
| 種類 | 主要な成功指標 | 測定方法 | 成功の条件 | 測定済み |
|---|---|---|---|---|
| ネットワークと品質 | 低品質の音声通話の割合は最小限にする必要がある | 通話品質ダッシュボード (CQD) | <Teams での低品質通話の 3% | 週単位、月単位 |
| 使用状況と認識 | チャット、会議、通話エクスペリエンスは、Skype for Businessと同じかそれ以上です | アンケート | 80% が同意するか、または強く同意します | パイロット、ロールアウト後の週単位 |
| 使用状況と導入 | ユーザーが積極的にソリューションを利用している | Microsoft 365 レポートまたは CQD | パイロット ユーザーからの 90% の参加、現在のソリューションよりも優れています | 週単位、月単位 |
| 使用状況とトレーニング | Teams を正常に使用するための適切なトレーニング/ヘルプ リソースがありました | パイロット後の調査 | 80% が同意するか、または強く同意します | パイロット後、ロールアウト後 |
| ユーザーの満足度 | 他のユーザーに Teams をお勧めします | パイロット後調査によるネット プロモーター スコア (NPS) | NPS > 0 | パイロット後、ロールアウト後 |
| ビジネス ドライバー | コスト削減 | 買掛金 | サード パーティ製ソリューション$X 100 万のコスト支出 | 6 か月後、1 年後、ロールアウト後 5 年 |
ヒント
プロジェクトを確実に軌道に乗り続けるために、より大きな長期的な目標に加えて、より小規模で短期的なマイルストーンを定義することを検討してください。 これには、ユーザー パイロットの一部としてキャプチャするメトリックを含めることができます。 タイムラインを検討するときは、Teams でまだ利用できない機能を待っている場合は、Microsoft 365 ロードマップを使用してください。
リスクと軽減策
プロジェクトでは、予期しないイベントやその他の要因が発生し、プロジェクトが軌道に乗り出す可能性があります。潜在的なリスクを事前に評価し、発生する可能性のある問題を克服するための軽減計画を定義して、プロジェクトが目標に向かって進むようすることが重要です。 リスク レジスタは、プロジェクトのリスクとその潜在的な影響を追跡し、軽減計画をキャプチャするための優れたツールです。 次の表に、リスク レジスタのサンプルを示します。
| リスク | 可能性 | 影響 | 全体 | 軽減計画 |
|---|---|---|---|---|
| ネットワーク品質 | 中 | 高 | 高 | ネットワーク計画演習を実行します。 |
| ユーザーの導入率が低い | 高 | 高 | 高 | パイロットフェーズとデプロイフェーズ中にユーザーと積極的に連携する。目標を達成し、意欲を生み出すトレーニング キャンペーンを実施します。 |
タイムライン
アップグレード体験のスコープを設定するときは、完了日に加えて、主要なマイルストーンのタイムライン (たとえば、すべてのユーザーに対して teams をSkype for Businessと共に有効にする) を設定してください。 定義されたタイムラインは、プロジェクト チームが一貫した終了状態に向かって進むのに役立ち、適切な作業バック スケジュールを通知し、プロジェクトが確実に軌道に乗っていることを確認するのに役立ちます。加速しすぎず (タスクが見落とされる可能性がある)、または遠すぎる (モメンタムが失われる可能性がある) タイムラインを検討してください。 理想的なタイムラインアカウントは次のとおりです。
- コンプライアンスとユーザー シナリオの要件に対する製品の準備: 製品ロードマップを参照して、Teams がorganizationの準備ができている時期を測定します。
- アップグレード グループ: Teams を有効にするか、アップグレード グループ別にユーザーをアップグレードするかを決定します。これは、アップグレード体験全体のタイムラインに影響する可能性があります。
- 変更の凍結、会計年度の終了、デプロイライフサイクルなどの組織の要因: アップグレードタイムラインに影響を与える可能性がある内部プロセスについて説明し、説明します。
- 同時または同時に発生するその他の変更: 変更をバンドルするか、間隔を空けて、ユーザー エクスペリエンスを向上させ、生産性への影響を最小限に抑えます。
- リソース管理: プロジェクト関係者とのリソース割り当てを確認して、一緒に集めたプロジェクト チームが必要なすべてのタスクを完了するのに十分な帯域幅を持っていることを確認します。
参照ポイントとして、Upgrade Pro 体験のアップグレード前、アップグレード、アップグレード後の各フェーズに関するサンプル タイムラインが用意されています。これは、organizationの特定のニーズに合わせて必要に応じて調整することをお勧めします。
上記のアクティビティを完了すると、プロジェクトの強固な基盤が得られます。 技術的な準備と組織の準備計画活動を続行します。
Skype for Business Online は 2021 年 7 月 31 日に廃止されました。 特典の実現を最大化し、organizationにアップグレードを完了するための適切な時間を確保するために、Microsoft Teams への旅を今すぐ開始することをお勧めします。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示