最近見たDXコラムのオススメ記事

最近見たDXコラムのオススメ記事

DX時代に適応していくためにリスキリングされているPMの方にとって、実用性の高いプロジェクトマネジメントの情報を配信しています。

Amebaでブログを始めよう!

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

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

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

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

それは、作業工数です。

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

 

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

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

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

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

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

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

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

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

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



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

 

 

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

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

👍 このコラムは

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

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

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

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

仕事の実用性:★★★★☆(今すぐ使える)

 

👀 コラム情報

コラミスト:MASAさん

発信元:iPM navi

配信日:2022年11月07日

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

 

😲 こんなお悩み

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

PMの経験は3年です。

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

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

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

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

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

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

 

😀 こうやって解決

ポイントはこれ❗️

・リスクを洗い出す。

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

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


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

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

 

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

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

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

 

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

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

そのため、計画段階で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プロジェクトで、自社社員だけで構成された体制であれば、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プロジェクトの経験者がいない時...

このようなとき、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さんが書いたコラムはこちら↓

 

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

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をタスクとして盛り込むべきか?、それとも要件定義工程と並行して別工程を作った方が良いのか?』

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

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

 

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

iPM naviのコラム【リスク管理表の作り方】をご紹介します。

このコラムは、大手コンサルファームのコンサルタントも使っているリスク管理表。

それを、iPMに参加しているプロコンサルのMIRIOさんが、

  • どのような項目が必要なのか?
     
  • どのように作っていくのか?

これらをわかりやすく解説しています。

わたしもリスク管理表に必要な項目や実用的な使い方を探していました。

そんなこともあり、このコラムを読んでみました。

 

👍 このコラムは

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

ボリューム :★★★★☆(9分-10分で読める)


気付き学び :★★★★★(リスク管理表の作り方)

お役立ち  :★★★★★(実用的なリスク管理表)

仕事の実用性:★★★★☆(今すぐ使える)

 

今回、ご紹介するコラム↓

 

 

🧑 こんな方におススメ

  • リスク管理表の作り方を知りたいPM
     
  • 実用的なリスク管理表を探している方
     
  • DX時代に適応するためにリスキリングしたいPM

 

👀 コラム情報

コラミスト:プロコンサル MIRIOさん

発信元:iPM navi

配信日:2022年10月24日

 

 

What)これは何のためのコラムか?

リスク管理表の作り方(手順)がわかる。

iPMに所属するプロコンサルのMIRIOさんが、大手コンサルファームでも活用しているリスク管理表の作り方を紹介するコラム。

一般的な、リスク管理表は実用性に乏しいことから、現場で使うために必要とされる管理項目が納得感を与えてくれる。

 

その他、リスクの見つけ方も分かってしまう優れもの。

 

 Why)このコラムを読む理由は何か?

プロジェクトは、不確実性が高いことからリスクがあるのは当然。

プロジェクトの計画段階で、数多くのリスクを洗い出しても、

 

いぜ!業務を遂行しているときに、リスクが発覚した時、PMは何を?、いつ?、どのように?で戸惑う場面が多いもの。

そのような、無駄を無くすためのリスク管理表を作っていく手順が覚えられるため。

 

 How)このコラムが伝える解決方法は何か?

PM初級者でも、これらを押さえるだけで、実用的なリスク管理表が作れてします。

 

今、使っているリスク管理表に、

 

  • リスク発生率
     
  • リスク影響度
     
  • リスク点数
     
  • リスク優先度

 

これらの項目を追加することで、PMは何を?、いつ?、どのように?が明確になり、適切にリスクコントロールができるようになる。

 

 感想・総評 

プロジェクトは計画段階で、ある程度のリスクを見つけ出し不測の事態になる前に対策を講じることで、プロジェクトの成功が約束されると言っても過言ではありません。

 

しかし、リスク管理ができていないプロジェクトが多いのが現実です。

 

