Deal Closing
Implementation Kickoff: 顧客成功の旅の開始
同じSaaSプロダクト、同じ顧客プロフィール、同じ期限を約束した2つの実装案件がありました。6ヶ月後:
実装プロジェクトA:
- 予定通りにライブ化(90日)
- ユーザー採用率: 85%
- 顧客満足度: 9/10
- 顧客コメント: 「キックオフが雰囲気を作りました。何を期待すべきか、何をしなければならないかが明確でした。」
実装プロジェクトB:
- 45日遅延でライブ化(135日)
- ユーザー採用率: 42%
- 顧客満足度: 5/10
- 顧客コメント: 「最初から混乱していました。期待が常に変わり、方向性が一致することはありませんでした。」
その違いは何でしょうか。キックオフです。
実装プロジェクトAは、ステークホルダーを調整し、明確な期待値を設定し、モメンタムを構築する準備の整ったキックオフで開始しました。実装プロジェクトBは、急いで実施されたキックオフで開始し、目的、タイムライン、責任について誰もが混乱したままでした。根本的な原因は、実装チームに重要なコンテキストを残さない、不十分なsales-to-CS handoff practicesにしばしば遡ります。
私は200以上の実装キックオフを実施してきました。うまくいくものは同じ特性を共有しています:現実的なものについての徹底的な誠実さ、明確なロール、そして人々が2日目に実際に開始するアクションアイテムです。失敗するものは?専門的に聞こえますが、誰も次に何が起こるかを知りません。
これはプロジェクト管理理論ではありません。神経質な顧客、限定的なリソース、既に積極的なタイムラインを抱えているとき、実際に機能することです。
キックオフが重要な理由(思った以上に)
ほとんどのチームはキックオフを形式的なものと見なしています。ボックスをチェック、チームを紹介、いくつかの会議をスケジュール、完了。
それはあなたが実装プロジェクトBのようになる方法です。
適切なキックオフなしで実際に起こること
あなたの顧客は1つのことを期待しています。あなたは別のものを提供します。どちらかが間違っているからではなく、誰も「成功」が何を意味するかについて具体的になっていないからです。
営業担当者は「簡単な統合」を約束しました。顧客は「プラグアンドプレイ」と聞きました。あなたの実装チームは40時間のIT作業が必要であることを知っています。誰もこれらの違いを解決しなかったので、3週目に、顧客は時間がかかっていることに激怒しています。
または、5人のステークホルダーがいて、みんなが自分たちが意思決定者だと思っています。2週目に、誰もあったことのない誰かが、プロジェクト全体をブロックします。セキュリティにサインオフする必要があることがわかりました。キックオフで誰が存在するかを知らなかったため、誰も言及しませんでした。
またはタイムラインは理論的には素晴らしく見えますが、既に満杯の顧客リソースが必要です。彼らは約束したものを提供できず、プロジェクトが停滞し、誰もが互いを責めます。
適切なキックオフが実際に行うこと
それは誰もが具体的になるように強制します。 「営業効率を改善する」ではなく、「ゴーライブから120日以内に、適格なリードから成約済み案件までの時間を60日から42日に短縮する。」
それはあなたのプロジェクトを殺すような人たちを浮き彫りにします。 IT営業担当者の呼び出しにはいなかったが拒否権を持つセキュリティ担当者。実は懐疑的だが黙っていた経営幹部スポンサー。これが経営陣の恐ろしい考えだと思うエンドユーザー。
それはこすぐ付く責任を作成します。 同僚の部屋に満ちたその中で誰かが「はい」とアクションアイテムに言うとき、後でメールで言うよりも、彼らは実際にそれをする可能性ははるかに高いです。
それは速く信頼を構築します。 あなたの顧客はちょうど数ヶ月を営業担当者と過ごしました。その担当者は、すべてが簡単に聞こえるようにインセンティブが設定されていました。今、彼らは悪い取引を売られたのか疑問に思っています。難しいもの、彼らの努力が必要なもの、そして間違った可能性があるものについて正直なキックオフは、チェックを現金化するためだけではなく、これを機能させるためにここにいることを彼らに伝えます。
強力な実装キックオフは価値実現時間を50%増加させ、ユーザー採用を40%改善します。何らかの魔法の方法論のためではなく、開始時の明確さは全体を通じて混乱を防ぐからです。問題が小さいときにそれをキャッチします。トレードオフが緊急事態になる前に調整します。
タイミング: キックオフを行う時期
契約署名の翌日にスケジュールしないでください。3週間も待たないでください。
最適なスポット:クローズ後3~7日
早すぎません。 実際に準備する時間が必要です。deal handoff protocolに従ったハンドオフノートを確認してください。何が約束されたかを理解してください。野心的ではなく現実的なドラフト計画を構築してください。顧客も時間が必要です。彼らはチームを組織し、実際に部屋にいるべき人を把握し、営業プロセス後に息をつかむ必要があります。
遅すぎません。 1週間以上待ち、他の優先事項が引き継ぎます。顧客の興奮は薄れます。あなたが無秩序かどうかを疑問に思い始めます。あなたが払ったセールスモメンタムは蒸発します。
実践的なプロセス:
- 日0(契約署名):CSチームは営業からのハンドオフを取得します
- 日1:CSは祝賀の言葉とともに連絡し、提案されたキックオフ日付を提示します
- 日2~3:CSチームはハンドオフ資料をレビューして準備します
- 日3~7:キックオフが発生します
実際に機能するアウトリーチ
クローズから24時間以内に、これを送信してください:
こんにちは [顧客チャンピオン],
すべてを完成させたことをおめでとうございます。[彼らが気に掛ける具体的な目的]をお手伝いするのに興奮しています。
開始するために、実装キックオフをスケジュールしましょう。この90分セッションカバーします:
- 実装ロードマップとタイムライン
- ロールと責任
- 成功基準とメトリック
- 次のステップと即時アクション
[日付1]または[日付2]を[時間]に提案しています。どちらが機能するか、または別案を提案してください。
また、あなたのチームからこれらの人を招待してください:
- [ロール1:彼らがそこにいる必要がある具体的な理由]
- [ロール2:具体的な理由]
- [ロール3:具体的な理由]
一緒にこれを開始するのが楽しみです!
[あなたの名前]
ほとんどのチームが送信するテンプレート廃棄物と異なることに注意してください:会議から何を得るかについて具体的です。実際にはそこにいる必要がある人と理由を正確に伝えています(そのため、ランダムな人を送信することはできません)。あなたのカレンダーをナビゲートするのではなく、時間を提案しています。
より早く移動するとき(1~2日)
時々あなたは速く移動する必要があります:
- 彼らは緊急のビジネスニーズを持っています
- 季節ウィンドウがあります(Q4の前にライブになる必要があります)
- ステークホルダーの可用性の狭いウィンドウがあります
- 競争圧力(彼らは代替手段を評価しています)
要件:CSチームは短期間で準備できます。顧客ステークホルダーは実際に参加できます。実装リソースはすぐに開始する準備ができています。
3つの要件すべてを満たすことができない場合、それを急ぐべきではありません。悪いキックオフは、わずかに遅延した1つより悪いです。
より遅く移動するとき(7~14日)
時々遅延は理にかなっています:
- 重要なステークホルダーがスケジュール済みの休暇を持っている
- 内部調整が必要な複雑なエンタープライズ
- 予算またはリソース承認がまだ保留中
- 調整が必要な複数の子会社
しかし、静寂しないでください。キックオフ前の資料をレビュー用に送信してください。簡潔な中間チェックインをスケジュールしてください。関係を温かく保ちます。
部屋に誰が必要か
これはアジェンダよりも重要です。
適切な人を取得し、どんな問題でも解決できます。間違った人を取得し、決定を求めるのに何週間も費やします。
顧客側:実際に必要な人
経営幹部スポンサー(購入を支援した人):
最初は15分、最後は10分必要です。それだけです。これはexecutive engagementのベストプラクティスと一致しており、ディール周期全体をサポートしています。
なぜか?彼らは他の組織にこれが重要であることを示します。彼らはこの投資をしたい理由についてのコンテキストを提供します。彼らはプロジェクトをサポートするために公開的にコミットしています。
彼らがライブで参加できない場合、2分間のビデオを記録してもらいます。「ハイチーム、私たちがこれをしている理由と、それがなぜ重要であるかはこちらです。」キックオフで再生します。これは90%と同じくらい効果的です。
プロジェクトリード/チャンピオン(これを日々推進している人):
これはあなたの主要な連絡先です。彼らはミーティング全体に存在する必要があり、積極的に参加しています。営業周期中のchampion developmentの努力がこの人を特定すべきでした。
彼らは決定を下します。彼らは顧客リソースを調整します。ものが横に進むと、テキストメッセージを送信する人です。彼らがキックオフに参加していない場合、あなたは苦労しています。
テクニカルリード/IT担当者:
統合、データマイグレーション、またはテクニカル構成を含む実装では、顧客のテクニカル環境を理解している人が必要です。
すべての質問について「マネージャーに確認する」必要がある若いIT担当者ではありません。テクニカルタイムラインにコミットし、テクニカルリスクにフラグを立てることができる人。
エンドユーザー代表(1~2人が毎日これを使用する):
彼らは、提案されたワークフローが実際に理にかなっているかを検証します。採用課題は経営幹部レベルから見えないことを特定します。ユーザーコミュニティとの買い込みを構築します。
5つを持ってこないでください。意思決定をする代わりに、グループダイナミクスの管理に全キックオフを費やします。
ベンダー側:あなたのチーム
顧客成功マネージャー(あなたがCSオーナーの場合):
あなたはキックオフをリードしています。あなたは関係の所有者です。この顧客が成功するかどうかは、あなたが責任を負います。
実装スペシャリスト(実際の作業を行う人):
彼らは実装計画を提示します。彼らは日々の活動を管理します。顧客と一緒に細部に入る人です。
技術リード/ソリューションアーキテクト(複雑な実装の場合):
統合またはカスタム構成の場合、テクニカル実行可能性について信頼性を持って話し、テクニカルリスクを浮き彫りにすることができる人が必要です。
営業担当者(オプションですが通常は含めるのが賢い):
最初の15分で彼らを持ってください。彼らは関係の継続性を強化し、営業周期からコンテキストを提供し、関係を上品に手放します。
その後、彼らは出発します。顧客は、営業担当者がもうショーを実行していないことを知る必要があります。
例外:顧客が明らかに移動する準備ができているか、すでに素晴らしいハンドオフを持っている場合はスキップしてください。
キックオフ前準備(成功するかどうかを決定する部分)
ほとんどのチームは30分を過ごしてジェネリックデッキを一緒に投げます。それから彼らはなぜキックオフがうまくいかないのかを疑問に思っています。
キックオフの前にこれらの質問に答えることができない場合、あなたは準備ができていません:
- この顧客が達成しようとしているビジネス成果は何ですか(具体的に)?
- 営業担当者が約束したこと(正確に)?
- 重要なステークホルダーが誰であり、それぞれが何を気に掛けていますか?
- この顧客の複雑さとリソースを考えると、現実的なタイムラインは何ですか?
- 成功への最大の2~3のリスクは何ですか?
カスタマイズされたキックオフデッキを構築する
ロゴがスラップされた上のテンプレートデッキではありません。あなたが彼らのビジネスを理解していることを示すデッキ。
その特定の目的を参照してください。あなたのではなく、彼らの用語を使用してください。彼らの制約(「Q4があなたの忙しい季節であることを知っているので、10月のUATをスケジュールしました」など)を説明するタイムラインを表示してください。
含めてください:
- 彼らの言葉での彼らのビジネス目的
- 彼らのニーズに特有の実装計画
- 彼らの制約を反映するタイムライン
- 彼らの目標に一致する成功メトリック
- 実際の名前を持つRACIマトリックス(単なるロールではなく)
ドラフトプロジェクト計画を構築する
「タイムラインについては一緒に把握します」とのキックオフに入らないでください。現実的な開始点が必要です。
特定のマイルストーンを持つフェーズに分割します。依存関係を特定します。顧客リソースが必要な場所と、コミットする必要がある時間を呼び出します。
それを現実的にして、野心的にしてください。達成できる8週間のタイムラインを提案する方が良い方が、すべてが完璧に進むことが必要な6週間のタイムラインではありません。
内部チームブリーフィング(24時間前)
実装チームをまとめて、以下を通り抜けます:
- 営業ハンドオフからの顧客背景とコンテキスト
- ステークホルダーマップと誰が何の権限を持っているか
- 営業中に行われた特定のコミットメント
- 既知のリスクとそれらに対処する方法
- キックオフで誰が何を提示するか
これは、キックオフ中の「オフラインで同期する必要があります」という会話を防ぎます。顧客の前に配置する前に配置します。
顧客ブリーフィング(48時間前)
メールを送信します:
- 確認された日付、時刻、期間
- ミーティングリンク
- アジェンダと目的
- 彼らの側から参加する必要がある人(理由付き)
- 彼らが完了する必要がある事前の仕事
- 事前に読む必要がある資料
これにより、彼らは準備ができます。彼らは質問を考えます。彼らは彼らの思考を整理します。彼らは最初のものすべてを聞く代わりに、決定を下す準備をして現れます。
キックオフの実行(実際のミーティング)
90分。それは通常正しい長さです。より短く、あなたは急いでいます。より長く、人々はチューン中です。
ウェルカムと紹介(10分)
ここにいる理由から始めます:「今日の目的は、目的に合意し、実装アプローチをレビューし、誰が何をするかを定義し、明確な次のステップで歩み去ることです。」
その後、ラウンドロビンの紹介。名前、ロール、そして何について興奮しているか、または達成したいと思っていることについて。
これはフィラーではありません。あなたは誰が何を気に掛けているかを学んでいます。「このパイプラインに最終的に可視性を得るために私を助けることを望んでいます」という人は、彼らにとって何が重要かを伝えています。それを覚えてください。
グラウンドルール:いつでも質問します。これは協力的です。私たちはメモを取って、それらを共有します。後ろに得た場合、私たちは調整します。
ビジネス目的レビュー(15分)
「[営業代理人]と[チャンピオン]との会話に基づいて、ここで達成しようとしていることについての私たちの理解があります...」
それから彼らの目的を提示し直します。一般的なもの。営業に必要であると彼らが言った具体的な成果。
その後、尋ねてください:「これはあなたが達成しようとしていることを正確にキャプチャしていますか?何を追加または変更しますか?」
これはあなたが早期に不一致をキャッチする場所です。多くの営業が簡略化された。優先事項が変わった。異なるステークホルダーが異なる目的を持っています。
メトリックをより深く掘り下げます:「サイクルタイムを30%削減することについて言及しました。助けてください。今日どこにいますか?成功は具体的に何のように見えますか?これをどのように測定しますか?いつ結果を見る必要がありますか?」
具体的に取得するか、後でそれを後悔します。
ソリューション概要とスコープ(20分)
あなたのソリューションが彼らの目的にどのように対処するかを説明してください。機能リストではなく、使用ケース。
「これがあなたの[シナリオ]の特定の使用ケースです。今日、X を手動で行います。これにより、Y 問題が発生します。私たちのソリューションを使用して、代わりに Z を行います。これにより、[結果]が得られるはずです。」
次に、スコープを明示的に定義します。あなたのSOW creation processは既にこれらの境界を文書化すべきでした。
フェーズ1のスコープ内:
- 機能 A
- システム B との統合
- 50人のユーザーへのトレーニング
スコープ外(フェーズ2または将来):
- 機能 C
- システム D との統合
- 高度なカスタマイズ
これにより、6週目の「それが含まれていると思った」という会話が防ぎます。それがスコープに入っていない場合、今それを言います。
実装計画とタイムライン(20分)
フェーズを説明します。それぞれについて:
- 何が起こるか
- 何が配信されるか
- 彼らから必要なもの
- どのように終わりを知ることができるか
特定の日付を持つタイムラインを表示します。依存関係を呼び出します:「1週目までにAPI アクセスが必要になります。そうしないと、3週目が遅れます。」
その後、検証します:「このタイムラインはあなたの可用性で機能しますか?どのような懸念がありますか?」
彼らが懸念を提起した場合、それらについて議論してください。フェーズを調整できますか?彼らはより多くのリソースが必要ですか?タイムラインを延長すべきですか?
現在知る方が、現実的でないものにコミットして、後で公開的に失敗するより良い。
ロールと責任(15分)
RACIマトリックスを表示します。各主要活動についての責任者、責任者、相談対象、通知対象。
重要な顧客責任を呼び出します:「あなたのチームから、[チャンピオン]を調整するために、[IT リード]は技術的設定を処理し、[エンドユーザー]はUATに参加します。」
ベンダー責任を呼び出します:「私たちのチームから、[CSマネージャー]は全体的な成功を所有し、[実装スペシャリスト]は日々の実行を処理します。」
決定権を明確にします:「ほとんどの決定では、[チャンピオン]が意思決定者です。テクニカル決定の場合、[ITリード]は権限を持っています。スコープまたはタイムラインの変更の場合、[経営幹部スポンサー]に段階的に上げます。」
エスカレーションパスを定義します:「問題が発生した場合、これがプロセスです...」
これにより、「あなたがそれをやっていると思った」という災害が防ぎます。
コミュニケーションとガバナンス(10分)
どのように配置を保つか:
- 週次ステータス会議(30分、特定の曜日/時刻)
- コミュニケーションチャネル(正式な対象はメール、迅速な質問はSlack)
- 各会議後のステータスレポート
- 問題をエスカレートする方法(週次会議まで待機しないでください。詳細が停止している場合)
スコープまたはタイムラインの変更の場合:「影響について議論し、変更リクエストを文書化し、影響を評価し、進む前に両側から承認を取得します。」このプロセスは、contract execution中に適用した厳密さを反映しています。
成功基準とメトリック(10分)
成功をどのように測定するかを定義します。
主要インジケータ(初期信号):
- ユーザー採用率(目標:60日までに> 80%)
- 機能使用(目標:週に5+ 主要機能を使用)
遅延インジケータ(ビジネス成果):
- [特定のターゲットを伴う彼らの主要なビジネスメトリック]
- [セカンダリメトリック]
測定アプローチ:
- 週次:使用と採用メトリック
- 月次:運営メトリクスを含むビジネスレビュー
- 四半期:経営幹部ビジネスレビュー
30/60/90日間のクイックウィンを提案します。モメンタムを構築し、価値を証明する小さく、目に見える成果。
質問と次のステップ(10分)
「質問や懸念はありますか?」
それらに正直に対処してください。売りすぎないでください。懸念を却下しないでください。
その後、即時の次のステップ:
今週末までに私たちから:
- 会議記録と更新されたタイムラインを送信
- 週次ステータス会議をスケジュール
- アクセスリクエストフォームを送信
今週末までにあなたから:
- アクセスプロビジョニングを完了
- UAT参加者を特定
- プロジェクト計画をレビューしてサインオフ
次回のミーティング:
- 週次ステータス:[特定の日付/時刻]
コミットメントを閉じます:「あなたの時間をありがとうございます。私たちはあなたの成功にコミットしており、このパートナーシップについて興奮しています。」
顧客チャンピオンまたは経営幹部スポンサーにそれを閉じてもらいます。コミットメントを肯定するか、最終的な懸念を提起する機会を与えます。
キックオフ後に起こること
キックオフはフィニッシュラインではありません。スタートガンです。
24時間以内
配信物を送信します:
- ミーティング記録
- 詳細なメモ
- アクションアイテムと担当者および期限
- 出てきた質問への回答
3日待たないでください。新しい間に送信してください。
日1~3
実際の仕事を始めます。テクニカルセットアップを開始します。繰り返しミーティングをスケジュール。内部タスクを割り当てます。
顧客も彼らのアクションアイテムに取り組むべきです。アクセスプロビジョニング。UAT参加者の識別。プロジェクト計画レビュー。
最初の週のチェックイン
簡潔なコール又はメール:「これらのキックオフアクションアイテムでどのように行われていますか?ブロッカーはありますか?」
何か詰まっている場合は、すぐに対処してください。最初のステータスミーティングまで待たないでください。
良いモメンタムのように見えるもの
- 日1:キックオフ
- 日2:両側がアクションアイテムで作業
- 週1:複数のワークストリームがアクティブ
- 週2:早期の進捗が表示される
悪いモメンタムのように見えるもの
- 日1:キックオフ
- 週1:フォローアップを待っています
- 週2:まだ待っています
- 週3:次のステップについて混乱
2番目のパターンが表示されている場合、問題があります。キックオフは真の責任を作成しませんでした。
キックオフが失敗する理由
紙の上では良く見えたが、困った実装につながった多くのキックオフを見ました。
一般的なテンプレートキックオフ
あなたはみんなに見せるのと同じデッキを提示します。顧客は準備しなかったことを見ます。彼らはあなたが気に掛けているのか疑問に思います。信頼は低く始まり、そこからドロップします。
セールスハングオーバーキックオフ
営業は現実的ではないものを約束しました。キックオフでこれを発見します。顧客は欺いたと感じています。実装は破損した信頼と不一致の期待で開始します。
予防:営業ハンドオフを慎重にレビューしてください。何かが聞こえない場合は、キックオフの前に営業担当者に電話してください。これが理由ですclosing readiness assessmentは現実的な実装期待を含むべきです。期待を早期にリセットします。
欠落した権限キックオフ
キックオフ内のすべてが配置されているようです。次に、そこにいなかった誰かがすべてをブロックします。彼らが実際の意思決定者であることがわかり、彼らはアイデアを嫌います。
予防:キックオフ準備中に誰が拒否権を持つかを明示的に尋ねてください。彼らを部屋に入れるか、事前にそれらを配置してください。営業プロセス中の適切なstakeholder alignmentはこれを完全に防ぎます。
曖昧なキックオフ
すべてが良く聞こえますが、何も具体的ではありません。成功基準は不明瞭です。タイムラインには実日付がありません。ロールは不明です。誰もが肯定的に感じて出発しますが、月曜日の朝に何をすべきか誰も知りません。
予防:具体性を強制してください。実日付。本当の名前。実メトリック。具体的なアクションアイテム。
オーバーコミットメントキックオフ
すべてが完璧に進むことが必要なタイムラインを約束します。顧客は興奮しています。その後現実が打たれ、期限を逃します。信頼は蒸発します。
予防:タイムラインにバッファを構築してください。何が悪くなるかについて正直でください。約束を少なく、より多くを提供します。
なぜこんなに重要なのか
私は200以上を実行しました。パターンは明確です:
強力なキックオフは、オンタイム実装、高採用、幸せな顧客、更新、および拡張につながります。
貧弱なキックオフは、遅延、低採用、不満のある顧客、困難な更新、および拡張なしにつながります。
その違いはプロダクト品質ではありません。チームスキルではありません。成功のように見えるもの、誰がしているか、現実的な道が前向きかどうかについてすべてが配置されているかどうかです。
投資はほどほどです:4~6時間の準備、90分のミーティング時間、2~3時間のフォローアップ。
リターンは巨大です:価値実現時間が50%高速、採用が40%高い、保持が30%向上。
キックオフを重要な成功の瞬間として扱う組織は、それらを通し抜けるか完全にスキップする組織よりも大幅に優れています。
真の目標
キックオフはアジェンダをカバーすることではありません。それは皆をその部屋から出て行かせることです:
- 成功のように見えるもののについての明確さ
- そこに到達する現実的な計画があるという自信
- 彼らの部分をしてコミットメント
- 彼らが一緒に働くチームとの接続
あなたの顧客が自信を感じ、明確で興奮して出発した場合、成功するための設定です。
彼らが不確実、圧倒、または懐疑的に感じて出発した場合、最初から戦いはします。
完全に準備してください。プロフェッショナルに実行してください。すぐにフォローします。
その後、実装が成功し、ユーザーが迅速に採用し、顧客が支持者になります。
キックオフは実装の始まりではありません。それは長期的な顧客成功の基盤です。
関連リソース
顧客成功を推進する準備はできていますか? チェックアウトcustomer onboarding initiationオンボーディング戦略とaccount transition関係継続のために。
詳細情報:

