遅れないWBSスケジュールを作るコツ

プロジェクトは、計画したスケジュールに従って作業を進めていきます。

「作業工数は正しく見積もれたのに、WBSスケジュールが遅延してプロジェクトが失敗した」

そんなふうに反省するPMも多いようです。

何を使って、WBSスケジュールを作るのでしょうか？

それは、作業工数です。

作業工数を見積もる時に、必要な要素が漏れていたら、誤ったWBSスケジュールが出来上がります。


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

冒頭のメッセージはiPM naviで公開されているコラムの一節です。

作業工数が正しければ、必ずしもスケジュール（プロジェクトの所要期間）が正しい、というのは幻想なんですね。

幻にならないように、スケジュールを作る前に❗️

WBSに開発作業以外のタスクが洗い出されていて、盛り込まれているか？

このチェックが必要です。

あなたがPMだったとしましょう。

作業工数は正しいのに、スケジュール（プロジェクトの所用期間）が遅れたら、スケジュールの見直しが必要です。

どのように見直しますか？


このような状況になったPMのお悩みを、iPMのプロコンサルであるMASA氏が解決し、コラムに整理しました↓


👍 このコラムは

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

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

気付き学び　：★★★★★(スケジュールの見積り手順)

お役立ち　　：★★★★★(スケジュールの作成)

仕事の実用性：★★★★☆（今すぐ使える）

👀 コラム情報

コラミスト：MASAさん

発信元：iPM navi

配信日：2022年11月07日

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

😲 こんなお悩み


わたしは、部品製造メーカーの情シスに勤務する30歳のPMです。

PMの経験は3年です。

①わたしは、元々開発エンジニアで、３年前からPMを行っています。

また、PMとしての理念はタスクをしっかり洗い出し、タスクとタスクの繋がりに気を付けてWBSを作ることです。

②作ったWBSをもとに、わたしのエンジニア時代の経験から作業工数を見積もっています。

③見積もった作業工数は常に正しいと自負しています。

④しかし、毎回プロジェクトはスケジュール遅延という結果に終わります。

⑤作業工数は正しいのに、スケジュール（プロジェクトの所用期間）が遅延する悪いクセを改善したいと思います。 どのような方法を取れば良いでしょうか？

😀 こうやって解決
ポイントはこれ❗️

・リスクを洗い出す。

・リスク対応工数からリスクを緩和させる期間を考える。

・新規メンバーがアサインされることを考慮して、キャッチアップ期間を考える。


これらを、しっかり実施することで、プロジェクトを円滑に実行することができるでしょう。

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

プロコンサルのMASAさんが、どのように答えを導き出したかを紹介しています。

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


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

WBSを変更するルールを作るコツ

プロジェクトは未知を既知に変えていく作業です。

そのため、計画段階でWBSを作ってプロジェクトの準備を行います。

WBSがプロジェクト終了まで変更されないことが理想です。

しかし、そんなことは滅多にありません❗️

プロジェクトではWBSが変更されるのは当たり前と捉えましょう。

しかし、WBSが場当たり的に変更されたり、意味なく頻繁に変わったりするプロジェクトでは、メンバーのモチベーションも低下することもあります。


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

冒頭のメッセージはiPM naviで公開されているコラムの一節です。

プロジェクトは未知を既知に変えるという、あやふやな作業であり、スムーズにゴールに辿り着くのは難しいものです。

せっかく、計画段階で念入りに計画を立てても、プロジェクトの実行中は外的・内的要因によって、計画を変更せざるを得ません。

あなたがPMだったとしましょう。

WBSの変更を余儀なくされた時、メンバーのモチベーションを保ちながら、どのように変更手続きをしていきますか？


このような状況になったPMのお悩みを、iPMのプロコンサルであるMASA氏が解決し、コラムに整理しました↓



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

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


👍 このコラムは

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

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

気付き学び　：★★★★★(WBS変更の時の手順)

お役立ち　　：★★★★★(WBSの変更手続き)

仕事の実用性：★★★★☆（今すぐ使える）

👀 コラム情報

コラミスト：MASAさん

発信元：iPM navi

配信日：2022年11月04日

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

😲 こんなお悩み

