引き続き、I/Oを中心にプロセス間の関連や、全体の構造や、フローを見てゆきます。今回のテーマは「スコープ定義」。

・ユーザーの要望を聞いて、
・今回の開発範囲を決定し、
・作業に入れるようなWBSを作る

といういつも我々がやっている仕事のうち、「開発範囲を決定」する部分です。

実務面、特に一括受託案件ではこのスコープ定義が最も重要である、といってもいいのではないでしょうか。その理由は、なんといっても、このプロセスのアウトプットには『プロジェクト・スコープ記述書』が含まれているから。

SI案件のトラブルの多くは、この『プロジェクト・スコープ記述書』のデキが悪かったり、曖昧だったりすることに起因します。そもそも契約時に『プロジェクト・スコープ記述書』に相当する”見積り仕様書”等の文書の添付が無いことも(!)。

いや、笑い事ではありません。営業が提出したプレゼン資料や、業務部門が指定する成果物(”ドキュメントおよびプログラム一式”などの記述)、組織の公式な押印の無い文書は、実はプロジェクトの成果物を規定したものではありません。

顧客による最終的な受入の基準は、この公式な『プロジェクト・スコープ記述書』に基づいて行われます。もし『プロジェクト・スコープ記述書』による運用が営業資料で代行されているような場合は、”見積り仕様書”等の文書の添付を案件受注の必須条件とするように、ぜひ業務部門を巻き込んでプロセスの改善にチャレンジしてください。

さて、スコープは計画時に決定されます。それが記述された『プロジェクト・スコープ記述書』は、顧客の受入まで凍結されるのでしょうか?よく、一括請負契約の案件では、アップフロントに決定された要件は、後生大事にプロジェクト完了まで持ってゆく誤解がありますが、違います。

『プロジェクト・スコープ記述書』は、チームメンバーの新業務システムに対する理解や、先行するパイロットシステムからのフィードバックによる技術的なブレークスルー、顧客側プロジェクトメンバーのITリテラシー向上などにより、すこしずつ精緻化されるのが自然です。

ただ、それらの変更要求をのべつまくなしに受け入れていたら、後続のアクティビティ順序設定、所要期間見積り、スケジュール等のアウトプットが信頼性を失い、たちまちプロジェクトは瓦解します。

柔軟な変更の受入はどうやるか。一括で委託されている大型プロジェクトの場合は特に、タイムボックス(3ヶ月とか6ヶ月とか)を決めて順次リリースし、その期限内で資源(開発要員)に見合ったアウトプットを決めてゆくのが経験則です。それぞれの版(バージョン)の管理を精緻に行うとともに、前の版で発生した軽微な変更要求に対応してゆきます。大きな変更は、より上位の変更イベントで吸収します。

さて、スコープ定義のITTOです。インプットは、プロジェクト全体を規定するプロジェクト憲章、手順や書式、テンプレート、類似案件などの組織のプロセス資産に加えて、この知識エリアのマネジメント計画書がインプットのお約束。特にこのプロセスでは、前プロセスの「要求事項収集」のアウトプットである『要求事項文書』から、今回採用する要求事項の選択が行われます。

(インプット)

・プロジェクト憲章
・組織のプロセス資産
・スコープ・マネジメント計画書
・要求事項文書

アウトプットは、前記の『プロジェクト・スコープ記述書』に加え、各種の『プロジェクト文書更新版』を忘れずに。

(アウトプット)

・プロジェクト・スコープ記述書
 [プロダクト・スコープ記述書、受入基準、成果物、除外事項、制約事項、前提条件]
・プロジェクト文書更新版

時々引いて、ふわっと全体を捉え、鷹の目でポイントを掴むことも大切です。図はPDFで以下に置きました。ダウンロードしてご利用ください。

5.3_スコープ定義_ITTO_20150614

※ 本資料はプロジェクトマネジメント知識体系ガイド(PMBOK® Guide)第5版 (A Guide to the Project Management Body of Knowledge)に準拠しています。PMI, PMBOK Guide, PMP は、プロジェクトマネジメント協会(Project Management Institute,Inc.)の登録商標です。

(27)スコープ定義ITTO

コメントを残す