기본 콘텐츠로 건너뛰기

실무에서의 Retained Logic과 Progress Override


실무에서는 Retained Logic Progress Override 중 어떤 것을 선택해야 할까요?

 

먼저 Retained Logic Progress Override의 차이에 대해서 알아야 합니다. 여기서는 개념적인 내용만 설명하겠습니다. 자세한 내용은 별도로 공부를 하세요.

 


  • Retained Logic을 선택하면 일정은 아래 그림과 같이 계산한다. , 후행작업의 잔여일정은 선행작업이 완료된 이후에 수행하는 것으로 계산한다.

     


    <그림 1 : Retained Logic>

     

  • Progress Override를 선택하면 일정은 아래 그림과 같이 계산한다. , 후행작업의 잔여일정은 선행작업의 영향을 받지 않고 진행되는 것으로 계산한다.

     


    <그림 2 : Progress Override>

 

계약이나 절차에 어떤 조건을 쓰라고 되어 있는 것과 상관없습니다. 왜 상관이 없는지는 뒤에서 설명하겠습니다. 이 옵션에 대해 정확하게 이해하고 필요한 옵션을 선택한 후 Schedule 실무를 진행해야 합니다. 저는 Retained Logic을 사용할 것을 권유합니다.

 

공정표는 내부공정표와 승인공정표로 구분됩니다. 내부공정표와 발주처공정표(승인공정표)가 어디 있냐고 말씀하시는 분도 있습니다. 하나의 공정표에 내부, 외부, 비용, 공정률 등 모든 것을 포함해야 한다고 주장하시는 분은 Schedule 관련 공부를 조금 더 하셨으면 합니다.

 

* 내부공정표

 

내부공정표 중 실무자들이 사용하는 공정표는 Retained Logic을 사용하세요. 그림 1 : Retained Logic과 같은 상황이 발생했고, 후행작업은 선행작업과 관계없이 계속해서 진행한다면 Schedule Option Progress Override로 바꾸는 것이 아니라, 연결된 Logic을 변경해야 하는 것입니다. 즉 공정표는 업데이트하는 과정에서 최대한 현실을 반영해야 하는 것입니다. 이것이 귀찮다면 Primavera로 관리할 필요가 없는 거에요.

내부공정표라고 하더라도 해당 공정표를 이용해서 완료일을 예상하고 싶다면 Retained Logic을 사용하세요. Retained Logic으로 인해 발생한 간격은 프로젝트의 포괄적 리스크를 조금이라도 완화해주는 효과가 있습니다. 그런데 이 상황에서 Retained Logic을 사용하는 것이 이해되지 않을 것입니다. “지금 진행되고 있는 작업을 어떻게 다음에 한다고 할 수 있냐”라고 말하는 것이죠. “공정표는 우리가 해야 할 일을 나타내 주는 것인데, Retained Logic으로 하면 해야 할 일을 엉터리로 나타내 주는 것 아니냐”고 말할 수도 있습니다. 이런 혼동은 한국 건설업에서 지금까지 진행해왔던 ‘공정관리’라고 불리는 업무와 새롭게 진행해야 하는 Schedule 업무와의 차이입니다. 지금까지는 ‘공정관리, 공정표’라고 부르면서 만든 것은 ‘작업현황’입니다. 지난주에 작업한 내용, 이번주에 작업할 내용을 글로 쓰거나, 바챠트 형태로 만들었고, 이것을 ‘공정관리’라고 생각하고, ‘공정표’라고 불렀습니다. 그래서 공정표를 보면 지난주에 작업한 내용과 이번주에 작업할 내용을 확인할 수 있었던 것입니다. 확인할 수 있어야 공정표라고 말했던 것입니다. 따라서 공정표에 지난주 작업, 이번주 작업을 정확하게 표현하기 위해서는 매주 만들어야 했고, 매주 만들어야 하는 것이 귀찮고, 시간이 많이 걸렸지만 꽤 정확하게 ‘공정관리’라는 업무를 수행할 수 있었습니다. 대신 준공(혹은 특정 작업의 완료일)은 예측하기 어려우므로 기술자의 감으로 판단하거나, 힘있는 사람이 늦었다고 말하면 만회대책을 세웠어야 했습니다. 그러나 최근 한국의 건설현장에서 가고자 하는 방향, 수행하고 싶어하는 Schedule 업무는 CPM 공정표 관리입니다. 해외에서는 대부분 사용하는 방법이라고 알고 있고, Primavera를 사용해서 CPM 이론을 적용한 공정표를 만들어 놓으면, 매주 공정표를 만들어야 했던 노력을 줄일 수 있을 것이라는 희망이 있는 것입니다. 또한 CPM 이론을 반영했으므로 준공(혹은 특정 작업의 완료일)을 예측할 수 있을 것이라는 희망도 있는 것입니다. 프로그램의 가격도 비싸고(비싼 것이니 뭔가 잘 될 것이라는 희망도 있는 것일까요?), 프로젝트 전체의 일정을 하나의 공정표에 포함해서 관리하기 때문에 지난주에 작업한 내용과 이번주에 작업할 내용도 바로 확인할 수 있을 것이라는 희망이 있는 것입니다.