わたしは、飲料会社の情シスに勤務する34歳のPMです。

PM歴は3年になります。

①わたしは、「プロジェクトは紆余曲折するため計画通り進めることが難しい」と感じています。

②そのため、臨機応変に課題や問題に対応するために頻繁なWBS（タスク、スケジュール）の変更はやむを得ないと考えています。

③そのため、わたしは頻繁にWBSを変更することから、メンバーが迷走してしまうことが多く、信頼関係が崩れています。

④前回のプロジェクトでは、頻繁なWBSの変更によって人員コストの超過、嫌気が差したメンバーの途中離脱などネガティブな状況に陥りました。

⑤今後、このようなことがないようにマネジメントを行なっていきたいのですが、WBSの変更に際して注意するべき点を教えてくれないでしょうか？

😀 こうやって解決

ポイントはこれ❗️

・WBSの変更が起こるパターンを洗い出す。

・WBSの変更に伴う新規・変更タスクの作業所用期間の算出方法を準備する。

・WBSの変更に伴う新規・変更タスクの作業工数の算出方法を準備する。

・WBSの変更に伴う新規・変更タスクに必要とされるスキル、割当人数の洗い出し方法を準備する。

・キックオフで『WBSの変更ルール』を説明する。


これらを、しっかり実施することで、プロジェクトを円滑に実行することができるでしょう。

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

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


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

複数のITパートナーを管理するリスクを探すコツ

ITプロジェクトで、自社社員だけで構成された体制であれば、PMとしては気が楽です。

しかし、最近のプロジェクトは様々な要因から、自社社員で推進していくのが、難しい状況です。

・業界全体で人手不足

・高度なテクニカルスキル

・業務スキルの不足...etc

そのため、ITパートナーに参加してもらうケースは多いものです。

この混成チームで、ようやくプロジェクトがスタートできます。

その瞬間から、PMは『複数のITパートナーを管理』するリスクを背負うことになります。

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

最近のプロジェクトは様々な要因から、自社社員で体制を組むことは不可能に近いものです。

複数のITパートナーや一緒に仕事をしたことの無いフリーランスをチームに招集して、マネジメントしていくスキルがPMには求められています。

プロジェクトの『組織マネジメント』においては、難しいことであり、特に経験の浅いPMの方であれば、苦労するのではないでしょうか？

今回、紹介したいコラムは、

SIer勤務の29歳PMの方から、複数のITパートナーで構成するチームでは、どんなリスクがあるのか？

その相談に、iPMに参加しているプロコンサルのMASAさんが答えている内容となります。


👍 このコラムは

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

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

気付き学び　：★★★★★(寄せ集めチームの管理)

お役立ち　　：★★★★★(寄せ集めチームのリスク)

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

👀 コラム情報

コラミスト：MASAさん

発信元：iPM navi

配信日：2022年11月02日

😲 どんな相談だったのか？

①今回のシステム開発は、複数の業務システムを改修するITプロジェクトです。

②システム開発には、各業務の専門知識が必要となりますが、

③弊社だけでは、プロジェクト体制が構築できません。

④そのため、複数のITパートナーに作業を依頼することになりました。

⑤わたしは複数のITパートナーを管理したことがないため、非常に不安を感じています

⑥プロジェクトを開始する前に、リスク管理表を作成したいと考えています

⑦しかし、複数のITパートナーを管理するリスクを見つける方法を知りません。

😀 これが答え❗️


ポイントは❗️

・ITパートナー同士が業務連携する範囲を探し、『業務要件』のリスクを推測する。

・システム要件のリスクを推測する。

・品質のリスクを推測する。

・リスク監査を失念しないようにマイルストーンに設定する。

これらを、しっかり実施することで混成チームでも、プロジェクトを円滑に実行することができるでしょう。

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

答えが分かったところで、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。

プロコンサルのMASAさんが、どのように答えを導き出したかは、コラムの中では、アプローチしていく上で持っておきたいスキルも紹介しています。

*リスク管理表を正しく作るスキルも必要なので、コラムで紹介してます。

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

要件定義工程で顧客の体制にITプロジェクトの経験者が居ない

プロジェクト進行中に顧客の都合で作業が停滞することは日常茶飯事です。

