先号　　　次号

「大きなマネジメントと小さなマネジメントとの違い(2)」

オンライン編集長　渡辺　貢成：5月号
1.　先月の要約(前回)
1)　ITプロジェクトの失敗要因の80%は顧客にある
2)　IT業界は契約の概念が希薄だ
　この二つの事例はいずれも最もクリティカル(重要)な問題と知りながら、顧客との話し合いで問題を解決することなく、できるところから仕事を進めるという、ごく日本的なやり方で業務を行っている。PMではこのクリティカルな問題を片付けるのがプロジェクトマネジャーの最大の任務で、これが大きなマネジメントです。クリティカルな問題を解決しないと、小さなマネジメントで頑張っても決して問題は解決できません。

2.　今月の要約
1)　顧客による失敗要因の解明
①顧客が自分の要求を明確に提示できない
②ITソリューションベンダーは顧客の代行ができると思っている
2)　大きなマネジメント：問題の解明をどうするか
①発注者、受注者は決して代行できないそれぞれの役割があることを認識して貰う
②図表の説明

3.　本　題
4月号からモニター制を採用しました。今月からモニターのコメントに従い、大胆に表現を変え、結論から入ります。添付図表がその結論です。
・
2)　失敗の要因と大きなマネジメント
　失敗の大きな要因は発注者、受注者がそれそれ自分にしかできない役割を認識し(失敗の要因の認識)、役割を明確に示し、構想計画を実行することがプロジェクトを成功させる大きなマネジメントとなります。
　発注者・受注者の役割と実行する業務を図表に示しました。
①発注者側の経営者の役割
  • 経営者はＩＴのことを考えずに自分が実行したい経営改革案をつくり、社内に明確に示す(要求仕様作成のベース)
  • この基本路線に従ったIT化計画策定をIT専門家に委ねる
  • 経営合理化に伴う余剰人員(経営資産の一部という発想で)の対策を真剣に考える
  • IT化計画ができた段階で、現場(ITユーザー)の了解を得で、その後は現場の意識改革を行う
IT業務の種類別関係者の役割分担表

②発注者のIT専門家
  • 構想計画段階で経営改革の大きな重要項目の可視化をおこなう
  • ベンダーと相談して(共同研究)要求仕様にまでレベルを高める
③発注者の現場
  • 計画を理解し、決定されたIT化への賛同と協力を約束する
  • 自ら意識改革を行う
④受注者
　受注者は発注者の経営改革の決断や、ユーザー(現)の意識改革を実行させることはできないから、ソリューションビジネスはあくまでも共同開発というスタンスを両者で認識することから出発する
詳細を図表に示しました。よく吟味してください。
結論：大きなマネジメントは論理的にはやさしいが、実行するとき、多くの人々の理解と協力が必要なため、先送りされがちである。しかし先送りは困難をさらに増大させ、失敗の大きな要因となる。

以上