プロジェクトを開始する前の立ち上げフェーズで、
ステークホルダーを特定し、
プロジェクトの目標を合意して、
核となるメンバーを選定し、
プロジェクトの前提条件、制約条件、リスクを分析しました。
PMBOKでは、これらがインプットとなり、プロジェクト憲章の作成と、スコープ記述書暫定版の作成が、立ち上げフェーズのプロセスであると定義されています。
何度も言いますが、プロジェクトは最初が肝心です。ここで誤った定義をすると、プロジェクトは迷走します。そういうプロジェクトを何度も見てきました。
そういう意味で、プロジェクトの立ち上げフェーズは、プロジェクトの定義フェーズであると言い換えることができます。
もし、この時期に、取り得るソリューションが複数あって、そのどちらを取ればよいかわからなかったら、どうしますか？
資源調達にも関係しますが、提案されたソリューションが複数あって、優劣付け難い場合などは、どのようにして最適案を決定しますか？
その時は、フィージビリティスタディを行なうことになります。大きいプロジェクトだと、フィージビリティスタディそのものを別プロジェクトとして実施する場合もあります。
皆さんも良くやると思いますが、複数の案のメリット、ディメリットを列挙して、比較検討することで、最適案を採用する。簡単なフィージビリティスタディは、このようなものです。
開発期間中にある課題を解消するための方法を検討する時、よく行ないますよね。
フィージビリティスタディの結果が、将来を左右することになりますから、慎重に行なわなければなりません。
ある医薬会社で行なわれていたBI導入のプロジェクトで、フロントとしてレポートを見せるためのOLAPを何にするかを決めなければならない局面になりました。
開発ベンダーがフィージビリティスタディを実施し、その報告書を顧客に提出しました。その報告書を顧客と一緒に評価したわけですが、非常に良くまとめられたものでした。
評価ポイントを決め、代替案ごとにそのメリット、ディメリットを列挙し、その詳細内容の分析手法と分析結果を比較できるような形で、50ページにもおよぶ報告書でした。その中には、当然、代替案ごとの制約条件、リスクも含まれており、顧客側としては、決定をしやすい内容となっていました。
方や、ある製造業のBI導入プロジェクトで、同じ局面で、ベンダーから提出されたフィージビリティスタディ報告書は、惨憺たる内容でした。
評価ポイントは決めていましたが、メリット、ディメリットも列挙されず、評価ポイントごとに○×△を付けているだけのわずか1ページの内容でした。
おまけに、評価ポイントに、機能、汎用性、開発リスク、コストと言うような言葉で書いてあり、その内容が全く分からないものでした。
フィージビリティスタディを行なうには、その評価ポイントの定義と、分析方法を決めなければなりません。そして代替案の相違点を分かりやすく報告しなければ、意思決定者が決定することができないのは、言うまでもありません。
おいおい、お前ら本当に分析したのか？とプロジェクトスポンサーが怒り出し、この報告書は、没になってしまいました。
フィージビリティスタディのやり方とその報告書の書き方をフィージビリティスタディって何？いつやればいいの？と言う記事で公開しています。
興味のある方は、是非ご覧ください。
コメントする