-
Be the first to like this
No Downloads
Views
Total views
172
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds
No notes for slide
グローバルプロジェクト よくある問題共通点と解決チェックリスト
- 1. グローバルプロジェクトを抱える組織によくある問題点&プラクティカルな改善策糸賀大祐 MBA,PMP
- 2. LESSON LEARNEDこの十年間プラス様々なグローバルプロジェクトに関わって来た結果、様々な組織のカルチャー、オペレーションの習慣を観てきました。そこで表面化してくる問題には共通点がよく有り、プラクディカルな改善の余地が十分あると思います。
- 3. 現在グローバルプロジェクトの抱える典型的な組織レベルでのカルチャー問題:
- 4. クオリティーのコミットメントレベルの低い組織例: スペック外のパートを無理矢理用途にはめ込もうとし、パーツを現場レベルで修正するが顧客にはその事実を伝えない。例: 又はITのREDUNDANCYを用意せずFAIL OVERのバックアッププラニングを省き、結果SLA契約違反を続ける結果:レピュテ―ション、ブランイメージが下がる&顧客が去っていく、又は訴訟問題になる
- 5. プロジェクフェーズ前にスコープを明確化しない組織例:コンサルタント・ベンダーレベルではなく組織側でランニングスコープを認め、チェンジリクエストなしにスコープクリープをプロジェクトに押し付ける。しかし必要な追加リソース、又はスケジュールの延長に手を回さず、しかもPMが対応できる権限を与えない。しかも組織側は結果に責任を取らない。そしてPM、又はベンダーに責任を押し付ける。結果:ベンダーやPMが寄り付かなくなり市場価格以上の金額を常に払わない限りリソースが確保できなくなる。又はリソースをタイムリーに確保出来ずプロジェクトが中々始められない。
- 6. 確りプランを建てずプロセスに従わず、結局行き当たりバッタリの組織例:全体像のINTEROPERABILITY/ARCHITECTURE を考えずプランなしに新しいスコープを抱え込み、次のプロジェクトの仕様に加えていく。結果:設計が悪くスケールアップが出来なくなり、常に消防署状態になっている。キャパがフルになる時点で再度設計のやり直しとなりTCO(総所有コスト)が高くなる。又はキャパがフルになる事前に対応が出来ずSLA違反を起こす。例:リリースプラニング、スプリントプラニング、レトロスペクディブ、レビュー、LESSON LEARNED、プロジェクトの副産物ドキュメント化を省く、又はチェンジリクエスト、又はスコープチェンジをスコープドキュメントに更新しない。例:プロジェクトプランをスケジュール(ガントチャート)だと間違えて解釈している。結果:又はプロジェクトのライフサイクルが長くなればなる程初期TO BEから結果が離れていく。最終的に理想像が何だったのか分からなくなりビジネスケースと関係のない結果が出来上がってしまう。結果:プロジェクトチームメンバーが変わり新規リソースが入ってきてもオンボーディングが満足に出来ずターンオーバーに繋がる
- 7. AVAILABILITY(可用性) とUTILIZATION (稼働率)の依存性を理解していない組織例:AGILEに変化に対応するにはある程度UTILIAZTIONの余裕を持たない限り変動的環境に対応できない。プロジェクトのUTILIZATIONを100%に上げて効率 を高めようとするが何か起こった時に対応できない。プロジェクトの変動的な要素と確立されたオペレーションの違いを確り理解出来ていない。結果:問題が発生した時に対応が出来ず/遅れSLA違反又は訴訟問題になりかねない。
- 8. 人使いの荒い・又はマネジメント力に掛ける組織例:クリアーな支持が出せない、又は意図的に出さず失敗責任をコンサルタント、又はベンダーに負わせる。支持は出すがデシジョンのリスク・インパクトを確り把握しようとしない、又は理解できる能力に掛ける。結果:リソースのターンオーバーが高く知識の蓄積、組織としてのレベルアップが全く無い。ベンダーやPMが寄り付かなくなりリソース確保が困難になる。リソースが確保できずプロジェクトが中々立ち上がらない。
- 9. 簡単改善策:チェックリスト1.SLA, 又は訴訟リスクを先ず戦略レベルでレビューし、ベンダーではなくフロントラインマネジャー&社内に責任をシフトする2.リリースに分けてインスコープ・アウトオブスコープをフェーズ開始前に明確にし、ステークホルダーがサインオフする3.スコープドキュメント、テクニカルスペックのサインオフ無しにはプロジェクト・プロジェクトフェーズを始めない4.スケーラビリティ、バックアッププランのサインオフをアーキテクト、エンジニアリングマネジャーレベルで必ず行う5.リスク対応策プランを必ずRACIで人とTO DOに落す6.会議後必ず筆記明確なデシジョンをノートに残し、リスク&インパクトを把握するサインオフをマネジャーレベルで行う。7.スコープチェンジには必ずチェンジリクエストとサインオフを必要とする、リスク&インパクト、そしてインパクトに対する対応プランを明確に筆記で残す。