기본 콘텐츠로 건너뛰기

공정관리의 대표적인 실패 사례 5

현장에서 공정관리자로 업무를 수행하면 공정관리 실패 사례에 대해서 직접 경험할 수 있습니다. 왜 실패했는지 살펴보겠습니다.
​
제가 다섯 번째로 말하고 싶은 것은 '공정관리자만 아는 액티비티'입니다. 공정관리자라면 다양한 공정관리 공부를 하면서 액티비티 작성에도 원칙이 있다는 것을 배웠을 것입니다. 그래서 액티비티를 만들 때 원칙을 정합니다. 예를 들어 '토목 기초작업-4구역'과 같은 방식입니다. '공종명-작업주요내용-위치명'으로 작성한 것입니다. 이렇게 체계적으로 액티비티 이름을 만들고, 이 액티비티를 이용해서 CPM 공정표를 만듭니다. CPM 공정표는 프로젝트 전체를 통합해서 운영해야 하니 담당자도 봐야 합니다. 따라서 CPM 공정표를 배포합니다. 결국 아무도 보지 않습니다. 3주 공정표, 3개월 공정표는 승인된 CPM 공정표에서 만들어야 합니다. 따라서 CPM 공정표에서 추출하여 만들어서 배포합니다. 결국 아무도 보지 않습니다. 공정회의는 승인된 공정표로 진행해야 한다고 주장합니다. 따라서 Primavera로 된 CPM 공정표를 화면에 띄우고 설명을 하지만 아무도 관심있게 보거나 듣지 않습니다. 결국 1~2주 정도 진행을 하다 CPM 공정표 발표는 없어지고 공정관리자의 발언권은 축소됩니다.
​
왜 이런 상황이 발생할까요? 공정관리를 체계적으로 진행하고 있고, 승인된 공정표를 가지고 공정관리를 운영하는데 왜 공정관리는 더욱 잘 진행되지 않을까요?
​
이런 현상을 저는 '그들만의 리그(A League Of Their Own)'라고 부릅니다. 공정관리자가 공정표를 만들 때 발생하는 현상입니다. 공정관리자가 해야 할 업무라고 생각하는 공정표를 만들었는데, 왜 더욱 공정관리가 되지 않을까요? 공정관리자는 이 사실을 잘 알아야 합니다. 프로젝트의 모든 사람들이 공정관리자에게 공정표를 만들라고 요구할 수도 있습니다. 공정관리자가 프로젝트의 모든 것을 알고 공정표를 만들어서 자신들을 이끌어 주길 원해서 만들라고 할까요? 아닙니다. 물론 Primavera를 다룰 수 없기 때문에 시키는 경우가 있습니다. CPM으로 어떻게 만들어야 하는지 모르기 때문에 시키는 경우도 있습니다. 대부분은 혹시나 해서 시키는 것입니다. 잘 만들면 본인들이 써먹고, 잘못 만들면 공정관리자가 능력이 없어서 공정표도 잘 못만든다라고 말하기 위해 시킬 수도 있습니다. 아무리 잘 만들어도 그들의 머리속에 있는 일정을 똑같이 맞출 수는 없습니다. 공정표의 핵심은 그들이 사용하는 언어(용어)로 만들어야 한다는 것입니다. 그런데 공정관리자가 혼자 만들면 그들의 언어(용어)로 만들기 어렵습니다. 격국 공정관리자가 만든 공정표는 '그들만의 리그(A League Of Their Own)'에서 사용하는 공정표가 되어 버리는 것입니다. 한국 건설업은 아직 공정관리의 초보적인 수준이라는 것을 직시해야 합니다. 공정관리자가 공정표를 만들어서 프로젝트를 이끌고 싶겠지만 지금은 조금 욕심을 내려놓아야 합니다. 공정관리자를 부하직원으로 데리고 일하는 부서 혹은 상사는 본인이 공정관리자를 데리고 공정표를 만들어서 프로젝트를 이끌고 싶겠지만 지금은 조금 욕심을 내려놓아야 합니다. 담당자 스스로 자신의 공정표를 만들도록 유도해야 합니다. 그들의 역량이 커지면 자연스럽게 공정관리가 진행될 수 있습니다.
​
이런 현상을 저는 '그들만의 리그(A League Of Their Own)'라고 부릅니다. 공정관리자가 프로젝트에 투입된 직원들과의 협업을 하지 않고, 그들이 이해하는 언어(용어), 내용으로 접근하지 않을 때 발생하는 현상입니다. 공정표의 핵심은 실제 운영해야 하는 직원들이 지속적으로 확인해야 하는 것입니다. 승인공정표(CPM공정표)는 체계적으로 만들어야 합니다. 승인공정표를 만드는 과정에서 체계적인 액티비티를 만들기로 합의를 보았다고 해서 직원들이 나중에 공정표를 확인하겠다는 의미는 아닙니다. 승인공정표를 배포할 때 충분한 설명을 다시 해야 합니다. 아니면 그들이 이해할 수 있도록 언어(용어)를 바꿔서 배포해야 한다는 것입니다. "바쁜데 언제 그걸 바꿔서 보내! 승인공정표는 스스로 보는 노력을 해야지"라고 말합니다. 맞습니다. 프로젝트 참여자라면 승인공정표를 이해하는 노력을 해야 합니다. 그러나 강요해서 해결될 문제가 아닙니다. 한국 건설업은 아직 승인공정표를 전 직원이 볼 정도로 공정관리가 성숙되지 않았습니다. 현실을 직시해야 합니다. 담당자 스스로 자신의 공정표를 만들도록 유도해야 하는 것은 당연하지만, 발주자의 승인을 받은 공정표의 일정을 스스로 확인할 수 있게 해야 합니다. 그러기 위해서는 그들이 이해할 수 있도록 공정관리자가 시간과 노력을 투자해야 한다는 것입니다.
​
이런 현상을 저는 '그들만의 리그(A League Of Their Own)'라고 부릅니다. 공정관리의 통합관리를 주장하고 시행할 때 발생하는 현상입니다. 공정관리의 통합관리는 한 두명이 할 수 있는 것이 아닙니다. 공정관리자가 훌륭하게 통합관리를 구현했다고 해서 그것이 원활하게 진행된다는 의미는 아니라는 것입니다. 직원 전체의 동의가 없는 통합관리는 그저 구호에 머물 뿐입니다. 공정표를 1개로 관리하는 것이 통합관리가 아닙니다. 승인공정표와 내부공정표가 있다는 것을 인식시키고 담당자 스스로 자신의 목표에 대한 공정표를 만들게 하는 것이 출발입니다. 내부공정표를 가지고 담당자와 협의 한 후 승인공정표를 만들어야 합니다. 승인공정표에 대해 충분한 설명을 해 줘야 합니다. 이렇게 공정관리는 지루한 과정을 거쳐야 조금 다가갈 수 있습니다. 이 과정이 귀찮다고 공정관리자 혼자 알아서 진행하면 결국 실패하게 되는 것입니다. 비용-일정을 통합하고 싶다고 해서 통합이 되는 것이 아닙니다. 통합한 후 생상된 정보를 어디에 쓸 것인지? 누가 참여할 것인지? 어떤 결과물을 만들어 낼 것인지?에 대한 내용이 충분히 논의되어야 합니다. 이런 논의 없이 막연하게 접근하면 무조건 실패하는 것입니다.
라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