それは、PMがリスクの内容がわかっていても、何を?、いつ?、どのように?といったリスク対応に不安があるからでは…

 

そんなPMの不安を、コラムの中では、上手に『リスク優先度』を付けることで、リスクコントロールが容易になると教えてくれています。

 

今まで、リスクの優先度の付け方を、ここまで明確に・簡単に教えている情報はなかったと思います。

 

また、iPM naviのコミュニティで、『短期間プロジェクトでもリスク管理表は必要なのか?』という、メンバーの質問にも丁寧に回答してました。


ぜひ、今使っているリスク管理表が現場に合わないと思っている方、リスク管理表の作り方を知りたい方に、おススメしたいコラムです。

『リスク管理表を作る手順』を読んでみて下さい。

 


 

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

iPM naviのコラム【初めてのITプロジェクト!見積りを鵜呑みにせず確認する方法】をご紹介します。

このコラムは、PM未経験の方がITパートナーからの見積もりをどのようにチェックすればいいのか?という、お悩みをプロコンサルが解決します。

わたしは、過去に事業会社のシステム部署にいました。

その時、相談者さんと同じ悩みを持ったことがあり、

『あの時、どんなふうにすれば良かったのか?』と

振り返りや教訓のために読みました。

 

👍 このコラムは

むずかしさ :★☆☆☆☆(PM初心者向け)

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

気付き学び :★★★★★(見積りのチェック)

お役立ち  :★★★★☆(見積りに疑問を持ったら)

仕事の実用性:★★★☆☆(関連スキルが必要

 

今回、ご紹介するコラム↓

 

🧑 こんな方におススメ

  • 他人が作った見積りの根拠を確認する方法を知りたいPM
     
  • PMを目指している方
     
  • DX時代に適応するためにリスキリングしたいPM

 

👀 コラム情報

コラミスト:プロコンサル Osamu Hirayamaさん

発信元:iPM navi

配信日:2022年10月28日

 

 

What)これは何のためのコラムか?

三者が作った見積りの正当性を判断する方法がわかる。

iPMに所属するプロコンサルが、PM未経験者の相談に答えるコラム。

事業会社の情報シスに所属するPM未経験者が、ITパートナーから提示のあった見積りをチェックする方法を教えている。
*相談者はIT業務も初めて。

 

 Why)このコラムを読む理由は何か?

PM未経験は、第三者が作った見積りの正当性を確認する時、ベテランと比べて、チェックするポイントが限られている(過去の私も同じ)。

初めてPMをやる人でも、第三者が作った見積りを確認するチェック手順を身に付けておけば、プロジェクトで無駄なコストを抑えられるため。

 

 How)このコラムが伝える解決方法は何か?

PM未経験者でも、これらを押さえるだけで、ITパートナーから提示のあった見積りの正当性が判断できる。

・プロジェクトの前提条件や制約条件

・想定されるリスクの原因

これらを使って仮説を作り確認していく。

 

 感想・総評 

見積りを作るのも難しければ、ましてや他人の見積もりであれば、尚更ではないでしょうか...

プロコンサルが伝える方法は、有識者の力も借りながら、

・プロジェクトの前提条件や制約条件

・想定されるリスクの原因

これらを押さえて、ITパートナーの見積りの意図を理解していきましょう!と提唱しています。

わたしが、初めてPMをやった時ですが相手に対して、

『なんで?』

『それは何で?』

『それって正しいの?』

これは、理詰めしているように思えますが、全く違って自分が相手を精神的に追い込んで、『お値引きさせていただきます』と言わせるような邪道な方法をとっていました。

本来、ビジネスの世界では間違ったやり方でした。

コラムの中では、正々堂々と相手も納得する手順で教えてくれます。

ぜひ、PMを初めてやる人、相談者のようにIT業務が初めてにも関わらず、会社の諸事情でPMをやらされる人には、おススメしたいコラムです。

『初めてのITプロジェクト!見積りを鵜呑みにせず確認する方法』を読んでみて下さい。