グローバルプロジェクト よくある問題共通点と解決チェックリスト

10
グググググググググググググググググググググググググ グググググググググググ ググググ MBA PMP

Upload: dice-itoga-pmp-itil-foundation-csm

Post on 12-Apr-2017

166 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: グローバルプロジェクト よくある問題共通点と解決チェックリスト

グローバルプロジェクトを抱える組織によくある問題点& プラクティカルな改善策

糸賀大祐  MBA , PMP

Page 2: グローバルプロジェクト よくある問題共通点と解決チェックリスト

LESSON  LEARNED

この十年間プラス様々なグローバルプロジェクトに関わって来た結果、様々な組織のカルチャー、オペレーションの習慣を観てきました。  そこで表面化してくる問題には共通点がよく有り、プラクディカルな改善の余地が十分あると思います。

Page 3: グローバルプロジェクト よくある問題共通点と解決チェックリスト

現在グローバルプロジェクトの抱える典型的な組織レベルでのカルチャー問題 :

Page 4: グローバルプロジェクト よくある問題共通点と解決チェックリスト

クオリティーのコミットメントレベルの低い組織  例 : スペック外のパートを無理矢理用途にはめ込もうとし、パーツを現場レベルで修正するが顧客にはその事実を伝えない。  例: 又は ITの REDUNDANCYを用意せず FAIL OVERのバックアッププラニングを省き、結果 SLA契約違反を続ける 結果:レピュテ―ション、ブランイメージが下がる&顧客が去っていく、又は訴訟問題になる

Page 5: グローバルプロジェクト よくある問題共通点と解決チェックリスト

プロジェクフェーズ前にスコープを明確化しない組織  例:コンサルタント・ベンダーレベルではなく組織側でランニングスコープを認め、チェンジリクエストなしにスコープクリープをプロジェクトに押し付ける。 しかし必要な追加リソース、又はスケジュールの延長に手を回さず、しかも PMが対応できる権限を与えない。しかも組織側は結果に責任を取らない。そして PM、又はベンダーに責任を押し付ける。 結果:ベンダーや PMが寄り付かなくなり市場価格以上の金額を常に払わない限りリソースが確保できなくなる。又はリソースをタイムリーに確保出来ずプロジェクトが中々始められない。

Page 6: グローバルプロジェクト よくある問題共通点と解決チェックリスト

確りプランを建てずプロセスに従わず、結局行き当たりバッタリの組織  例:全体像の INTEROPERABILITY/ARCHITECTURE を考えずプランなしに新しいスコープを抱え込み、次のプロジェクトの仕様に加えていく。 結果:設計が悪くスケールアップが出来なくなり、常に消防署状態になっている。キャパがフルになる時点で再度設計のやり直しとなり TCO(総所有コスト )が高くなる。又はキャパがフルになる事前に対応が出来ず SLA違反を起こす。 例:リリースプラニング、スプリントプラニング、レトロスペクディブ、レビュー、 LESSON LEARNED、プロジェクトの副産物ドキュメント化を省く、又はチェンジリクエスト、又はスコープチェンジをスコープドキュメントに更新しない。

例:プロジェクトプランをスケジュール(ガントチャート)だと間違えて解釈している。 結果:又はプロジェクトのライフサイクルが長くなればなる程初期 TO BEから結果が離れていく。 最終的に理想像が何だったのか分からなくなりビジネスケースと関係のない結果が出来上がってしまう。 結果:プロジェクトチームメンバーが変わり新規リソースが入ってきてもオンボーディングが満足に出来ずターンオーバーに繋がる

Page 7: グローバルプロジェクト よくある問題共通点と解決チェックリスト

AVAILABILITY(可用性) と UTILIZATION (稼働率)の依存性を理解していない組織  例: AGILEに変化に対応するにはある程度 UTILIAZTIONの余裕を持たない限り変動的環境に対応できない。 プロジェクトの UTILIZATIONを 100 %に上げて効率 を高めようとするが何か起こった時に対応できない。 プロジェクトの変動的な要素と確立されたオペレーションの違いを確り理解出来ていない。 結果:問題が発生した時に対応が出来ず / 遅れ SLA違反又は訴訟問題になりかねない。

Page 8: グローバルプロジェクト よくある問題共通点と解決チェックリスト

人使いの荒い・又はマネジメント力に掛ける組織 例:クリアーな支持が出せない、又は意図的に出さず失敗責任をコンサルタント、又はベンダーに負わせる。 支持は出すがデシジョンのリスク・インパクトを確り把握しようとしない、又は理解できる能力に掛ける。結果:リソースのターンオーバーが高く知識の蓄積、組織としてのレベルアップが全く無い。ベンダーや PMが寄り付かなくなりリソース確保が困難になる。リソースが確保できずプロジェクトが中々立ち上がらない。

Page 9: グローバルプロジェクト よくある問題共通点と解決チェックリスト

簡単改善策:チェックリスト 1 . SLA, 又は訴訟リスクを先ず戦略レベルでレビューし、ベンダーではなくフロントラインマネジャー&社内に責任をシフトする 2 .リリースに分けてインスコープ・アウトオブスコープをフェーズ開始前に明確にし、ステークホルダーがサインオフする 3 .スコープドキュメント、テクニカルスペックのサインオフ無しにはプロジェクト・プロジェクトフェーズを始めない 4 .スケーラビリティ、バックアッププランのサインオフをアーキテクト、エンジニアリングマネジャーレベルで必ず行う 5 .リスク対応策プランを必ず RACIで人と TO DOに落す 6 .会議後必ず筆記明確なデシジョンをノートに残し、リスク&インパクトを把握するサインオフをマネジャーレベルで行う。 7 .スコープチェンジには必ずチェンジリクエストとサインオフを必要とする、リスク&インパクト、そしてインパクトに対する対応プランを明確に筆記で残す。

Page 10: グローバルプロジェクト よくある問題共通点と解決チェックリスト

Thank You !