 |
||||||||||||||||||
|
||||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||||
|
||||||||||||||||||
| 施策1：しっかりとしたプロジェクト計画の策定と合意 | ||||||||||||||||||
|
プロセスのギャップを未然に防ぐために、そしてギャップを早期発見するための最大の施策は、プロジェクトを進めて行く上でのベースとなるプロジェクト計画書を情報システム部門主導で策定すること。そしてプロジェクト関係者全体と合意することである。 プロジェクトマネジメントは、それを行うためのベースラインがあった上で、はじめて正しい状況を把握し、ギャップの早期発見／早期対処に踏み切ることができる。これは開発ベンダーだけが理解していればよいものではなく、プロジェクトの当事者としてユーザ企業内でも十分に理解し、関係者全員と共有し、しっかりとした協力体制を構築しておかなければならない。 なお、初期の段階で無理にすべてを詳細に記述する必要はない。プロジェクト活動そのものと同様、計画書も状況に合わせて段階的に詳細化され、必要に応じて修正と共有を繰り返すことになる。不明確な点があった場合、詳細化される時期や方法が明 確になってさえすればよいのである。  図1：段階的に詳細化するプロジェクト計画書の目次例 （画像をクリックすると別ウィンドウに拡大図を表示します） 初期の計画書で重要なことは、ビジネス上のゴールやプロジェクトの目的について、ユーザ企業の普遍的な思いを自分たちの言葉で込めることである。こうしておくことで、困難な状況に陥ったときなどに原点に立ち返ってその状況を冷静に判断することが可能となる。そのためにも、計画書は情報システム部門がしっかりと主導し、考え抜く必要がある。 |
||||||||||||||||||
| 施策2：プロジェクトの現場に入り込む | ||||||||||||||||||
|
計画を策定して共有・合意形成がなされた後は、実施とコントロールを行うことになる。実施とコントロールを行う上で要となるのが、定例の進捗会議などによる報告である。 ここで注意しなければならないことは情報システム部門として報告を聞いて指摘するだけ、といった受身の姿勢ではだめだということである。発注側と受注側それぞれの立場の違いから、考慮漏れは常に発生するものだということを認識した上で「足りない部分は自ら補う」といった気概で臨む必要がある。 報告から得られる断片的な情報をプロジェクト全体の整合性といった視点で捉えた上で、様々な判断を行うことが重要なのである。 しかし、報告だけでは必要な情報が十分でない場合もある。このようなケースでは、プロジェクトの現場の中に入り込んで自らコミュニケーションを行い、必要な情報を取得するといったことが大切である。 開発ベンダーのPM以外と話をすることで、実際の報告とは違う側面が見えることもある。ただし、PM以外から情報を引き出す場合は、オフィシャルなコミュニケーションではなく、非公式なコミュニケーションを駆使しないと正しい情報は得られないことも多いので注意が必要である。  図2：ユーザ企業側PMの立ち位置 （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
-
-
連載
