1.だれとコミュニケーションをとるべきかが重要

コミュニケーションリスクで大きいのは、経営層がタッチしてないこと、要件定義でのメンバーが足りないこと。役割とミッションは必ず明確にしておくあとでひっくり返されるのは最悪なのでかならずステークホルダー（社長や部門長など）に計画を承認。

2.人によってコミュニケーションの仕方をかえる

たとえば、ステークホルダーのうち経営層などへ見せるプロジェクト計画は1枚でいいです。経営陣には簡潔でポイントをおさえた説明、議事録はとっても意味はありません。途中で気が変わるのは当たり前のつもりで接しつつ、発注前承認などの重要なチェックポイントは意識してもらいましょう。

プロジェクトオーナーやユーザ部門の意見はとりあえず聞くだけは聞いてください。めんどくさがらず聞iいてください。でもきちんとそれが目的に合致しているか考えさせてください。UMLや詳細な要件定義書を作ってもいいです、トラブル防止のため議事メモを活用するのもいいでしょう。またWBSや課題管理表などはどうしても”きっちりしたプロジェクト管理をやりたい”人をほど詳細な資料を作ってきてしまいますが、見てる人は”あー、すごい資料だけよくわからないなあ"と思われてるかもしれません。ポイントだけ抜き出してメンバーに理解しやすくするということも考えてください。またそれだけ苦労しても、確定した要件に、不足や変更がある程度あることは織り込んでおきましょう。

開発側メンバーへのプロジェクト後のフォローを最後にしっかりやりましょう。参加メンバーにモチベーションがないのは当たり前と考えてください。

3.定例会議は必ず

プロジェクトメンバー、顧客、委託先との定例会議は必ず実施しましょう。週１回でいいです。議事はかならず取るようにしてください。

あまりプロジェクトマネジャーが話題がないと思っても週に一回は定例やりましょう。みんなが集まってこそ新しい発見や、会議のときじゃないと話しづらいという人もいます。作業を割り込まれるのを嫌がるかたもいらっしゃいます。定例会議はリスクの洗い出しにも絶好の機会なのでぜひうまく活用しましょう。