Client Communication Cadence:構造化されたアップデートを通じて信頼を構築する

Professional Servicesのエンゲージメントを期限未達よりも早く潰すものをご存知ですか?無線の沈黙です。Clientはあなたが彼らのお金で何をしているのか疑問に思い始めます。彼らはあなたが話していない問題を想像します。彼らはあなたの提供能力への自信を失います。そして、あなたが優れた仕事を持って現れる頃には、彼らは既に精神的に代替先を探しています。

イライラする部分は?これらの状況のほとんどは、プロジェクトが順調に進んでいるときに起こります。仕事は順調で、Teamは成果を出していて、すべてがコントロール下にあります。しかしClientはそれを知りません、あなたが伝えていないからです。

Communication cadenceがこの問題を解決します。それはstatus update、check-in、stakeholderエンゲージメントの構造化されたリズムであり、エンゲージメント全体を通してClientに情報を提供し、自信を持たせ続けます。正しく行えば、驚きを防ぎ、信頼を構築し、Clientを支持者に変えます。間違って(または全く行わない)行えば、scope creep、プロジェクトの失敗、関係の損傷の条件を作り出します。

このGuideでは、エンゲージメントタイプ、stakeholderのニーズ、提供の複雑さに合わせたコミュニケーションパターンを確立する方法を示します。なぜなら、一貫したコミュニケーションは単に良いClient Serviceではなく、それがClientを維持し、アカウントを成長させる方法だからです。

なぜcommunication cadenceがClient満足度を決定するのか

ほとんどのConsultantが見逃していることがあります:Clientはあなたの成果物と同じくらい、あなたのコミュニケーション方法であなたのパフォーマンスを判断します。優れた仕事をすることができますが、もし彼らが情報不足を感じたり、Timelineに不安を感じたり、進捗について不確実に感じたりすれば、彼らは結果よりもストレスを記憶します。

Communication cadenceは予測可能性を作り出します。Clientが毎週火曜日の朝にstatus updateを受け取ることを知っているとき、または隔週金曜日にsteering committee reviewがあることを知っているとき、彼らはリラックスします。彼らは情報を求めてあなたを追いかける必要がありません。先週提起した問題にあなたが対処しているのか疑問に思う必要がありません。Cadence自体が安心感を与えます。

それはまた、あなたがエンゲージメントをしっかり把握し続けることを強制します。毎週進捗を報告する必要があることを知っているとき、気づかずに2週間物事を流すことはできません。Communicationのリズムは、Teamに内部的な説明責任を生み出します。

しかし、ここで戦略的になります:正しいcadenceは、エンゲージメントタイプ、Client文化、プロジェクトの複雑さによって劇的に変わります。3ヶ月の実装には日次standupが必要です。1年のRetainerは月次のexecutive summaryが必要かもしれません。Agile開発プロジェクトは、Waterfall戦略エンゲージメントとは異なるリズムを必要とします。

最悪なことは、万能のアプローチを選択し、すべてのClientに強制することです。あなたのcommunication cadenceは、デフォルトではなく、設計されるべきです。

エンゲージメントが必要とするものを評価する

Communication cadenceを確立する前に、それを形成すべき要因を理解する必要があります。

Client文化と好み:一部の組織は、詳細な週次status reportで繁栄します。他の組織はそれを官僚的だと感じ、月次の高レベル更新だけを望みます。一部のExecutiveはすべてのMeetingで対面時間を望みます。他の人は、自分のScheduleで読める簡潔な書面の要約を好みます。

Client onboardingおよびproject kickoffの間に注意を払ってください。明示的に尋ねてください:「プロジェクトの進捗について情報を得るための好みの方法は何ですか?」そして「非公式なcheck-inと公式なupdateをどのくらいの頻度で望みますか?」

既存のproject management規律を持つClientと作業している場合は、彼らのリズムに合わせてください。彼らが2週間ごとにsprint reviewを行う場合は、並行するcadenceを作成するのではなく、そのScheduleに接続してください。

エンゲージメントの複雑さ:明確な成果物を持つ単純なプロセス改善プロジェクトは、複数の統合ポイントを持つ複雑なシステム実装よりも頻繁なコミュニケーションを必要としません。動く部品が多いほど、コミュニケーションが頻繁である必要があります。あなたのproject management methodologyは、異なるエンゲージメントタイプの標準コミュニケーションリズムを定義する必要があります。

複雑さには以下が含まれます:

