기본 콘텐츠로 건너뛰기

우리가 지금 잘하고 있구나

'우리가 지금 잘하고 있나?'라는 의문이 듭니다. 이 생각은 경험의 많고 적음과 크게 관계가 없고, 직급의 높고 낮음과 크게 관계가 없습니다.

이런 생각이 들지 않는 경우는 시키는 일을 무비판적으로 수행하고 있을 가능성이 높습니다.

​

이런 생각은 '우리가 지금 잘하고 있구나'라는 생각으로 바뀌어야 합니다. 이건 쉽지 않습니다. 혼자 잘 한다고 생각하는 것으로 끝이 아니기 때문입니다.

​

스스로도 잘 해야 하지만, 함께 일하는 타부서직원들도 바른 방향으로 갈 수 있어야 합니다. 타부서 직원들의 의견을 경청하고 수렴해야 하지만, 옳다고 생각하는 방향이 있다면 타부서 직원들(설계, 시공 직원들)을 이끌 수 있어야 합니다.

​

많은 경우 공정관리자가 설계, 시공 이야기로 타부서 직원들과 소통하려고 합니다. 결국 타부서 직원들의 의견에 휘둘리는 방향으로 진행됩니다.

공정관리자는 공정관리에 대한 이야기를 해야 합니다. 왜 공정관리가 필요한지, 공정관리를 진행하기 위해서는 어떤 내용이 들어가야 하는지에 대해 이야기 해야 합니다. CPM 이론을 적용하기 위해서는 설계, 시공팀에서 단순한 작업 내용이 아니라, 액티비티와 기간, 로직이 필요하다는 것을 설명해야 합니다. 그런 정보를 주면, 어떤 피드백을 줄 수 있는지에 대해 설명해야 합니다. 예를 들어 발주처 지연 요인을 명확하게 액티비티로 만들고, 기간을 넣고, 로직을 다른 액티비티와 FS, SS, FF로 연결을 해야 발주처 지연에 의한 준공일 변화를 예상할 수 있다는 것을 알려줘야 합니다. 막연하게 '용지보상이 지연되었다'라는 정보만 가지고는 준공을 분석할 수 없다는 것을 보여줘야 하는 것입니다.

​

시공 위주의 공정관리를 진행했던 많은 건설인들은 처음에는 잘 이해하지 못합니다. 용지보상이 3개월 지연되었다면, 준공도 3개월 지연될 것이라는 막연한 희망이 있습니다. 그런데 본인들이 작성하여 제출한 공정표에 용지보상을 넣고, 준공을 분석하면 준공에 영향이 없는 경우를 보여줘야 하는 것입니다. 승인공정표를 가지고 분석할 때 CP에 해당될 때만 지연된다는 사실을 알려줘야 한다는 것입니다. 발주처의 지연요인이 Total Float이 많은 액티비티에 영향을 준다면, 준공의 지연은 예측되지 않습니다. 발주처의 지연요인이 특정 액티비티에 연결하기 어려운 상황이라면, 준공의 지연은 예측되지 않습니다.

​

설계, 시공팀의 의견을 공정표에 직접 반영하고, 그들의 생각과 공정관리 기법과의 차이를 보여줘야 합니다. 막연한 생각으로는 공정관리를 수행할 수 없다는 것을 보여줘야 하는 것입니다. 그래서 그들이 이해하고 따라온다면 '우리가 일을 잘하고 있구나'라고 생각할 수 있습니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

[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개의 액티비티를 하나씩 확인하면서 공정관리를 진행한다는 것은 매우 어렵다....
댓글 쓰기
자세한 내용 보기

상세공정표와 CPM 공정표

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

공정관리와 Fragnet

Fragnet? 사전에도 나오지 않는 이 단어는 무슨 의미일까요? 이 단어를 처음 본 것은 P3(Primavera Project Planner)를 사용할 때 였습니다. P3의 Fragnet 잘 사용하는 기능이 아니었기 때문에 기능이 있다는 것은 알았지만 Fragnet이라는 단어는 기억 깊은 한 구석에 있는 단어일 뿐이었습니다. 그런데 최근 EOT 클레임에서 종종 사용되는 단어로 부각되고 있습니다. 그렇다면 P3의 Fragnet은 어떤 기능이었을까요? 반복적인 일정이 있다면 Fragnet으로 저장해 놓고 꺼내 쓰는 기능이었습니다. 예를 들어 A-B-C가 FS로 연결되어 있고, 종종 사용한다면 Fragnet으로 저장해놓고, 사용이 필요할 때 불러오면 됩니다. P6에서는 Copy, Paste로 할 수 있어서인지 Fragnet 기능이 사라졌습니다. 이런 기능이라는 것을 이해하고, Fragnet이라는 단어의 의미를 유추해보면 '단위 일정' 혹은 '단위 공정표'라는 것을 알 수 있습니다. 그래서인지 EOT 클레임에서도 Sub-Network과 Fragnet을 혼용해서 사용하고 있습니다. 최근 EOT 클레임이 부각되면서 Fragnet이 다시 사용되기 시작했습니다. 해외에서는 계속 써왔는데, 국내에서 EOT 클레임이 부각되면서 쓰기 시작했을 수도 있고요. 어쨌든 Fragnet은 특정한 사건이 발생했을 때에 대한 단위공정표라고 이해하시면 됩니다. 승인공정표는 관리 가능한 수준에서 액티비티를 만들게 됩니다. 무조건 상세하게 만드는 것이 아닙니다. 따라서 '발주자 지연 요인'이 발생했을 때 승인공정표로는 상세한 설명이 어렵고, 증명할 자료로 사용하기에 불충분 할 수 있습니다. 이런 상황이 발생했을 때 상세한 설명을 하기 위한 공정표가 바로 Sub-Network(Fragnet이라고도 불림)을 만들어서 설명을 하는 것입니다. 만들었다면 업데이트할 때 승인공정표에 포함하여 발주자에 공기연장에 대한 증거서류로 제출해야 합니다....
댓글 쓰기
자세한 내용 보기