#059 プロマネのお仕事(本編9) - 統合マネジメント(変更管理はしっかりと)

こんにちは。中小企業診断士の多田と申します。

この連載、本編の残りはあと2回となりました。
本編9回目は「統合マネジメント」。

# 051: 資源マネジメント
# 052: コミュニケーション・マネジメント
# 053: ステークホルダー・マネジメント
# 054: リスク・マネジメント
# 055: スケジュール・マネジメント
# 056: コスト・マネジメント
# 057: 品質マネジメント
# 058: 調達マネジメント
# 059: 統合マネジメント ← 今回
# 060: スコープ・マネジメント

基本的には他の9つの知識エリアをまとめていく作業になるのですが、それらの中でも「プロジェクトの立ち上げ」や「変更管理」など、プロジェクトの節目節目で行うべき仕事の進め方が書かれており、これらをきちんと行うことでプロジェクトが「ぐだぐだ」になるのを防ぐことができます。
また、プロジェクト全体の「知識」に関するマネジメントもこの領域です。メンバーの暗黙知を形式知にしていくことでチームを成長させていきます。

なかなか、この領域に書かれている内容をきっちり実行できるプロジェクトは多くないかもしれませんが、実は重要なことがたくさん書かれていたりします。

「統合マネジメント」とは

PMBOKの10の知識エリアの中では1番最初。

PMBOKでの定義は以下のとおりです。
「プロジェクトマネジメント・プロセス郡内の各種プロセスとプロジェクトマネジメント活動の特定、定義、結合、統一、調整を行うためのプロセスと活動からなる。」
(PMBOK 第6版 p.23)

言い換えるなら、全体最適の観点から、他の全ての領域を統括する仕事である、ということになるでしょうか。

PMBOKに書かれているプロセス

「統合マネジメント」に書かれているプロセスは、ちょっと多くて全部で7つ。
立ち上げ・計画・実行・監視・終結、全てのプロセス群に対してプロセスが存在するのも大きな特徴です。

1. 「プロジェクト憲章の作成」
→ プロジェクト憲章を作成し、ステークホルダーからプロジェクトの認可を受けます。
→ このプロセスを経ることで、正式にプロジェクトマネージャとして必要な権限が与えられます。
→ アウトプット文書: プロジェクト憲章

2. 「プロジェクトマネジメント計画書の作成」
→ 各マネジメント領域で作成された計画書を統合して、プロマネとしてこのプロジェクトをどうやってマネジメントしていくかの計画書を作成します。
→ アウトプット文書: プロジェクトマネジメント計画書

3. 「プロジェクト作業の指揮・マネジメント」
→ 2. で作成したプロジェクトマネジメント計画書の内容に従い、プロマネとしての作業を行っていきます。

4. 「プロジェクト知識のマネジメント」
→ プロジェクトメンバーのスキル・経験・専門知識をマネジメントします。例えば、別のプロジェクトの経験がこのプロジェクトで使えないか検討したり、新しい知識を見つけ出して文書化することで組織の知恵にしたりします。
→ アウトプット文書: 教訓登録簿

5. 「プロジェクト作業の監視・コントロール」
→ 計画と実績の比較を行ったり、問題を検知したり、リスクをチェックしたりすることで、プロジェクトが順調に進むようにします。

6. 「統合変更管理」
→ プロジェクト進行中に発生する様々な変更要求に対して、その可否(変更するかしないか)、および、変更するならどう変更するのかを判断し、その判断に従って変更作業を行います。
→ アウトプット文書: 関連するプロセスで作成された文書や成果物の更新・維持

7. 「プロジェクトやフェーズの終結」
→ 契約に基づき、プロジェクトで作成した成果物を引き渡します。
→ プロジェクトの成果物がステークホルダーの要求を満たしていることを確認します。

では、例によって、これらのプロセスの中からすぐに使えそうなテクニックをいくつかご紹介したいと思います。

「プロジェクト憲章の作成」 → キックオフミーティングを開催しよう!

プロジェクト憲章、というとなんだか難しそうに感じてしまいますが、要は、これから始まるプロジェクトがどういうものなのかをまとめて文書化したもの、のことです。
文書のフォーマットもプロジェクトによって様々ですが、個人的にはパワポとかでも十分かと思います。