• Workstreamまたは並行活動の数
• 技術的難易度と統合の課題
• StakeholderとDecision pointsの数
• Client ResourcesまたはThird Partiesへの依存
• Riskレベルとscopeの変更の可能性

高複雑度エンゲージメントは、より多くのことが間違う可能性があり、より多くの調整が必要なため、よりタイトなcadenceが必要です。

Stakeholderの数と年功:1人の主要連絡先と作業している場合、コミュニケーションは簡単です。3つの部門にわたる8人のStakeholderと可視性を必要とする2人のExecutiveがいる場合、多層コミュニケーション計画が必要です。

Senior Executiveは通常、より戦略的な更新をあまり頻繁に望みません。Project teamメンバーは、より頻繁な戦術的情報を望みます。End userは、意思決定者(進捗、ROI、戦略的影響)とは異なるコミュニケーション(何が変わるか、それが彼らにどう影響するか、どのようなサポートが利用可能か)を必要とします。

Risk許容度とTimeline圧力:低いRisk許容度またはタイトな締め切りを持つClientは、より頻繁な安心を必要とします。年末までにliveに行かなければならないプロジェクトは、柔軟なTimelineを持つプロジェクトよりも多くの不安を生み出します。高い不安=より頻繁なコミュニケーション。

一部のClientは本質的に神経質です。彼らはConsultingエンゲージメントに不慣れであるか、以前に裏切られたことがあるか、Executive teamが彼らの首に呼吸しています。これらのClientは、信頼が確立されるまで、エンゲージメント初期に過剰コミュニケーションから利益を得ます。

Decision cycleの調整:Update cadenceは、Decisionが実際に行われるときに調整する必要があります。Clientのleadership teamが月次でプロジェクトをReviewするMeetingを行う場合、そのMeetingの数日前にstatus reportが届くように、Sponsorが自信を持って報告できるようにしたいです。Procurementが2週間ごとに請求書をReviewする場合、それに応じて進捗updateの時間を調整してください。

効果的なCadenceの設計原則

コンテキストを理解したら、コミュニケーションリズムを設計する際にこれらの原則を適用します。

驚きを防ぐのに十分な頻度:Client communicationの基本ルールは「驚きなし」です。締め切りを逃す、予算を超える、または重大な問題を発見する場合、Clientは危機になる前にあなたからそれを聞く必要があります。あなたのCadenceは、問題が表面化してエスカレートする前に伝達されるほど十分にタイトである必要があります。

良いTest:月曜日に何かがうまくいかなかった場合、Clientがあなたの正式なコミュニケーションプロセスを通じてそれを聞くまでどれくらいかかりますか?答えが「おそらく金曜日のstatus meetingまでに」である場合、複雑なエンゲージメントにとってあなたのCadenceは緩すぎます。

ノイズになるほど頻繁ではない:より多くのコミュニケーションがより効果的でなくなる転換点があります。「報告する新しいことはありません」と言う日次Emailは、人々にあなたのUpdateを無視するように訓練します。80%の時間が無駄にされる3時間の週次Meetingは、恨みを生み出します。

実際の変更と進捗のレートにコミュニケーション頻度を一致させます。意味のあるUpdateが週次で発生する場合、日次Check-inを強制しないでください。主要なMilestoneが月次で発生する場合、週次steering committeeは過剰かもしれません。

自然なProjectのMilestoneに合わせる:最高のcommunication cadenceは、仕事の自然なリズムに従います。AgileのSprintは、組み込みの2週間サイクルを作成します。WaterfallのPhaseは、Phase遷移で自然なCheckpointを作成します。Retainer workは、月次の成果物サイクルに合わせるかもしれません。

コミュニケーションリズムが作業リズムに一致するとき、Updateは実際の進捗を報告するため、より意味があります。

ClientのDecision cycleに一致する:週次でDecisionを行う必要がある場合、週次のDecision-making forumが必要です。承認が月次で行われる場合、それをサポートするためにCadenceを構造化します。Clientの利用可能性またはプロセスに一致しないTimelineでDecisionを必要とするコミュニケーションイベントを作成しないでください。

エンゲージメントPhaseに適応:プロジェクトが進化するにつれて、Cadenceを変更する必要があります。実装の初期、DiscoveryとRequirementsを行っているとき、日次のコラボレーションが必要かもしれません。明確なRequirementsでBuild modeに入ったら、週次Updateで十分かもしれません。Go-live中、日次コミュニケーション以上に戻ります。

これらのPhase遷移について明示的にします。「DiscoveryとPlanが固まったので、日次Standupから週次Status meetingに移行しています。」

