프로젝트 계획 관리에 대하여도 논의하기

Thread Content

백운범이 직접 쓴 글을 가져와서 모두와 함께 논의해 봅시다. 어제 페이스북 그룹에서 프로젝트 계획 관리에 관한 글을 봤는데, 그 안에서는 디자인, 조달, 시공, 감독 등 다양한 측면이 프로젝트 계획 관리에 미치는 영향과 함께 몇 가지 대응 전략도 제시되어 있었습니다. 언뜻 보면 꽤 말이 되는 것 같아요.하지만 자세히 분석해보면, 이것들은 사실 계획 담당자들이 계획이 예정된 시간에 이루어지지 않을 때 자주 사용하는 변명들일 뿐입니다. 많은 사람들이 계획에 대해 진행 상황, 품질, 비용이라는 삼각 관계에만 머물러 있으며, 이것이 바로 프로젝트 관리의 본질이라고 생각하며 즐겨 이야기합니다.이러한 이해는 품질, 진척도, 비용을 일방적이고 인위적으로 대립시켜, 프로젝트 관리의 표면에만 머물러 있습니다. 제 개인적인 견해로는, 좋은 계획이라면 진행 상황과 관련된 문제들을 해결할 뿐만 아니라, 품질과 진행 속도 사이의 모순도 동시에 조율할 수 있습니다. 그렇다면, 도대체 계획이란 무엇일까요? 영어에서 계획은 Plan이며, Plan은 단순히 계획이라는 뜻뿐만 아니라 방안이라는 뜻도 가집니다.즉, 계획은 단순한 일정 목록에 그쳐서는 안 되며, 반드시 방안과 통합되어야 합니다.실행 방안을 고려하지 않는 계획은 단지 종이 위의 이론에 불과한 고드바흐 추측일 뿐이다. 계획은 도대체 어떻게 수립해야 할까? 국내의 많은 교과서에서는 계획의 계층화를 강조하는데, 보통 1단계 계획을 2단계 계획으로 세분화하고, 그 다음 3단계, 4단계로 이어지는 위에서 아래로의 세분화 방식을 따릅니다.제가 말하고 싶은 것은, 이러한 계획 수립 방식은 계획 자체의 원칙과 의미에 반하는 것이며, 필연적으로 고드바흐 추측식의 계획으로 이어진다는 점입니다.왜?이유는 간단해요. 만약 1단계 계획 자체가 비현실적이라면 어떡하죠?아니면, 당신의 2단계 계획에 있는 어떤 단계 자체가 헛소리인 걸까? PMP에서는 계획 수립의 일반적인 절차가 제시되어 있습니다.계획 수립의 기초 작업은 업무 범위의 확인이며, 이는 원가 관리의 영역에 속합니다.작업 범위는 특정한 관계에 따라 계층적으로 나뉘어야 하며, 그렇게 함으로써 작업 패키지가 형성된다.명확히 해야 할 점은, 워크팩 자체에는 프로젝트 관리도 포함되어야 한다는 것입니다. 왜냐하면 각 워크팩에는 비용 관리를 위한 계정이 대응되어 있으며, 이것이 바로 비용 관리의 기초가 되기 때문입니다.작업 패키지 자체는 발주처와 작업 범위 및 프로젝트 비용을 확정하는 기초가 되어야 합니다. 워크팩을 기반으로 작업을 세분화하는 단계로, 이때가 바로 실행 계획을 구체화하는 단계입니다.이 단계에서는 각 작업 패키지에 포함된 작업들을 상세하게 분해해야 합니다.마찬가지로, 프로젝트의 규모에 따라 최종적으로 분해되는 작업의 세분화 정도는 5인시간을 초과하지 않거나 10인시간을 초과하지 않도록 할 수 있으며, 실행 계획에 따라 세분화된 작업들을 순서대로 정렬합니다. 워크팩을 분할하는 과정과 작업을 세분화하는 과정에서는 필연적으로 몇 가지 불확실한 요소들이 존재합니다.이러한 사항들은 프로젝트 리스크 등록부에 기재되어야 하며, 프로젝트 계획 수립 및 실행 과정에서 중점적으로 모니터링해야 할 대상이 됩니다. 필요한 경우에는 대체 방안도 마련해 두어야 합니다. 인력 시간 계획을 수립한 후에야, 계획 엔지니어는 본격적으로 역할을 수행하기 시작합니다. 각 작업에 필요한 인력을 집계하고, 인력 수요 계획도를 작성한 뒤, 인적 자원 공급을 최적화하기 위해 다양한 방안들을 논의합니다. 배출될 계획들을 분류하여 요약해야만 첫 번째 버전의 작업 계획을 만들 수 있습니다.이를 바탕으로 프로젝트의 핵심 단계들을 대조하여 논의하고 최적화하며, 필요한 경우 프로젝트 단계 자체를 조정합니다.마지막으로, 프로젝트의 실제 상황에 따라 계획을 최적화하고 업무 계획을 조정하여 개선된 버전 또는 최종 계획을 도출합니다. 각 방안 자체의 인건비와 자재비 등은 모두 워크팩 및 그 세부 작업 목록에 이미 반영되어 있으므로, 계획 자체에 이미 비용 관리가 포함되어 있습니다. 계획 자체에서 프로젝트 관리를 작업 패키지로 세분화했기 때문에, 프로젝트의 품질 관리도 프로젝트 계획에 포함되었으며, 관련 리소스도 할당되었습니다.자원과 비용에 대해 논의하는 과정에서 해당 방안은 이미 예비적으로 논의되고 확정되었으며, 위험도 파악되었습니다. 따라서 이 계획 수립 과정 자체가 바로 위험 관리의 과정입니다.무리하게 프로젝트 리스크를 분석하는 것이 아니라. 계획 수립 과정에서의 가정 조건 목록과 계획 수립 자체의 사고방식이 프로젝트 계획의 실현 가능성을 결정합니다.계획으로서 일단 승인되면, 프로젝트 관리자의 중점은 각 단계에서의 위험 관리로 옮겨집니다.프로젝트 실행 단계에서는 한편으로는 프로젝트 계획 수립 시의 가정 조건, 즉 위험 요소들을 철저히 관리해야 하며, 다른 한편으로는 아직 완료되지 않은 작업 단계들을 분석하여 남은 계획을 적절히 조정해야 합니다. 네, 계획은 조정될 수 있어야 하고, 반드시 조정이 가능해야 합니다.조정할 수 없는 계획은 그저 헛소리이자 자만에 불과하다.계획은 각자가 매일의 업무를 정리하는 가이드이기 때문입니다.하지만 당신의 계획이 이미 현실과 장기적으로 심각한 괴리를 보일 때, 그것이 어떻게 프로젝트의 실행을 계속 이끌어갈 수 있겠습니까?제 생각에 이건 매우 심각하지 않은 일입니다.진지하지 않은 계획이란 존엄성이 없는 계획이며, 존엄성이 없는 계획은 반드시 실패한 프로젝트로 이어진다. 외국에는 ‘Lessons learned’라는 과정이 있는데, 이는 사실상 품질 관리 PDCA의 확산과 적용입니다.이것은 계획 관리에서도 마찬가지로 적용됩니다.편차 상황을 분석함으로써, 프로젝트의 향후 실행 과정에서 주의해야 할 많은 사항들을 도출할 수 있으며, 이를 통해 프로젝트의 위험을 최소화할 수 있다. 외국인의 시각에서, 특히 미국인의 시각에서는 프로젝트란 단순히 계획을 세운 다음, 그 계획에 따라 한 단계씩 실행해 나가는 것에 불과하다.Plan을 수립하는 사람은 프로젝트의 고위급 인물이지만, 이러한 Plan들을 실행하는 사람은 그다지 높은 지능이 필요하지 않은 것 같습니다. 갑자기 뭔가 쓰고 싶어져서, 그냥 마구마구 이렇게 많이 써버렸어요.