정확하고 실현 가능한 일정을 산정해 내는 것은 범위산정 및 계획/기획에서 했던 고생과 노력 뒤에 오는 끝없는 PM의 고뇌 중 하나 입니다.
프로젝트 일정 계획은 팀원 관리에서 부터 Stakeholder 관리, Communication 관리까지의 모든 관리 Skill을 투자해야 하는 일이기에 그런 고민과 고뇌가 당연한 일 입니다.
그 동안 많은 프로젝트를 수행하며, 어려운 일정 계획을 수행하기 위한 방법론으로 WBS수립을 위해 주로 MS-Project 사용하고 있습니다. (아래 화면은 MS-Project 소개 홈에서 가져 왔습니다.)
WBS는 전체 업무를 중심으로 세부 액티비티(Activity) 를 정의해 가며, 하나의 Activity를 수행하는 시간을 산출하여 전체 일정을 산출해 내는 것입니다.
액티비티를 정리하고 각 액티비티들의 상관관계(앞 단계가 끝나야 다음 업무를 진행할 수 있는 일들의 관계)를 정의하고 나면, 하나의 업무가 연결된 일정이 나오게 됩니다.
이렇게 연결된 모든 액티비티가 최종적으로 프로젝트가 끝나는 시점이 나오게 됩니다. 이렇게 일정을 산정하는 방법에서 중요한 제약사항이 있는데, 최종 프로젝트 완료일을 강제적으로 넣을 수 없다는 것입니다.
이렇게 작업을 하다 보면, 어떻게 된 것이 거의 대부분의 프로젝트가(적어도 강팀장이 수행했던 프로젝트) 거의 대부분 RFP 또는 계약 당시 합의하는 최종 완료 일정과 상당히 큰 차이를 보이게 된다는 것입니다.
고객은 초기에 일정보다 쿼리티(품질)을 요구하는 경우가 많지만, 중요한 전제는 항상 일정입니다.
자~ 그럼 여기서 한번 진지하게 고민 해 보아야 할 주제가 나오게 됩니다.
※ WBS를 작성할 때는 최종 완료일을 PM 마음대로 결정할 수 없다. -> 최종 완료일은 각 액티비티를 정의하고, 이에 따른 각 액티비티 일정을 계획 후 단계별 진행할 경우 연결된 각기의 일정에 따라 최종 완료일이 결정된다.
위의 전제는 PM에게 항상 많은 고민을 하게 만듭니다.
WBS 상 일정을 산정해 보니, 도저히 계약된 일정 내에 작업을 수행할 수 없다.
그럼 이 문제를 어떻게 해결해야 할까요?
고객에게 산출된 기간을 기준으로 일정 내 진행이 어렵다고 설득시킨다.
예산이 넘어가더라도, 인력을 더 투입시킨다.
액티비티 수행 단계를 없애거나 기간을 줄인다.
1번은 해결방법이 되지 않습니다. PM으로써 단지, 그대로 놓아두는 것 일뿐…
2번은 어떨까요? 프로젝트는 고객쪽에서 본다면 예산은 벌써 정해져 있고, 집행을 했다고 봐야 하기 때문에 비용은 더 들이지 않고 완료를 요청할 것입니다. 그렇다면 수행쪽에서 결국 예산이 넘어가더라도 기간내 수행하기 위해 인력을 더 투입하는 방법을 선택하게 되고 그렇게 되면 프로젝트 순수 이윤에 대한 부분에 문제가 발생할 것입니다. 이 방법으로 아무리 프로젝트가 일정내 완료되었다고 하더라도 성공적인 프로젝트고 할 수 없을 뿐더러 PM의 평가 문제도 발생 될 것입니다.
3번은 규모가 작은 프로젝트에서는 어느 정도 해결책이라고 할 수는 있겠으나, 품질에 대한 문제가 발생할 가능성이 높습니다. 프로젝트의 완료는 고객측에서 만족을 해야 하는 중요한 과제를 가지고 시작하게 됩니다.
솔직히 강팀장은 정확한 해결책을 가지고 있지 않습니다.
프로젝트의 성격, Stakeholder와의 관계, 내외부적 요인 등 다양한 변수들에 의해 선택될 수 있는 방법은 많을 것이라 생각합니다.
프로젝트를 관리하는 방법은 여러가지가 있는 것 같습니다. 우리가 흔히 많이 알고 있는 일정을 관리하는 방법, 산출물 관리 방법, 인력을 관리하는 방법, 비용을 관리하는 방법...
그런데... 이런 것들을 보면 거의 비슷한 말들로 통하는 것 같습니다. 비용~!!
일정을 관리하는 것도 결국 비용을... 산출물을 관리하는 것도 결국 비용을... 인력을 관리하는 것도 결국 비용을...
약간의 표현과 관리 관점은 차이가 있을 수 있으나, 최종적으로 프로젝트를 제대로 관리하기 위한 방법 중 하나인 것 같습니다.
그래도 가장 많이 이야기가 대두되고, 프로젝트가 꼭 IT에만 있는 것이 아니기 때문에... 순수 프로젝트 관리라는 의미에서 본다면 비용으로 관리되는 것이 정통적인 방법이 아닐까 합니다.
프로젝트 관리에서 비용, 예산(Budget)으로 관리해 나가기 위해 알아야 할 몇가지 단어와 정보가 있어야 하겠습니다.
(개인적으로... 이 부분을 정확히 알고... 프로젝트를 바라보면... 눈이 훨씬 넓어지는 것 같았습니다.)
u 계획요소
•WBS (Work Breakdown Structure) : 작업분류체계
•CA (Control Account): 공정&비용의 통합관리 기본 단위
•PMB (Project Management Baseline) : 프로젝트관리 기준
(공정&비용의 통합관리 기준)
•BAC (Budget At Completion) : 예산 내 성공여부를 판단하는 기준(Baseline)
u 측정요소
•BCWS (Budget Cost for Work Scheduled) 계획 예산PV (Plan Value)
계획된 일정상 작업 종료하는데 드는 예산
•BCWP (Budget Cost for Work Performed) 할당 예산 EV (Earned Value)
수행된 작업에 할당된 예산
•ACWP ( Actual Cost for Work Performed) 실행된 비용 AC (Acutal Cost)
수행된 작업에 대해 실제 실행된 비용
u 분석요소
•SV (Schedule Variance) : 현 프로젝트 일정진척 상황
= BCWP – BCWS
•SPI (Schedule Performed Index) : 진척율
= BCWP/BCWS
•CV (Cost Variance) : 계획대비 실적 차이
= BCWP – ACWP
•CPI (Cost Performed Index) : 실적율
= BCWP/ACWP
u 예측요소
• BCWR (Budgeted Cost for Work Remained) : 잔여예산
= BAC – BCWP
•ETC (Estimate to Completion) : 잔여예산 원가
= BCWR / CPI
•EAC (Estimated At Completion) : 총 예산 원가
= ACWP + ETC
계획, 측정, 분석, 예측 이렇게 4가지 요소는 프로젝트 관리에서 프로젝트 관리자에게 올바른 판단과 빠른 결정을 도와주는 막강한 힘이 되어 줍니다.
각각의 수치에 대해서 어떻게 계산되어지나... 싶기도 하겠습니다..
그것보다.... 위의 4가지요소중, 분석요소를 통해... 프로젝트가 어떻게 진행되는가에 대해서 한번 알아보겠습니다.
(작년에 강팀장이 워크넷이라는 프로젝트를 한적이 있었습니다. 당시 SK에서 일명 할아버지 PM이 오셨는데.... 오랫동안 같이는 못했지만.... 밀고 나가는 추진력에 대해서는 한수 배우기도 했습니다. - 그 당시에 다른 팀원 및 PL들에게 "프로젝트는 말이야... 이렇게 되는거야.. S 자... S 자... 원래 이렇게 진행되는거야~!!!" 이렇게 힘주어 말하던 것이 기억납니다. 그때 알아 들은 사람도 있었겠지만, 분명 못 알아 들은 사람도 있을 겁니다. S자 그래프를 그려가며... 힘주어 말하던 할아버지 PM이 다 설명하진 않았지만... 왜 그렇게 되어야 하고... 그게 어떻게 된다는 것을 이해를 했을까 싶기도 합니다. 단지.. 진척율 측정을 하기 위해 다른 사람들은 이해한게 아닐까 하는 아쉬움도 들기도 합니다...)
그럼... 그래프를 가지고 한번 보겠습니다. (그래프를 어떻게 그리느냐.... 혹시 질문하시려는 분들 계실려나??? ㅡ.ㅜ 공부공부 공부만이 살길입니다. ^^) 할아버지 PM이 박박 소리치던.. 그 S자 곡선입니다.
먼저 그래프는 세로가 비용, 가로가 일정 또는 시간입니다. (40, 50, 60 은 그냥 계산해 보라고 붙이 금액인데... 40K = 40,000 이라는 뜻입니다. 그림 실력이 떨어져 조금 간격이 잘못 되었더라도 이해를...) 상단선인 노동예산은 예산의 Base Line 이라고 생각하면 되겠습니다. 뭐... 계약금과 비슷하긴 하지만, 정확히 계약금하고 틀린수도 있습니다. (회사가 처음부터 손해 보고 하고자 하는 프로젝트 경우 틀리겠습니다.) 마감시한은 프로젝트 끝 시점입니다.
BCWS 는 최종 프로젝트 끝날때까지 예산 그래프고... 어떻게 보면... 일정별 진척율이라고 봐도 됩니다. MS Project를 돌리면.... 이렇게 그래프가 생기죠.
1번 그래프 입니다. 결과적으로 말하면.... 일정은 늦어지고, 예산을 많이 들어가고.... 현재 프로젝트가 힘든 상황입니다. 많은 리스크가 동시 다발적으로 발생하고 있을 가능성도 높고.... 상급자부터... 최하위 팀원들까지 힘들어하고 있는 상태 입니다.
왜 그런지 한번 볼까요? SV = BCWP-BCWS = 40k - 50k = -10k 입니다. 즉 지금 약 10,000달러치 일을 안했다는 것입니다. -10k 만큼 일정이 늦어지고 있다는 소리겠죠.
CV = BCWP-ACWP = 40k - 60k = -20k 입니다. 현재 초기 계획에 비해 더 들어가서 오차가 20k 를 오버하고 있다는 것입니다.
이렇게해서 그래프를 유추해 보면.... 돈은 더 많이 들어가고, 일정을 계속 늦어지고 있는 상태 입니다.
2번째 그래프 입니다. 위의 방법으로 한번 해석해 볼까요? SV = BCWP - BCWS = 60k - 40k = +20k 지금 +20k 가 발생되었으니... 20k 만큼 일을 더 했다. +20k 만큼 일정이 빠르다 라는 것을 말합니다.
CV = BCWP - ACWP = 60k - 60k = 0k 0k 가 나온것 보니깐.... 돈은 제대로 나간 것입니다. (일을 많이 한 만큼 비용도 많이 나갔다는 의미겠지요. 하지만, 정직하게 돈이 나간거니깐.... 그나마 위안이긴 합니다.) 결과 : 일정은 앞서고 있고, 돈은 조금 더 나간듯 하지만 계획대로 지출된 프로젝트 입니다. 하지만 이대로 가다가 일정이 늘어지게 된다면... 나중에는 오버가 발생된 수 있는 위험수준에 도달해 간다는 것을 의미 합니다. 사람이 하는 일이 완벽할 수 없기 때문에... BCWP, ACWP 곡선이 x 자로 꼬인다면... 큰 문제가 되겠죠.
3번째 그래프 입니다. 이제 여러분이 한번 해석해 보실래요??? 정히 어렵다면... 아래를 클릭하시면 됩니다.
3번 그래프 해석 보기..
결과적으로 2번 그래프와 비슷하지만 한가지, 일정이 늦어지고 있는 것입니다. SV = 40k-50k = -10k 만큼 늦어지고 있다는 것이고, CV 는 0k 이니깐... 계획대비 비용은 적당하게 나간 것 같습니다. 일을 안했으니... 그 만큼 지출된 비용이 없겠죠.. 하지만... 이도 위험한 수준의 프로젝트 입니다.
4번째 그래프 입니다. 이것도 한번 풀어보시는 것도 괜찮을 듯합니다.
4번 그래프 해석 보기..
이 그래프가 가장 안정적인 프로젝트를 진행하고 있다는 것입니다. SV = 60k-50k = +10k CV = 60k-40k = +20k 일정도 +10k 만큼 진행되고 있고, 예산도 절약하여 +20k 만큼 벌여 들였습니다.(절약되었다는 것입니다.) 즉... 돈은 작게 들어가고.. 일정은 빨라지고.... 이렇게 진행되면.... 회식을 일주일에 한번씩해도 뭐라고 하는 사람이 없을지도 모릅니다. ^^
기타 이런저런 이야기 얼마전 한동환대표님이 운영하시는 PMPCafe에서 좀처럼 기회잡기 힘든 세미나를 준비하셔서 참여 했습니다. ARES사의 부사장님(Mr. Chip Glode)께서 직접 설명해 주셨던 세미나였는데... 솔직히 영어가 딸려서 거의 대부분의 내용을 놓쳤습니다. 대규모 프로젝트에서의 PM 관리 기술에 대한 말씀..... PRISM 이라는 Management Suite 활용법.... 현실적인 Q&A등등등.....
그런데 여기서 흥미 있는것이 있었습니다 .PRISM 시스템에서 위의 표를 쉽게 레포팅하게 해 준다는 것이였습니다.
그리고 그동안 보아왔던 다른 Management Tool 들은 멤버들의 일정과 실적위주로 관리하는데 반해 PRISM 은 비용을 중심으로 관리한다는 것입니다. (예산관리를 EVM-Earned Value Management 이라고 합니다.)
Q&A 시간에 나왔던 의미 있는 2가지 내용도 잠깐 말씀 드리면.... - 이런 Tool 들이 만능은 아니다, 결국엔 팀장과 팀원의 협력과 관계, 관리와 통제에 의해 프로젝트가 원활히 진행되는 것이다. -> 영어 표현으로 따지자면.. No Magic~!! - 좋은 Tool 이 있다고 하더라도, 팀원들이 특히 개발자들이 참여하지 않으면 결국 힘들어진다. 개발자들이 원한히 관리와 통제안으로 스스로 참여하도록 하는 몫도 결국 PM의 자질이다. -> 당근책도 좋은 방법이지 않을까??
- 뜨거운 현장 사진입니다. ^^; 한동환대표님 수고 많으셨구요. 사진은 김태영 회원님의 블로그에서 몇장 가지고 왔습니다.
어느 정도 경력도 갖추고 어느 정도 실력을 갖추었다고 자부하던 팀원에게 받은 쪽지는 강팀장에게 약간의 고민을 안겨 주었습니다.
한국형 프로젝트????
도대체 한국형 프로젝트란 무엇이지?? 외국에는 다른 프로젝트를 수행하는 건가??? 아니면.. 다른 개발 언어로 개발하는 건가??? 무엇이 다른거지????
간혹 모임이나 동호회에서도 이런 부분에 대해서 토론을 하게 될때도 한국형 프로젝트와 비슷한 말들을 듣습니다.
"선진국의 프로젝트는 이렇게 되는데, 한국에서는 그렇지 못하기 때문에 실패 경우가 많은 거야...."
솔직히 강팀장은 그런 말들에 대해서 이해가 잘 가지 않습니다. 선진국이라고 말하는 부분... 한국형이라고 말하는 부분... 이런 말들은 너무나 상식적인 선에서 자주 나오기 때문에 강팀장 스스로도 혼란스러울때가 많습니다.
일전에... 블로그에 [프로젝트 실패의 원인] 이라는 글을 올린 적이 있습니다.
한국이라는 상황에 스스로 비관적 생각보다는, 어떻게 프로젝트를 효율적으로 진행할 것인가를 고민하는 것이 낫다~! 라는 것입니다.
선진국(?), 외국(?) 사례와 많은 연구 보고서를 보면 한국에서 프로젝트를 진행하면서 겪는 일들이 결코 한국이라는 상황때문에 일어나는 것이 아니라, 발전을 위해 한번은 경험해 보아야하는 과정 같은 것이라 쉽게 알 수 있습니다. - 물론 그런 과정자체를 겪어서는 안되겠지만...... -
The Standish Group CHAOS Report 에 따르면, 전세계적으로 프로젝트의 성공율이 올라가고 있지만, 아직도, 체 30%수준에 못미치는 프로젝트만이 성공하고 있으며, 그 부분도, 프로젝트 규모가 커질 수록 실퍠확률은 더 높아진다고 하고 있습니다.
개발 일정에 대해서도 전체 프로젝트 중 2/3정도가 일정을 심각하게 초과한다고 말하고 있으며.. (Lederer and Prasad 1992, Gibbs 1994, Standish Group 1994) 이 또한 대형 프로젝트는 평균 25%~50%까지 완료일정을 놓쳤고, 프로젝트 크기가 클수록 일정 지연은 더욱 심각해진다(Jones 1994)라고 보고 하고 있습니다.
이렇기 때문에..??... 결국 포기하는 것인가?? 당연히 실패?? 일정 지연....?? 많은 문제점들을 정당화하고자 하는 것이 아니라...
지금 겪고 있는 현재의 상황을 너무 극단적으로 비판할 필요는 없을 것 같습니다.
실패를 최소화 하기 위한 많은 연구가 진행 중이고, 이런 부분에 대한 적용과 실무 진행등의 노력도 지속적으로 이뤄지고 있으니, 앞으로 더 좋아질거라 생각 됩니다.
굳이 "한국형" 이라는 굴레를 만들어 버린다면.. 그 또한 문제가 있지 않을까 생각합니다.