エンゲージメントモデル別のコミュニケーションタイプと頻度

異なるエンゲージメントタイプには異なるリズムが必要です。標準的なパターンを以下に示します。

AgileとIterativeエンゲージメント

AgileプロジェクトまたはIterative実装を実行している場合、Cadenceは通常次のようになります:

日次Standup(15分):毎朝、アクティブなProject teamが昨日達成したこと、今日計画していること、存在するBlockerについて同期します。これらはstatus meetingではありません - 調整Meetingです。短く戦術的に保ちます。

参加者:Core project teamのみ(あなたのTeam + Clientの日常的な参加者)

週次Sprint reviewまたはIteration demo(30-60分):各SprintまたはIterationの終わりに、完了したものを表示します。動作する機能を実演し、完了したものと計画されたものをReviewし、次のSprintの調整について議論します。

参加者:Project team + Key stakeholder + 進捗を見ることに興味がある人

隔週Steering committee(60分):Senior stakeholderが戦略的進捗をReviewし、ScopeまたはPriority変更についてDecisionを下し、エスカレートされた問題を解決し、プロジェクトがビジネス目標に沿ったままであることを確認します。

参加者:Project sponsor、Key executive、Project manager、Subject matter expertsの可能性

この3層アプローチは、仕事を日次で動かし続け、定期的に進捗を示し、実行を妨げることなく、Leadershipに可視性とコントロールを与えます。

WaterfallとPhasedエンゲージメント

従来のPhasedプロジェクトは、より構造化されたGovernanceを必要としますが、頻繁な戦術的コミュニケーションは必要ありません:

週次Status meeting(30-60分):Project teamと主要Stakeholderが計画に対する進捗をReviewし、問題とRiskについて議論し、戦術的Decisionを下し、今後の活動について調整します。

参加者:Project team + 現在のPhaseに積極的に関与しているStakeholder

Phase gate review(90-120分):各主要Phaseの終わりに、成果物の正式なReviewを実施し、承認を得て、次のPhase計画を確認し、必要に応じてTimelineと予算の期待をリセットします。これらのReviewは、あなたのdeliverable quality assurance標準を組み込む必要があります。

参加者:すべてのKey stakeholder、Decision-maker、前進を承認する必要がある人

月次Executive summary(書面+オプションの30分Review):達成、計画遵守、予算status、Risk、今後のMilestoneをカバーする高レベルの進捗報告。一部のExecutiveはそれを読むだけを望みます。他の人はそれについて議論したいです。

参加者(Meetingの場合):Executive sponsor、C-levelステークホルダー、あなたのSenior leadership

WaterfallプロジェクトはPhase遷移の明確さで生きるか死ぬかです。あなたのcommunication cadenceは、それらのGateの周りに規律を強制する必要があります。

RetainerとOngoingエンゲージメント

離散的なプロジェクトではなく、継続的なServiceを提供しているとき:

週次Check-in(30分):あなたのTeamとプライマリーのClient連絡先の間で、今週何が提供されたか、来週何が計画されているか、問題をフラグし、必要に応じてPriorityを調整する簡単な同期。

参加者:あなたのAccount lead + Clientの主な連絡先

月次Business review(60分):月の成果物をReviewし、結果と影響について議論し、Retainer hoursに対する利用率をReviewし、Service品質の懸念に対処し、来月のPriorityを計画します。

参加者:あなたのTeam + 関係を所有するClient stakeholder

四半期ごとのStrategic review(90-120分):戦術的な提供から後退して、より大きな絵について議論します - Retainerが価値を提供しているか、新しいニーズや機会があるか、ScopeまたはStructureを変更すべきか、何がうまくいき何がうまくいかないか。これらはClient success reviewと調整して、全体的な関係の健康を評価します。

参加者:双方のSenior leader、戦略的関係に関与する人

Retainer関係はリズムを必要とします、なぜなら仕事は継続的であり、「私たちのお金で何を得ているのか確信が持てない」領域に簡単にドリフトする可能性があるからです。定期的なReviewはそれを防ぎます。

危機駆動型または高緊急性エンゲージメント

危機を修正するために呼ばれたとき、または極端な締め切り圧力の下で作業しているとき:

日次2回のStandup(朝15分、終業時15分):その日のPriorityとBlockerを調整するための朝。何が完了し、次の朝をセットアップするための終業。

日次Executive update(書面または15分Call):Leadershipに進捗とDecisionを知らせ続けます。危機の間、Executiveはあなたがそれに取り組んでいるという日次の安心を必要とします。

