立ち上げフェーズでリスクと制約条件を把握せよ

リスク管理は、立ち上げフェーズだけではなく、プロジェクト全期間を通して行なうものです。IT業界では、なぜか、リスク管理は行なわず、課題管理を行なっているのが現状です。

なぜリスクではなく、課題管理をおこなうのでしょうか？

まず、リスクと課題はどのような違いがあるかを考えて見ます。

リスクとは、将来起こり得る事象で、プロジェクトに対してプラス、或いは、マイナスの影響を与えるものです。

課題は、現在起こっている事象で、プロジェクトに対してマイナスの影響を与えているものです。

何も対策を考えていないリスクが発生したら、それは、課題となります。

プロジェクトでいろいろなことが起こり、発生の都度、担当者を決め、解決していくから、前もってリスクの対応策を考えておくことは無意味なことだと考えているのでしょうか。

そうではないですよね！

リスクや制約条件を把握することで、合意したプロジェクトの目標が本当に達成できるかどうかを判断することができます。

IT業界で行なわれているプロジェクトの大半が目標をしっかり立てていない状況を考えると、それに関係しているのでしょうか。

では、どのようなポイントからリスクや制約条件を分析すればよいのでしょうか。

リスクを考える領域は、

資金
時間
要員
顧客との関係
プロジェクトの規模
外部要因

等のプロジェクトそのものの領域と、

市場の受容
市場投入までので時間
コスト

等のビジネス上の領域を分析しなければなりません。

制約条件を考えるには、

予算
スケジュール
要員
現実
設備

等があります。

特に、よくある例が、

カットオーバー期日が決められていて、
それに合わせたスケジュールを作成し、

プロジェクトをスタートしたのは良いが、

十分なスキルを持った要員を確保できない

というような事態に陥るプロジェクトが多いことです。

現実的に、実行できる計画を作成するためには、その前提となる条件を考える必要があります。

ITプロジェクトが、「24時間戦えますか」の状況に陥ってしまうのは、リスク、制約条件を考慮した計画を作成できていないことに原因があると考えています。

あるITベンダーが私の顧客に提出した提案書を評価した時に感じたことです。

その提案書は、わずか5ページにも満たないもので、作業手順、スケジュール、コストだけしか書かれてありませんでした。当然、制約条件、リスクなどはありません。

もし、このベンダーに発注したら、プロジェクトで、

プロジェクトの目的が分かっているのか...？
成果物が特定できない...？
必要な作業がすべて洗い出されているのか...？
詳細スケジュールが作成できるのか...？
詳細スケジュールなしでプロジェクトがスタートしてしまうのではないか...？
スケジュール変更を平気で行なうのではないか...？
コスト超過になるのではないか...？

のような、たくさんの？？？が出てくるのではないかと感じてしまいました。

この提案書は、このベンダーに発注したら、このようなリスクが発生するかを考える上で、顧客にとって良い材料となってしまいました。

少なくとも、提案書は、安心感を与えるものを提出してもらいたいものです。

そういう意味で、顧客にとっては、プロジェクトのリスク、前提条件、制約条件を考える上で、ベンダーから提出された提案書を分析、評価することが、その第一歩となると思います。