Primavera를 실무에 적용해보면 이런 희망은 대부분 실천할 수 없습니다. 지난주에 작업한 내용도 확인할 수 없고, 이번주에 작업할 내용도 엉터리로 나옵니다. 준공(혹은 특정 작업의 완료일)도 예상할 수 없거나, 이해할 수 없는 예상 값이 나옵니다. 왜일까요? ‘공정관리’와 ‘Schedule’을 혼동하기 때문입니다. ‘공정표(작업현황)’과 ‘공정표(CPM)’를 동일하게 바라보기 때문입니다. 한국 건설업에서는 과거와 현재에 대해 가장 관심이 많습니다. 따라서 원하는 공정표는 CPM 공정표가 아닙니다. 지난주에 진행된 작업내용, 이번주에 진행될 작업내용을 알 수 있게 나타내는 것입니다. 1년 뒤의 미래 혹은 준공의 단축/지연에는 큰 관심이 없습니다. 이런 상황이라면 Primavera와 같은 프로그램을 활용하는 건 도움이 되지 않습니다. 그냥 표형식으로 ‘지난주 작업 현황/금주 작업 현황’을 글로 적는 것이 가장 효과적입니다. 굳이 공정표의 형태로 나타내라고 하면, 그냥 바챠트로 그리는 것이 가장 좋은 방법입니다. 그게 귀찮고, 시간이 많이 걸리고, 더 효과적인 방법을 찾고 싶겠지만, Primavera는 더 효과적인 방법이 아닙니다. Primavera의 목적은 ‘지난주 작업 현황/금주 작업 현황’을 보여주기 위한 것이 아니기 때문입니다. 물론 Primavera를 이용해서 구현할 수도 있습니다. 그러나 ‘지난주 작업 현황/금주 작업 현황’을 작성하는 것은 지금 하는 방식(표형식)으로 진행하는 것이 더 효과적입니다.

 

* 승인공정표

 

승인공정표에 어떤 옵션을 써야 하는지에 대해 설명하기 이전에 승인공정표는 여러분들이 원하는 ‘공정표(작업현황)’가 아닙니다. 여러분이 원하는 ‘지난주 작업 현황/금주 작업 계획’을 보여주지 않습니다. 승인공정표는 현재 상황에서 합리적인 준공의 단축/지연을 판단하고, 지연이 예상될 때 원인을 계약적으로 규명하는 것입니다. 계약자의 잘못으로 지연이 예상된다면 만회대책을 수립해서 조기에 만회를 해야 하고, 발주자의 잘못으로 예상된다면 공기연장에 대한 논의를 진행하든, 만회하기 위해 발생하는 비용에 대한 논의를 진행해야 하는 것입니다. 서로의 계약적인 권리를 주장하기 위한 공정표가 바로 승인공정표입니다. 한 개의 공정표를 가지고 한국 건설인들이 원하는 ‘공정표(작업현황)’도 보고, 준공의 단축/지연도 예상하고, 공기연장 클레임도 진행하고 싶겠지만, 한 개로 그런 모든 것을 구현할 수는 없습니다. 설령 할 수 있다고 하더라도 좋은 방법은 아닙니다. 오히려 분리해서 관리하는 것이 더 효과적인 경우가 많습니다. 승인공정표는 계약자/발주자의 계약적인 권리를 주장하기 위한 공정표라고 말씀드렸습니다. 이 권리에 적합한 옵션이 바로 Retained Logic입니다.

 


 

위와 같이 승인공정표가 작성되었다면, 계약자는 A 작업과 B 작업을 순서대로 진행하겠다는 의미이고, 25일간 진행하는 건 계약자의 권리입니다. 발주자가 이 두 작업을 병행해서 진행하고 싶다면 병행작업에 필요한 추가 비용을 지불해야 하는 것입니다.

 


 