Critical decisionsのリアルタイムコミュニケーション:即座のDecisionを必要とする主要な問題に当たった場合、次のScheduledされたMeetingを待たないでください。明確なエスカレーションProtocolを持ちます。

この強度は長期的に持続可能ではありませんが、短期的なバーストのためには必要です。Clientがこれが危機モードであり、通常の操作ではないことを理解していることを確認してください。

移行と変更管理プロジェクト

エンゲージメントに組織変更、Training、またはシステム移行が含まれるとき:

週次Core team meeting(60分):Workstream(Training、Communications、Technical implementation、Change management)全体で調整します

隔週Change network meeting(45分):部門で変更を支持する広範なStakeholder groupを関与させます

月次Leadership update(30-60分):Executiveに採用進捗、抵抗ポイント、サポートニーズについて情報を提供し続けます

Go-live日次Huddle:実際の移行期間中、問題に対処し、Trainingを調整し、サポートカバレッジを確保するための日次Check-in

Change managementは多くのコミュニケーションを必要とします、なぜなら成果物だけでなく、人々と感情を扱っているからです。

実際に機能するStatus updateフォーマット

コミュニケーションのタイミングと同じくらい、どのようにコミュニケーションするかが重要です。異なるFormatは異なる目的に役立ちます。

書面Status report

古典的なstatus reportは、正しく行われればまだ機能します。このように構造化してください:

Executive summary(2-3文):TL;DRバージョン。「プロジェクトは10月15日のGo-liveに向けて順調です。今週UATを完了し、Critical issueはありません。Data migration timelineに関する1つのModerate riskが監視されています。」

計画に対する進捗:何が起こるべきだったか、実際に何が起こったか。遅れている場合は、そう言って理由を説明してください。進んでいる場合は、それも言ってください。

この期間の主要な成果:完了したことの箇条書きリスト。具体的にします - 「Workflowの設定を完了」ではなく「Workflowで進捗を遂げた」。

次のステップと今後のMilestone:次に何が起こるかといつ。これは次のUpdateの期待を設定します。

問題とRisk:現在の問題、潜在的な問題、そしてそれらについてあなたが何をしているか。ClientがそのFormatを好む場合は、RAG(Red/Amber/Green) statusを使用してください。Red = Critical、即座の注意が必要。Amber = 懸念、監視中。Green = コントロール下。

必要なDecision:前進し続けるためにClientから必要なもの。何のDecision、誰がそれを行う必要があるか、いつまでに明示的にします。

1〜2ページに保ちます。誰も5ページのstatus reportを読みません。より詳細が必要な場合は、Appendixとして添付するか、リンクします。

DashboardとVisual update

一部のClientはVisual進捗trackingを好みます。これは、明確なMilestoneまたは定量化可能な成果物を持つ実装プロジェクトまたはRetainer workに特に適しています。

進捗Dashboard:完了パーセンテージ、Milestone tracking、Timeline visualizationを表示します。Monday、Asana、Smartsheet、またはよく設計されたSpreadsheetなどのToolsがうまく機能します。

Metrics tracking:エンゲージメントがKPI(利用率、システム採用、パフォーマンス改善、提供された時間)を持っている場合、時間の経過とともに視覚的にTrackします。

WorkstreamによるRAG status:プロジェクトのどの部分が健全(Green)、懸念(Amber)、またはCritical(Red)であるかを示す信号機の色。

Dashboardの利点は、スキャン可能であることです。忙しいExecutiveはそれを一目見て、深く掘り下げる必要があるか、物事がコントロール下にあるかを知ることができます。

欠点は、過度に単純化できることです。Greenを示すWorkstreamには、Status colorに収まらないニュアンスのある問題があるかもしれません。Dashboardと物語の要約を一緒に使用し、代わりに使用しないでください。

Meeting-basedのUpdate

時々、コミュニケーションする最良の方法は対面(またはVideo-to-video)議論です。

構造化されたMeeting agenda:ただ現れて即興しないでください。事前にAgendaを送信してください:

• 進捗Review(15分)
• 問題とBlocker(15分)
• 今後の作業とDecision(10分)
• Open discussion(10分)

Timingを守ってください。一貫して終了するMeetingは、人々に出席しないように訓練します。

問題解決Session:時々、status meetingが特定の問題を解決することにピボットする必要があります。それは問題ありませんが、認めてください:「Data統合に関するBlockerを特定しました。前進するのではなく、この時間の残りを使用して前進の道を見つけましょう。」

