Project Portfolio Measure Cards

1,509 views

Published on

プロジェクトポートフォリオの施策カード(5x3;表のみ)です。詳しくはこちら→ http://yattom.jp/trac/public/wiki/ProjectGames/ProjectPortfolio

なぜか画面上では表示されません。Downloadすれば見られます(印刷も)。

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,509
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
21
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Project Portfolio Measure Cards

  1. 1. M1 USER 強引に仕様を確定す る ユーザーの要求を強引に統一し て仕様を確定する。作業と期間を 節約できるが、内容として不十分 な部分ができてしまう。 A RISK Quality Cost Delivery -3 +1 +1 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  2. 2. M2 USER コスト追加の承認を 受ける プロジェクトの追加予算を獲 得する。ただしスケジュールの 遅延は許されない。「不景気で 予算削減される」をキャンセル できる。 A RISK Quality Cost Delivery -1 +2 -2 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  3. 3. M3 USER 新しい技術を使う 未検証の先端的な技術を採用す るという決定をする。検証に時間 がかかり、また期待通りの機能 や性能を発揮できない部分があ るが、生産性向上でコストを減ら せる。 A Quality Cost Delivery -2 +2 -1 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  4. 4. M4 USER 仕様を頻繁に変える 途中で仕様の変更が多発する。 追加のコストが必要となり、また テスト不十分な部分が出てくる。 B Quality Cost Delivery -1 -1 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  5. 5. M5 USER 厳しい期間を設定す る スケジュールを厳しめに設定する ことで、コストの圧縮を図る。 B Quality Cost Delivery 0 +1 -2 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  6. 6. M6 USER 厳しい品質要求を提 示する 品質要求を高く設定することで、 品質を担保する。検証のための コストがかかる。「全く動かないモ ジュールが発見される」をキャン セルできる。 B Quality Cost Delivery +1 -2 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  7. 7. M7 USER 大規模な仕様変更を 要求する ユーザー側の要求を調整した結 果、大規模な仕様変更が必要と なる。スケジュールを遅らせるこ とはできない。 B Quality Cost Delivery 0 0 -2 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  8. 8. M8 USER ドキュメント標準を 提示する 包括的ドキュメントの標準を提示 し、品質の確保をはかる。標準作 成と準拠確認の作業コストが必 要。 C Quality Cost Delivery +1 -2 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  9. 9. M9 USER プロセス監査を厳し くする 厳格なプロセス監査を導入する。 品質を担保できるが、追加の作 業が必要なため、コストと期間に 影響する。 C Quality Cost Delivery +1 -1 -1 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  10. 10. M10 USER 仕様未定で着手する 仕様が決まるめどが付かないま ま見切り発車するため、そのぶ んスケジュールが遅延する。 D RISK Quality Cost Delivery 0 0 -1 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  11. 11. M11 USER 膨大な仕様を提示す る 予算とスケジュールに対して仕様 が大きすぎる。ただちに影響は出 てこないが、どこかにしわよせが 行く。「部署間調整に失敗」をキャ ンセルできる。 D RISK Quality Cost Delivery 0 0 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  12. 12. M12 USER 現場のわがままを聞 く 現場の要望を受け入れて仕様を 変更する。追加のコストがかかる。 「部署間調整に失敗」の影響を半 分にできる。 D Quality Cost Delivery 0 -1 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  13. 13. M13 DEVELOPER スケジュール延長を 説得する ステークホルダーを説得し、スケ ジュールの延長に成功する。期 間は延びるが、コストに対する引 き締めが厳しくなる。「協力会社 が逃げる」のDelivery変化をゼロ にできる。 A RISK Quality Cost Delivery 0 -3 +2 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  14. 14. M14 DEVELOPER オフショア開発をす る 開発の一部をオフショアに依頼す る。大幅なコスト圧縮とスケ ジュールの前倒しが見込まれた が、思った以上に品質が悪かっ た。「競合他社が新サービスを発 表」のDelivery変化を-1にできる。 A RISK Quality Cost Delivery -3 +2 +1 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  15. 15. M15 DEVELOPER プロセス監査を導入 する プロセス監査を導入して品質を 担保する。対応のための作業が 増加し、コストとスケジュールに 悪影響。 B Quality Cost Delivery +2 -2 -1 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  16. 16. M16 DEVELOPER 難しい技術を使う 複雑で習得や利用が難しい技術 を採用する。生産性が下がり、コ ストに悪影響を与える。「パフォー マンスが出ない」をキャンセルで きる。 B RISK Quality Cost Delivery 0 -1 -1 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  17. 17. M17 DEVELOPER メンバーを入れ替え る プロジェクトメンバーを一部入れ 替える。引き継ぎのドタバタに時 間を食われるが、品質が改善。 「開発者が大勢退職する」の Delivery変化をゼロにできる。 B RISK Quality Cost Delivery +1 0 -1 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  18. 18. M18 DEVELOPER 残業でこなす 残業を積み重ねて生産性を上げ る。作業は前倒しで進むが、徐々 に品質が悪くなっていく。 C RISK Quality Cost Delivery -1 +1 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  19. 19. M19 DEVELOPER テストを自動化する テスト自動化を導入する。品質に 好影響があるが、導入と習得ま でに時間がかかる。「協力会社が 逃げる」のQuality変化をゼロに、 Delivery変化を-1にできる。 C Quality Cost Delivery +1 0 -1 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  20. 20. M20 DEVELOPER 厳しい品質管理を導 入する 品質管理プロセスを導入する。 品質は上がるが、コストもかかる。 「全く動かないモジュールが発見 される」をキャンセルできる。 C Quality Cost Delivery +1 -1 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  21. 21. M21 DEVELOPER 若く安価なメンバー を調達する プロジェクトメンバーを若手中心 に構成し、コストを圧縮する。未 熟なため品質に問題が出がち。 「開発者が大勢退職する」の Quality変化を-1に、Delivery変 化を-1にできる。 D Quality Cost Delivery -1 +1 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  22. 22. M22 DEVELOPER 短期リリースする リリースを短期で繰り返す。リ リースの手間で作業が増えるが、 フィードバックを得て品質が上 がった。 D Quality Cost Delivery +1 -1 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  23. 23. M23 DEVELOPER 優秀なメンバーを集 める コストがかかることを覚悟して、 優秀なメンバーを社内外から集 める。「協力会社が逃げる」の QualityとCostの変化をゼロにで きる。 D Quality Cost Delivery +1 -1 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4
  24. 24. M24 DEVELOPER 空き要員を活用する 社内の手空きのメンバーに手 伝ってもらう。「不景気で予算が 削減される」のCost変化を-1にで きる。 D RISK Quality Cost Delivery 0 0 0 (C)2009 やっとむ・安井力 http://yattom.jp Rev.4

×