Tara Minh
Operation Enthusiast
On this page
- キックオフが重要な理由(思った以上に)
- 適切なキックオフなしで実際に起こること
- 適切なキックオフが実際に行うこと
- タイミング: キックオフを行う時期
- 最適なスポット:クローズ後3~7日
- 実際に機能するアウトリーチ
- より早く移動するとき(1~2日)
- より遅く移動するとき(7~14日)
- 部屋に誰が必要か
- 顧客側:実際に必要な人
- ベンダー側:あなたのチーム
- キックオフ前準備(成功するかどうかを決定する部分)
- カスタマイズされたキックオフデッキを構築する
- ドラフトプロジェクト計画を構築する
- 内部チームブリーフィング(24時間前)
- 顧客ブリーフィング(48時間前)
- キックオフの実行(実際のミーティング)
- ウェルカムと紹介(10分)
- ビジネス目的レビュー(15分)
- ソリューション概要とスコープ(20分)
- 実装計画とタイムライン(20分)
- ロールと責任(15分)
- コミュニケーションとガバナンス(10分)
- 成功基準とメトリック(10分)
- 質問と次のステップ(10分)
- キックオフ後に起こること
- 24時間以内
- 日1~3
- 最初の週のチェックイン
- 良いモメンタムのように見えるもの
- 悪いモメンタムのように見えるもの
- キックオフが失敗する理由
- 一般的なテンプレートキックオフ
- セールスハングオーバーキックオフ
- 欠落した権限キックオフ
- 曖昧なキックオフ
- オーバーコミットメントキックオフ
- なぜこんなに重要なのか
- 真の目標
- 関連リソース