プロジェクト憲章には、最低限、以下のような情報を書いておくと良いでしょう。
・このプロジェクトの目的。何のためにやるのか。
・予算やスケジュールをざっくりと。
・わかっている制約や優先順位。例えば、このプロジェクトは余りお金がないのでできるだけ節約する方向で、とか、お客さんの納期が決まっているのでスケジュール優先で、とか。
・プロジェクトに参加するメンバーの紹介と、各自の役割分担。

これらの情報をまとめ、まずステークホルダー(お金を出してくれる社長さんとか)に確認してもらっておきましょう。

ここでお勧めしたいのは、プロジェクトの開始時に、関係者全員に集まってもらって「キックオフミーティング」を開催することです。
ドキュメント(プロジェクト憲章)をメールで共有するだけだと、なかなかプロジェクトの一体感が生まれませんし、後で「俺そんな話聞いてないよー」みたいなことが起こりがちです。

キックオフミーティングの時間は概ね1時間程度。これ以上長いとダレてしまうかも。
できればステークホルダーや社外の関係者にも参加してもらうと良いでしょう。

キックオフミーティングでは、プロマネがプロジェクト憲章の内容を説明した後、メンバー全員の紹介(できれば一言づつ意気込みを語ってもらう)、質疑応答、そして最後にステークホルダーからも一言プロジェクトへの期待を述べてもらいます。

司会はプロマネ自身でやるのが良いと思います。メンバー全員の前に立ってきちんと仕切ることで、このプロジェクトのプロマネが自分であることをメンバーに対して意識付けることができます。
たまにステークホルダー(社長さんとか)が仕切りはじめたりすることがあったりしますが、そこはできるだけ譲らず、プロマネとしての存在感をメンバーに見せることを意識しましょう。「私はステークホルダーからこのプロジェクトを任されているんだ」という雰囲気をメンバーに対して見せつけることが大切です。

「プロジェクト知識のマネジメント」 → メンバーの暗黙知を発表する機会を作ろう!

プロジェクトを進めていく中で、それぞれのメンバーは様々な新しい経験をしていくことになります。
そのような新しい経験を、何らかの形でメンバー間で共有し、チームとしての知恵にしていくことが重要です。
このような活動を、暗黙知の表出化、とか、形式知化、などと呼んだりします。

SECIモデルとは？　初心者でもわかるマネジメント理論 - STUDY HACKER｜これからの学びを考える、勉強法のハッキングメディア https://studyhacker.net/what-is-seci

こうした暗黙知は、発表する機会を強制的に用意してあげないとなかなか表に出ることはありません。
プロマネとして「暗黙知を発表する機会」を作れると良いと思います。

例えば、週に一度の定例会の際、進捗共有の他に20分ほどの時間を捻出して、メンバーの「ショートピッチ」を行うようにしてはどうでしょうか。
発表するメンバー1名を事前に指名しておき、まず最初の10分間、そのメンバーから「最近苦労した話」「ちょっと工夫した話」「困っていること」などを自由に発表してもらいます。そして、その後の10分間で、その発表に対する意見交換を参加者全員で行います。
(経験上、5分 + 5分の10分だとちょっと短いと思います。どうしても20分くらいは必要かと)
こうした機会を定期的に用意することで、あまり表に出てこなかったメンバーの経験を共有し、プロジェクト全体をレベルアップしていくことができるようになります。