[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

  "공정관리를 잘 안다고 말하면서 어떻게 PERT/CPM을 모를수있지?" ​ 가끔 발주자 혹은 감리자가 PERT/CPM 공정표를 제출하라는 요구를 한다. 이때 놀라운 일이 벌어진다. ​ 프로젝트가 진행되면 발주자도 감리자도 현장소장도 공무팀장도 시공팀장, 시공담당자도 모두가 공정관리에 대해 잘 알고 있다고 주장한다. 특히 공정관리자가 투입된 국내 현장에서는 이런 현상이 도두라지게 나타난다. 모두가 공정관리자에게 조언을 한다. "공정관리는 이렇게 하는거야. 공정표는 이렇게 만드는 거야" 이런 현장에서 'PERT/CPM 공정표를 제출하라는 요구'를 받게 되면 나서는 사람은 없다. PERT/CPM 공정표가 무엇이고 어떻게 만들고 운영하는지에 대해 조언하는 경우는 거의 찾기 어렵다. 그동안 공정관리에 대해 잘안다고 잘난척 하는 사람들은 어디에 있는지 찾기 어렵다는 것이다. ​ PERT와 CPM은 공정관리의 가장 기본 이론 중 하나다. 잘난척 하고 싶으면 공정관리에 대한 공부부터 하자. PERT는 무엇의 약자일까? 또 대답을 못한다. PERT가 어떻게 언제 만들어 졌는가는 상식의 영역이다. PERT의 역사를 몰라도 일은 할 수 있다. PERT는 Program Evaluation and Review Technique의 약자다. 따라서 대문자로 쓰는게 맞다. CPM은 Critical Path Method의 약자이다. 이름을 알았으니 내용을 알아보자. <그림1> <그림2> <그림3> <그림1>과 <그림2>, <그림3> 중 어떤것이 PERT이고 어떤것이 CPM일까? ​ <그림1>과 <그림2>, <그림3> 모두가 PERT라고 할 수도 있고, CPM이라고 할 수도 있다. 그러나 아마도 "<그림2>과 <그림3>은 PERT이고 <그림1>이 CPM이다"라도 답변할 가능성이 높아보인다. 이런...
댓글 쓰기
자세한 내용 보기

[Planning And Scheduling 지침서] 목차

 1. Planning and Scheduling(공정관리) 1.1. Planning and Scheduling(공정관리) 지침서 (이하 PnS 지침서) 1.1.1. PnS지침서 개요 1.1.2. PnS지침서의 목적 1.1.3. PnS지침서 작성 및 배포 목표 1.1.4. PnS지침서의 적용 가능성 1.1.5. PnS지침서의 개정 1.2. Planning and Scheduling(공정관리) 기본 준비 및 가정 1.3. Planning and Scheduling(공정관리) 범위 및 초점 1.4. Planning and Scheduling(공정관리)에서의 공정표 관리 1.4.1. 공정표의 종류와 이해 i. 입찰공정표 ii. 내부 목표 공정표(Target Schedule) iii. Level 1, 2, 3 공정표 iv. Baseline Schedule(관리기준공정표) v. Update Schedule(관리기준공정표 기준) vi. Revision Schedule(새로운 Baseline) vii. As-Built Schedule(완료공정표) viii. Logic-Linked As-Built Schedule ix. 최종공정표 1.4.2. 프로젝트의 공정표관리 1.4.3. 공정표관리가 필요한 이유 1.4.4. 공정표관리의 개요 1.4.5. 공정표관리의 목적 1.5. Scheduling 방법과 기법   2. CPM 공정관리의 기초, 기본 원칙 및 일반 원칙 2.1. CPM 공정관리의 기본 원리 2.2. Critical Path Method(CPM) – 출처 : PMBOK 2.3. CPM 공정관리의 일반 원칙 a) CPM 계산 사용 b) Datadate 개념 사용 c) Network Float의 소유권 d) Level 4 공정표와 Baseline의 Float 값 e) Critical Activity와 Critical Path Activity f) 준공의 지연은 Critical Path가 지연될 때 g) 준공 지연의 만회는 계획이 아니라 실적으로 판단 h) 준공의 지연...
댓글 쓰기
자세한 내용 보기