前回、このシリーズのまとめに入ろうと思っていたのですが、肝心の改善手法に触れるのが不十分だったので、少しだけ延長することにしました。悪しからずご容赦ください。
次にそのプロセスを１００％活用できるように環境を整えます（無駄な待ち時間をなくし、作業に集中できるようにマルチタスクを排除するのでした）。
さらに、それでも改善が充分でなければ、能力の拡大を図ります（省力化のためのツールの導入や人材の追加ですね）。
最後に、再度プロセスのパフォーマンスを測り、その時最も効率の悪いプロセスを探し出し、改善の作業を行います。
このように、改善活動を繰り返し行うことで、さらにプロセスのパフォーマンスを上げることができます。改善とは継続的に行うもので、一過性のものではないということですね。
もう一つ大きなポイントとして、プロジェクトのプロセスにはプロジェクトに固有のプロセスと、多くのプロジェクトに共通のプロセスがあるので、これを区別して考える必要があるということでした。
もちろん、多くのプロジェクトに共通するプロセスを改善することは、その効果も大きくなるので最重要なポイントとなります。
しかしながら、このような汎用的なプロセスの問題は、得てして組織の文化に依存したり、強固な習慣として行われていたり、多くの部署や関係者が存在したりします。
そのためそれを改善しようとすると、非常に大きなエネルギーと相当の時間が必要になることがあり、単なるプロジェクトプロセスの改善で終わらなくなることがありますので、費用対効果を見定めてどう取り組むかを判断する必要があります。
でも、大変ですが改善が実現した時の効果も大きくなるので、それに取り組むことは決して無駄ではないと、キットＰＭは考えています。
一方、無駄な待ち時間の発生によるスケジュールオーバーや、成果物の品質に問題があるなど、プロジェクト固有のプロセスにパフォーマンスの問題がある場合、そのほとんどはプロジェクトの立ち上げや計画段階で、ちゃんとマネジメントできていないことに原因を求めることができます。
つまり、プロジェクトで発生する多くの問題は、マネジメント品質に依存していることになります。このような場合は、ＰＭＢＯＫ®で示されている各知識エリアの要素に従って、本来必要な作業が抜けていないか、実行しているけれど不十分ではないか、ツールやテクニックの理解が不十分でないかなどを、チェックすることが必要となります。
最後に誰が改善活動を主導し、誰が実施するのか改善の組織構造について考えてみます。
プロジェクトのプロセス改善は上で述べたように、その活動を継続的に行うことが必要となります。決して一過性の活動ではありません。ということは、改善活動そのものをプロジェクトとして捉えることはできないということになります。
実施するのは、プロジェクトに関わった経験のある社内のメンバーとなるはずですが、それを主導しマネジメントするのは、常設の組織である必要があります。
プロジェクトマネジメントに関わる常設の組織と言えば、ＰＭＯ（プロジェクト・マネジメント・オフィス）ですね。
つまり、プロジェクトプロセスの改善は、ＰＭＯもしくはそれに類する組織体が主導して、実際に改善活動を行うメンバーをサポートすることになります。
大変な作業ですが、改善活動の立ち上げタイミングで外部のコンサルタントを導入するのも、効率的な手段ｔなります。もしこのような御用命があれば、キットＰＭまでご連絡いただければ、喜んでご相談に乗りますのでよろしくお願いいたします。
さて、随分と長くなりましたが、これで本シリーズは最後となります。まだ、考慮しないといけないことも沢山ありますが、一先ず終了してまたどこかで取り上げたいと思っています。
次回から新テーマでお送りしますが、テーマはまだ決まっていません。お楽しみに！