プロジェクトマネジメント、プロジェクト管理におけるポータルサイト

HOME > ITの達人 > 能登原伸二達人のコラム> のとはらブログ相談(4) 要件定義フェーズでの顧客から出る要件のコントロール

2008年10月28日

のとはらブログ相談(4) 要件定義フェーズでの顧客から出る要件のコントロール

【質問】

■ご相談テーマ:プロジェクトマネジメント、その他

■課題・ご相談内容
PJ予算がおおよそ決まっていて、要件定義フェーズで要件をヒアリングする途中段階で、PJ予算を超過することが明確に分かるケースがあります。

その時点で顧客側に、このまま要件をヒアリングしてもPJ予算がオーバする旨、伝えたり議事録に記載します。

しかし、顧客側からは、PJ予算は一旦無視して要件全体をとりあえず聞いて見積するように要望が出るのですが、いざ最終的に見積を提示すると予算超過に対して納得が得られないばかりか、クレームがつくケースがあります。

開発側のプロセスとしては予算超過の兆候についてアナウンスしておりますし、特別に間違ったことはしていないと思いますが、顧客満足度やPJメンバのモチベーションが低下してしまいます。

Q1.
このようなケースにおいて顧客満足度低下やモチベーションをコントロールする術などありますでしょうか?

Q2.
また、このようなケースにおいて要件規模のコントロールはどのようにするべきなのでしょうか?


【回答】

A1.
プロジェクトの予算がほぼ決まっていてる場合には、その予算の範囲で開発すべき要件に抑えて、開発スコープを決定することが正論だと思います。
本来は、要件定義の工程までで契約して、それ以後の工程の作業について別契約にしておけば、その工程の契約をしなくて良いわけですから、問題ないと思います。

今回のケースでは、要件が決まっていない段階で、情報システムのカットオーバーまでの契約を一括で請け負ったということでしょうか?
ITプロジェクト全工程の一括受注には、本来大きなリスクが伴います。大きな利益を得る可能性がある反面、大きな損失も生み出す可能性があります。
そういったリスクを理解した上で、受注した案件であれば、案件を受注した主体者(営業、PM)は大きな責任があると思います。

顧客との交渉によって、適切な開発スコープを目指すと共に、契約に関わりのない開発メンバーの評価に影響が出ないように、営業、PMが必死でプロジェクト成功に向けて、活動することが、メンバーもモチベーションを維持する唯一の方法だと思います。


A2.
正しい要件定義の技法に従って、要件を実施し、作業工数、金額を見積り、顧客と交渉することに尽きると思います。

当初の予算をオーバーした分については、すぐに必要のない要件を作成しないか、ファーズを分けて工程を延期して開発するかなど、顧客の状況に応じて、対応します。

コメント[2件] | トラックバック[0件]

コメントを書く

名前もしくはニックネーム(投稿者名として表示されます)※必須

メールアドレス(ページには表示しません)※必須

URL

コメント(スタイル用のHTMLタグが使えます)

 

※コメントは承認後に公開されますので少々お待ちください。

トラックバック

このページのトラックバックURL:
http://www.promane.jp/blog_manager/mt-tb.cgi/611

このページへのコメント一覧

ご回答ありがとうございます。投稿者です。
状況が正確に伝わっていないようですので補足させていただきます。

今回のケースは、当然ながら要件定義で契約は分割しています。

つまり要件定義フェーズで、以降のフェーズの見積もするということなのです。

ここで言っているPJ予算というのは、
「例えば1億円という予算が決まっている。」
要件は自分たち(顧客側)で定義できないので、いっしょに要件定義して、見積もって欲しいという依頼なのです。

結果として、次々と要件が出てきて、聞いているとどう考えても1億円ではおさまらないが、顧客からは「とりあえず全部聞いてくれ」ということです。

以降のストーリーは説明済みです。

これを受けてご回答を頂けると幸いです。

投稿者:clarions 2008年10月28日 15:57

能登原です。
コメントありがとうございます。

契約は分割していることは、理解しました。
契約を分割しているのであれば、要件定義フェーズで顧客の要件を全部聞いた上で、後続フェーズの契約を結ぶことになります。
以下のような対応が考えられます。
①予算の範囲内に絞った要件分のみ、開発する。
②顧客に追加予算を取ってもらい、全ての要件を開発する。
③利益はほぼ無し、あるいは赤字でも契約し、開発を継続する。

ベンダーのPMのミッションはプロジェクトを実行することで、利益を上げることですから、そのミッションを果たすことを最優先させることが最も重要です。
よって、①、②のケースに持っていくように交渉するべきです。交渉の過程で利益率もぎりぎりになる場合もあるでしょうが、大幅に赤字が出るような契約はするべきではありません。撤退も念頭に置きながら粘り強い交渉をする以外に打開策はありません。
顧客満足度を論じる前に、理不尽な契約を結んで、開発を継続した場合の開発メンバーのモチベーション低下を考えるべきです。どんなに熱意をもって開発しても、赤字プロジェクトとして評価が下がるのであれば、モチベーションが上がるはずがありません。

ただし、長期的な利益を得るために、③のケースのように利益を重要視しないのであれば、経営層の承認も含めて、社内の関係者の合意を取った上で、開発を継続することもあると思います。
この場合は、利益を評価基準にするのではなく、計画通り開発を遂行し、顧客に満足を与えたことで、後続の仕事がもらえたことを評価基準にすれば、開発メンバーのモチベーションは低下しないと思います。

投稿者:能登原伸二 2008年11月06日 08:03

↑ このページの先頭へ