特に、厄介なのが顧客サイドにITプロジェクトの経験者がいない時...

このようなとき、PMはプロジェクトを遂行するのに耐えうる体制を構築してもらえるように、プロジェクトオーナーへ直談判するのも一つの手です。

しかし、顧客の人材リソースにも制約（有識者は本来の業務で忙しい、たのプロジェクトに参加中...etc）があり、難しい場合が多いものです。

これは、プロジェクトのリスクです❗️

顧客体制がプロジェクトに耐えられない貧弱な状況であれば、PMはどうすれば良いのでしょうか？


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

あなたが、

『要件定義工程で顧客の体制にITプロジェクトの経験者が居ない』

こんなプロジェクトでPMをやったら、どんなトラブルが起こるか想像してください！

想像しただけで、お先真っ暗…そんな気分ではないでしょうか？

このような問題を起こすプロジェクトの特徴は5つです。

特徴：1
顧客の仕様に関する不明点がQA管理されていない

特徴：2
顧客が業務で利用するデータ項目の定義を理解していない

特徴：3
顧客が業務改善範囲の優先度は理解しているがシステム機能としてのイメージがない

特徴：4
顧客がプロジェクトで『自分たちがやるべきタスクと実現体制』を洗い出されていない

特徴：5
顧客がプロジェクトのリスクが発生した場合に品質・コスト・スケジュール・要望のどれに影響が出るかを理解していない。

今、あなたが参加しているプロジェクトで、どれかに当てはまっていれば赤信号です...

この問題（要件定義工程で顧客の体制にITプロジェクトの経験者が居ない）は、実際に起こりました。

このトラブルをiPMに参加しているプロコンサルのMASAさんが、どのように解決したかをコラムで解説しています。


-----------------------
👍 このコラムは
むずかしさ　：★★☆☆☆（PM初級者向け）
ボリューム　：★★★☆☆(5分-8分で読める)
気付き学び　：★★★★★(PJが成功せう体制作り)
お役立ち　　：★★★★★(顧客体制を強化する攻略法)
仕事の実用性：★★☆☆☆（有識者のサポートが必要かな）
-----------------------
👀 コラム情報
コラミスト：MASAさん
発信元：iPM navi
配信日：2022年11月01日
-----------------------

それでは、コラムのあらすじをお伝えします。

😲 どんなプロジェクトなのか？

【プロジェクトの体制とスコープ】
・顧客は大手出版会社の情報システム部で財務会計の新規構開発を実施。

・システム化スコープは財務会計管理、管理会計管理、社員管理が対象。

・中堅SierのA社が開発ベンダーとして参画。

・A社は全開発工程の成果物の納品 とシステムリリースの責任を請け負う。

・開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成

【プロジェクトの状況】
・現在、プロジェクトは要件定義工程を行なっている。

・A社の開発メンバは、PMの作成したWBSで作業を進めていた。

・しかし、要件の確認や確定が一向に進まなかった。

・これはITチームの要件定義の進め方、業務やシステムの理解が不足している訳ではなく、顧客が業務関連部署へのシステム化の説明と要件確定の調整が難航していた。

・そのため、要件定義工程の実施期間を延長しなければならない状態になっている。

😵 どんな特徴のプロジェクトなのか？
今回の実例は、炎上プロジェクトの特徴として『特徴4：顧客がプロジェクトで"自分たちがやるべきタスク"を洗い出されていないケース』です。

😀 どのように解決すればいいのか？

答えから言うと、この実例プロジェクトでは、こんな解決策を実施しました。

【解決策】
要件定義の取り纏めをITチームが支援し、100%の要件を盛り込みリリーススケジュールを変更しないようにタスクを組み替える。


顧客サイドにITプロジェクトの経験者が居ないと分かれば、PMなら初めに想像しなければならないのが、こんなことではないでしょうか？

自分たち（顧客）が、”やるべき作業（WBS）”が分からないだろ〜

こんなことを考えると思います。

そして、解決までの道標を作って、顧客のフォローをしていくはずです。

今回の問題プロジェクトは、iPMでプロコンサルとして参加しているMASAさんの実体験です。