Action itemのキャプチャ:誰かがNotesを取り、所有者と期日でAction itemsをキャプチャする必要があります。Meetingが新鮮な間に24時間以内にこれらのNotesを配布してください。

Meeting-basedのコミュニケーションは、議論から利益を得る複雑なTopicがあるとき、および関係構築が重要なときに最適に機能します。書面Updateよりも効率的ではありませんが、しばしばより効果的です。

VideoのUpdateとAsync communication

分散Teamまたは会議に固定するのが難しいExecutiveのために:

記録されたVideo walkthrough:Dashboardまたはデモ完了した作業をウォークスルーする5-10分のVideoを記録します。Clientは自分のScheduleで視聴でき、セクションを一時停止してReviewでき、質問を持って戻ることができます。

LoomまたはSimilar tool:説明するのではなく、表示するのに最適です。「これは私たちが構築した新しいInterfaceです」は、書面の説明よりも3分のScreen recordingとして機能します。

Async discussion thread:Slack、Teams、またはProject management platformなどのToolsを使用して、Project communicationのための専用Channelを作成します。正式なStatus cycle間の迅速な質問と非公式なUpdateに適しています。

Videoは、Schedule調整を必要とせずに個人的です。Visual work(Design、Interface、Dashboard)を表示したり、複雑なTopicを説明したりするのに特に適しています。

Stakeholder固有のコミュニケーション戦略

異なるStakeholderは、異なるScheduleで異なる情報を必要とします。万能のアプローチは誰も満足させません。

ExecutiveとC-levelステークホルダー

彼らが気にすること:戦略的な成果、ROI進捗、主要なRisk、予算またはTimelineに影響を与えるDecision、ビジネス影響。

彼らが気にしないこと:実装の詳細、既に処理している戦術的な問題、Meeting notes、Project teamのDrama。

コミュニケーションアプローチ:ビジネス成果に焦点を当てた高レベルの要約。危機がない限り月次または四半期ごと。時間を尊重するため、書面がMeetingよりも良い場合が多いです。会う場合は、30分に保ち、問題だけでなく解決策を持ってきてください。

Format:Executive summaryとオプションの詳細Appendix。Bottom lineでリードします - 「Q4までに200万ドルのコスト削減を提供する軌道に乗っています」 - 次に、信頼を構築するのに十分な詳細でサポートします。

Project sponsorと主要Stakeholder

彼らが気にすること:詳細な進捗、Timeline遵守、Teamのパフォーマンス、約束されたものを提供しているかどうか、彼らに影響を与える可能性のある問題。

彼らが必要とすること:LeadershipにProjectを代表し、戦術的Decisionを下し、TeamのBlockerを削除するのに十分な情報。

コミュニケーションアプローチ:週次または隔週の詳細Update。これらはあなたの日常のPartnerなので、コミュニケーションはあまり正式ではありません。構造化されたUpdate(Status report、Scheduled meeting)と非公式なコミュニケーション(Quick call、Slack message)の組み合わせがうまく機能します。

Format:標準のstatus reportと定期的なMeeting。Status reportの内容に驚くべきではありません、なぜなら既に非公式に問題について議論しているからです。

Technical teamと実装Partner

彼らが気にすること:技術的詳細、依存関係、統合ポイント、特定の成果物のTimeline、彼らが対処する必要があるBlocker。

彼らが必要とすること:特異性。「次の火曜日までにAPI endpointを文書化する必要があります、そうすれば統合を開始できます」は「すぐにAPI文書が必要です」よりも有用です。

コミュニケーションアプローチ:頻繁な戦術的コミュニケーション。密接に協力している場合は日次Standup。Project management toolsを通じたTask-level可視性。迅速な質問のための直接コミュニケーションChannel。

Format:作業Session、技術文書、Task board、Standup meeting。より少ない正式な物語、より多い仕様とAction item。

End userと変更受信者

彼らが気にすること:これが彼らの仕事にどう影響するか、変更がいつ起こるか、どのようなTrainingとサポートが利用可能か、彼らの懸念が聞かれているかどうか。

彼らが必要とすること:変更の事前通知、何が異なり、なぜの明確な説明、移行を通じてサポートされるという安心。

コミュニケーションアプローチ:Project stakeholderとは異なるCadence。頻繁ではないかもしれません(月次Newsletter)が、より広い(影響を受けるすべてのUserへのEmail)。Go-liveが近づくにつれて頻度を増やします。

Format:FAQ、Training発表、「何が変わるか、いつ」要約、サポートResource。簡単でUser focusedにし、Project focusedではありません。