계약자가 계획과는 달리 B작업을 먼저 시작했고, B작업은 연속해서 진행하더라도 위 그림과 같이 A 작업과 B 작업의 완료기간은 25일이 되어야 하는 것입니다. 만약 B 작업이 연속해서 진행되어야 한다고 생각해서 Progress Override를 사용하면 아래와 같이 진행될 것이고, 10일간의 기간이 단축되는 것 처럼 보입니다. A 작업을 병행해서 진행하든, B 작업이 완료된 후 시작하든, 전체 공기를 지연시키는 것이 아니라면 선택은 계약자의 몫이라는 것입니다.

 


 

한국 건설인들은 당장 진행되는 작업에 대해 현실적으로 반영해야 한다는 생각이 있습니다. 그래서 Progress Override가 더 적합한 방식이라고 생각하는 경우도 꽤 많습니다. 그렇다면 매 업데이트 할 때마다 로직을 현실에 맞게 새롭게 고쳐줘야 합니다.

 


 

Primavera를 이용해서 실제 Schedule 업무를 진행해 봤다면, 이런 수정이 많은 노력과 시간이 소요된다는 것을 알고 있습니다. 단지 아래 직원에게 지시만 한 경우에는 절대 알 수 없는 어려움이죠. 따라서 현실적으로 수정이 안되는 경우가 종종있고, 준공의 단축/지연을 적절하게 판단하지 못하는 경우가 발생한다는 것입니다. Progress Override를 적용하고, 해당 경로에 발주처 지연 Event가 있다면 계약자가 발주자의 지연을 단축해 주는 결과로 이어지게 된다는 것입니다. 계약자에게 공기연장의 권한이 있음에도 스스로 병행작업을 통해 단축시켜 주겠다고 말하는 것입니다.

 

CPM 공정표는 당장 진행되는 작업 현황을 보여주기 위한 공정표가 아닙니다. 계약적인 권한을 가지고 합리적인 분석을 통해 준공의 단축/지연을 판단하기 위함입니다. 이번주에 무슨 작업을 할 것인가는 ‘작업현황보고서’를 작성해서 관리하는 것이 더 효과적입니다. 하나의 공정표로 모든 것을 통합하고 싶은 욕심이 있겠지만, Schedule 관리는 그렇게 하는 것이 아닙니다. 작업현황 보고서, 바챠트 공정표를 이용해서는 당장 진행되는 현실적인 내용을 보여주는 것이 좋고, CPM 공정표는 발주자와 합리적인 준공의 단축/지연의 판단, EOT 클레임에 활용해야 하는 것입니다.

 

우한길/

댓글

이 블로그의 인기 게시물

상세공정표와 CPM 공정표

