メンバーの進捗を確認するようになってから、WBSに書かれている予定や進捗率を見るだけでは、実際の状況が分からないことがありました。
私が進捗確認で使っていたのは、WBSを見ながらの打ち合わせです。個別に確認したいことはチャットで聞き、確認結果をメールで共有することもありました。
それでも、「間に合います」と聞いていた作業が、後から確認すると想定していた状態になっていないことがありました。
私が進捗管理で一番難しいと感じたのは、遅延そのものより、相手の作業が実際にどこまで進んでいるのかを把握することでした。
この記事では、WBSで見ていた項目や進捗率の付け方、途中成果物の確認、遅れそうなときの報告など、実際に行っていた進捗確認について紹介します。
実装中心だった仕事から進捗確認や顧客・他社との調整が増えていった経緯は、SEはプログラミングしなくなる？で紹介しています。
WBSを見ながら打ち合わせで確認していた
普段はWBSを見ながら打ち合わせを行い、各メンバーの進捗を確認していました。
WBSで見ていたのは、開始日、終了日、遅延の有無、担当者などです。
それに加えて、特定の担当者へタスクが集中しすぎていないかも見ていました。
現在の一般的な説明として、IPAのプロジェクトマネージャ試験シラバスでは、WBSはプロジェクトで実施する作業を、成果物に基づいて管理しやすい小さな作業へ階層的に分割して作成するものとされています。
進捗率は作業の状態と結びつけていた
進捗確認では、本人に「何％終わっていますか」と細かく聞くことはあまりしていませんでした。
私が使っていた進捗率は、作業の状態と結びつけていました。
たとえば、
- 作成を始めたら10％
- 作成中は10〜90％
- 作成自体が終わって他の人によるレビューやチェックを受ける前なら90％
- レビューやチェックまで終われば100％
という形です。
進捗率を見るときも、数字だけではなく、その数字がどの作業状態を示しているのかを確認していました。
なお、大きなタスクでは、レビュー自体をWBS上の別タスクとして作ることもありました。
「間に合います」と聞いていても実態が違うことがあった
「間に合います」と聞いていても、内容を確認すると、こちらが想定していた状態とは違うことがありました。
作業内容を聞くと、実際に行った内容と、やる予定だった内容が混ざっていることもありました。
また、間違っている部分を正しいと思い込み、調べずにそのまま進めていたケースもありました。
同じ内容を進めているはずなのに、途中で工程が変わっていることもありました。
いくつかは事前に確認することで防げましたが、「やっていると思っていた部分が実は抜けていた」というケースには気づけず、後から問題になることもありました。
「進んでいる」という報告と、実際に終わっている内容が同じとは限らないことは、進捗を見るうえで難しかった部分です。
途中成果物を見るようにしていた
こうした経験から、途中成果物を確認することもありました。
口頭やチャットで進捗を聞くだけでなく、作成途中のものを見て、聞いていた状況と実際の作業内容に違いがないかを確認していました。
進捗率や本人からの報告だけでは判断しにくいときに、確認材料の一つにしていました。
期限は少し前に伝えてリカバリーする時間を残していた
相手へ伝える期限は、実際に必要になるタイミングよりある程度前に設定することもありました。
予定どおり終わらなかった場合に、リカバリーする時間を残しておくためです。
質問がまったくない場合も気にしていた
進捗確認では、質問がまったくない場合に不安を感じることがありました。
こちらから聞かないと情報が出てこない場合も同じです。
報告が少ないメンバーについては、1日の始まりや終わりに最低限の進捗をこちらから確認していました。
毎日の打ち合わせでも進捗を確認していました。
遅れる可能性が出た段階で上長へ報告していた
遅延については、実際に期限を過ぎてからではなく、遅れる可能性が出た段階で上長へ報告していました。
顧客への連絡が必要になりそうな場合は、まず上長と、顧客へ連絡するかどうかを相談していました。
WBSについては、必要に応じて担当者の変更や日程変更も行っていました。
ただし、日程の変更は相手先との調整次第でした。
一番難しかったのは相手の進捗の実態を知ることだった
WBSには予定や担当者、進捗率を記録できます。
それでも、本人が考えている進捗と、こちらが確認したときの状態が違うことはありました。
私にとって進捗管理で一番難しかったのは、相手が実際に何を終えていて、何がまだ残っているのかを知ることでした。
