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の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。
また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。
「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。
著書の詳細は、こちらをご覧ください。