タスクの割当人数のミスをリカバリーする方法

プロジェクト計画では、作業工数、スケジュールを見積ります。

そのとき、『作業に対する割当人数』を軽視しないでください。

取り敢えず、感覚で人数を割り振っておくか...

今のところ、間違ってても後でどうにかなるだろう...

これは非常に危険です。

割当人数を間違うことで、

・メンバーの過剰労働によるチームからの途中離脱

・工数の超過

・スケジュールの遅れ

・品質の劣化...etc

こんなことが起こり、プロジェクトは崩壊していきます。


お疲れ様です、ゆーろーです。

冒頭のメッセージは、iPMに参加しているMASAの教訓です。

*iPM naviのご案内（こちら）

これは、論理的に作業工数・スケジュールが正しいとしても、タスクへの割り振り人数を間違えると、プロジェクトは失敗する、と示唆しています。


これを注意喚起として、
リスキリング中のPMの方、PM初心者の方へお伝えしたいネタがあります。

実は、
MASAさんのところに、このようなお悩みが届きました。

どうやって、MASAさんはフォローアップしたでしょうか？

10分程度、お時間のある方は、こちらのコラムを読んでください↓


時間がないんだよ！という方は、今から『ポイント』をお伝えします。
*最後までお読みください（ざっと1分です）


ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。

ぜひ、このコラムを読んでください↓



コラムの内容を、

あなたのプロジェクトで使っているリスク管理表にコピペするのもOK！

PMOとして活動しているのであれば、クライアントての指南材料にするのもOK！

ご自由にお使いください😀



最後まで、読んでくれて有難う御座います。

メンバーのプロジェクト参画日をミスった時の対処

プロジェクトは、開発を進めるう上で、いくつかの開発プロセスを順番に進めていきます。

各プロセスで必要なスキルが違うためプロジェクトへ参加するメンバーの着任タイミングも違うものです。

メンバーの着任タイミングを間違えることで、プロジェクトのスケジュールが遅延したり、品質が劣化、メンバーの疲弊といったリスクがあります。

PMであれは、しっかりと考慮しなければなりません。


お疲れ様です、ゆーろーです。

冒頭のメッセージですが、iPMにプロコンサルとして参加してくれているMASA氏が示唆しています。

プロジェクト計画を考えるときに、メンバーのアサインタイミングの間違いがプロジェクトを炎上させる”きっかけ”になるということです。

さて、

あなたが、PMとしてメンバーのアサイン計画を作りました。

しかし、メンバーが着任するたびにスケジュールが遅れる❗️

そうならないために、計画段階でどのような対策を打ちますか？

今回、このような状況になったPMのお悩みを、MASA氏がコラムで紹介しています↓


それでは、MASA氏のコラムのあらすじを紹介します！

ご興味がありましたら、コラムをじっくりと読んでください。



👍 このコラムは

むずかしさ　：★★☆☆☆（PM初級者向け）

ボリューム　：★★★☆☆(5分-8分で読める)

気付き学び　：★★★★★(人材投入の計画立案)

お役立ち　　：★★★★★(人材投入の計画を作る手順)

仕事の実用性：★★☆☆☆（有識者のサポートが必要かな）


👀 コラム情報

コラミスト：MASAさん

発信元：iPM navi

配信日：2022年11月10日

*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考になると話題です！

1.こんなお悩み

わたしはSerIに勤める42歳です。

IT業界では、20年の経験があり、PM歴は8年になります（ベテランのPMです）。

①現在、わたしの担当しているプロジェクトは詳細設計工程の中盤を実施しています。

②ガントチャート（スケジュール）に従って、メンバーの着任タイミングを設定していますが、

③メンバーの着任と同時にスケジュールが遅延する状態が続いています。

④このプロジェクトは計画段階で策定した工数、スケジューリングには問題がなく、またメンバーのスキルは他のプロジェクトチームと比較しても高い方です。

⑤メンバーが着任するたびにスケジュールが遅れる一方です、なにか方法はないでしょうか？

（コラムを読む... ）

2.こうやって解決


ポイントはこれ❗️

・担当するメンバーのスキルやキャリアとタスクの難易度から、キャッチアップ期間を設定する。

・WBS（ガントチャート）に、キャッチアップ期間を加える。

これらのポイントを押さえてプロジェクトオーナーと協議しましょう！


ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。

また、難易度が高いと言われる『プロジェクトマネージャ試験』の論文対策の参考にも役立ちます。

ぜひこのコラムを読んでください↓


最後まで、読んでくれて有難う御座います。

工数オーバーの時のリリース方針を作る手順

ITプロジェクトを成功させるには、作業工数とスケジュールの見積もりが、どれだけ現実的な数字が算出されたかによります。

しかし、これらを見積るのはベテランのPMでも苦労し、算出した結果に確固たる自信を持てないものです。

ましてや、実行中のプロジェクトにPMとして招かれた場合は、前任者が作ったスケジュールと作業工数をベースにマネジメントを行うものです。

この時、前任者の見積りを信じ込んでしまうと、プロジェクトを危険に晒すこともあります。

