前回、フェーズを分割することでプロジェクトのリスクを減らすということについて考えました。少し補足をしておきます。
フェーズを分割することで、フェーズとフェーズの間に一旦区切りを設け、プロジェクトが自動的に進んでしまうのを防ぎます。その上で、終わったフェーズの作業を振り返って、その内容を評価することでいろいろな気づきを得ることができ、その気づきを次のフェーズにインプットすることで、次フェーズの品質をアップすることが可能になります。
この気づきの中には、期限の見直しや考慮不足やタスクの漏れなど、あらゆるプロジェクトを危うくする可能性のあるものが含まれます。
ではどうやってこの振り返りの作業を実行するのでしょうか。
具体的には、フェーズ移行判定というタスクをフェーズとフェーズの間に入れ、終了したフェーズのアウトプットを評価し、当初計画との差異を分析します。その上で、不足している情報があればそれを補うタスクを抽出します。また、次フェーズ計画の内容で修正すべき点があれば、新たな修正計画を作成します。
それらの作業を行った上で、最終的に次フェーズを実行するかどうかの判断を行います。
このように、フェーズを区切ることで、プロジェクト計画の修正チャンスを意図的に設けることが可能になり、そうすることでプロジェクトの精度も向上します。課題はリスクを低減するためのコストがかかってくるということです。
また、もしプロジェクトが外部のベンダーと協力して実施するのであれば、ベンダーの再選択もフェーズ毎に行うことが可能になるということです。つまりフェーズ毎に最適なベンダーを選択することができるということです。
このように、手堅くプロジェクトを進めて行くにはプロジェクトのフェーズ分割はとても有効な手段となります。
ただ、そのためのコストも発生することになるので、適切なフェーズ分割を組み立てることが必要になります。よくあるのは、調査フェーズ＞実行フェーズ＞試行フェーズのような大きな枠組みで分割することです。
プロジェクトの形を考えるときこのフェーズについても考慮し、デザインすることはとても有効なこととなります。
フェーズ分割について、いかがでしたでしょうか。次回は、プロジェクトをデザインする上では欠かせない、チーム作りについて考えていくことにします。
以前、途中で終わっていた「ストーリーで語る」について考えて行くことにします。