プロジェクトをブレなく推進するためには、「プロジェクト憲章」や「プロジェクト・スコープ記述書」が有効なツールとなります。しかし、これらの名前を知っていても、どのように作成すべき文書なのか、まだ十分に理解されていません。
作成をITベンダーなどに丸投げすると、偏りのある内容になってしまいがちです。客観的な立場でプロジェクトを見ることができるPMOには、文書を実のあるものにする、大きな役割があります。
システム開発において、詳細設計フェーズ以降、プログラミング、単体・結合テスト、システムテストでは、ほとんどの作業が明確になり、担当者もほぼ完璧に割り振ることができるでしょう。このため、大きな仕様変更でもない限り、作業の抜け漏れをほとんどなくすことができます。詳細スケジュールとして作成したWBSは活用され、計画と実績の対比も有効に行えます。
しかし、プロジェクトの立ち上げフェーズや計画段階、またはシステム開発プロジェクトにおける要件定義フェーズなどでは、作成したWBSがすぐに現実と乖離してしまうもの。計画と実績の対比はおろか、担当者の作業の負荷状況も見えにくくなることがよく起こります。当初予定していた作業工数よりも少ないのであれば対応も容易ですが、ほとんどの場合、予定外の作業が出てきたり、思っていたよりも調整が難航したりするケースが多いものです。
そのような事態に陥らないために、プロジェクトのスコープや前提条件を盛り込んだプロジェクト憲章やプロジェクト・スコープ記述書を作成することが有効な対策の1つです。
プロジェクト憲章はプロジェクトの背景と目的、内容など、これから実施するプロジェクトの定義を明記した文書のことであり、「プロジェクト外部でその作成と認可が行われる」とされています。
ただ実際には、プロジェクトを客観的に定義できる外部の人間が作成するのではなく、プロジェクトマネジャーが作成したり、ITベンダーやコンサルタントが作成したりすることが少なくありません。
特にコンサルタントやシステム開発を請け負うITベンダーが作成した場合、総花的なプロジェクト憲章やプロジェクト・スコープ記述書となり、自社に都合のよい内容になることもしばしばです。また、他のプロジェクトとの関連やプロジェクト実施中に発生し得る様々なリスクも加味して作成すべきですが、利害が偏るため、なかなか網羅的な内容になりません。
PMOは、客観的にプロジェクトの状況を把握する立場として、このプロジェクト憲章およびプロジェクト・スコープ記述書の作成に、積極的に関与すべきです。一部のITベンダーでは、プロジェクトの開始前に採算を判断するためのPMOを組織し、収益改善に貢献していますが、プロジェクト憲章の作成段階からPMOが参画することで、プロジェクトを推進していくなかでもスコープ調整に貢献することができるようになります。
もちろんPMOの役割は、他のチームのようにプロジェクトの成果物を作成することではありませんから、中身にまで突っ込んだ議論ができないジレンマもあります。しかし、ある意味コンサルタント的な役割でプロジェクトに関わり、客観的な視点で貢献することができるため、プロジェクトマネジャーやチームリーダーとは違った意見を出せるでしょう。
また、想定されるリスクを洗い出す際、プロジェクトマネジャーが言いにくいことであっても、PMOの立場であれば言える場合があります。コンサルタントやITベンダーの意見を取りまとめ、調整することも可能です。