なぜプロジェクトマネジメントが機能しないのか 03 リスクの早期顕在化

日本で最初の民間シンクタンクで、プロジェクトマネジメントのコンサルタントとして、ある時はＰМ、ある時はＰМОとして、お客様と問題解決に取り組んでいます。本記事では、まだＰМＢОＫには書かれていない暗黙知を言語化し、形式知としてお伝えすることにチャレンジしてみようと思います。
マガジン：https://note.com/think_think_ab/m/m0e070db46016

実現性の確認

プロジェクトにおける比較的大きな不確実性として、
要件の実現性があります。

技術的な課題、オペレーション上の課題、材料や要員の調達上の課題や
法律上の課題など、要件の実現にあたってはさまざまな課題があり、
やってみなければわからない状況があります。

こうした状況の場合、
実現性確認の工程の置き方ひとつで「不確実性の排除＝リスクの顕在化」のタイミングが異なってきます。

上述の３パターンのうち、
Ａパターンのみが、プロジェクトマネジメントが機能しているパターンで、

残念ながら、Ｂ、Ｃパターンは成り行きリスクが顕在化するパターンで、
プロジェクトマネジメントは何も機能していません。

以下、個別に説明していきます。

Aパターン：不確実性の早期排除

不確実性の早期排除との観点でプロジェクトマネジメントが機能しており、
要件定義と並行して、実現方式が検討され、ポイントとなる課題について
実現性が確認されることで、不確実性の排除が前倒しされています。

このパターンの場合、
要件定義と並行して、要件の実現性が確認されるため、
要件定義完了時は実現性確認済みの状態となります。

そのため、設計工程まで進んでから、
実現できないとの理由で要件が見直されることは
ほとんどなくなります。

Ｂ、Ｃパターン：成り行きマネジメント

一方、Ｂ、Ｃパターンでは、
不確実性の早期排除との観点でプロジェクトマネジメントは機能せず、
要件定義中には実現方式が検討されず、実現性も確認されていないため、
不確実性（＝リスク）は残されたまま設計工程に入ります。

成り行きでリスクが顕在化していくため、
設計工程で要件が実現できないことが五月雨で発覚し、
その都度、要件の大きな見直しが発生します。

ユーザ部門は
度重なる要件見直しに対して、開発部門に不信感を持ちつつも
なぜ事前に実現性を確認してなかったのかと責任を問うこともなく、
苦々しくても、ただただ要件変更を受け入れざるを得ない状況です。

このパターンの場合、ユーザ部門・開発部門のいずれも、
プロジェクトマネジメントが機能しているＡパターンを知らないため、

成り行きでリスクが顕在化しても、お互いに仕方がない、
そういうものだと状況を受け入れることになります。

ユーザ部門にとっては、開発部門から
「まずは先に要件を決めてください」といわれて要件を定めたものの、
　ことごとくできないことになり、モチベーションを失います。

残念ながら、実際にこうしたパターンは散見されます。

ガントチャートを引いたり、進捗管理を行ったり、
「プロジェクトマネジメントのようなこと」は形式的にやっているものの、

本来の目的である不確実性の早期排除と繋がっていないため、
プロジェクトマネジメントが機能しないのです。