Column
コラム
ホーム > コラム > プロジェクトマネジメント > DCMA14ポイント ~ スケジュール構築の評価方法
2024/07/10
DCMA14ポイント ~ スケジュール構築の評価方法
2005年、アメリカ国防契約管理局(DCMA)は、国防総省が抱える膨大な量の契約とスケジュールの評価を支援するために、工程評価の14項目をDCMA 14-POINT Schedule Assessmentとして策定、公開しました。
後年、この工程評価14項目は「DCMA 14ポイント」としてプロジェクトマネジメントの現場で広範囲に使用されるガイドラインとなり、Primavera P6などのスケジュールツールにもチェック機能として実装されています。
日本では馴染みが薄く、日本語でわかりやすく解説した情報が少ないため、弊社コンサルタントによる解説を公開いたしました。
プロジェクトの種類や規模を問わず、スケジュール作成時に留意するべきポイントが示されていますので、ぜひ「DCMA14ポイント」をスケジュール構築の評価にご活用ください。
より適切なスケジュール構築のため、合わせてこちらもご参照ください。
企業としてのプロジェクト管理の仕組み作り(5) ~工程管理編~ (クリティカルパス・メソッド解説)
①ロジックの確認 (Checking the Logic)
ネットワークスケジュールのロジック(リンク)が途中で切れていないか。
もしロジックが切れていてネットワークが完全ではない場合は、クリティカルパスの妥当性が低くなる。
② リードの調査 (Looking for Leads)
負のラグは「リードタイム」と呼ばれる。
負のラグはあらゆる種類の問題を引き起こす可能性があり、また紛らわしくなりがちである。負のラグはないのが望ましい。
③ ラグの調査 (Looking for Lags)
DCMAは正のラグになると少し寛容であるが、ここではスケジュール作成におけるラグの使用を最小限に抑えることを目標にする。
ラグを持つリレーションシップを全体の5%以内とすることが目標である。
④ 正しいリレーションシップタイプ (The Right Relationship Types)
P6などのスケジューリングソフトウェアは4つのリレーションシップタイプをサポートしている。
しかしStart to Start (SS) などFinish to Start (FS) 以外を多用するスケジュール計画は最適ではなく、DCMAではスケジュールの90%以上をFinish to Start (FS) で計画するべきであるとされている。
⑤ 強制制約について (How 'bout those Hard Constraints)
強制制約はロジックに影響し、スケジュールロジックを無効にする。
DCMAでは、強制制約はすべての制約アクティビティの5%以内にすべきといている。
⑥ 総フロートの長さ (Rein-in your Total Float)
総フロートは44稼働日を限界とする。
とても長いフロートを持つアクティビティは正しくロジックが組まれていない可能性があり、クリティカルパスを崩壊させる原因となる。
⑦ 負のフロートはあってはならない (Negative Float is Never Good)
DCMAでは負のフロートはあってはならないといている。
ある場合は文書化したキャッチアップ計画が必要となる。
⑧ 所要期間の長いアクティビティは分解する (Break Down Those Long Durations)
所要期間が2ヶ月を超えるアクティビティは長すぎるとし、一連の短いアクティビティに分解する。
また、長い所要期間のアクティビティは全アクティビティの5%以内に制限する。
⑨ 無効な日付を確認する (Check for Invalid Dates)
実績の日付が計算日(Data Date)より将来にあってはならない。
逆に今後のアクティビティの予測日付(未来の日付)が計算日(Data Date)より過去にあってはならない。
Primavera P6 はこのような状態を許容しないが、どのソフトウェアで作成されたスケジュールに対してもこのチェックは適用される。
⑩ リソースとコストを山積みする(Load it up with resoures and costs)
DCMAでは、リソースとコストが山積みされたスケジュールを好む。
有効なアクティビティは全て対象とする。
⑪ アクティビティの遅れを無くす (Subvert Activity Slippage)
誰でも納期は守りたい。ここでは、ベースラインと比較して遅れて終了したアクティビティ数を確認する。
プロジェクトが時間通りに完了するかを確認するための包括的なチェックとなる。
⑫ クリティカルパスの正当性 (Critical Path Integrity)
良いロジックによる流動性を確認し、スケジュールにおけるクリティカルパスの正当性をチェックする。
DCMAでは、(クリティカルパス上のアクティビティの所要期間を極端に長くしてみるなど)スケジュールの遅れにより、プロジェクト完了日が同じように遅れるかをチェックする。
⑬ CPLI (Critical Path Length Index)
プロジェクトの「クリティカルパスの長さ」と「プロジェクト総フロート」を加算したものを「クリティカルパスの長さ」で割り、比率を計算する。
計算結果が100%になることが良く、95%未満は失格とする。
⑭ BEI (Baseline Execution Index)
ベースライン実行指数(BEI)は、「完了したアクティビティ数」を「ベースライン上で完了しているべきアクティビティ数」で割り、比率を計算する。
計算結果が100%になることが良く、95%未満は失格とする
この記事へのお問い合わせ
カテゴリ:プロジェクトマネジメント