 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| PMBOK第3版の特長である「要求済み変更」 | ||||||||||
|
特に大事な「要求済み変更」について、用語集では「公式に文書化された変更のうち、承認を得るために統合変更管理プロセスに廻されたもの」と定義されています。つまり、「統合変更管理プロセス」のインプットであるということまで明確に定義しているのです。 そして様々なプロセスから「要求済み変更」がアウトプットされ、統合変更管理プロセスのインプットとなります。「承認済み変更要求」は様々なプロセスのインプットとなっています。これによって各プロセスは全体として有機的につながり、「プロジェクトが全体として1つのものである」という一体感を表現しています。この「感覚」は、プロジェクトマネジメントを成功に進めていく上で極めて重要です。 |
||||||||||
| 誤解をまねきやすいプロセス分類の変更 | ||||||||||
|
プロセス群などの分類が理解しやすいように整理された例として、まず「契約管理プロセス」があります。PMBOK2000では「実行プロセス群」にありましたが、PMBOK第3版では「監視コントロール・プロセス群」に分類されました。また知識エリアの変更としては、「コミュニケーション・マネジメント」にあった「完了手続きプロセス」が「プロジェクト終結」と名称を変えて「統合マネジメント」となりました。 「契約管理」は、支払処理などに視点を当てると、見方によっては契約内容の履行（実行）といえます。また監視や変更管理の対象が「契約」であって、直接の成果物作成活動ではないということになり、コントロール・プロセス群からは少し離れた活動ともとれます。ですから実行プロセス群に位置していた事については、個人的におおむね納得していました。しかし、わかりにくいということや契約を対象とした「監視コントロール（変更管理）」という視点で変更されたのだと思います。 「完了手続きプロセス」は試験対策講座でよく質問されましたが、個人的には好感を待っていました。。というのも、技術者としてはおちいりがちな「物ができたから終わり」ということではなくて、「顧客他承認者から、（コミュニケーションを取った上で）明確に承認を得てはじめて終了となる」という観点から、コミュニケーション・マネジメントに配置されるべきと筆者自身が納得しているからです。 業務システム開発においては、プロジェクトの最後に顧客側と開発側双方がスッキリと「これで終わり、とてもうまくいきましたね！」と、心の中に何ら引っかかるところのない形でプロジェクトが終了できることを目指すべきです。そしてそのためには、何よりもコミュニケーションが重要です。それもただのコミュニケーションではなくて、相互の理解と納得の実現を目指したものでなければなりません。このことを言葉にするのは簡単ですが、実現はとても大変です。 とはいえ、理解しにくいことによって広く受け入れられないとなれば、結局その意義も薄れてしまうという観点もあったのではないかと思います。それこそ、コミュニケーション・ギャップになってしまいます。 真意を理解してもらうのは次のステップに回すとして、まずは受け入れてもらわなければなりません。第1回の冒頭に記述しましたが、内容よりも「少し表現が異質」という表面上の要因で悪くいわれてしまうこともありますので、その視点でPMBOK第3版の構成はぱっとみてわかりやすいものとなっていると思います。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