Key insightは、異なるAudienceのために複数のコミュニケーションStreamが必要である可能性が高いということです。あなたの週次Project status reportは100人のEnd userに行くべきではありません。あなたの月次Change management newsletterは、Project sponsorへの唯一のコミュニケーションであるべきではありません。

エスカレーションProtocolと重大な問題コミュニケーション

定期的なcommunication cadenceは通常の操作を処理します。しかし、何かがうまくいかないとき、異なるProtocolが必要です。

Issue重大度レベルを定義する

すべての問題が緊急Callを必要とするわけではありません。明確な重大度定義を作成します:

Critical(P1):システムダウン、Go-liveがRiskにある、主要な成果物が締め切りを逃す、予算超過が差し迫っている、関係を脅かす問題。

High(P2):重大な遅延の可能性、重要な機能がRiskにある、アプローチに関するStakeholderの懸念、中程度の予算Risk。

Medium(P3):軽微な遅延、Critical itemsではない品質懸念、プロセスの問題、TeamのFriction。

Low(P4):提案、最適化、Nice-to-have、軽微なプロセス改善。

Clientがこれらの定義に同意していることを確認してください。あなたがMediumだと思うものが、彼らの世界ではCriticalかもしれません。

エスカレーションPathとResponse commitment

各重大度レベルに対して、以下を定義します:

誰が通知されるか:Critical issueは即座にExecutiveとProject sponsorに行きます。Medium issueは次の定期的なstatus updateで言及されます。

どれくらい早く:Critical issue = 1時間以内に通知、4時間以内に初期Response計画。High = 同日通知、24時間以内に計画。Medium = 次のstatus update。Low = Backlogでキャプチャされ、優先順位付けされます。

コミュニケーション方法:Critical = 電話またはVideo meeting、Emailではありません。High = StakeholderへのEmailと次のScheduled meetingでのフォローアップ。Medium/Low = Status report。

Decision権限:誰が何のDecisionを下すことができますか?あなたのProject managerはおそらくMedium issueを処理できます。High issueはProject sponsorが必要かもしれません。Critical issueはC-level承認が必要かもしれません。

これをあなたのproject kickoffで文書化し、問題が発生したときにそれを参照してください。合意されたProtocolを持つことは、「なぜもっと早く教えてくれなかったのか」という会話を防ぎます。

Critical issueのコミュニケーションChain

Critical issueが発生したとき、この順序に従ってください:

1. 即座の通知:1時間以内にProject sponsorとKey stakeholderに電話(Emailしない)
2. 状況評価:何が起こったか、影響、実行されている即座のActionの簡単な説明
3. Action計画:4時間以内に、Timelineを含む解決のためのより詳細な計画を提供
4. 定期的なUpdate:危機モード中、「新しい情報なし、まだ計画を実行中」だけでも4-8時間ごとにUpdateを提供
5. 解決Summary:解決されたら、何が起こったか、何が行われたか、学んだ教訓を文書化
6. プロセス改善:再発を防ぐためにどのような変更が行われるかを議論

Critical issueで最悪なことは、それを修正している間に暗闇に入ることです。Clientは問題を処理できます。彼らは不確実性を処理できません。

悪いニュースの配信Best practice

誰も悪いニュースを配信するのが好きではありませんが、それはprofessional servicesの一部です。効果的に行う方法は次のとおりです:

砂糖でコーティングしない:問題について直接的になります。「締め切りを逃します」であり、「少し遅れるかもしれません」ではありません。

計画を持ってくる:提案された解決策なしで悪いニュースを配信しないでください。「統合はScopeよりも複雑です。進める方法についての3つのOptionがあります。」追加の作業が必要な場合は、あなたのchange order processに従ってOptionを文書化し、価格設定します。

ミスを所有する:あなたのTeamがミスした場合は、そう言ってください。Clientが問題を引き起こした場合は、非難せずに事実的に説明してください。「先週のSpec変更がTimelineに2週間追加しました。」

Optionを提供する:対応方法についてClientに選択肢を与えます。「Scopeを削減して期日通りに提供できます、完全なScopeのためにTimelineを2週間延長できます、またはResourcesを追加してコストを吸収してScopeとTimelineの両方に到達できます。」

早期に配信され、Optionを伴う悪いニュースは信頼を構築します。危機になるまで隠された悪いニュースは信頼を破壊します。

コミュニケーションToolsとPlatform

Medium matters。異なるToolsは異なるコミュニケーションニーズをサポートします。

