| « 2006年12月15日 | 2006年12月16日の投稿 |
2006年12月17日 » |
赤字プロジェクトは頭が痛い問題です。赤字の原因としては、「要件の詰めが甘く、ユーザとの認識違いから仕様変更が多発しそれに対応するため、結果として赤字になった」と言われます。
確かに、要件を全て確定することは、業務の要求もそれを実現するシステムが複雑化している現状では難しいことだと思います。ある程度のリスクがこの部分に内在していることは否めません。しかし、その一方で、要件定義、設計、さらにはプロジェクト管理の工数を、このリスクを減らすために有効に活用したかどうかに関してはあまり議論されません。かかってしまった工数に関してもう一度その使い方、特に100%は無理にしても出来る限り要件のぶれをなくすために打てる手を打ってきたかどうか、その反省は殆ど行われていません。
プロジェクトによって、事情は様々だと思いますが、特に大規模プロジェクトでは、目の前の設計や管理作業だけでなく、プロジェクト全体を見渡して、ある程度標準的な管理手法を逸脱しつつも、ユーザとの要件の詳細の詰めや確認作業を行う工数を別途確保しておくことで、後半になってのブレを多少でも少なくすることは可能だと思います。
もう一度赤字になったプロジェクトの、前半での資源の使い方を見直してみることも、今後同じ失敗を繰り返さないために重要なことだと思います。
| « 2006年12月15日 | 2006年12月16日の投稿 |
2006年12月17日 » |

顧客に“ワォ!”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命