情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

ベンダーの進捗報告がダメダメだったらどうする?

2024

8/01

ベンダーの進捗報告がダメダメだったらどうする?

手ぶらで進捗報告するベンダーPM

「すみません、時間がなくて…」

ある現場で、ベンダーとの週次進捗会議に出席しました。

要件定義キックオフの後、はじめてのベンダーとの定例会です。

ベンダーのプロジェクトマネージャー(以降、PMと省略)からの進捗報告でしたが、まさかの「手ぶら」です。資料がありません(汗)

まぁ、キックオフ準備でバタバタしたし、その日はベンダーPMから口頭で進捗を説明してもらいました。

そのPMは「弁は立つ」ので、説明を聞くと、それなりに安心しました。

ところが翌週・・・

「すみません、時間がなくて箇条書きですが…」

とメモ帳を開いて、わずか5行ほどのメモで説明します。

このメモだけだと、進んでいるのか、遅れているのかがわかりません。課題やリスクもわかりません。

そのため、きちんとした報告書の作成を依頼しました。

「はい、承知しました。ちょっと会議が立て込んでしまったのですが、頑張ります!」

しかし、その翌週も、その次の週も、改善されませんでした。

口頭での説明はあるものの、数行のメモしか準備してきません。

ユーザーは明らかに不満そうな表情を浮かべ、情シスAさんは今にも怒り出しそうです。

何より、この雰囲気の中で、準備もせずやってくるベンダーPMの鈍感力というか勇気もすごいと思いました(苦笑)

このように、ベンダーの進捗報告が「ダメダメ」だった場合、どうすればいいのでしょうか?

中小ベンダーあるある

まず、この光景は大手ベンダーでは、あまり見られない光景です。

なぜなら、大手ベンダーは、このような進捗報告は日常茶飯事であり、進捗報告書のフォーマットは確立されているからです。様々なプロジェクトを経験し、プロジェクト管理ノウハウが蓄積され、整備されているからです。

大手ベンダーの費用は高いですが、その内訳には「プロジェクト管理フィー」がしっかりと含まれています。

そのため、大手ベンダーには「高いお金を払ってプロジェクトリスクを抑止している」という考え方もできます。

一方で、中小ベンダーは、技術の腕は経ちますが、プロジェクト管理がイマイチというケースは少なくありません。

中小ベンダーは人的リソースに限りがあり、PMの専任者が少ないからです。

そのため、システムエンジニアや営業がPMを兼務することが多く、片手間ではプロジェクト管理ノウハウが整備されないのです。

中小ベンダーを選んでいるということは「安さと引き換えに相応のリスクをとっている」ともいえます。

そして、その中小ベンダーを選んだのは、他ならぬユーザー企業なのです。

ベンダーへの改善アプローチ

さて、ベンダーの進捗報告がダメダメだった場合、2つのステップでベンダーに改善アプローチをしていきます。

第一ステップ:進捗報告の項目を要求

ベンダーに次のように、記載項目を要求します。

● プロジェクト概況
・プロジェクトの全体状況を書いてください
・直近1週間の主な予定と実績を示してください
・全体予定の「予定通り/遅れ/前倒し」がわかるようにしてください

● 各タスク状況詳細
・WBSをベースに予実を説明してください
・各タスクは件数等を定量的に示し、進捗率がわかるようにしてください
・各タスクの「予定通り/遅れ/前倒し」が分かるようにしてください
・直近1週間の実績と次週の予定を示してください

● プロジェクト課題とリスク
・課題管理表をベースに説明してください
・発生、未完了、完了件数を明確にしてください
・直近1週間での新規発生分と更新分を中心に説明してください
・全体に影響のある課題については、協議事項としてください
・リスクがあれば、早期に共有してください

● その他連絡事項・共有事項
・プロジェクトに関連して、共有事項や相談事項があれば書いてください
 例)体制変更の連絡、年末年始の予定、XXXの日程調整、等

 

まずは、ベンダーに考えさせることが重要です。必要な項目をベンダーに認識してもらい、それに沿った報告を受けられるようになれば、解決となります。
 

第二ステップ:進捗報告フォーマットを指定

前ステップで解決しなかった場合は、さらに踏み込んで介入します。こちらから書式を渡し、そこに記入してもらいます。

書式は、見栄え優先で「パワーポイント」等にする必要はなく、ベンダーも使い慣れた「エクセル」の方が、ベンダーの負担も少なくなります。

次のような書式を渡します(もし、他により良い書式をお持ちであれば、それを提示してください)

(※ 画像をクリックすると、大きな画像が表示されます)

見ての通り、非常にシンプルです。必要項目を枠で囲っただけです。でも、それでいいのです。

ベンダーの報告内容に自由度をもたせることで、ベンダー側が本来表現したかった内容を制限なく書いてもらえるからです。書く内容が多ければ、ベンダー側で勝手に行を増やして書いてもらえます。

ベンダーにもプライドがあるでしょうから、書式を渡すのは気が引けるかもしれません。かつて、私もそうでした。

ところが、実際に渡してみると、意外にも「助かりました」という反応の方が多いのです。そこにこだわりがない、とも言えます。

中小ベンダーは、PMに専念する余裕もないし、労せずして書式を入手したなら「ラッキー」なのかもしれません。他の現場でも使うこともできるし、何より開発に集中できる、といった思いもあるのかもしれません。

今までの経験から、書式を渡したベンダーは、きちんとその書式で作ってくれるようになります。

ここで変に「お金を払っているんだから、きちんとやれ!」みたいに締め付けても、ベンダーの工数を浪費し、信頼関係を壊していくだけです。

変な摩擦を生む前に、書式をさっさと渡して、本来の進捗確認に注力した方が、お互いにとって有意義な時間になるのではないでしょうか。

本来の進捗会議へ

「進捗報告書に沿って報告させていただきます」

冒頭の現場は、情シスAさんからベンダーPMに書式を渡し、説明してもらいました。

それ以降、ベンダーPMはこの書式できちんと説明してくれるようになります。

今は、会議の参加者全員が、報告内容に集中できています。

情シスは「PMO」として、プロジェクトを円滑に進めていくのも重要な役目といえます。

貴社のIT部門・情報システム部門は、相対しているベンダーと進捗会議を円滑に進められていますでしょうか?

関連コラム

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか

情シスコンサルタント
田村 昇平

情シス(IT部門、情報システム部門)を支援するコンサルタント。

支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。

多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。

また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。

「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。

著書の詳細は、こちらをご覧ください。