春分の日だった土曜日は、キットＰＭの３０回目の結婚記念日でした。かといって特別なことがあるわけではないのですが、近所のちょっといいお鮨屋さんで相方と食事をしてきました。３０年といっても特に何かしらの感慨があるわけではなく、これまでいろんなことがあって、これからもいろんなことが起きるのだろうなぁと、思った次第です。これから何かが起きたとき、相方と一緒に乗り越えられれば幸せなのかもしれません。
プロジェクトの品質と効率を上げるために必要なのは、プロジェクトマネジメントの質を向上させる必要があるわけですが、それだけで解決するものでもありません。
プロジェクト実施のプロセスそのものを最適化する、プロセス改善の活動が不可欠になります。
前回考えたのは、どのような体制でプロセス改善を進めるのかでした。キットＰＭの考えは、ＰＭＯなどのプロジェクトを統括すべきしかるべき組織がスポンサーとなって、プロジェクト化する方法です。
普通プロジェクトは、組織の様々な部署が相互にかかわりを持ちながら進んで行きます。ということは、プロジェクトのプロセスそのものも部署間調整の在り方に多くを依存することになります。ですから、プロセス改善もまた必要な関係者を集めて実施する、プロジェクト形式で行うことが自然な流れになります。
これには、プロジェクトがアウトプットした成果を取りまとめるＰＭＯが存在することが前提となります。ＰＭＯはプロジェクトで得られた結果を正式に組織のルールにし、内部に周知するという役割を担うことになります。
プロジェクト化することで得られるメリットには、関係者が集うことで合意形成を行い易くなるということがありますが、逆に改善のスピードが伴わなくなるというデメリットも考えられます。
多くの人が関わるれば関わるほど（ステークホルダーが多岐に渡るほど）、プロジェクトのコントロールは難しくなります。特にプロセス改善プロジェクトとなると、その利害関係の調整のハードルは高くなり、多くの時間が必要となります。
ではこのような状況が起きるのを回避するには、どうしたら良いのでしょうか。
一つの考え方として、多くの改善点を上げて一度に対策を行おうとせず、最も効果があると考えるものを、１つを改善するという方法があります。
逆に言うと、最もプロジェクト実施の足を引っ張っているものを改善するということですから、改善の効果を測ることも簡単になります。
もう一つのメリットは改善の効率が良くなるということです。小さなコストで明確な改善効果を得ることができます。
最初に一連のプロジェクト実行に必要なプロセスの問題点を考えたとき、多くの課題に行きつくことができます。
それらの問題を改善すれば、プロセスの効率がアップするということはある意味正しいのですが、必ずしも真にならない場合があります。
次回は、この問題を掘り下げて行くことにします。