프로젝트 일정계획수립의 네 가지 모델
프로젝트 특성을 고려한 일정계획 모델을 적용해야 합니다.
프로젝트 일정계획은 ‘어떤 작업을, 누가, 언제부터 언제까지 수행할 것인가’에 대한 정보를 포함하고 있습니다. 간단해 보이는 일정표이지만 작성하는 과정은 쉽지 않습니다. 프로젝트 특성과 상황, 팀원의 역량을 고려한 일정계획 수립 모델을 선택해야 일정계획 수립에 투입되는 낭비를 최소화하고 일정의 달성가능성도 높아집니다. 일정계획 수립 시 적용가능한 모델은 CPM, CCPM, 스크럼, 칸반으로 구분할 수 있습니다. 아래 내용을 중심으로 일정계획 모델의 개요를 살펴보겠습니다.
• 일정계획 수립 모델의 유형은?
• 일정계획 수립 모델의 공통점은 무엇인가?
• 일정모델을 적용할 때 유의할 사항은?
• 각 일정 모델을 적용하기 적합한 업무는?
1) 일정계획 수립 모델의 유형
프로젝트 일정계획을 수립하는 모델은 프로젝트 관리 방법론에 따라 달라집니다. 폭포수 방법론을 적용하는 일정계획 모델에는 CPM(Critical Path Method)과 CCPM(Critical Chain Path Method)이 있고, 애자일 방법론을 적용하는 일정계획 모델에는 스크럼과 칸반이 있습니다. 폭포수 방법론은 전체 업무를 한꺼번에 수행하기 때문에 프로젝트 착수시점에 전체 업무의 일정계획을 수립하고, 애자일 방법론은 업무를 나누어 수행하기 때문에 해당업무를 수행하는 시점에 일정계획을 수립합니다. 폭포수 방법론과 애자일 방법론의 차이는 다음을 참조하시기 바랍니다.
https://brunch.co.kr/@kbhpmp/81
폭포수 방법론은 전체 업무를 대상으로 일정계획을 수립하기 때문에 지연되어도 일정에 차질이 없는 액티비티와 지연되는 만큼 일정이 지연되는 액티비티를 구분하는 것이 중요합니다. 일정지연의 여유가 없는 액티비티의 연결을 주경로(critical path)라고 합니다. CPM과 CCPM모두 주경로를 도출하지만 CCPM은 개별 액티비티의 버퍼를 프로젝트 차원의 버퍼로 통합하여 일정 리스크를 관리합니다. CPM에서는 개별 액티비티에 버퍼를 부여하는 것을 통제하지 않기 때문에 개별 액티비티의 달성 가능성이 80 ~ 90%인 상태로 추정합니다. 그러나 CCPM에서는 개별 액티비티의 달성 가능성이 50%로 추정할 것을 권고합니다. CCPM의 내용은 이론적으로는 설득력이 높지만 실제 적용은 어렵기 때문에 현실에서 활용도는 낮습니다. CPM과 CCPM에 대해서는 아래를 참조하시기 바랍니다.
https://brunch.co.kr/@kbhpmp/91
https://brunch.co.kr/@kbhpmp/185
폭포수 방법론이 프로젝트 종료시점에 모든 결과물을 한꺼번에 제공한다면 애자일 방법론은 요구사항의 우선순위에 따라 프로젝트 진행도중에 결과물을 나누어 제공합니다. 스크럼은 제한된 스프린트 기간(보통 1~4주) 동안 구현가능한 요구사항을 도출하여 일정계획을 수립하는 반면, 칸반은 스프린트 기간을 제한하는 것이 아니라 동시에 수행가능한 작업수를 제한하기 때문에 특정 작업을 완료한 뒤에 백로그 중에서 프로젝트 팀이 수행할 다음 작업을 선택합니다. 칸반의 일정관리에 대해서는 다음을 참조하시기 바랍니다.
https://brunch.co.kr/@kbhpmp/134
이상 설명한 네 가지 일정계획 모델을 요약하면 다음과 같습니다.
그림. 일정계획수립의 모델
2) 일정계획 수립의 공통점
일정계획 수립을 위한 모델의 유형에 상관없이 모든 일정표는 공통적으로 무엇을, 언제부터 언제까지 수행할지 결정해야 하며 그 과정의 공통점은 다음과 같습니다.
일정계획 수립 모델의 공통점① 일정계획의 수립대상이 되는 작업 또는 결과물을 정의해야 합니다.
일정계획을 수립하기 위해서는 일정계획을 수립할 대상을 정의해야 하고 이를 WBS(Work Breakdown Structure, 작업분할구조)라고 합니다. WBS의 Work은 결과물(예:빌딩, 앱)을 만들기 위한 작업을 의미합니다. 앱 개발을 위해 요구사항을 분석하고, 설계하고, 코딩하고, 테스트하는 활동이 소프트웨어 개발 프로젝트의 대표적인 작업입니다. 그렇지만 잘게 쪼갠 프로젝트 결과물을 작업으로 관리할 수도 있습니다. 예를 들어 ’00 사용자 스토리 개발’전체가 2주 정도에 끝난다면 분석, 화면설계, 개발, 테스트로 분할하여 일정계획을 수립하고 관리하는 것이 낭비일 수 있습니다. 이런 경우에는 쪼개어진 결과물을 하나의 작업처럼 관리하는 것이 효율적입니다. WBS를 어떤 수준까지 상세화 할 것인지는 분할의 장점과 단점을 고려하여 결정해야 합니다.
WBS는 프로젝트 관리를 위한 출발점인데 그 이유는 WBS를 정의해야 프로젝트 팀원이 수행할 작업을 분배하고 이해관계자들이 일정을 공유할 수 있기 때문입니다.
WBS에 대한 자세한 내용은 다음을 참조하시기 바랍니다.
https://brunch.co.kr/@kbhpmp/89
② 작업수행을 위해 필요한 기간을 추정합니다.
작업의 착수일과 종료일을 결정하기 위해서는 작업의 수행기간을 추정해야 하고, 작업의 수행기간을 추정하기 위해서는 작업의 크기와 작업을 수행하는 사람의 생산성을 파악해야 합니다. 폭포수 방법론에서는 작업을 수행하는 사람을 결정하지도 않거나 업무를 상세하게 파악하기도 전에 작업기간을 추정하기도 합니다. 이론적으로는 ‘작업 수행기간 = 작업의 크기/작업을 수행하는 사람의 생산성’이지만 작업의 크기와 생산성을 정량적으로 계산하기 힘들기 때문에 작업기간을 직관적으로 추정하는 경우가 대부분입니다. 그나마 작업을 수행할 사람이 직접 작업기간을 추정하면 다행입니다.
③ 작업을 수행할 착수일과 종료일을 결정합니다.
작업의 착수일은 선행작업의 완료일이 결정합니다. 경우에 따라 특정 작업을 수행하기 위해서는 N개의 작업이 완료되어야 할 수도 있습니다. 예를 들어 통합 테스트를 시작하기 위해서는 개발, 통합 테스트 시나리오, 통합테스트 계획 등이 완료되어야 합니다. MS Project와 같은 프로젝트 일정관리 툴을 사용하면 작업 간의 선후관계를 지정해야 하지만, 대부분의 프로젝트는 작업 간의 선후관계를 명시하지 않고 직관적으로 연관된 작업을 검토하여 작업의 착수일을 결정합니다. 이럴 경우 특정 작업이 지연될 경우 영향을 받는 후행작업을 놓치기 쉽습니다.
작업의 착수일을 결정하면 완료일은 ‘착수일 + 작업 수행기간’으로 계산하면 됩니다.
3) 일정계획 모델을 적용할 때 유의사항
- 잘 모르는 업무를 상세하게 정의해서는 안됩니다.
대부분의 사람들은 1~2개월 이내의 업무는 어느 정도 상세하게 정의할 수 있지만 3개월 이후의 업무는 상세하게 정의하기 힘듭니다. 설계가 끝나기 전에 개발할 프로그램 목록을 알 수 없는 것이 대표적입니다. 그러나 잘 모르는 업무를 형식에 맞추어 억지로 상세하게 정의하면 우스꽝스러운 계획이 됩니다. 이런 계획을 수립하는 이유는 계획이 디테일하지 않는 것은 프로젝트 관리자의 실력이 없기 때문이라는 생각을 하기 때문입니다. 한 가지 더, 디테일 한 계획이 정확한 계획이라고 착각하는 이유도 있습니다. 무리하게 수립한 상세한 계획은 우스꽝스러운 것에서 끝나지 않고 계획수립을 위한 낭비, 계획 차질에 대한 대책을 수립하는 낭비를 유발합니다. 무엇보다 이런 계획을 받아보는 프로젝트 팀원의 심정은 어떨까요?
폭포수 방법론에서 주로 이런 상황이 발생할 수 있는데 어떤 방법론을 사용하더라도 아는 만큼 상세하게 WBS를 분할해야 합니다. 어떤 업무는 3 레벨, 어떤 업무는 5 레벨, 어떤 업무는 2 레벨로 분할할 수 있습니다. 예를 들어 2 레벨로 분할한 업무는 해당 업무의 내용이 명확해지고 수행할 담당자가 결정된 시점에 좀 더 상세하게 WBS를 분할하고 그에 맞는 일정계획을 수립해야 합니다.
프로젝트 일정계획 수립에 필요한 정보를 잘 아는 상태는 다음과 같습니다.
• 유사한 업무를 수행한 경험이 조직에 축적되어 표준 WBS 적용이 용이
• 업무의 요구사항이 명확하고 변경가능성이 낮음
• 업무를 수행할 담당자들이 정해졌고 업무 생산성을 알고 있음.
일정계획에 수립에 필요한 정보를 아는 만큼 일정계획을 구체화해야 합니다. 아는 만큼 점진적으로 프로젝트 계획을 상세화 하는 것을 점진적 상세화(progressive elaboration) 또는 연동기획(rolling wave planning)이라고 합니다.
- 일정실적을 취합하는 방법을 고려하여 도구를 결정해야 합니다.
일정계획을 수립한 뒤에는 일정진척 현황을 집계하고 이해관계자들에게 공유해야 합니다. 일정진척 현황을 집계하기 위해 많은 사람들의 노력이 필요하거나, 이해관계자들이 일정현황을 실시간으로 파악하기 힘들거나, 일정현황 공유를 위한 누군가의 많은 노력이 필요하다면 이것은 모두 낭비입니다. 예를 들어 일정진척 집계를 위한 담당자가 있어 매주 개인들에게 일정실적을 취합하고 이를 집계하여 일정진척 현황을 정리하고 배포한다면 담당자 1명의 낭비뿐만 아니라 관련된 여러 인원들의 낭비가 발생합니다. 프로젝트 규모가 커서 서브시스템별로 조직을 운영한다면 서브시스템 내부에서도 누군가는 일정을 집계하기 때문입니다. 따라서 일정계획 모델을 결정할 때는 프로젝트 팀원들이 익숙한 도구를 고려해야 합니다. 예를 들어 팀원들이 Jira에 익숙하다면 스크럼이나 칸반과 같은 일정모델을 적용해야 하고, MS Project에 익숙하다면 CPM이나 CCPM과 같은 일정모델을 적용할 수 있습니다.
- 일정관리 도구는 수단이지 목적이 아닙니다.
CPM 모델을 적용하는 이유는 프로젝트의 주경로를 식별하여 프로젝트 일정지연의 위험을 관리하는 것입니다. 그러나 프로젝트의 주경로를 관리할 여건이 되지 않는 프로젝트에서 CPM을 적용하면 일정관리를 위한 대부분의 노력들은 헛수고가 됩니다. 따라서 일정관리 도구를 통해 얻을 수 있는 가치를 고려하여 일정관리에 투입되는 비효율을 최소화해야 합니다. SI 프로젝트는 고객이 계약내용에 적용효과가 낮은 일정관리 도구를 명시할 수도 있습니다. 이럴 경우에는 계약요건을 충족시키는 수준으로 일정관리 도구를 적용하는 것도 고려해야 합니다.
- 보기 좋은 일정표보다 내용이 중요합니다.
보기 좋은 일정표가 잘 수립된 일정표라는 착각을 제공하기도 합니다. 엑셀로 작성한 표 형식의 일정표보다는 일정관리 도구로 작성한 간트차트가 더 보기 좋은 것은 사실입니다. 그러나 보기 좋은 일정이 내용도 좋은 것을 보장하지는 않습니다. 엑셀로 작성한 일정이라도 팀원들이 내용을 정확하게 이해하고 제때 업데이트한다면 회의실 벽에 부착되어 먼지만 쌓여가는 간트차트보다 훨씬 유용합니다.
4) 일정계획 모델의 유형별 적합한 업무
- CPM은 업무 간의 관계가 복잡한 프로젝트에 적합합니다.
CPM을 적용하는 대표적인 업무는 건설 프로젝트입니다. 건설 프로젝트는 건설 자재 공급, 선행작업 완료, 날씨의 영향 등 일정관리를 위해 고려해야 할 요소가 많습니다. 특정 작업이 지연될 경우 영향을 받는 후행작업의 파악뿐만 아니라 전체 건설공기에 미치는 영향도 분석해야 합니다. 누리호 우주발사 프로젝트도 CPM 일정계획을 적용했을 가능성이 높습니다.
폭포수 방법론을 적용한다고 CPM을 적용해야 하는 것은 아닙니다. 예를 들어 SI 프로젝트에서는 착수시점에 전체 프로젝트 계획을 수립하지만 CPM을 적용하지 않는 경우가 많습니다.
- 자원의 제약이 많은 프로젝트에 CCPM 적용이 가능합니다.
CCPM 일정계획은 CPM 일정계획을 기반으로 합니다. CCPM 일정계획을 위해서는 주경로(critical path)를 도출한 뒤, 자원의 제약조건을 반영한 애로사슬(critical chain)을 정의해야 하기 때문입니다. 애로사슬을 도출한 뒤에는 애로사슬이 지연되지 않도록 버퍼를 관리해야 합니다. 따라서 CPM을 적용가능한 프로젝트를 대상으로 CPPM 적용이 필요할지 검토해야 합니다. 그러나 개별 액티비티에서 버퍼를 제외하는 것이 쉬운 일은 아니기 때문에 CPM보다는 적용사례가 많지 않습니다.
- 동일한 개발주기의 적용효과가 있을 때 스크럼을 적용합니다.
동일한 개발주기를 적용하면 프로젝트 업무 중 우선순위가 높은 것을 먼저 개발하여 릴리즈 할 수 있습니다. 예를 들어 2주 또는 4주의 정해진 개발기간 동안 수행할 업무를 결정한 뒤 개발하는 것입니다. 동일한 개발주기는 케이던스(cadence)라고도 하며, 반복되는 리듬에 따라 프로젝트를 수행하기 때문에 잘 적용하면 일정계획도 쉽고 예측가능성이 높아집니다. 신상품 출시 이후 상품개선을 위한 요구사항들을 반영할 때 스크럼 방식의 일정계획이 효과적입니다.
- 고객이 개발팀을 신뢰하는 운영업무에 칸반을 적용하면 효과적입니다.
칸반은 일정계획을 수립하지 않습니다. 쌓여 있는 백로그 중 우선순위를 고려하여 하나를 개발한 후 다음 요구사항을 개발합니다. 칸반은 기업의 정보시스템을 운영하는 전산실에서 정보시스템의 개선 요구사항(Service Request)을 개발하는 방식에 적합합니다. 칸반을 적용하기 위해서는 개발팀에 대한 이해관계자의 신뢰가 있어야 합니다. 왜냐하면 개발팀이 일정계획을 수립하지 않아도 일정기간 동안 일정량의 업무를 지속적으로 완료할 것이라고 믿을 수 있어야 각 업무의 완료계획을 수립하지 않기 때문입니다.
https://brunch.co.kr/@kbhpmp/160
