必ず作ろう、実行計画書

これまで情報化資源調達フェーズを扱ってきました。今の時点は、採用するソリューションを決定し、以降の開発フェーズを行なうベンダーも選定できましたという段階です。
この段階になると、開発プロジェクトの実行計画書を作成しなければなりません。これは、資源調達フェーズと開発の橋渡しをする成果物です。


実行計画書では、これまでの成果物をまとめ、文書化します。この文書は、PMBOK第3版で言えば、プロジェクト憲章、或いは、作業範囲記述書と言えるものです。私としては、作業範囲記述書と言う言葉を使うと、どうもピンとこない。実行計画書とか、プロジェクト企画書と呼んだほうが良いのではないかと思っています。
さらに、PMBOKでは、プロジェクト憲章、作業範囲記述書を立ち上げプロセスで作成することになっています。どちらも同じような内容の文書であり、企業によっては、同じ意味で使われることもあります。
これらの文書の違いは何でしょうか。
PMIの用法では、プロジェクト憲章は、プロジェクトマネジャーがプロジェクトを開始し、ヒト・モノ・カネを投入することを許可する文書と位置づけています。一方、作業範囲記述書は、プロジェクトを正式に定義する文書であり、プロジェクトから生み出される製品・サービスを規定するものとしています。
どんな言葉で呼ぼうと、いずれにしても、以降に開始するプロジェクトを定義する文書であることには変わりありません。
実行計画書は、小規模なプロジェクトであれば、1,2ページ程度ですが、大規模なプロジェクトになれば、技術的な内容も記述するため、100ページほどになることもあります。
一体、何を記述するのでしょうか。
記述するポイントは、以下のような事項です。
まず、プロジェクトの目的。そもそも、なぜプロジェクトを実施するのか?という問いに対して、明確に答えなければなりません。
スコープ。プロジェクトでやること、やらないことを明確に定義します。
プロジェクト成果物。プロジェクトが何を生み出すのかを明記します。
プロジェクト目標。プロジェクトの成功基準を明確にしなければなりません。
コストとスケジュールの概算見積。概算ながら、根拠のある見積をしなければなりません。算出前提条件などを明確にしながら記述します。
ステークホルダー名簿。プロジェクトに影響を与える利害関係者とその役割を明確にします。
指揮命令系統。プロジェクトの体制図、報告関係を明確にします。
前提条件と合意事項。プロジェクトの選択肢を限定する前提条件や、制約条件、さらに、基本となる合意事項について、ここで明記しておきます。
コミュニケーション計画。基本となる報告書の発行、会議の目的、参加者などを明確にしておきます。
以上の事項が基本的に必要な項目です。場合によっては、さらに、採用するソリューションの概要、フィージビリティスタディの結果、技術的な内容、リスク分析などいろいろな項目が必要となります。
要は、この文書でもって、開発プロジェクトを実行に移すための承認を得るために必要な項目を網羅すると考えればよいでしょう。
では、誰が実行計画書を作成するのでしょうか。
基本的には、プロジェクトの母体組織が作成します。PMIの考え方では、プロジェクトスポンサー、或いは、ビジネス上の責任者が作ることになっています。でも、日本では、まず考えられない。実質的には、プロマネが作成することになるのではないでしょうか。
しかし、場合によっては、実行計画書をベンダーに作成してもらったりする場合もあります。
あるSIベンダーが実施しているプロジェクトでの話です。プロジェクトの母体組織である企業の常務より依頼があり、レビューを行ないました。この常務がプロジェクトスポンサーです。
常務曰く、「プロジェクトの全体像が分からないので、今どの様な位置にいるのかもわからない」とのこと。このプロジェクトは、要件定義で約1ヶ月程度遅れが出ている状態でした。
まず、実行計画書を見せてもらうと、それは、プロジェクト計画書であり、詳細な内容ばかり記述されているものでした。当然、プロジェクトの目的等は記述されていません。
常務にとっては、詳細すぎて、全体像が分からなかったのでしょう。そこで、SIベンダーのプロマネに、プロジェクトの目的、スコープ、成果物などを数枚のレポートにしてもらい、常務に納得してもらいました。
それにしても、これでよくプロジェクトを開始できたものだと思いました。まだこのプロジェクトは、早い段階で根本的なことを合意できましたが、何もしないでおくと….ゾッとします。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*