PMBOKにおいて、統合マネジメントが規定されているが、ここは他のマネジメントエリアとは質を異にする。他のマネジメントエリアではマネジメントテーマごとに、そのテーマに対してのプロセスが明記されているが、プロジェクトにおいては個別のマネジメントだけで済むはずもなく、様々なマネジメントの要素がプロジェクトの局面ごとで必要となってくる。

統合マネジメントは、局面ごとでそれぞれの要素を統合するためのマネジメント要素であるが、別な見方をすればプロジェクトを動かすための基本的なマネジメントの流れの記述であるとも言えよう。言い換えれば、統合マネジメントこそが、プロジェクトを運営するための一連のマネジメントの流れであり、マネジメントの基本原則であるPDCA(Plan, Do, Check, Action)サイクルそのものといっても過言ではない。ただ、PDCAサイクルは継続的なマネジメントの流れであることに対して、統合マネジメントはプロジェクトの特徴である開始と終了を前後に付け加えて定義している。

統合マネジメントにおいては、プロジェクト憲章(Initiation)、プロジェクトマネジメント計画書(Plan)、プロジェクト実施・コントロール（Do/Check/Action）、プロジェクト終結(Close)がマネジメントサイクルの中で定義されている。ここでは、それぞれについて解説することとしよう。

プロジェクト憲章

プロジェクトが正式に認知された後、プロジェクトをどのような方針で進めていくのかを定義する必要が出てくる。一般的に、プロジェクトチャーター（憲章）はプロジェクト推進のための憲法のようなもので、プロジェクトの目的、プロジェクトの範囲、プロジェクトの体制、主要な成果物、マイルストン、プロジェクトの運営方法などが記載されている。

しかし、一般的にプロジェクト憲章を作成するケースは少なく、国内においては多くのプロジェクトがプロジェクト憲章を作らずに実施しているのが現状であろう。その理由として幾つかあるが、一つはプロジェクト憲章を作成する手間がある。プロジェクト憲章を作り上げるにはそれ相当の時間を必要とするため、特に規模の小さいプロジェクトでは敬遠されがちでる。プロジェクトが大きくなり、それなりのガバナンスが必要となる場合はその重要性は増してくるが、小規模プロジェクトでプロジェクト憲章を作るメリットはあまり感じられないというのが本音のところであろう。また、プロジェクト規模が小さいと、プロジェクト関係者のプロジェクトへの理解度も深く、実質的にプロジェクト憲章を見る機会も大きく減ってくる。

PMBOKでは、プロジェクト憲章として最初に作成すべきものとして定義されるが、実践面においては、大規模プロジェクトでは重要性が増すが、中小規模のプロジェトにおいてはプロジェクト憲章を参照する機会も少なくなり、作る割にはメリットが少ないことも事実である。逆に、作ることが義務化して綺麗なプロジェクト憲章を作成したものの、ほとんど誰も見ないというケースもあることも事実である。これは提案であるが、プロジェクト憲章は標準的なテンプレートを組織として準備し、最小限の内容を記載すればプロジェクトに取りかかれるようにすることが望ましいと思われる。

プロジェクト計画書

プロジェクトスコープが明確になれば、プロジェクト計画を立案するが、プロジェクト計画には様々なマネジメント要素が入れ込まれることになる。スコープマネジメント、リスクマネジメント、タイムマネジメント、コストマネジメント、品質マネジメント、人的資源マネジメント、調達マネジメント、コミュニケーションマネジメントなどプロジェクト計画を立案する上でほとんどのマネジメント要素が組み込まれることとなる。しかし、PMBOKの第3版は統合マネジメントの部分が強化されてページ数も厚くなったが、逆に複雑すぎてますます難解になってきたようである。プロジェクト憲章の後に、プロジェクトスコープ記述書暫定版の作成、次にプロジェクトマネジメント計画書作成となっているが、物事は極力シンプルに理解しないと、ものの本質を見失ってしまうので注意した方が良い。

