|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
| 「計画」の計画 | ||||||||||
|
前のページの通り、主要な文書の内容とその意義を明確に区別、理解します。その上で当該プロジェクト内容に関して具体的な計画を立てる前に、「記述の区分けの計画活動自体を含めたプロジェクト全体をどのように進めていくか」というプロジェクト・マネジメント活動についての計画をより明確にする必要があります(そのためにも、新たに加わった「プロジェクト・スコープ記述書暫定版作成プロセス」の理解は重要です)。 そして段階的詳細化によって、これらの計画もプロジェクトが進むに従って様々に書き加えられたり、変更されたりします。前回でも説明しましたが、これは変えられる部分を柔軟に変えていきながら当初の目標を達成するということです。つまり、「管理された臨機応変」といったところです。 こういうと当たり前のように聞こえるかも知れませんが、いざ実際のプロジェクトに入ると、「いきなりプロジェクトが対象としている成果物をどう作るか」ということに関する具体的な作業の洗い出しなどに入ってしまいます。 プロジェクトをどう進めるのか、自分たちが置かれているのは(本当は)どういう状況なのかなどについて(その気になれば変えられることや、一見大丈夫と思えてしまうが実は問題が発生しているなどの識別)、なるべく多くのステークホルダーと話し合って熟慮する時間を割く必要があります。 しかし、これが充分でない場合がとても多いようです。大抵の場合は頭ではわかっていて、手順を踏んでいるだけで何となくやっている気持ちになっていたり、本来できるはずのことも簡単にできないと思いこんで、実行していなかったりします。 PMBOK第3版では、このような曖昧になりがちな部分がより明確に表現されています。 |
||||||||||
| 統合マネジメントの明確化 | ||||||||||
|
統合マネジメントはプロジェクトの立ち上げから終結までのひとまとまりが記述され、統合マネジメントだけでひとまず完結する形に変わりました。そしてそれぞれの知識エリアにおける計画プロセス群のプロセスは、プロジェクトマネジメント計画書作成プロセスのより詳細な説明ともいえるイメージです。これらの詳細な計画の対象として、それぞれの知識エリアの計画プロセス群以外のプロセスをガイドとして捉える考え方も成り立つと思います。 例えばPMBOK2000ではスコープ・マネジメントに「立上げプロセス」が入っていて、そこで「プロジェクト憲章」が作成されていましたが、「プロジェクト憲章」はスコープの範疇とはいいにくいものでした。そして「スコープ計画プロセス」では、「スコープマネジメント計画書」と「スコープ記述書」の両方を作成しており、スコープに関して定義の仕方や変更管理などの「進め方を考えること」と「スコープ自体を定義すること」の区分けは、プロセス単位では実現されていなかったことになります。 PMBOK第3版ではこのあたりが大きく変更されて明確に区別されるようになり、その内容はIT業界にあてはめてみても理解しやすいものになっています。これについては考え方として大切なところでもありますので、後の回で詳しく説明する予定です。 |
||||||||||
| 統合変更管理の位置付けや他プロセスとの関連 | ||||||||||
|
PMBOK第3版では「変更などの承認にあたってはプロジェクト全体をよく見渡す」という考え方が統合マネジメントを中心として、より明確になっています。それをあらわす言葉として「要求済み変更」「提案済み是正処置」「提案済み予防処置」「承認済み変更要求」「確認済み欠陥修正」などがあります。特に「要求済み変更」は重要です。 これらは用語集で明確に定義され、すべて文書化される必要があるものとしています。 例えば「欠陥修正」は、「品質管理プロセス」や「プロジェクト作業の監視コントロールプロセス」などから「提案済み欠陥修正」がアウトプットされます。そしてアウトプットされた「提案済み欠陥修正」は「統合変更管理プロセス」で「承認済み」となり、「プロジェクト実行の指揮・マネジメント・プロセス」を経て「実施済み」となります。 そしてさらに、再度「品質管理プロセス」や「統合変更管理プロセス」で「確認済み欠陥修正」となります。またそのほかは大抵が「提案済み」「承認済み」「実施済み」までの流れとなっています。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||