必ず、プロジェクトの経緯・現状・未来を鑑みて、スケジュールと作業工数の再見積りを行うことが必要です。


お疲れ様です、ゆーろーです。

冒頭のメッセージですが、iPMにプロコンサルとして参加してくれているMASA氏が、開発プロジェクトを行う時に、品質基準で注意していたことだそうです。


プロジェクトの途中でプロジェクトマネージャー職を引き継ぐ時に注意しているこちだそうです。

さて、
あなたが、プロジェクトでPMを引き継ぐことになったとしましょう。

前任PMが見積もった工数ではリリースが出来ません❗️

どのようなリリース方針をクライアントに提案しますか？

今回、このような状況になったPMのお悩みを、MASA氏がコラムで紹介しています↓


それでは、MASA氏のコラムのあらすじを紹介します！

ご興味がありましたら、コラムをじっくりと読んでください。


👍 このコラムは

むずかしさ　：★★☆☆☆（PM初級者向け）

ボリューム　：★★★☆☆(5分-8分で読める)

気付き学び　：★★★★★(工数超過のリカバリー)

お役立ち　　：★★★★★(予算追加の依頼手順)

仕事の実用性：★★★☆☆（関連スキルが必要かも）



👀 コラム情報

コラミスト：MASAさん

発信元：iPM navi

配信日：2022年11月09日

*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀

1.こんなお悩み


わたしは物流企業の情報システム部門に勤める32歳です。

この度、システムエンジニア職からPM職に転身しました。

今回のプロジェクトで初めPMになった未経験者です。

①現在、プロジェクトは詳細設計工程の終盤です。

②わたしは、前任PMが見積もった工数を鵜呑みにして作業進捗を行っていました。

③しかし、大幅に工数超過してプロジェクトが終了することが判明しました。

④社内のシステム開発なので、工数超過の旨を伝え予算の追加をお願いしたいところですが、

⑤弊社は数年間売り上げが低迷していて、予算を追加の余裕がありません。

⑥このままでは、プロジェクトが破綻してしまうため、『経営側がある程度納得するプラン（落としどころ）』があればご教授ください。

（コラムを読む... ）

2.こうやって解決

ポイントポイントはこれ❗️

・EVMを使って将来予測をする。

・ビジネスインパクトの強い機能を洗い出し、リリースの優先度を決める。

・WBS、作業工数、追加要員のスキル等を洗い出してスケジュールする。

（コラムを読む... ）

3.どんなメソッドを使ったのか？

ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。

また、難易度が高いと言われる『プロジェクトマネージャ試験』の論文対策にも役立ちます。

ぜひこのコラムを読んでください↓


最後まで、読んでくれて有難う御座います。

クライアント目線の品質基準を作る手順

プロジェクトは、一般的に要件定義・基本設計の最終的な品質保証をITパートナーが主体となり総合テストで行います。

このテストを通じて、システム要件とシステム不具合（バグ）が解消していればシステム視点として品質が合格となります。

そして、最終工程のユーザーテストで、開発されたシステムを試運転し正確な業務運用ができていると判断されたときに、全ての品質条件がクリアーされたことになります。

この品質保証の判断には、ITパートナーとクライアントに大きなギャップが生じます。

それは、システム視点とクライアント視点という品質目線が違うからです。

そのためにも、ITパートナーは総合テストでも『クライアント視点』のテストを盛り込み実行することで、クライアントは安心できて、無用な誤解も避けられるのです。


お疲れ様です、ゆーろーです。

冒頭のメッセージですが、iPMにプロコンサルとして参加してくれているMASA氏が、開発プロジェクトを行う時に、品質基準で注意していたことだそうです。

品質基準は、システム（エンジニア）と業務（クライアント）の2つの視点で作らなければなりません。

クライアント視点の品質基準、どこに着目すれば良いのでしょうか？

エンジニア視点とクライアント視点を、明確に線引きすることでテストの効果が全く違ってくるものです。

さて、

あなたが、PMとして品質基準を作る立場だったとしましょう。

クライアントから、「私達は技術的なことは一切わからない。リリース後に正確な業務運用ができるのかを知りたい」、そんなことを言われたらどうしますか？

今回、このような状況になったPMのお悩みを、MASA氏が解決し、コラムに整理しました↓


それでは、MASA氏のコラムのあらすじを紹介します！

ご興味がありましたら、コラムをじっくりと読んでください。

--------------------
👍 このコラムは

むずかしさ　：★☆☆☆☆（PM初心者向け）

ボリューム　：★★★☆☆(5分-8分で読める)

気付き学び　：★★★★★(顧客目線の品質基準の重要性)

お役立ち　　：★★★★★(顧客目線の品質基準の作り方)

仕事の実用性：★★★★☆（今すぐ使える）
--------------------
👀 コラム情報

コラミスト：MASAさん

発信元：iPM navi

配信日：2022年11月08日
--------------------

*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀


1.こんなお悩み


わたしはSIerに勤める38歳です。

この度、システムエンジニア職からPM職に転身しました。

