87. CPM(Critical Path Method)
성공적인 소프트웨어 신상품 개발가이드
CPM은 많은 작업들의 수행순서가 복잡하게 얽혀 있는 프로젝트의 일정을 계산하는 알고리즘으로 프로젝트 관리의 대표적인 기법이다.
1) Critical Path(주공정)의 기본개념과 계산방법
다섯 가지 작업으로 구성된 프로젝트가 있고 작업 수행순서와 각 작업의 수행기간(일)이 그림 *과 같다고 가정하자.
휴일을 고려하지 않은 전체 프로젝트 수행기간이 14일임은 쉽게 알 수 있다. 주공정이란 ‘특정작업이 지연될 경우 전체 프로젝트 수행기간이 지연되는 작업의 연결’이다. 위의 예에서 주공정은 ‘A→ B→ C→ E’이다. 주공정을 식별하고 관리하는 목적은 프로젝트 완료일을 준수하기 위해 집중할 작업을 식별하고 관리하기 위함이다.
특히 건설 프로젝트는 지연되면 페널티 또는 기회비용이 발생하기 때문에 주공정 관리가 중요하다. 소프트웨어 개발은 주공정 관리의 필요성이 상대적으로 낮지만 기본개념은 숙지할 필요가 있다. 주공정을 계산하기 위해 ‘프로젝트 계획 수립’의 예를 들어보자. PMBOK에서는 프로젝트 관리계획서 개발을 위해 아래 그림과 같이 총 10개의 작업을 제시하고 있다. 실제로는 더 많은 활동이 있지만, 프로젝트 계획을 수립하기 위해서 그림에 있는 활동만 수행한다고 가정할 때 프로젝트 계획수립을 몇 일 만에 할 수 있을까? 이 그림에서는 비교적 간단하지만, 활동의 수가 많거나 연관관계가 복잡하면 정답을 구하기가 어렵다. 물론 프로젝트 일정관리 도구가 계산해주기 때문에 일일이 계산할 필요는 없다. 하지만 프로젝트 전체 수행기간을 어떻게 도출하는지 기본규칙은 알고 있어야 한다.
주공정을 계산하기 위해서는 전진계산을 통해 달성 가능한 일정을 계산하고, 후진계산을 통해 달성해야 하는 일정을 계산한다.
- 전진계산과 후진계산
전진계산(forward scheduling)은 그림 *와 같이 각 작업의 빠른 착수일(Early Start, ES)과 빠른 종료일(Early Finish, EF)을 계산하여 달성 가능한 가장 빠른 종료일을 도출한다.
후진계산은 역으로 각 작업이 최대한 늦게 끝날 수 있는 종료일(Late Finish, LF)과 최대한 늦게 착수할 수 있는 착수일(Late Start, LS)을 계산한다. 아래 그림에서는 프로젝트관리 계획서 개발이 늦어도 29일에는 끝나야 한다고 가정하였다. 최대한 빨리 끝낼 수 있는 일정은 상품개발팀이 제시하고, 늦게 끝낼 수 있는 최대한의 일정은 경영층이 제시한다. 만일 아래 그림에서 아무리 늦어도 25일에 끝내야 한다면 끝낼 수 있는 일정은 29일이기 때문에 4일의 갭이 발생한다.
전진계산을 통해 끝낼 수 있는 일정을 계산하고 후진계산을 통해 끝내야 하는 일정과의 갭을 구하면 그것이 플롯(Float)이 된다. 위의 예에서는 끝낼 수 있는 완료일과 끝내야 하는 완료일을 동일한 29일로 가정했다. 따라서 전체 프로젝트 기간의 갭은 없고 주공정은 플롯이 ‘0’인 작업들의 연결이 된다.
플롯은 프로젝트 납기에 영향을 주지 않고 해당 작업이 가지는 여유시간이다. 플롯은 ‘LS – ES’ 혹은 ‘LF – EF’로 계산해서 구한다. 주공정은 플롯이 ‘0’인 작업을 연결한 경로다. 주공정상의 작업은 ‘플롯 = 0(또는 음수)’이기 때문에 작업이 지연되면 프로젝트 전체 종료일이 지연된다. 위 그림에서 색깔 있는 굵은 선이 주공정이며 나머지 선은 non-critical path이다. Non-critical path의 작업은 정의에 의해 ‘플롯 › 0’이므로 전체 프로젝트 기간을 지연시키지 않고 가지는 여유시간을 가진다.
흔히 PERT/CPM으로 붙여서 이야기하는데 두 가지 개념은 다르다. CPM은 위에서 설명하였고, PERT(Program Evaluation and Review Technique)는 3점 추정에서 설명하였다. PERT는 3점 추정과 동일하다고 생각해도 무방하다. 즉, 개별작업의 수행기간은 PERT를 활용하여 주청하고 전체 프로젝트 수행기간은 CPM을 활용하여 계산한다.
참고로 PERT는 1958년 미 해군이 폴라리스 잠수함용 미사일의 개발을 관리하기 위해서 부즈알렌&해밀턴사가 개발했고, CPM은 1956년 Dupont사와 Remington사가 Plant의 설계 및 건설을 위해 공동 개발했다.
2) CPM적용시 유의사항
소프트웨어 개발의 경우 주공정을 효과적으로 사용하는 프로젝트는 보기 드물다. 몇 가지 이유를 살펴보면 다음과 같다.
- 모든 활동이 주공정처럼 느껴진다
프로젝트를 관리해본 프로젝트 관리자라면 “지연되어도 되는 작업이 있는가?”라는 반문에 쉽게 답하기 힘들다. 왜일까? 그것은 프로젝트에 투입된 모든 자원들이 적어도 외형상으로는 프로젝트 활동에 투입되어 있기 때문에, 특정 활동이 지연되면 그 활동 담당자가 수행해야 할 다른 활동의 착수가 지연되기 때문이다. 주공정 관리의 핵심이 중점적으로 관리해야 하는 활동을 선별하는 것인데, 모든 활동이 중요해지면 주공정 관리의 의미가 없어진다.
- 주공정 도출 시 가정한 자원과 실제로 투입되는 자원의 역량과 투입시점이 다르다
투입자원의 역량은 작업기간에 영향을 주기 때문에 주공정 도출에 영향을 미친다. 상품개발의 초기단계에서 프로젝트에 투입되는 자원이 확정되지 않으면, 일정계획을 수립하는 사람이 가정한 자원의 역량에 따라 주공정을 도출한다. 그러나 프로젝트를 진행하면서 실제 투입되는 자원의 역량이 기대보다 낮다면 주공정이 바뀔 수 있다. 또한 약속했던 자원의 투입시기가 늦어져도 전체 일정이 변경되어 주공정을 지속적으로 갱신, 관리하기 힘들어진다.
- WBS가 자주 변경된다
신상품 개발 시 WBS가 추가, 변경, 삭제가 지속되면 주공정 변경을 관리하기 힘들다. 상세한 관리는 효과보다 비용이 많아진다.
그렇다면 현실에서 CPM은 어떻게 활용해야 할까? CPM은 최초 ‘할 수 있는 일정’을 도출할 때 의미가 있다. 따라서 처음부터 ‘해야 하는 일정’에 맞춘 일정계획에서는 CPM이 필요 없다. 필자는 주공정을 상황에 맞게 활용하길 권고한다. 현실에서 적용 가능한 CPM 활용법은 다음과 같다
- 프로젝트 관리 도구를 사용한다
CPM을 수작업으로 계산하는 것은 거의 불가능하다. 따라서 주공정 관리 기능이 있는 도구가 있을 때만 CPM을 분석해야 한다.
- 할 수 있는 일정과 해야 하는 일정의 갭을 도출한다
할 수 있는 일정과 해야 하는 일정의 갭을 도출해야 한다. 해야 하는 일정계획을 수립해야 하는 상황에서도 할 수 있는 일정과 해야 하는 일정이 어느 정도 차이가 있는지를 파악하고 예산이나 범위와 같은 프로젝트 제약조건을 조정해야 한다.
- 대규모의 복잡한 프로젝트에서 모든 작업에 대해 CPM 적용이 복잡하고 어렵다면 하위 팀에 유연성을 부여한다.
대규모의 복잡한 프로젝트에서는 CPM 관리가 힘들거나 실제와 차이가 많을 수 있다. 프로젝트 하위 팀들이 도구에서 제시하는 작업순서 또는 일정과 다르게 진행하고 있다고 판단되면, 하위 팀에 일정관리를 맡기고 전체 프로젝트 차원에서는 상위 수준의 실적만 파악하는 것도 고려해야 한다. 현실에 맞지 않는 복잡하고 상세한 수준의 CPM 일정표를 팀원에게 강요하고 업데이트를 요청할 때, 거짓 일정이 생겨날 수 있다.
필자는 필요한 상황에 필요한 만큼 도구를 사용하는 것이 상품개발팀에게 도움을 준다고 생각한다. 현장에서 어떻게 일정계획을 수립하는가에 대한 어느 프로젝트 관리자의 이야기를 읽어보기 바란다.
현재 프로젝트를 수행중입니다. 공교롭게도 다음 주부터 개발에 들어갑니다. 지금 하고 있는 작업이 400여 개의 프로그램에 개발자를 배정하는 작업입니다. 일정이 아주 짧기 때문에 주공정을 적용해야 하는 상황이지요.하지만, 일반적인 예에서 보는 것처럼 항목과 조건이 단순하지 않다는 게 애로사항입니다. 1개의 프로그램을 개발하는 데 소요되는 일정은 프로그램의 성격, 난이도에 따라 천차만별이며, 이를 개발하는 개발자의 생산성 역시 천차만별입니다. 두 가지 요소를 고려해서 주공정을 적용하다가는, 계산하다가 개발기간이 끝나버릴지도 모르겠네요
https://brunch.co.kr/@kbhpmp/160
