プロジェクトを無事に立ち上げ、計画を策定するフェーズに入りました。
皆さんはプロジェクトで、何回程度スコープを変更していますか？
顧客の要求を満たすため、何度、機能を追加していますか？
スコープをどの様に定義するかをまず最初に計画しなければなりません。
PMBOK第3版では、スコープ計画、スコープ定義、WBS作成と3つのプロセスが計画プロセス群に定義されています。このうち、WBS作成は、第3版から新たに追加されたプロセスです。
でも、スコープって一体何でしょうか。分かりやすそうで、なかなか定義できない言葉です。日本語に直せば、文字通り「範囲｣のことですが、何の範囲を定義するのでしょうか。
スコープといっても2種類あります。
プロダクトスコープ（成果物スコープ)と
プロジェクトスコープ
です。
プロダクトスコープとは、
「プロジェクトの成果物に関連する要求事項｣を言い換えたものです。
プロダクトスコープは、前フェーズ、或いは前プロジェクトの結果からもたらされるかもしれませんし、新たにプロジェクトで定義しなければならないものです。
では、プロジェクトスコープとは？
プロジェクトの成果物を作成するために必要な作業を意味します。
会議、報告書、分析など、プロジェクトマネジメントに関する作業を含みます。
ちなみに、PMBOKで出てくるスコープベースラインとは、
「プロジェクトが顧客の要求を満たしているか｣
というプロジェクトの成功を評価するための指標となるものであり、
プロジェクトスコープ記述書、WBS、WBS辞書などが該当します。
言葉の定義はこれくらいにしておいて、これから始まるプロジェクトの枠組みを決定するプロセスが、スコープマネジメントだと覚えておいてください。
これが、変更されると、スケジュール、コスト、品質に大きな影響を与えることになります。
顧客側の皆さんは、何でもかんでもプロジェクトで実現して欲しいと要求を出してきますが、ここがぶれるとプロジェクトもぶれることになります。中には、スコープを変更しても、軽微な影響しかない場合もありますが。
当然、プロジェクト側と顧客側で、スコープの合意を得ておく必要がるのは言うまでもありません。
では、プロジェクト実行中にスコープを変更することはダメなのか？
そうではありません。
SAPプロジェクトの場合、コンサルタントの方からスコープ変更を申し出る場合があります。私もよく、スコープ変更を言い出しました。（笑)
顧客の要求をよく聞くと、実現しようとする機能を実装するには、標準機能だけではできない場合があります。
しかし、詳細に聞いていくと、スコープに入っていないモジュールを追加することで、標準機能を組み合わせるて実現できる場合があります。
「そういうことを実現したいなら、xxxモジュールを追加すれば、アドオンを開発することなしに、実現できますよ。ただし、新たにコンサルタントを入れる必要があるので、コストは膨らみますが。でもアドオンを開発するよりはましでしょ。」
と定番のように言っていました。
トラックバックありがとうございました。