DX時代に役立つPMブログのレビュー

マネジメントに四苦八苦して20年。今はマネジメントを教える、楽しい、不思議なものだ!皆さんの参考になれば。

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

2022-11-10 14:59:39 | DX
プロジェクトは、計画段階でスコープを決めます。

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

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

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

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



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

冒頭のメッセージですが、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として取り入れておきたいスキルの一つです。

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

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

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

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

2022-11-07 10:53:44 | DX
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プロジェクトの経験者が居ない

2022-11-02 18:17:54 | DX
プロジェクト進行中に顧客の都合で作業が停滞することは日常茶飯事です。

特に、厄介なのが顧客サイドに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を後回しにさせない方法

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

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

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