Email:正式なUpdate、文書、Paper trailが必要なDecisionに最適。緊急コミュニケーション(人々は常にそれをCheckしない)または複雑な議論(Threadが混乱する)には最悪。

Project management software:Asana、Monday、Jira、SmartsheetなどのToolsは、Task-level可視性、進捗tracking、すべての人が何が起こっているかについて調整を保つのに最適です。戦略的議論または関係コミュニケーションにはあまり良くありません。

Video meeting:Zoom、Teams、Google Meet for対面コミュニケーション、Screen共有、関係構築。複雑な議論と問題解決に不可欠。簡単なstatus updateに過度に使用されると非効率的である可能性があります。

Instant messaging:Slack、Teamsで迅速な質問、非公式な調整、迅速な問題解決。主要なコミュニケーションChannelになると危険です、なぜなら情報がChat historyで失われるからです。

Client portal:報告、成果物、Timeline、文書への集中アクセスのための専用Platform(一部のConsulting firmはCustom portalを構築)。組織化に良い、維持するのが厄介な場合があります。

Dashboard:Tableau、Power BI、Custom dashboardで視覚的な進捗trackingとMetrics。一目でStatusを望むExecutiveに最適。

最高のアプローチは、複数のToolsを戦略的に使用します:

• 正式なstatus reportとDecisionのためのEmail
• TaskのtrackingとTeamの調整のためのProject management platform
• 週次Team meetingと月次Steering committeeのためのVideo call
• 日常の迅速な質問のためのSlack/Teams
• 成果物と文書のための共有DriveまたはPortal

どこで何を探すかをすべての人が知っていることを確認してください。「Status reportは毎週月曜日にInboxに届きます。TaskのUpdateはAsanaにあります。週の間の質問はSlack #project-phoenixチャンネルに行きます。」

Client関係を損なう一般的なコミュニケーションミス

良い意図があっても、Consultantは予測可能な方法でClient communicationを台無しにします。

ExecutiveへのTactical詳細の過剰コミュニケーション

あなたのCEO clientは、Test environmentの更新が遅れていることや、AccountingのBobが作業Sessionに遅刻したことを知る必要はありません。彼らは、プロジェクトがGo-liveに向けて順調かどうか、ビジネス成果へのRiskがあるかどうかを知る必要があります。

ExecutiveをImplementationの詳細で埋め尽くすと、彼らはTune outします。その後、実際に重要な何かに注意を引く必要があるとき、彼らはもう注意を払っていません。

Audienceにコミュニケーションを合わせます。Tactical詳細はProject teamに行きます。戦略的要約はExecutiveに行きます。

RiskとIssueの過少コミュニケーション

Consultantは楽観主義へのBiasを持っています。「この問題はおそらく管理可能です、Clientをまだ心配させる必要はありません。」その後、それはより大きな問題に変わり、Clientは盲目打ちです。

ルールは次のとおりです:これが本当の問題になる30%のChanceがある場合、status updateでRiskとして言及します。Clientはまだそれに行動する必要はありませんが、あなたのRadarに乗っていることを知る必要があります。

Clientは問題よりも驚きを嫌います。3週間フラグされてから実現するRiskは、突然現れる問題よりもはるかに管理しやすいです。

一貫性のないCadence

6週間週次status meetingを行い、その後「報告する新しいことはありません」ため1つをSkipし、別のものを行い、2つをSkipします。この一貫性のなさは不安を生み出します。「Projectがうまくいかないため、Meetingをスキップしましたか?」

週次Cadenceを確立した場合、Updateが短くても維持します。「休日のため今週はあまり進捗がありませんが、来週の成果物に向けてすべて順調です。」それは2分かかり、リズムを維持します。

Cadenceを変更する必要がある場合(エンゲージメントPhaseが変更されたため週次から隔週に移動)、それを明示的にします。ただ現れるのをやめないでください。

「悪いニュースなし」病

一部のConsultantは、無能に見えると思うため、問題をコミュニケーションすることを避けます。だから彼らは、修正できるまで問題を隠します。これは時々機能しますが、機能しないとき、それは壊滅的です。

Professional servicesは問題を解決することです。Clientは課題があることを期待しています。彼らが期待しないことは、何かする時間がなくなってからそれらの課題について知ることです。

問題を「これが状況です、これがそれに対処する私たちの計画です、これがあなたから必要なものです」とFrameします。それはProfessionalな問題解決であり、無能ではありません。

貧弱なMeeting facilitation

Agendaがないため90分間さまようstatus meeting、または同じ3人が会話を支配し、他の人がTune outするMeeting、または明確なAction itemなしで終わるMeeting - これらはすべての人の時間を無駄にします。

