 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 「案件見積もり」フェーズの注意点 | ||||||||||
|
このフェーズにおいて、以下のような注意点があげられます。
表2：「案件見積もり」フェーズの注意点 我々と同様、お客様側もビジネスを行っているので、お客様側の担当者もシステムに関する予算枠や担当者の上長への折衝、内部検討会議のスケジューリングなど様々な業務に忙殺されています。時間や余裕がないことは珍しくなく、完全なRFPを頂けることは稀です。 案件の業務知識と実現したい内容についてはお客様が「プロ」ですが、システム化についてはプロジェクトマネージャー（以下、PM）や、プロジェクトリーダー（以下、PL）が「プロ」になります。見積もり段階といえども曖昧模糊としたRFP要件に対して、ある程度のシステム化提案を行うことができれば、お客様に信頼して頂けることが多いと感じておられる方もいらっしゃるかと思います。 これに加えて、システム化提案が機能ごとに具体化してあり、なおかつ前提条件をつけてあると仮定しましょう。すると、万一お客様と営業、PM、PLの間にRFPの内容などの相互理解に齟齬があり、要件定義時以降のフェーズで案件にあわない見積もりであることが発覚したとしても、基本設計後の再見積もりなどプロジェクト体制を見直す方向へと話を繋げていくことも無理のある話ではありません。 「だいたいこのような機能を実現して欲しい」に対して、前提条件も無く、見積もり根拠とした内容提示を行わない概算見積もりを提出してしまうと、なし崩し的に開発着手となり、多方面から「こんなはずではなかった」との声があがってくる結果にもなり兼ねません。 最終的にお客様に満足して頂くためにも、見積もり前提条件などの条項を加え、決定していない事項や、不明な点については、常に明らかにし、別途打合せを設けるなどの管理を行う必要があります。 |
||||||||||
| 「案件見積もり」フェーズでの管理手法 | ||||||||||
|
「案件見積もり」フェーズでは管理ツールよりも「管理手法」の比重が高くなります。用いられる管理手法としては以下のようなものがあります。
表3：「案件見積もり」フェーズで使われる見積もり手法の例 |
||||||||||
| 「要件定義、ヒアリング」と「基本設計」フェーズ | ||||||||||
|
誌面の都合上一緒に解説しますが、この「要件定義、ヒアリング」と「基本設計」は、「お客様の業務要件を正しくヒアリングし、最適な課題解決ソリューションを提案」する土台となるフェーズです。 これは見積もりと同等かそれ以上に大事なフェーズであり、ここで正しく相互理解を獲得できなければ、お客様満足度や瑕疵対応、追加案件の切り分けなど、後々のフェーズに大きな影響が出ます。 |
||||||||||
| 「要件定義、ヒアリング」と「基本設計」フェーズの注意点 | ||||||||||
|
「要件定義、ヒアリング」と「基本設計」フェーズにおいては、以下のような注意点があげられます。
表4：「要件定義、ヒアリング」と「基本設計」フェーズの注意点 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