また、定期的に発表する時間が取るのが難しい場合は、オンラインでの発表機会を用意するのも良いと思います。
チャットツール(「#052 コミュニケーションマネジメント」で紹介しました)に、「未来のメンバーに伝えたいこと」のようなチャンネルを作っておき、今のプロジェクトから得た経験を、気がついたタイミングで書き込むようにしてもらいます。

「統合変更管理」 → 変更管理は、すぐに、適切に行おう!

この記事のタイトルにも書きましたが、プロジェクトが失敗する大きな理由の1つが「変更管理がきちんとできていないこと」です。

例えば、会社紹介 Webサイトをつくるプロジェクトの場合。
ステークホルダーである社長さんが、プロジェクトの途中で、プロマネに内緒でデザイナーに対して Web サイトの構成を変えるような指示を勝手に出しちゃう、なんてことは割とよくあるように思います。

油断していると、色々な人がプロジェクトメンバーに対して勝手に指示を出してきます。そして、一旦プロマネがこの状態を放置してしまうと、プロジェクトは必ず混乱します。

こうした事態を防ぐためには、あらかじめ「変更管理」の手続きを決めておき、キックオフの際に関係者に周知しておくのが良いと思います。
具体的には、
・プロジェクトの成果物の仕様や、コスト、スケジュールを変更する際には、必ず「変更管理会議」を行う。
・「変更管理会議」は、プロマネが関係者を招集して行う。
・会議は、まず起案者が変更内容の説明を行い、参加者の意見を聞いた上で、プロマネが変更する・しないの最終決定を行う。
・予算やスケジュールが20%以上(この数値は各プロジェクトで適切に決めてください)変更になる場合、必ずプロマネがステークホルダーの了解を得る。
といったルールを、プロジェクト開始時に決めておきましょう。

変更管理会議は、変更要求が上がったらできるだけ早いタイミングで行うのが良いです。できれば1-2日以内。
1週間遅れてしまうとプロジェクトに与えるダメージは思ったより大きくなってしまいます。

「プロジェクトやフェーズの終結」 → メンバーを集めて振り返りを行おう!

プロジェクトの経験を次につなげるためには、終わった後の振り返りも大切です。
振り返りには色々なやり方がありますが、工数をかけずに効果的な振り返りを行う方法として、「KPT法(けぷとほう、と読むことが多いと思います)」をお勧めします。

KPT 法とは、メンバーに集まってもらい、以下の3つの観点から意見を出してもらうやり方です。

1. Keep: 次のプロジェクトでも継続してやりたいこと
2. Problem: 今回のプロジェクトで問題だと思ったこと、次のプロジェクトでは改善したいこと
3. Try: 次のプロジェクトで試してみたいこと

前回の「#057 品質マネジメント」でも紹介しましたが、観点を決めることで、効率的で深い考察を行うことができます。
チャットツールなどを使ってオンラインでやることも可能ですが、できれば、実際に集まってブレスト的に行った方が良いアイデアが出るように思います。

「プロジェクトやフェーズの終結」 → きちんとステークホルダーに報告会を行おう!

最後に、とても重要な割には、意外と忘れがちなお仕事について。
プロジェクトが終わって成果物ができ、メンバーによる振り返りも終わったら、きちんとステークホルダーに対して報告を行っておきましょう。

この報告をせずになんとなく終わってしまうと、次のプロジェクトにつながりにくいように思います。逆に、ここをしっかりやっておくと、「次もこいつにプロマネを任せてみようか」と思ってもらえるのではないでしょうか。

報告の際には、プロジェクトが当初予定していた成果物に関する報告だけではなく、このプロジェクトを通してメンバーがどのように成長したか、チームにどのような知見がたまったか、次のプロジェクトではどのような挑戦をしてみたいか、などにも言及できると良いと思います。

上の方で紹介した「暗黙知の形式知化」や「プロジェクトの振り返り」がきちんとできていると、こうしたステークホルダーへの報告もやりやすいと思います。

まとめ。

(1) 「統合マネジメント」とは、全体最適の観点から、他の全ての知識エリアの業務をまとめる仕事になります。プロジェクト立ち上げと集結、変更管理、知識のマネジメント、など、ここをしっかりできるとグダグダしない、絞まったプロジェクトになります。

(2) プロジェクト立ち上げ時のキックオフや、終了時の報告会、プロジェクト中の変更管理会議など、ポイントにおけるイベントに関しては、やり方を決めてきちんと行うのが良いと思います。忙しいと、いろいろ面倒になってしまっていいかげんになりがちな仕事ではあるのですが、気合いをいれてきっちり行うのがプロジェクト成功の為には重要です。

(3) プロジェクトの進行中に得たメンバーの新しい経験(暗黙知)を、形式知としてチームで共有することで、チームをレベルアップさせることができます。オンライン・オフライン両面から、メンバーがこうした暗黙知を発表する機会を作ってあげると良いと思います。

----------
(ここに書かれている内容はいずれも筆者の経験に基づくものではありますが、特定の会社・組織・個人を指しているものではありません。)