タイトなMeetingを実行します:事前に配布されたAgenda、時間通りに開始、Time boxに固執、DecisionとAction itemをキャプチャ、時間通りに終了、24時間以内にNotesを配布。

あなたのClient文化が「Meetingは常に終了し、誰もAgendaに従わない」である場合、あなたはそれを変更できないかもしれません。しかし、少なくともあなたのUpdate部分が明快で組織化されていることを確認してください。

即座のコミュニケーションが必要なときにScheduledされたUpdateを待つ

「水曜日にVendorが来月まで提供できないことを発見しましたが、月曜日のstatus meetingまで待って言及しようと思いました。」

いいえ。Critical issueは即座にコミュニケーションされます。定期的なCadenceはRoutine updateを処理します。Scheduleが常識をオーバーライドさせないでください。

Communication cadenceを持続可能にする

Project kickoffで確立するCadenceは、エンゲージメント全体にわたって持続する必要があります。つまり、Clientだけでなく、あなたのTeamにとっても持続可能である必要があります。

Project planningに組み込む:エンゲージメントをScopeするとき、status update、Meeting、Report準備のための時間を含めます。週次詳細Reportを約束するが、それを書く時間を予算化しない場合、それらは低品質になるか、あなたのTeamはBurn outします。これをあなたのutilization and capacity planningに組み込みます。

TemplateとAutomationを使用する:毎週status report formatを再発明しないでください。標準Updateのためのtemplateを作成します。進捗reportを自動生成するproject management toolsを使用します。必要な手動の努力が少ないほど、Cadenceはより持続可能です。

適切に委任する:Senior partnerは毎週のstatus meetingすべてに出席する必要はありません。Project managerは戦術的Updateを処理できます。Senior注意を月次Steering committeeとCritical decisionのために保存します。

エンゲージメントが進行するにつれてCadenceを進化させる:実装中に意味があることは、定常状態の操作中には過剰かもしれません。適切に頻度とFormatを調整しますが、それを意図的に行い、Client合意で行います。

Feedbackを求める:数ヶ月ごとにCheck-in:「このコミュニケーションはあなたにとって機能していますか?多すぎますか?十分ではありませんか?異なるFormatが役立ちますか?」Clientは何かが機能していない場合、あなたに教えます。

他のService提供Practiceへのコミュニケーションの接続

Communication cadenceは単独で存在しません。それはあなたのより広い提供Methodologyに接続します。

あなたのproject management methodologyは、異なるプロジェクトタイプの標準コミュニケーションリズムを定義する必要があります。すべてのエンゲージメントでこれを再発明しないでください。

Client onboarding processは、コミュニケーションの期待と好みを確立する場所です。プロジェクトが始まる前にCadenceで合意を得ます。

あなたのissue resolution processは、問題がどのようにコミュニケーションされ、エスカレートされるかを定義します。Communication cadenceは、これらの問題が表面化する方法です。

Client success reviewは、Project statusから後退し、関係の健康と価値提供について議論するためのより戦略的なコミュニケーションForumを提供します。

これらすべてのPieceが一緒に機能するとき、コミュニケーションはad-hocではなく体系的になります。それが本当のClient信頼を構築し始めるときです。

Communication cadenceについてのBottom line

良いコミュニケーションはプロジェクトの成功を保証しませんが、悪いコミュニケーションはほぼプロジェクトの失敗を保証します。Clientは、情報を得て、関与し、あなたが物事の上にいることを自信を持っている必要があります。

特定のCadenceは、1つを持ち、それに固執することよりも重要ではありません。週次または隔週、書面またはMeeting-based、詳細または高レベル - すべては以下のように機能できます:

• 特定のエンゲージメントとClient用に設計されている
• プロジェクト全体を通して一貫して維持されている
• 異なるStakeholderレベルに適している
• 問題が発生したときに対応している
• あなたのTeamにとって持続可能である

Project kickoff中にCadenceを提案することから始めます。Clientの合意を得ます。それを一貫して実行します。Feedbackに基づいて調整します。それだけです。

Communication cadenceをマスターするConsultantは、単に良い仕事を提供するだけではありません - 彼らは拡大されたエンゲージメント、Renewal、ReferralにつながるClient関係を構築します。なぜならClientは、あなたが提供したものだけでなく、あなたと作業するのがどのように感じたかを覚えているからです。そして「彼らはすべてのステップで私に情報を提供し続けた」というのは、長期的なClient関係につながる感覚です。