Delay Analysisの手法③ Time Impact method~これからプロジェクトマネージャーになる人のためのDelay Analysisの基礎知識⑰~

      2020/01/21

前回は、As planned impact methodについて解説しました。

 

As planned impact methodは、オリジナルの工程表に、遅れを生じさせる事象による影響を入れ込んでいくことで完成予定日、つまり納期がどれだけ後ろにズレていくのかをみる手法でした。

 

この手法は、オリジナルの工程表があればできるので、簡単です。おそらく、費用もさほどかからないでしょう。

 

しかし、重大な欠陥をもっている手法でもあります。その欠陥とは、「現実の仕事の進捗を把握しきれていない」ということです。

 

この手法によれば、遅れを生じさせる事象が生じる前に、コントラクターがオリジナルの工程表にあるよりも、早く仕事を進めることができている場合でも、あくまで使うのはオリジナルの工程表になります。

 

そのため、遅れを生じさせる事象が生じた時点で、実際にはcritical pathになっていない工程上の仕事に遅れが出ているに過ぎないのに、その事象の影響を受けた仕事がcritical path上のものであると決めつけて完了予定日をずらしていくということで納期延長期間を算定することになります。

 

これでは、正しく遅れを分析したとはいえません。

 

この欠点を補う手法が、Time Impact methodです。

 

この手法も、始まりはオリジナルの工程表、つまり、as planned programです。しかし、これを、遅れを生じさせる事象が発生したら、その直前までの現実の進捗状況を反映したものにアップデート(更新)します。

 

その上で、遅れを生じさせる事象(Owner’s Risk Event)の影響を入れ込んでいくのです。以下は、Time Impact mehodをイメージ化したものです。

例えば、仕事開始1カ月後に遅れを生じさせる事象として、Force Majeureが生じたとしましょう。これが仕事2に影響を及ぼし、本来であれば、5日で出来る仕事を10日かかるように遅らせるものだったとします。

 

このときのDelay Analysisは、まず、as planned programを仕事開始1カ月後までの現実の進捗状況を表すように修正・更新します。例えば、予定よりも仕事が早く済んでいる、または、コントラクターのせいで遅れが生じている、そういった、工程に影響が出る要素を入れ込み、最新の状況を表すようなプログラムを作成します。これは、updated programと呼ばれます。このupdated programは、遅れを生じさせる事象の発生直前までは実際の進捗を示す工程で、それ以降は予想・計画としての工程で構成されることになります(as planed programが、その全てが計画としての工程であることとの違いに注意しましょう)。以下にプログラムを示します(水色のバーがcritical path、赤色のバーがnon-critical pathです)。

このUpdated programができたら、そこに、as planned impact methodで行ったのと同じように、Force Majeureの影響を受けた仕事2の部分(Sub-net)を入れ込みます。

すると、仕事2以降に予定されている様々な仕事の始期と終期が次々とズレていきます。最後には、完了予定日がズレます。これが、Force Majeureの影響によって予想される新しい完了予定日となります。

 

このとき出てきた完了予定日と、updated programに示されている完了予定日を比較します。

 

この差が、このForce Majeureによってコントラクターが得られる納期延長日数となります。

 

上記を実施するために、as planned programはもちろんですが、実際の進捗状況を示すデータが必要です。つまり、どの仕事がどのように進んでいるのかを示す記録です。これがないと、いざ遅れを生じさせる事象が生じた場合に、プログラムをアップデートすることができません。

 

しかし、それがきちんと保存されていれば、この手法を用いることができます。そしてこれば、as planned impactの欠点を見事に補うものです。

 

この手法であれば、アップデートプログラムを見て、critical pathがオリジナルのものから変化していることもわかります。そうすれば、最初はcritical path上の工程に影響を及ぼす事象が生じていたのかと思っていたが、アップデートプログラムを見ると、実はそうではなかった、つまり、今回生じた事象によってはコントラクターに納期延長が与えられる必要はないことが明らかになることもあるでしょう。

 

つまり、オーナーから、「これは正しい結果を示していない!」と反論される可能性を減らすことができます。

 

実際、英国プロトコルでは、このTime Impact methodを用いてDelay Analysisを行うように推奨しています。

 

・・・しかし、この手法にも欠陥があります。いや、欠陥というよりも、実現するために不都合と言った方がよいかもしれません。

 

それは、異様に手間がかかる、というものです。

 

遅れを生じさせる事象が1つの場合には、おそらくできます。しかし、これが次々と生じたら、その都度プログラムを現実の進捗状況を表すように毎回アップデートしていくことは、かなりの労力となるでしょう。

 

「ちゃんとやればよいだけ」とも思えますが、作業現場でこのような管理をするのは、おそらく、現実的には難しい。

 

というわけで、今度は、手法としては正しいが、手間がかかる、という欠点がある、ということになりました。

 

この欠点をある程度補うものとして考えられているものがあります。

 

それは、Windows methodと呼ばれるものです。

 

次回は、このWindows methodについて解説します。

【Delay Analysisの解説の目次】

DelayとDisruptionの違い 納期延長に伴って生じる費用(prolongation cost)について その③ 本社経費と逸失利益における因果関係と金額の立証方法
クリティカル・パス その① 納期延長クレームと追加費用クレームの関係
クリティカル・パス その② mitigationとacceleration

補足~constructive acceleration

フロートとは何か? Delay(遅れ)の種類(様々なDelay)
フロートは誰のものか? Delay Analysisの手法①~はじめに+Delay Analysisを行う時期~
フロートは誰のものか?契約書に記載がない場合 Delay Analysisの手法②~As planned impact method~
同時遅延の扱い その① 納期延長について Delay Analysisの手法③~Time Impact method~
同時遅延の扱い その② 追加費用について Delay Analysisの手法④~補足 工程表(プログラム)は契約書の一部なのか?~
納期延長に伴って生じる費用(prolongation cost)について その① Delay Analysisの手法⑤~Windows method~
納期延長に伴って生じる費用(prolongation cost)について その② 本社経費と逸失利益 Delay Analysisの手法⑥~as planned impact/Time Impact/Windowsの比較
21 Delay Analysisの手法⑦~EPC契約における工事の進捗状況のデータの取得・保管義務の定め~
22

必要な立証の程度~balance of probabilities~

 - Delay Analysisの基礎知識