タスクの割当人数のミスをリカバリーする方法
プロジェクト計画では、作業工数、スケジュールを見積ります。
そのとき、『作業に対する割当人数』を軽視しないでください。
取り敢えず、感覚で人数を割り振っておくか...
今のところ、間違ってても後でどうにかなるだろう...
これは非常に危険です。
割当人数を間違うことで、
・メンバーの過剰労働によるチームからの途中離脱
・工数の超過
・スケジュールの遅れ
・品質の劣化...etc
こんなことが起こり、プロジェクトは崩壊していきます。
お疲れ様です、ゆーろーです。
冒頭のメッセージは、iPMに参加しているMASAの教訓です。
*iPM naviのご案内（こちら）
これは、論理的に作業工数・スケジュールが正しいとしても、タスクへの割り振り人数を間違えると、プロジェクトは失敗する、と示唆しています。
これを注意喚起として、
リスキリング中のPMの方、PM初心者の方へお伝えしたいネタがあります。
実は、
MASAさんのところに、このようなお悩みが届きました。
😭 SerIに勤務するPM初級者（29歳）のお悩み
①現在、プロジェクトは、詳細設計工程の中盤。
②作業工数、スケジュールスは論理的には正しい。
③しかし、メンバーが体調不良等により、休みがちで進捗に遅れが。
④体調不良の原因は、メンバーのオーバーワーク。
⑤このままでは、スケジュールが遅れる一方でリカバリーできない。
この難局を切り抜ける手立てを教えて欲しい…
どうやって、MASAさんはフォローアップしたでしょうか？
10分程度、お時間のある方は、こちらのコラムを読んでください↓
時間がないんだよ！という方は、今から『ポイント』をお伝えします。
*最後までお読みください（ざっと1分です）
👍 ポイント（1分で読めます）
プロジェクトでは、メンバーの体調不良等により、計画通りに進捗しないケースもあります。
これを仕方ない...とPMであれば片付けてはいけません。
体調不良になる原因は、様々ですが、進捗が何かしらの原因で遅れることは、プロジェクト計画の段階で、想定しておかなければなりません。
そのためには、『作業工数』、『スケジュール』、『メンバーのスキル』、『作業への割当人数』のバランスを監視しておくことが必要です。
また、メンバーのキャリアや今のスキルてベルを把握しておき、各メンバーの力量に合わせて、進捗のアラートラインを決めておくのも、一つの方法です。
プロジェクト実行中に、メンバーが離脱した場合は、素早くこれらを行うのがポイントです❗️
・遅延している作業と主従関係や関連がある作業を見つける。
・警戒タスクに対するリスク（作業工数、スケジュール、メンバーのスキル、作業の割当人数）を洗い出す。
*遅延している作業と主従関係・関連がある作業 ＝ 警戒タスク
・遅延している作業と警戒タスクに対して詳細なWBSを作成する。
これらを、しっかり実施することで、プロジェクトを円滑に実行することができるでしょう。
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。
ぜひ、このコラムを読んでください↓
👍 このコラムは
むずかしさ ：★★☆☆☆（PM初級者向け）
ボリューム ：★★★☆☆(5分-8分で読める)
気付き学び ：★★★★★(人材投入の計画立案)
お役立ち ：★★★★★(人材投入の計画を作る手順)
仕事の実用性：★★★★☆（今すぐ使える）
👀 コラム情報
コラミスト：MASA
発信元：iPM navi
配信日：2022年11月11日
*プロコンサルのコラムはプロジェクトマネージャ試験の論文対策になると評判です！
コラムの内容を、
あなたのプロジェクトで使っているリスク管理表にコピペするのもOK！
PMOとして活動しているのであれば、クライアントての指南材料にするのもOK！
ご自由にお使いください😀
最後まで、読んでくれて有難う御座います。
こちらのコラムシリーズもご覧ください♩
PM HACKERを読んでみる（こちら）
【 お知らせ 〜 私も参加しているiPM navi 〜 】
iPM naviは、PM初心者・PMスキルをアップしたい方、DX時代に適応するためリスキリングしているPMの方。
そのような方々へ
無料で❗️
プロジェクト計画・管理・問題解決…etcのお悩みを解決できるサービスが利用できます。
今すぐ、無料メンバーに登録してください😀
メンバーのプロジェクト参画日をミスった時の対処
プロジェクトは、開発を進めるう上で、いくつかの開発プロセスを順番に進めていきます。
各プロセスで必要なスキルが違うためプロジェクトへ参加するメンバーの着任タイミングも違うものです。
メンバーの着任タイミングを間違えることで、プロジェクトのスケジュールが遅延したり、品質が劣化、メンバーの疲弊といったリスクがあります。
PMであれは、しっかりと考慮しなければなりません。
お疲れ様です、ゆーろーです。
冒頭のメッセージですが、iPMにプロコンサルとして参加してくれているMASA氏が示唆しています。
プロジェクト計画を考えるときに、メンバーのアサインタイミングの間違いがプロジェクトを炎上させる”きっかけ”になるということです。
さて、
あなたが、PMとしてメンバーのアサイン計画を作りました。
しかし、メンバーが着任するたびにスケジュールが遅れる❗️
そうならないために、計画段階でどのような対策を打ちますか？
今回、このような状況になったPMのお悩みを、MASA氏がコラムで紹介しています↓
それでは、MASA氏のコラムのあらすじを紹介します！
ご興味がありましたら、コラムをじっくりと読んでください。
👍 このコラムは
むずかしさ ：★★☆☆☆（PM初級者向け）
ボリューム ：★★★☆☆(5分-8分で読める)
気付き学び ：★★★★★(人材投入の計画立案)
お役立ち ：★★★★★(人材投入の計画を作る手順)
仕事の実用性：★★☆☆☆（有識者のサポートが必要かな）
*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考になると話題です！
1.こんなお悩み
わたしはSerIに勤める42歳です。
IT業界では、20年の経験があり、PM歴は8年になります（ベテランのPMです）。
①現在、わたしの担当しているプロジェクトは詳細設計工程の中盤を実施しています。
②ガントチャート（スケジュール）に従って、メンバーの着任タイミングを設定していますが、
③メンバーの着任と同時にスケジュールが遅延する状態が続いています。
④このプロジェクトは計画段階で策定した工数、スケジューリングには問題がなく、またメンバーのスキルは他のプロジェクトチームと比較しても高い方です。
⑤メンバーが着任するたびにスケジュールが遅れる一方です、なにか方法はないでしょうか？
（コラムを読む... ）
2.こうやって解決
ポイントはこれ❗️
・担当するメンバーのスキルやキャリアとタスクの難易度から、キャッチアップ期間を設定する。
・WBS（ガントチャート）に、キャッチアップ期間を加える。
これらのポイントを押さえてプロジェクトオーナーと協議しましょう！
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。
また、難易度が高いと言われる『プロジェクトマネージャ試験』の論文対策の参考にも役立ちます。
ぜひこのコラムを読んでください↓
最後まで、読んでくれて有難う御座います。
こちらのコラムシリーズもご覧ください♩
PM HACKERを読んでみる（こちら）
工数オーバーの時のリリース方針を作る手順
ITプロジェクトを成功させるには、作業工数とスケジュールの見積もりが、どれだけ現実的な数字が算出されたかによります。
しかし、これらを見積るのはベテランのPMでも苦労し、算出した結果に確固たる自信を持てないものです。
ましてや、実行中のプロジェクトにPMとして招かれた場合は、前任者が作ったスケジュールと作業工数をベースにマネジメントを行うものです。
この時、前任者の見積りを信じ込んでしまうと、プロジェクトを危険に晒すこともあります。
必ず、プロジェクトの経緯・現状・未来を鑑みて、スケジュールと作業工数の再見積りを行うことが必要です。
お疲れ様です、ゆーろーです。
冒頭のメッセージですが、iPMにプロコンサルとして参加してくれているMASA氏が、開発プロジェクトを行う時に、品質基準で注意していたことだそうです。
プロジェクトの途中でプロジェクトマネージャー職を引き継ぐ時に注意しているこちだそうです。
さて、
あなたが、プロジェクトでPMを引き継ぐことになったとしましょう。
前任PMが見積もった工数ではリリースが出来ません❗️
どのようなリリース方針をクライアントに提案しますか？
今回、このような状況になったPMのお悩みを、MASA氏がコラムで紹介しています↓
それでは、MASA氏のコラムのあらすじを紹介します！
ご興味がありましたら、コラムをじっくりと読んでください。
👍 このコラムは
むずかしさ ：★★☆☆☆（PM初級者向け）
ボリューム ：★★★☆☆(5分-8分で読める)
気付き学び ：★★★★★(工数超過のリカバリー)
お役立ち ：★★★★★(予算追加の依頼手順)
仕事の実用性：★★★☆☆（関連スキルが必要かも）
*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀
1.こんなお悩み
わたしは物流企業の情報システム部門に勤める32歳です。
この度、システムエンジニア職からPM職に転身しました。
今回のプロジェクトで初めPMになった未経験者です。
①現在、プロジェクトは詳細設計工程の終盤です。
②わたしは、前任PMが見積もった工数を鵜呑みにして作業進捗を行っていました。
③しかし、大幅に工数超過してプロジェクトが終了することが判明しました。
④社内のシステム開発なので、工数超過の旨を伝え予算の追加をお願いしたいところですが、
⑤弊社は数年間売り上げが低迷していて、予算を追加の余裕がありません。
⑥このままでは、プロジェクトが破綻してしまうため、『経営側がある程度納得するプラン（落としどころ）』があればご教授ください。
（コラムを読む... ）
2.こうやって解決
ポイントポイントはこれ❗️
・EVMを使って将来予測をする。
・ビジネスインパクトの強い機能を洗い出し、リリースの優先度を決める。
・WBS、作業工数、追加要員のスキル等を洗い出してスケジュールする。
（コラムを読む... ）
3.どんなメソッドを使ったのか？
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。
また、難易度が高いと言われる『プロジェクトマネージャ試験』の論文対策にも役立ちます。
ぜひこのコラムを読んでください↓
最後まで、読んでくれて有難う御座います。
こちらのコラムシリーズもご覧ください♩
PM HACKERを読んでみる（こちら）
クライアント目線の品質基準を作る手順
プロジェクトは、一般的に要件定義・基本設計の最終的な品質保証をITパートナーが主体となり総合テストで行います。
このテストを通じて、システム要件とシステム不具合（バグ）が解消していればシステム視点として品質が合格となります。
そして、最終工程のユーザーテストで、開発されたシステムを試運転し正確な業務運用ができていると判断されたときに、全ての品質条件がクリアーされたことになります。
この品質保証の判断には、ITパートナーとクライアントに大きなギャップが生じます。
それは、システム視点とクライアント視点という品質目線が違うからです。
そのためにも、ITパートナーは総合テストでも『クライアント視点』のテストを盛り込み実行することで、クライアントは安心できて、無用な誤解も避けられるのです。
お疲れ様です、ゆーろーです。
冒頭のメッセージですが、iPMにプロコンサルとして参加してくれているMASA氏が、開発プロジェクトを行う時に、品質基準で注意していたことだそうです。
品質基準は、システム（エンジニア）と業務（クライアント）の2つの視点で作らなければなりません。
クライアント視点の品質基準、どこに着目すれば良いのでしょうか？
エンジニア視点とクライアント視点を、明確に線引きすることでテストの効果が全く違ってくるものです。
さて、
あなたが、PMとして品質基準を作る立場だったとしましょう。
クライアントから、「私達は技術的なことは一切わからない。リリース後に正確な業務運用ができるのかを知りたい」、そんなことを言われたらどうしますか？
今回、このような状況になったPMのお悩みを、MASA氏が解決し、コラムに整理しました↓
それでは、MASA氏のコラムのあらすじを紹介します！
ご興味がありましたら、コラムをじっくりと読んでください。
👍 このコラムは
むずかしさ ：★☆☆☆☆（PM初心者向け）
ボリューム ：★★★☆☆(5分-8分で読める)
気付き学び ：★★★★★(顧客目線の品質基準の重要性)
お役立ち ：★★★★★(顧客目線の品質基準の作り方)
仕事の実用性：★★★★☆（今すぐ使える）
*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀
1.こんなお悩み
わたしはSIerに勤める38歳です。
この度、システムエンジニア職からPM職に転身しました。
今回のプロジェクトで初めPMになった未経験者です。
①現在、プロジェクトは総合テストの中盤です。
総合テストはシステム要件をもとにして作成された要件定義書・基本設計書の品質を実機で確認することが目的であるため、システム視点でテストを実施しています。
②わたしは、クライアント主体で実施するユーザーテストへスムーズに引き継げるように、総合テストの中間報告をしました。
③中間報告前にチームで進捗状況・品質状態を確認したところ、スケジュール通りに進行しており、不具合に対しても品質管理プロセスに従い修正していました。
④しかし、クライアントは「わたしたちは技術的なことは一切わからない。リリース後に正確な業務運用ができるのかを知りたい。」とご指摘を受けました。
⑤わたしは、総合テストの位置付けと目的を説明しましたが、お客さまは納得してくれません。
⑥クライアントに、納得してもらえる方法はないでしょうか？
（コラムを読む...）
2.こうやって解決
ポイントポイントはこれ❗️
・クリティカルな業務要件を整理する。
・総合テストで実施すべき業務範囲を確定する。
・テスト範囲を明確にするために、ユースケースを作成する。
・クライアントへユースケースとテスト仕様書を説明し理解を得る。
（コラムを読む... ）
3.どんなメソッドを使ったのか？
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。
また、難易度が高いと言われる『プロジェクトマネージャ試験』の論文対策にも役立ちます。
ぜひこのコラムを読んでください↓
最後まで、読んでくれて有難う御座います。
仕様漏れが発覚した時のリカーバリー方法
プロジェクトは、計画段階でスコープを決めます。
そのとき、既存システムの改修がメインであれば、顧客の要求を実現させるために、予め『システム仕様』、『業務仕様』を併せて調査しなければなりません。
意外にも、この調査が不十分なケースが多いものです。
そのシワ寄せが、プロジェクトの詳細設計工程、テスト工程で発覚したら、大きな手戻りとなります。
そうなるとプロジェクトは失敗する可能性が高いものです。
お疲れ様です、ゆーろーです。
冒頭のメッセージですが、iPMにプロコンサルとして参加してくれているMASA氏が、開発プロジェクトを行う時に、既存システムの改修を含む場合に、注意していたことだそうです。
既存システムの改修は、作業を進めながら、仕様の理解を深めていけばどうにかなるだろう？と考えてしまうものです。
しかし、計画段階で調査は必須ですが、様々な条件において100％の調査が出来なくてもで、後工程で実施するといった課題として残しておくことが大事だと思っています。
さて、
あなたが、既存システムの改修プロジェクトのPMだったとしましょう。
詳細設計工程の終盤で業務仕様の抜け漏れ・誤認識を発見したら、どのようなリカバリー計画を立てますか？
このようなプロジェクトは、たくさんあります。
今回、このような状況になったPMのお悩みを、MASA氏が解決し、コラムに整理しました↓
それでは、MASA氏のコラムのあらすじを紹介します！
ご興味がありましたら、コラムをじっくりと読んでください。
👍 このコラムは
むずかしさ ：★★☆☆☆（PM初級者向け）
ボリューム ：★★★☆☆(5分-8分で読める)
気付き学び ：★★★★★(遅延PJのリカバリー方法)
お役立ち ：★★★★★(リカバリー計画)
仕事の実用性：★★☆☆☆（有識者のサポートが必要かな）
*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀
1.こんなお悩み
わたしは、SIerに勤務する26歳のPMで今回初めてPMをやらしていただいてますが、詳細設計で大きなトラブルを抱えています。
①わたしは既存システムに対する機能追加のプロジェクトを行なってます。
②現在、詳細設計工程の終盤を迎え、プログラム製造工程に向けて業務要件・システム要件の誤認識や抜け漏れの再確認レビューを行いました。
③レビューの結果から、一部の機能設計に業務要件を満たしていない不具合がありました。
④原因は、システム調査（詳細設計工程の前に実施）を行ったメンバーのスキル不足により、調査範囲を間違ったことでした。
⑤当該プロジェクトは、スケジュールがタイトであるためリリース日を延期するのが難しいです。
⑥現状を踏まえ、プロジェクトオーナーと協議したところ「まずはどのようにリカバリーするのか？提案が欲しい」、「その提案が許容範囲であれば前向きに検討する」と合意しています。
⑦しかし、どのように解決すれば良いかアイデアがありません。
（コラムを読む...）
2.こうやって解決
ポイントポイントはこれ❗️
・業務仕様の抜け漏れの範囲を業務単位、システム単位で整理する。
・設計の見直し範囲の優先度を設定する。
・計画の見直しを行う（顧客の合意が必須）
（コラムを読む...）
3.どんなメソッドを使ったのか？
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。
また、難易度が高いと言われる『プロジェクトマネージャ試験』の論文対策にも役立ちます。
ぜひこのコラムを読んでください↓
最後まで、読んでくれて有難う御座います。
遅れないWBSスケジュールを作るコツ
プロジェクトは、計画したスケジュールに従って作業を進めていきます。
「作業工数は正しく見積もれたのに、WBSスケジュールが遅延してプロジェクトが失敗した」
そんなふうに反省するPMも多いようです。
何を使って、WBSスケジュールを作るのでしょうか？
それは、作業工数です。
作業工数を見積もる時に、必要な要素が漏れていたら、誤ったWBSスケジュールが出来上がります。
お疲れ様です、ゆーろーです。
冒頭のメッセージはiPM naviで公開されているコラムの一節です。
作業工数が正しければ、必ずしもスケジュール（プロジェクトの所要期間）が正しい、というのは幻想なんですね。
幻にならないように、スケジュールを作る前に❗️
WBSに開発作業以外のタスクが洗い出されていて、盛り込まれているか？
このチェックが必要です。
あなたがPMだったとしましょう。
作業工数は正しいのに、スケジュール（プロジェクトの所用期間）が遅れたら、スケジュールの見直しが必要です。
どのように見直しますか？
このような状況になったPMのお悩みを、iPMのプロコンサルであるMASA氏が解決し、コラムに整理しました↓
それでは、MASA氏のコラムのあらすじを紹介します！
ご興味がありましたら、コラムをじっくりと読んでください。
👍 このコラムは
むずかしさ ：★★☆☆☆（PM初級者向け）
ボリューム ：★★★☆☆(5分-8分で読める)
気付き学び ：★★★★★(スケジュールの見積り手順)
お役立ち ：★★★★★(スケジュールの作成)
仕事の実用性：★★★★☆（今すぐ使える）
*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀
😲 こんなお悩み
わたしは、部品製造メーカーの情シスに勤務する30歳のPMです。
PMの経験は3年です。
①わたしは、元々開発エンジニアで、３年前からPMを行っています。
また、PMとしての理念はタスクをしっかり洗い出し、タスクとタスクの繋がりに気を付けてWBSを作ることです。
②作ったWBSをもとに、わたしのエンジニア時代の経験から作業工数を見積もっています。
③見積もった作業工数は常に正しいと自負しています。
④しかし、毎回プロジェクトはスケジュール遅延という結果に終わります。
⑤作業工数は正しいのに、スケジュール（プロジェクトの所用期間）が遅延する悪いクセを改善したいと思います。 どのような方法を取れば良いでしょうか？
😀 こうやって解決
ポイントはこれ❗️
・リスクを洗い出す。
・リスク対応工数からリスクを緩和させる期間を考える。
・新規メンバーがアサインされることを考慮して、キャッチアップ期間を考える。
これらを、しっかり実施することで、プロジェクトを円滑に実行することができるでしょう。
💪 どんなメソッドを使ったのか？
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。
プロコンサルのMASAさんが、どのように答えを導き出したかを紹介しています。
ぜひ、このコラムを読んでください↓
最後まで、読んでくれて有難う御座います。
WBSを変更するルールを作るコツ
プロジェクトは未知を既知に変えていく作業です。
そのため、計画段階でWBSを作ってプロジェクトの準備を行います。
WBSがプロジェクト終了まで変更されないことが理想です。
しかし、そんなことは滅多にありません❗️
プロジェクトではWBSが変更されるのは当たり前と捉えましょう。
しかし、WBSが場当たり的に変更されたり、意味なく頻繁に変わったりするプロジェクトでは、メンバーのモチベーションも低下することもあります。
そのため、計画段階でWBSを作ってプロジェクトの準備を行います。
WBSがプロジェクト終了まで変更されないことが理想です。
しかし、そんなことは滅多にありません❗️
プロジェクトではWBSが変更されるのは当たり前と捉えましょう。
しかし、WBSが場当たり的に変更されたり、意味なく頻繁に変わったりするプロジェクトでは、メンバーのモチベーションも低下することもあります。
お疲れ様です、ゆーろーです。
冒頭のメッセージはiPM naviで公開されているコラムの一節です。
プロジェクトは未知を既知に変えるという、あやふやな作業であり、スムーズにゴールに辿り着くのは難しいものです。
せっかく、計画段階で念入りに計画を立てても、プロジェクトの実行中は外的・内的要因によって、計画を変更せざるを得ません。
あなたがPMだったとしましょう。
WBSの変更を余儀なくされた時、メンバーのモチベーションを保ちながら、どのように変更手続きをしていきますか？
このような状況になったPMのお悩みを、iPMのプロコンサルであるMASA氏が解決し、コラムに整理しました↓
それでは、MASA氏のコラムのあらすじを紹介します！
ご興味がありましたら、コラムをじっくりと読んでください。
👍 このコラムは
むずかしさ ：★★☆☆☆（PM初級者向け）
ボリューム ：★★★☆☆(5分-8分で読める)
気付き学び ：★★★★★(WBS変更の時の手順)
お役立ち ：★★★★★(WBSの変更手続き)
仕事の実用性：★★★★☆（今すぐ使える）
*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀
😲 こんなお悩み
わたしは、飲料会社の情シスに勤務する34歳のPMです。
PM歴は3年になります。
①わたしは、「プロジェクトは紆余曲折するため計画通り進めることが難しい」と感じています。
②そのため、臨機応変に課題や問題に対応するために頻繁なWBS（タスク、スケジュール）の変更はやむを得ないと考えています。
③そのため、わたしは頻繁にWBSを変更することから、メンバーが迷走してしまうことが多く、信頼関係が崩れています。
④前回のプロジェクトでは、頻繁なWBSの変更によって人員コストの超過、嫌気が差したメンバーの途中離脱などネガティブな状況に陥りました。
⑤今後、このようなことがないようにマネジメントを行なっていきたいのですが、WBSの変更に際して注意するべき点を教えてくれないでしょうか？
😀 こうやって解決
ポイントは これ❗️
・WBSの変更が起こるパターンを洗い出す。
・WBSの変更に伴う新規・変更タスクの作業所用期間の算出方法を準備する。
・WBSの変更に伴う新規・変更タスクの作業工数の算出方法を準備する。
・WBSの変更に伴う新規・変更タスクに必要とされるスキル、割当人数の洗い出し方法を準備する。
・キックオフで『WBSの変更ルール』を説明する。
これらを、しっかり実施することで、プロジェクトを円滑に実行することができるでしょう。
💪 どんなメソッドを使ったのか？
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。
ぜひ、このコラムを読んでください↓
最後まで、読んでくれて有難う御座います。
