複数のITパートナーを管理するリスクを探すコツ
ITプロジェクトで、自社社員だけで構成された体制であれば、PMとしては気が楽です。
しかし、最近のプロジェクトは様々な要因から、自社社員で推進していくのが、難しい状況です。
・業界全体で人手不足
・高度なテクニカルスキル
・業務スキルの不足...etc
そのため、ITパートナーに参加してもらうケースは多いものです。
この混成チームで、ようやくプロジェクトがスタートできます。
その瞬間から、PMは『複数のITパートナーを管理』するリスクを背負うことになります。
お疲れ様です、ゆーろーです。
最近のプロジェクトは様々な要因から、自社社員で体制を組むことは不可能に近いものです。
複数のITパートナーや一緒に仕事をしたことの無いフリーランスをチームに招集して、マネジメントしていくスキルがPMには求められています。
プロジェクトの『組織マネジメント』においては、難しいことであり、特に経験の浅いPMの方であれば、苦労するのではないでしょうか？
今回、紹介したいコラムは、
SIer勤務の29歳PMの方から、複数のITパートナーで構成するチームでは、どんなリスクがあるのか？
その相談に、iPMに参加しているプロコンサルのMASAさんが答えている内容となります。
👍 このコラムは
むずかしさ ：★★☆☆☆（PM初級者向け）
ボリューム ：★★★☆☆(5分-8分で読める)
気付き学び ：★★★★★(寄せ集めチームの管理)
お役立ち ：★★★★★(寄せ集めチームのリスク)
仕事の実用性：★★★☆☆（関連スキルが必要かも）
😲 どんな相談だったのか？
①今回のシステム開発は、複数の業務システムを改修する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が成功せう体制作り)
お役立ち ：★★★★★(顧客体制を強化する攻略法)
仕事の実用性：★★☆☆☆（有識者のサポートが必要かな）
それでは、コラムのあらすじをお伝えします。
😲 どんなプロジェクトなのか？
【プロジェクトの体制とスコープ】
・顧客は大手出版会社の情報システム部で財務会計の新規構開発を実施。
・システム化スコープは財務会計管理、管理会計管理、社員管理が対象。
・中堅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をタスクとして盛り込むべきか？、それとも要件定義工程と並行して別工程を作った方が良いのか？』
プロコンサルの方が回答されていますので、ご興味があればコミュニティでご覧ください。
iPM navi【初めてのITプロジェクト！見積りを鵜呑みにせず確認する方法】レビュー
こんにちは、ゆーろーです。
PM naviのコラム【初めてのITプロジェクト！見積りを鵜呑みにせず確認する方法】をご紹介します。
このコラムは、PM未経験の方がITパートナーからの見積もりをどのようにチェックすればいいのか？という、お悩みをプロコンサルが解決します。
わたしは、過去に事業会社のシステム部署にいました。
その時、相談者さんと同じ悩みを持ったことがあり、
『あの時、どんなふうにすれば良かったのか？』と
振り返りや教訓のために読みました。
👍 このコラムは
むずかしさ ：★☆☆☆☆（PM初心者向け）
ボリューム ：★★★☆☆（3分-５分で読める）
気付き学び ：★★★★★（見積りのチェックがわかる）
お役立ち ：★★★★☆（見積りに疑問を持ったら）
仕事の実用性：★★★☆☆（関連スキルを身に付けてから）
🧑 こんな方におススメ
⚫︎他人が作った見積りの根拠を確認する方法を知りたい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プロジェクト！見積りを鵜呑みにせず確認する方法』を読んでみて下さい。
iPM navi【プロジェクトを計画通り実行するには洗練された体制が必要〜プロジェクト体制の構築の方法〜】レビュー
こんにちは、ゆーろーです。
今回は、iPM naviのコラム【プロジェクトを計画通り実行するには洗練された体制が必要〜プロジェクト体制の構築の方法〜】を紹介です。
おススメ度：★★★★★
基本スキルの要素（★★★★★）
現場での実用性 （★★★★★）
人に教えたい度 （★★★★☆）
◆コラム情報
コラミスト：プロコンサル Osamu Hirayamaさん
発信元：iPM navi
配信日：2022年10月28日
👍 こんな方におススメ！
・DX時代に適応するためにリスキリングしたいPM
・PJ計画書の正しい作り方の手順を知りたいPM
・洗練されたプロジェクト体制を作りたいPM
What)これは何のためのコラムか？
プロジェクト計画書の中の体制図とは”なんぞや”がわかる
プロジェクトを円滑に進める正しい開発チームの体制がわかる
プロジェクトの体制を構築する方法がわかる
Why)このコラムを読む理由は何か？
プロジェクト計画書を正しく作れるようになるため
勘に頼った体制続くりでプロジェクトの失敗が多いため
品質・コスト・スケジュールの目標をクリアーできないため
How)このコラムが伝える解決方法は何か？
上手くプロジェクト体制を作れずプロジェクトを炎上させてしまったPMが多いため、体制構築を考える時は、これらの要素を入れるべし👊
・役割分担の整理
・要員計画の作成
・指揮命令系統が明確な体制図
これをやることで、プロジェクトが成功するチームが出来上がる😀
感想・総評
プロジェクト体制を考える上で、WBSやスケジュールは必須です。
しかし、これらの資料だけでは見えていない役割があり、体制を作るためには不十分なんです。
何故ならば、成果物を期日までに作っていくことに特化した資料であり、リスク・問題に素早く対処する体制要素が盛り込まれていないからです。
また、要員計画にプロジェクトへの参加・終了タイミングを、定義していないことから、これらの事故が起こっています。
・無駄なコストの発生
・品質の劣化
・スケジュールの遅延
これで、着実にプロジェクトを進めることができるでしょうか？
役割分担の整理
↓
要員計画の作成
↓
指揮命令系統が明確な体制図
この順番で、体制構築をアプローチすることで、プロジェクトを円滑に進ませるチームが出来上がります。
そのメソッドを丁寧に教えてくれるコラムです。
ぜひ読んでみて下さい↓
しかし、これらの資料だけでは見えていない役割があり、体制を作るためには不十分なんです。
何故ならば、成果物を期日までに作っていくことに特化した資料であり、リスク・問題に素早く対処する体制要素が盛り込まれていないからです。
また、要員計画にプロジェクトへの参加・終了タイミングを、定義していないことから、これらの事故が起こっています。
・無駄なコストの発生
・品質の劣化
・スケジュールの遅延
これで、着実にプロジェクトを進めることができるでしょうか？
役割分担の整理
↓
要員計画の作成
↓
指揮命令系統が明確な体制図
この順番で、体制構築をアプローチすることで、プロジェクトを円滑に進ませるチームが出来上がります。
そのメソッドを丁寧に教えてくれるコラムです。
ぜひ読んでみて下さい↓
iPM navi【プロジェクト目標を設定する方法】レビュー
こんにちは、ゆーろーです。
今回は、iPM naviのコラム【WBS・マイルストーンを作る手順】を紹介です。
おススメ度：★★★★☆
プロジェクト計画書を作る時ですが、目的と目標を記載すると思います。
優秀なPMは、目的と目標の意味をきちんと理解した上で、エッジの効いた計画書を作り上げます。
しかし、目的と目標がごっちゃになっているプロジェクト計画書を使って業務を行っていくと、顧客の望まないシステムが出来上がったりと意に反する結果になるものです。
目的とは何でしょうか？
目標とは何でしょうか？
目的と目標はどのように紐づいているのでしょうか？
初めてプロジェクト計画書を作る人でも簡単い理解できて、プロジェクトの目標の設定の手順を教えてくれるコラムです。
◆コラム情報
コラミスト：プロコンサル Osamu Hirayamaさん
発信元：iPM navi
配信日：2022年10月26日
👍 こんな方におススメ！
・DX時代に適応するためにリスキリングしたいPM
・プロジェクトの目的と目標が混合しちゃうPM
・プロジェクト目標の設定手順を知りたい方
What)これは何のためのコラムか？
プロジェクトの目的と目標のメリハリがわかる
プロジェクトの目標の意味がわかる
目標の設定の手順がわかる
Why)このコラムを読む理由は何か？
プロジェクト計画書を正しく作れるようになるため
プロジェクト目標が曖昧なことでプロジェクトの失敗が多いため
目標を設定する方法が間違っているため
How)このコラムが伝える解決方法は何か？
今、あなたが使っているPJ計画書に、これらの要素を入れるべし👊
・品質目標
・コスト目標
・スケジュール目標
これだけで、目的を達成するために、何を、どのくらい、クリアーしていけば良いのか、という計画書が出来上がります😀
感想・総評
プロジェクトの目標ってなんですか？
そんな問いかけをしたときに、目的を語るPMが多いものです。
目的とは、なにを実現すのか、ということです。
*今回のコラムの付属として目的を明確にする方法も紹介
プロジェクトの目標とは
・品質
・コスト
・スケジュール
これらの3つとなります。
この目標をクリアーした先に目的が達成されるというロジックになっています。
それでは、どのように品質目標・コスト目標・スケジュール目標を設定していくのか、これは大手コンサルファームのコンサルも使うメソッドがあります。
そのメソッドの基本部分を丁寧に教えてくれるコラムです。
ぜひ読んでみて下さい↓
そんな問いかけをしたときに、目的を語るPMが多いものです。
目的とは、なにを実現すのか、ということです。
*今回のコラムの付属として目的を明確にする方法も紹介
プロジェクトの目標とは
・品質
・コスト
・スケジュール
これらの3つとなります。
この目標をクリアーした先に目的が達成されるというロジックになっています。
それでは、どのように品質目標・コスト目標・スケジュール目標を設定していくのか、これは大手コンサルファームのコンサルも使うメソッドがあります。
そのメソッドの基本部分を丁寧に教えてくれるコラムです。
ぜひ読んでみて下さい↓
iPM navi【WBS・マイルストーンを作る手順】レビュー
PM naviのコラム【WBS・マイルストーンを作る手順】の紹介です。
おススメ度：★★★★★
WBSは、プロジェクトを推進する上で必須アイテムです。
会話の中で、当たり前のように出てくるWBS...
しかし、初めてPMをやる人、ましてやベテランPMでも、つまずく作業がWBSを作ることです。
WBSを作るのに、スペシャルなテクニックが必要なのか？
初めてWBSを作る人でも、使いやすい手順を教えてくれるコラムです。
◆コラム情報
コラミスト：プロコンサル Osamu Hirayamaさん
発信元：iPM navi
配信日：2022年10月26日
👍 こんな方におススメ！
・DX時代に適応するためにリスキリングしたいPM
・WBSに抜け漏れがあって悩んでいる方
・正しいWBSの作り方を知りたい方
What)これは何のためのコラムか？
大手コンサルファームのコンサルタントも使っているWBSの正しい作り方が分かる
Why)このコラムを読む理由は何か？
WBSはステークホルダーごとに3種類ある。
それを包括してWBSを作る手順が見当たらなかった...
また、WBSで表現する項目の定義と作成するための正しい手順が理解できて、
今すぐ、現場で使える実用性が高いため。
How)このコラムが伝える解決方法は何か？
今、あなたが使っているWBSに、これらの要素を入れるべし👊
・作業工程を主軸に置いてWBSを作っていく
・作業概要を洗い出すときは、成果物の目次を使う
・過去プロジェクトで起こった問題、プロジェクト予防するという教訓をタスクとして盛り込む
・マイルストーンは、プロジェクトの中で、工程遅延が許されない大きな節目を設定する
これだけで、WBSに厚みが出て、抜け漏れがなくなるんです😀
感想・総評
社内でWBSの作り方を標準化したいんだよね！
コンサルタントをやっていると、このようなご相談を受けることがあります。
標準化とは、聞こえが良く、『誰でも簡単に使えるもの』というイメージを持ってしまいます。
なかなか、そのようにはなりません。
このような、大きな原因があるのではないでしょうか？
・標準化する対象物がそもそも標準化できるのか？
・標準化するためには対象となるモノを深く理解できているのか？
よく耳にするのは後者で、実際に標準化を設計する人のスキルが足りないということが多いものです。
特にWBSはプロジェクトの成功を大きく左右するアイテムであり、間違った手順で作ったWBSでプロジェクトを遂行したら、どうなるでしょうか？
そうです❗️炎上プロジェクトに❤️🔥
このコラムでは、多くの炎上プロジェクトにPMOとして参画して、
火消し役で活躍されたOsamu Hirayamaさんのメソッドが詰まったコラムです。
ぜひ読んでみて下さい↓
コンサルタントをやっていると、このようなご相談を受けることがあります。
標準化とは、聞こえが良く、『誰でも簡単に使えるもの』というイメージを持ってしまいます。
なかなか、そのようにはなりません。
このような、大きな原因があるのではないでしょうか？
・標準化する対象物がそもそも標準化できるのか？
・標準化するためには対象となるモノを深く理解できているのか？
よく耳にするのは後者で、実際に標準化を設計する人のスキルが足りないということが多いものです。
特にWBSはプロジェクトの成功を大きく左右するアイテムであり、間違った手順で作ったWBSでプロジェクトを遂行したら、どうなるでしょうか？
そうです❗️炎上プロジェクトに❤️🔥
このコラムでは、多くの炎上プロジェクトにPMOとして参画して、
火消し役で活躍されたOsamu Hirayamaさんのメソッドが詰まったコラムです。
ぜひ読んでみて下さい↓
◆ Osamu Hirayamaさんのキャリア
2001年に大手コンサルファームBにジョイン。
ITコンサルタントとして複数のシステム開発プロジェクトのPM・PMOに従事。
2016年よりSIerの取締役として、BtoC向けスマートフォンアプリ開発サービスのビジネススケールに貢献。
2019年にITコンサルファームを設立。
大手金融会社の新規事業のIT担当として、脳機能を定期的に測定することにより、認知機能の変化を把握するシステムの開発を担当し自社ビジネスを拡大。