プロジェクトの条件がクリアになれば、次にやるべきことはプロジェクト計画の立案である。プロジェクト計画には大きく二つの流れがあり、ひとつはプロジェクトの成果物をどのように作っていくかを定義するプロジェクト実施の計画と、プロジェクトを円滑に運用するためにプロジェクト関係者がどのようにプロジェクトを進めていくかを記載したまマネジメント計画である。前者は、全てのプロジェクトにおいて必須であり、その計画立案に組織のもつ知恵とエネルギーを許す限り最大限に注入すべきものであり、プロジェクトマネジメントの中心軸となるものであるが、後者はプロジェクトによってその位置づけが異なってくる。マネジメント計画は、大規模プロジェクトでは関係者も多く、情報量も膨大となるためにマネジメントのやり方自体を明確にし、プロジェクト運営の方法を徹底しないとプロジェクトは混乱し大きな問題となってくるが、小規模プロジェクトにおいて関係者も少ないために、日々のコミュニケーションさえ充分にとっていればそれほどプロジェクトの運営で混乱することは少なく、ある程度の方針さえ決めておけば充分である。

PMBOKでは理想を記載しているが、プロジェクトの実態をよく理解した上でプロジェクトを運用しないと、形式的な部分に多くの労力を使うことになりかねないので気をつけよう。

プロジェクト実施・コントロール

プロジェクト実施・コントロールにおいてもっとも重要なことは、「適切なタイミングでて適切なアクションをおこすこと」、これにつきる。そのアクションの如何によってプロジェクトは成功もし、迷走もする。

では、適切なアクションをとるためにはどのようにすれば良いかであるが、ここで二つのキーワードがでてくる。１つは情報であり、もう１つが予測である。正しいアクションをとるには、正しい判断が不可欠であるが、正しい判断を得るためには現状を正しく把握することが基本である。そのためには、プロジェクトの状況が監視され、判断を行うための情報がそろっていなくてはならないが、ひとくちに判断を行うための情報といっても、その詳細度、鮮度などを考えると監視すべき情報には、やり方によって大きな差がでてくる。プロジェクト情報を収集するにあたっては、適切な判断が可能なように、プロジェクトで収集する詳細度と収集頻度を設計する必要がある。闇雲に詳細化し、頻度を上げるとマネジメント負荷が増大しプロジェクト運用のための工数も増大するので気をつける必要がある。

また、予測はさらに難しい。将来を予測できれば、今適切な判断することは容易であるが、なかなか将来を見通すことは困難である。しかし、情報を継続して見続け、さらにプロジェクト現場を見ていると、情報と現状のイメージが次第に一致してくるようになる。サイエンスとアートの融合であるが、数字を見ることで、このままではどうなるかが次第にイメージされてくるのである。勘というものかもしれないが、情報を分析し続けると、人の勘にも磨きがかかるものである。より優秀なプロジェクトリーダーは数字によって、ある程度の現場の状況を判断し、打つべき手を見出していく。予測とはサイエンスと人知が織り成す技である。

さて、もう一つプロジェクト実施・コントロールで議論すべきテーマとして、変更管理(Change Control)がある。これは、プロジェクトの混乱要因に対するマネジメントとして理解しておくとよいであろう。ほとんどのプロジェクトは計画通りにはいかない。かならずといって想定外のことが起きる。したがって、その想定外への対応の方法を明確にしていないと、プロジェクトは間違いなく混乱する。変更には、様々な理由が存在する。明確な理由もあれば、曖昧な理由もあり、責任の所在も不明確なものさえ存在する。変更管理を行うにおいて、そのような様々な変更が常に発生することを前提としてプロジェクト運営方法を定義しておくことが重要である。特に、責任の所在が見えにくい変更の対応については、事前にプロジェクト関係者で合意しておくことが必要であろう。　なぜなら、プロジェクトは始まれば中断することは難しく、プロジェクトを推進していく中で変更への対応を行わなくてはならないからである。

プロジェクト終結

プロジェクト終結は、実施されたプロジェクトそのものに役立つものではないが、プロジェクトを実施した組織にとっては重要なプロセスである。残念ながら、多くの組織においてプロジェクト終結のプロセスに時間を使っていない。つまり、ほとんどのプロジェクトがやりっぱなしとなっている。同じプロジェクトは2度と無いかもしれないが、類似したプロジェクトはいくらでも存在する。プロジェクト終結のプロセスは組織としてプロジェクトで得た経験を、組織の資産に変えるプロセスであり、その使う時間から比べると得るものは非常におおきなものである。プロジェクト終結プロセスをやっていない組織は、同じような失敗を何度も繰り返すためプロジェクトの生産性は低くなる。これほど、投資対効果の大きなものはないので、是非プロジェクト終結のプロセスをルール化し、組織の知的資産を増やしていただきたい。