どんな問題？
- 2種類の計画過多がある
- Glass Case Plan
- Detailitis Planのサブセット
- プロジェクトが始まったら計画過多はなくなる
- Detailitis Plan
- Glass Case Plan
- プロジェクトスタート時の計画は完璧だと見なされている
- でも実際には，計画がトラッキングされたり更新されないと，プロジェクトの進行とともに不正確になってしまう．
- プロジェクトの進行の情報に関する具体的な情報がないときに起きる
- Detailitis Plan
- 絶え間ない計画の更新が必要とされる
- 階層的でシーケンシャルな計画
- プロジェクトが完璧にコントロールされていると知覚する
症状と結果
Glass Case Plan
- 症状として下記を最低1つ含む
- pragmaticなレベルの計画を立てられない
- 納品よりコストに重点を置く
- 開発資金がある限り詳細にこだわる
- 結果はインクリメンタルに起きる
- 開発状況を関知しない
- 時間が経つにつれ，計画の意味がなくなる
- 納期に間に合うかどうかは誰もわからない
- 納品失敗する
- プロジェクトがoverrunすると，以下のオプションがある
Detaiilis Plan
- 症状はGlass Case Planのサブセット
- pragmaticなレベルの計画を立てられない
- 納品よりコストに重点を置く
- 計画詳細化，再計画に時間をかける
- プロジェクトマネージャーがプロジェクトのactivityを計画する
- チームリーダーがチームと開発者のactivityを計画する
- 開発者がactivityをタスクに分解する
- 結果はお互いに結びつく
- 各自が計画通りかモニターする
- 終わりのない再計画が行われる
- 目的が納品ではなく計画そのものになる
- 納品の遅れが起き，プロジェクトが最終的に失敗する
原因
Glass Case Plan
- 計画を更新しない
- プロジェクトマネジメントの原則を無視する
- 初期計画に熱心すぎる
- 契約獲得のための営業の影響
Detailitis Plan
- 契約更新に熱心すぎる
- 計画を立てることが，プロジェクトの主目的となる
- 顧客や重役とのコンプライアンスの影響
どう解決する？
- 計画は納品物を示すべき
- 納品物は2つのレベルで定義される
- 納品物とはたとえば以下
- ビジネス要件
- 技術仕様書
- 定量評価可能な基準
- 製品の使い方のシナリオ
- 要素技術のユースケース
- 計画はマイルストーンも含む必要がある
- 概念レベルの同意
- 仕様レベルの同意
- 実装レベルの同意
- テスト計画の同意
yusuke-ujitoko.hatenablog.com