MASAさんが、どんなアプローチで解決に至ったのか、詳しくはMASAさんが書いたコラムを読んでください。

特に、原因の分析と解決案から選んだ最後の手段は、あなたのお役に立つと思います😀

MASAさんが書いたコラムはこちら↓


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

プロジェクト計画で要件のFIXを後回しにさせない方法

ITプロジェクトは、プロジェクト計画で大枠でクライアントニーズを掴み、要件定義工程で詳細な要件に落とし込みます。

この段階でクライアント要件をFIXさせます。

しかし、全ての要件がこの工程でFIXするのは難しいこともあります。

クライアントの要件の中には、要件のFIX作業を進めるにつれて、社内調整が困難で、必要以上に時間が掛かることがあります。

そのため、プロジェクト計画の中で、社内で調整が難しい要件については、これらをWBSとスケジュールに反映して下さい。

⚫︎クリティカルパス

⚫︎マイルストーン

こんにちは、ゆーろーです。

冒頭はiPM naviのコラムの引用です。


あなたも経験があると思いますが、要件定義のFIXの面倒さと難しさを…

顧客の要件って、プロジェクト計画の段階で大枠は見えています。

そして、要件定義工程で詳細を詰めていくのが通例で、全ての要件がFIXすることが理想ですよね。

しかし、顧客の社内事情等があり、完全FIXは夢のまた夢では無いでしょうか？

そのことを分かっているにも関わらず、PMは、要件定義工程でFIXさせるようにWBSやスケジュールを作ってしまいます。

PMであれば、無理・無茶・無駄をリスクと捉えて、事前に排除しなければプロジェクトは炎上します。

🔥 炎上させなための攻略法が分かるコラム

iPM naviで紹介されているプロコンサルの平山 理さんが書いたコラムで、

『プロジェクト計画で要件のFIXを後回しにさせない方法』

を読むことで、ヒントが得られます。

このコラムは、SIerに勤務している若手PMが、

要件をFIXさせるのが下手のプロジェクトでトラブルを起こしてしまう、

という相談に平山理さんが答えものです。


-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-

👍 このコラムは

むずかしさ　：★★☆☆☆(PM初級者向け)

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

気付き学び　：★★★★★(要件は難易度で分類)

お役立ち　　：★★★★★(要件FIXの攻略法)

仕事の実用性：★★★☆☆(関連スキルを身に付けてから)

-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-

👀 コラム情報

コラミスト：平山 理さん

発信元：iPM navi

配信日：2022年10月31日

-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-

コラムのでは、要件をFIXさせるには、こんなことを提唱しています。

☘️ クライアントの社内事情を考量すると、要件定義フェーズで全ての要件をFIXするのは難しいもの。

☘️ クライアントの事情に合わせて要件定義ではFIXできない要件と、そうでない要件を分類する。

☘️ 分類した単位でWBSのタスクネットワークを作り、クリティカルパスとマイルストーンを設定。

ここで、大事なのがプロジェクト計画の段階で、要件を4つのパターンに分類しておくことだそうです。

【パターン1】
社内調整が順調に進めタスクが単独で進行する。

【パターン2】
社内調整が難航すると思われるタスクが単独で進行する。

【パターン3】
社内調整が難航すると思われるタスク（先行タスク）と社内調整が順調に進めタスク（後続タスク）が連携してタスクが進行する。

【パターン4】
社内調整が順調に進むタスク（先行タスク）と社内調整が難航すると思われるタスク（後続タスク）が連携してタスクが進行する。

👀 もっと深く知りたい方

この4つのパターンを使って、クリティカルパスやマイルストーンを設定していきます。

☘️ どんなふうに設定するのか？

☘️ 相談者のお悩みをどのようなアプローチで解決したのか？

このようなことを、お知りになりたい方は平山 理さんのコラムに答えがあります。

コラムはこちらです↓


-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-
P.S.

iPM naviのコミュニティでは、こんな質問がありました！

『要件定義の工程の中で、パターン1から4をタスクとして盛り込むべきか？、それとも要件定義工程と並行して別工程を作った方が良いのか？』

プロコンサルの方が回答されていますので、ご興味があればコミュニティでご覧ください。
-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-⚫︎-

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