 |
||||||||||||||||||
|
||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||
|
||||||||||||||||||
| 当事者意識が欠如していないか | ||||||||||||||||||
|
さらにB部長の話しを聞いていくと遅延自体の引き金をB部長自身が引いてしまっていたこともわかってきた。 「開発ベンダーはスコープが増大したといっていますが、確かに、設計終盤に『業務ユーザとの調整が難航しており、新たな要望によって仕様が膨らんでいる』という相談を受けたことはあります。でも、新システムのコンセプトとは多少ずれるけれども、現行業務でできることは新システムでも保証範囲だと当初から話しをしていたので押し込みました。一括委託契約の範囲での変更ですから、工数が増加しても当社にとってのコスト増加にはなりませんからね。開発ベンダーからもそれ以上何もいってこなかったので『できるんだ』と思うじゃないですか」  図1：A社システムの一括委託契約範囲 （画像をクリックすると別ウィンドウに拡大図を表示します） B部長は、ここでもプロジェクト全体を見ると言うよりも、発注側としての立場で行動していることがわかる。そのため、稼働中のプロジェクトに対する影響を考慮せず、想定していなかった大きな仕様を無理矢理押し込んでしまったのである。 発注側であるユーザ企業の優位な立場を利用して、無理に大きな仕様を押し込めた場合、必ず全体になんらかの影響を及ぼすことを発注側でもプロジェクト推進の当事者として十分に注意する必要がある。 もちろん、全体に対する影響を的確に報告し、代替案を含めて正しい判断を仰いでもらえるようユーザ企業側と調整することができなかった開発ベンダー側にも問題はある。ただ、開発ベンダー側が睡眠時間を削ってまで作業を行っている状況で、正しい判断を仰いでもらうための働きかけが十分にできない可能性は、ユーザ企業側でも考慮しておくべきであった。  図2：発注側、受注側の立場の相違による対立 （画像をクリックすると別ウィンドウに拡大図を表示します） つまりB部長がプロジェクト推進者として当事者意識を持ち、プロジェクトの進捗や課題・リスクと向き合い、主体的に課題解決に取り組んでいれば、今回のような事態は未然に防げた可能性があるのだ。 |
||||||||||||||||||
| プロジェクトのギャップを解消するためには | ||||||||||||||||||
|
「プロセスのギャップ」はほとんどの場合、プロジェクト終盤に顕著化してしまうことは説明してきた通りだ。しかし、このような危機的な状況に陥った場合、そこから解決をはかることは並大抵の努力では達成できない。 このためプロセスのギャップに対処するにはあらかじめギャップそのものを発生させないよう、事前に対処しておくことが重要だ。 次回は、このプロセスのギャップを発生させないための方法について解説する。 |
||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
-
-
連載