今回のプロジェクトで初めPMになった未経験者です。

①現在、プロジェクトは総合テストの中盤です。

総合テストはシステム要件をもとにして作成された要件定義書・基本設計書の品質を実機で確認することが目的であるため、システム視点でテストを実施しています。

②わたしは、クライアント主体で実施するユーザーテストへスムーズに引き継げるように、総合テストの中間報告をしました。

③中間報告前にチームで進捗状況・品質状態を確認したところ、スケジュール通りに進行しており、不具合に対しても品質管理プロセスに従い修正していました。

④しかし、クライアントは「わたしたちは技術的なことは一切わからない。リリース後に正確な業務運用ができるのかを知りたい。」とご指摘を受けました。

⑤わたしは、総合テストの位置付けと目的を説明しましたが、お客さまは納得してくれません。

⑥クライアントに、納得してもらえる方法はないでしょうか？

（コラムを読む...）

2.こうやって解決

ポイントポイントはこれ❗️

・クリティカルな業務要件を整理する。

・総合テストで実施すべき業務範囲を確定する。

・テスト範囲を明確にするために、ユースケースを作成する。

・クライアントへユースケースとテスト仕様書を説明し理解を得る。

（コラムを読む...）


3.どんなメソッドを使ったのか？
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。

また、難易度が高いと言われる『プロジェクトマネージャ試験』の論文対策にも役立ちます。

ぜひこのコラムを読んでください↓


最後まで、読んでくれて有難う御座います。

仕様漏れが発覚した時のリカーバリー方法

プロジェクトは、計画段階でスコープを決めます。

そのとき、既存システムの改修がメインであれば、顧客の要求を実現させるために、予め『システム仕様』、『業務仕様』を併せて調査しなければなりません。

意外にも、この調査が不十分なケースが多いものです。

そのシワ寄せが、プロジェクトの詳細設計工程、テスト工程で発覚したら、大きな手戻りとなります。

そうなるとプロジェクトは失敗する可能性が高いものです。


お疲れ様です、ゆーろーです。

冒頭のメッセージですが、iPMにプロコンサルとして参加してくれているMASA氏が、開発プロジェクトを行う時に、既存システムの改修を含む場合に、注意していたことだそうです。

既存システムの改修は、作業を進めながら、仕様の理解を深めていけばどうにかなるだろう？と考えてしまうものです。

しかし、計画段階で調査は必須ですが、様々な条件において100％の調査が出来なくてもで、後工程で実施するといった課題として残しておくことが大事だと思っています。

さて、

あなたが、既存システムの改修プロジェクトのPMだったとしましょう。

詳細設計工程の終盤で業務仕様の抜け漏れ・誤認識を発見したら、どのようなリカバリー計画を立てますか？

このようなプロジェクトは、たくさんあります。

今回、このような状況になったPMのお悩みを、MASA氏が解決し、コラムに整理しました↓



それでは、MASA氏のコラムのあらすじを紹介します！

ご興味がありましたら、コラムをじっくりと読んでください。


👍 このコラムは

むずかしさ　：★★☆☆☆（PM初級者向け）

ボリューム　：★★★☆☆(5分-8分で読める)

気付き学び　：★★★★★(遅延PJのリカバリー方法)

お役立ち　　：★★★★★(リカバリー計画)

仕事の実用性：★★☆☆☆（有識者のサポートが必要かな）

👀 コラム情報

コラミスト：MASAさん

発信元：iPM navi

配信日：2022年11月07日

*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀


1.こんなお悩み


わたしは、SIerに勤務する26歳のPMで今回初めてPMをやらしていただいてますが、詳細設計で大きなトラブルを抱えています。

①わたしは既存システムに対する機能追加のプロジェクトを行なってます。

②現在、詳細設計工程の終盤を迎え、プログラム製造工程に向けて業務要件・システム要件の誤認識や抜け漏れの再確認レビューを行いました。

③レビューの結果から、一部の機能設計に業務要件を満たしていない不具合がありました。

④原因は、システム調査（詳細設計工程の前に実施）を行ったメンバーのスキル不足により、調査範囲を間違ったことでした。

⑤当該プロジェクトは、スケジュールがタイトであるためリリース日を延期するのが難しいです。

⑥現状を踏まえ、プロジェクトオーナーと協議したところ「まずはどのようにリカバリーするのか？提案が欲しい」、「その提案が許容範囲であれば前向きに検討する」と合意しています。

⑦しかし、どのように解決すれば良いかアイデアがありません。

（コラムを読む...）

2.こうやって解決


ポイントポイントはこれ❗️

・業務仕様の抜け漏れの範囲を業務単位、システム単位で整理する。

・設計の見直し範囲の優先度を設定する。

・計画の見直しを行う（顧客の合意が必須）

（コラムを読む...）

3.どんなメソッドを使ったのか？
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。

また、難易度が高いと言われる『プロジェクトマネージャ試験』の論文対策にも役立ちます。

ぜひこのコラムを読んでください↓

最後まで、読んでくれて有難う御座います。