한국 건설인들이 공정관리에서 가장 혼동하는 것이 상세공정표와 CPM 공정표의 차이다. 즉, 공정관리에 대해서 잘 모르고 있다는 것이다. 한국 건설인들은 주로 시공공정표를 만들어 왔다. 시공공정표는 본인들의 진행해야 할 작업의 착수, 완료 목표를 알려주는 공정표다. 이 공정표는 선후행관계에 의해 작성되는 것이 아니라, 본인들의 목표를 바챠트로 그리면 되는 것이다. 따라서 목표만 있다면 작성은 어렵지 않았다. 그리고 세상의 중심은 자신이기 때문에 자신이 정한 목표에 대한 선행작업들은 그 목표에 맞게 진행이 되어야 했던 것이다. 선행작업이 지연된 것은 자신의 잘못이 아니라, 선행작업을 진행했어야 할 다른 직원들이 잘못인 것이었다. [그림1. 시공팀의 바챠트 공정표] 위 공정표는 분명 작성자의 의도가 숨어있을 것이다. 4월 1일에 착수해야 준공을 준수할 수 있다는 경험치가 반영되어 있을 것이다. 그런데 믿도 끝도 없이 이렇게 작성해 놓으면 되는 것일까? 터파기를 착수하려면 인허가, 하청사 선정, 장비 및 인원 동원, 시공계획서 작성 및 승인 등이 되어야 할 것인데, 이 공정표를 작성한 시공담당자는 그런 일 들은 본인의 업무가 아닐 것이다. 인허가는 발주자가, 하청사 선정은 공무가, 장비 및 인원 동원은 하청사가, 시공계획서는 아래 직원이 당연히 완료해 놓아야 한다는 신념이 있을 것이다. 그 중 하나가 지연된다면 해당 담당자가 잘못한 것이지, 본인이 잘못한 것이 아니라는 믿음도 있을 것이다. [그림2. 시공팀의 상세공정표] 시공담당자는 이런 상세공정표를 만들기도 한다. 위 공정표의 숨은 의도는 아래와 같을 것이다. [그림3. 시공팀의 의도] 위 그림과 같이 철근의 작업조 기준으로 진행될 것을 긍정적으로 예상하고 만든 공정표 일 것이다. 시공계획에서는 이런 식으로 만들 수 있고, 시공팀의 목표로 진행하는 것에 대해서 반대할 이유는 없다. 그러나 위 공정표를 CPM으로 구성한다면 아래와 같이 만드는 것이 좋다. [그림4. 시공팀의 의도와는 다른 CPM

[PK] 공정표의 활용

PMBOK 제6판 '그림 6-21. 프로젝트 일정도표 - 예'를 이용해서 공정표를 한 번 만들어 보자. 1. WBS/WBS Level 1 (프로젝트) : 신제품 Z 개발사업 WBS Level 2 (패키지) :   - 제품 개발 및 인도   - 작업패키지 1   - 작업패키지 2   - 작업패키지 3 2. Activity List PMBOK에서는 아래와 같은 예를 보여주고 있다. PMBOK 제6판 219페이지 * 위 그림에서 마지막 4번째 줄과 5번째 줄은 액티비티 이름이 바뀌었다. '1.1.3.T 구성요소 1과 2 통합완료'와 '1.1.3.M1 통합구성요서를 제품 Z로 테스트'가 서로 이름이 바뀌었다. Primavera로 구현한 내용은 아래와 같다. 여기서 일정도를 표시하기 위해 PMBOK는 실적을 반영한 모습을 보여주고 있다. 공정표는 위와 같이 항상 마일스톤과 요약된 내용을 확인할 수 있어야 한다. 이것을 공정관리(공정표 관리)의 기본이다. 프로젝트의 공정표를 만들 때 액티비티를 늘리는 것은 좋지 않다. 아무리 복잡한 프로젝트라 하더라도 최대 3,000개를 넘지 않는 것이 좋다. 프로그램이 있다 하더라도 실적을 입력해야 하는 건 1명의 사람이다. 사람은 물리적인 시간에 구속을 받게 되어 있다. 또한 단순 반복 작업은 오래할 수 없는 특성도 있다. 3,000개의 액티비티의 움직임을 확인하는 것도 현실적으로 쉽지 않다. 그런데 그 이상이라면? 그것은 공정표를 보지 않겠다는 의미와 같다는 것이다. "난 1만개, 2만개도 관리해 봤어"라고 말하는 건 자랑이 아니라, 본인 스스로 공정표를 효과적으로 관리해 보지 않았다는 증거를 떠들고 있는 것이다. 아무리 액티비티를 줄이려고 해도 한계는 있다. 3,000개의 액티비티를 하나씩 확인하면서 공정관리를 진행한다는 것은 매우 어렵다.

[용어] PERT/CPM

공정관리에 대한 간단한 역사와 정의에 대해서 아는 것은 매우 중요합니다 . 중고등학교 교육처럼 역사와 년도 등을 외울 필요는 없습니다 . 그러나 간단하게 알고 있어야 합니다 . ​ ​1. Pert (Program Evaluation and Review Technique) ​​1958 년 미해군이 폴라리스잠수함용 미사일의 개발을 관리하기 위해서 부즈알렌앤드해밀턴사가 개발했다고 합니다 . 제가 공부했던 교재에 나와 있던 내용입니다 . ​​PERT 는 액티비티의 작업시간 ( 기간 ) 을 추정하기 위한 기법이라고 이해하세요 . 작업시간 , 즉 Original Duration 은 3 가지로 정리할 수 있습니다 . 낙관치 (a), 정상치 (m), 비관치 (b). 이 세가지 값을 이용해서 아래와 같은 수식에 의해 기대시간 (Original Duration) 을 산정하는 방식이 바로 PERT 기법입니다 . ​ * PMBOK 5 판까지 ​ 기대시간 (Original Duration) = ( a + 4m + b) / 6 ​* PMBOK 6 판 ​ 기대시간 (Original Duration) = ( a + m + b) / 3 ​ ​2. CPM (Critical Path Method) ​​1956 년 Dupont 사와 Remington 사가 Plant 의 설계 및 건설을 위해 공동개발했다고 합니다 . 제가 공부했던 교재에 나와 있던 내용입니다 . ​​ 확정된 공기 (Original Duration) 을 이용해서 작업간의 연관관계를 연결해주고 , 이 연관관계를 전진계산 , 후진계산을 통해 전체여유 (Total Float) 을 계산하는 방식입니다 . 여기서 계산된 전체여유 (Total Float) 이 0 보다 작은 경우를 Critical Path 라고 합니다 . ​ 3. PERT/CPM ​​ 즉 , 공기산정은 PERT 기법을 통해서 , 연관관계를 통한 Critical Path 는 CPM 방식을 통해서 하기 때문에 이 두가지를 합쳐서 PERT/CPM 이라고 부르는