일정관리 이야기

프로젝트 일정관리 할 때 생각해야 할 것들

첫 번째, 최대한 자세한 일정표를 수립하자.

대형 건설회사에서 커다란(한 30층 쯤되는) 빌딩을 지을 때나, 1000세대쯤 되는 아파트 단지를 지을 때 사용하는 WBS(*)를 본 적이 있는가, 빌딩의 상세한 설계도를 기반으로 각 공정별 소요 자재, 장비, 인력에 대한 상세한 WBS를 작성한 후, 공정별로 설계도에 따라 지어지는 모습을 BIM(Building Information Modeling) 솔루션 상에서 3차원으로 미리 시뮬레이션으로 지어본다. 2년의 공사기간을 20분으로 압축하여 수십 번 돌려보는 과정에서 순서가 잘못된 공정을 찾아내기도 하고, 타워크레인의 위치가 현재 계획대로 하면 공사장 동선에 문제가 생길 것으로 판단되어 타워크레인 위치나 대수, 기종을 바꾸기도 한다.  공사장 진출입로 위치를 좀 더 효율적인 위치로 바꾸면 공사기간이 2주 줄어든다는 시뮬레이션 결과에 따라 실제로 바꾸기도 한다.

* WBS(Work Breakdown Structure, 업무 분해 구조, 프로젝트 팀이 프로젝트 목표를 달성하고 필요한 인도물을 산출하기 위해 실행하는 작업을 인도물 중심의 계층 구조로 세분해 놓은 것) 

이와 같이 건설업계는 최대한 공기를 줄이고, 이렇게 공기가 지연되는  것을 막기 위해 모든 노력을 아끼지 않는다. 일정의 지연은 곧 원가의 증가를 의미하기 때문이고, 건설업은 단위가 큰 만큼 지연에 따른 원가의 증가도 어마어마하다.

만일, IT시스템 구축 프로젝트를 할 때에도 건설업계에서 수행하는 정도의 WBS를 수립한다면? 착수시점에 모든 일정을 상세히 수립하고 특정 인력의 투입되는 시점과 철수 시점까지 정확히 계산할 수 있다면, 납기지연의 오차를 최소화할 수 있지 않을까?

물론 몇백, 몇천억 짜리 건물을 짓는 WBS의 수준으로 몇억짜리 IT시스템 구축 프로젝트에 적용하는 게 과연 적절하냐, 가능은 하냐라는 반론을 제기할 수 있을 것이다. 하지만, 당신이 PM이고, 제안서 작성에 참여했고, 제안 발표를 하고 수주를 해서, 현재 WBS를 작성해야 하는 시점이라면, 적어도 개발범위가 어느 정도이고, 어떠한 시스템의 구성을 갖고 있으며, 개발 본 수가 대략 몇 본 정도 될 것인지 산정할 수 있을 것이다. 요구사항 분석을 하지 않은 시점이라 할 지라도, 일단 추정되는 개발범위만큼을 놓고 WBS에 대입하여 일단위(Daily) 일정표를 작성할 수 있을 것이다. 모든 개발 목록을 뽑을 수 없다면, 기능 1, 기능 2, 화면 1, 화면 2 이런 식으로라도 쪼개서 적어보라는 얘기이다. 요구사항 분석 4주, 화면 설계 2주, 기능 개발 8주 이런 식의 일정표를 갖고 용감하게 프로젝트 관리를 하겠다고 뛰어들지 말라는 의미이다. 이와 같이 가상으로라도 Daily 일정표를 수립해보면 프로젝트 단계별로 예상되는 공수를 추정할 수 있으며, 이를 기반으로 인력 투입 계획을 수립하거나, 또는 현재의 인력 투입 계획이나 일정계획이 적절한지 확인할 수 있다.

매주 진척률의 금주 진행 실적, 공정률을 보고하기 위해서라도, 예상되는 개발 규모의 MM만큼을 미리 WBS에 생성하고, 가중치를 부여해놓아야 한다. 그래야 전체 개발 MM에 변동 없이 일관된 기준에서 진행률을 산정할 수 있다. 타 프로젝트의 WBS템플릿이 있다거나, 회사 내에 WBS 표준 템플릿이 있다면, 초기 WBS수립에 들어가는 시간을 줄일 수 있다. 잘 만들어진 WBS 템플릿은 과거 프로젝트의 경험과 노하우가 모두 담겨있는 중요한 자산이다.

이와 같이 일단위 WBS를 작성했다면, 그 WBS는 변화하는 프로젝트의 상황에 맞추어 수없이 업데이트해 가야 한다(Rolling Wave Plan). Rolling Wave Plan(*)을 적용하더라도, 현재 알 수 있는 일정에 대해서만 구체적으로 적고, 불명확한 것들은 비워놓는 것이 아니라, 예상되는 개발범위에 대해 최대한 쪼개서 기입해놓고, 분석/설계 과정을 통해 구체화되어 갈수록 그 사항을 좀 더 상세하게 적용해야 한다. 적어도 향후 1개월 이내의 일정에 대해서는 실제 수행 가능한 실행 작업 단위 수준으로 분해하여 일정을 수립해야 한다. 각 실행 작업 단위별 실제 수행 시 예상되는 작업공수(MD)를 산정하여 기입하고 일정, 작업의 순서, 자원배정을 조율한다.

*Rolling Wave Plan : 곧 착수할 작업은 하위 수준까지 세밀하게 계획하고, 먼 미래의 작업은 상위 수준에서 개략적으로 계획하는 방식의 반복 점진적 계획 수립 기법

이와 같이 일정을 업데이트하는 과정에는 개발자의 참여가 필수적이다. 일주일에 한 번 만이라도 개발자들과 일정을 리뷰하자. 정해져 있는 주요 마일스톤(*)에 대해 공유하고, 그 주에 해야 하는 작업에 대해 실제로 어떤 작업을 해야 하는지 개발자들과 의견을 교환하고, 하위 레벨 작업에 실제 수행할 작업을 추가로 기입하자. 지난주에 계획했던 작업이 실제로 얼마나 이루어졌는지 확인하고, 지연된 이유를 분석하며, 새로운 일정을 기입하자.

*마일스톤 : MileStone, 이정표, 특정 프로젝트와 관련된 중요 시점, 프로젝트 계약, 착수, 인력 투입, 선금 수령, 중간보고, 감리, 종료, 잔금 수령 등 프로젝트 성공을 위해 반드시 거쳐야 하는 중요한 지점

개발자들과 WBS를 리뷰하는 과정에서 누락된 부분은 없는지, 뭉뚱그려놓은 부분은 없는지, 선후관계가 제대로 부여되어있는지 확인하자. 불명확한 부분이 있거나, PM스스로 이해가 되지 않는 부분이 있다면, 끝까지 제대로 확인하여 실제 수행하는 작업 단위로 분해하는 노력을 게을리하지 말아야 한다. WBS에 표시되지 않은 부분은 PM이 관리할 수 없다는 것을 명심하고, 프로젝트의 모든 요소를 관리하기 위해 집중해야 한다.

두 번째, WBS는 보고용과 내부용을 따로 관리하자.

우리나라의 SW 개발 프로젝트에서는 대체로 프로젝트 팀 내부용, 고객사 보고용 WBS를 따로 관리하는 경우가 많다. 보고용 WBS에는 큰 틀에서의 일정만 기입하며, 실제 진행과정 상 일부 지연이 있다 하더라도 웬만해서는 보고용 WBS상의 일정이 변경되지 않도록 관리하는 경우가 많다.

"과연 그렇게 하는 게 맞을까? 아니면, 시시각각 변화하는 상세 WBS를 고객에게까지 오픈하는 것이 맞는가"

나도 가능하다면 고객에게까지 공개하는 게 맞다고 생각한다. 하지만, 상세 WBS의 의미와 현재 지연되고 있는 요소와 지연되는 부분을 만회하기 위해 수행하는 활동들까지 모두 이해하고 받아들일 정도로 오픈마인드가 되어있는 고객은 없다고 봐야 한다. 너무 상세한 부분까지 오픈할 경우에는 오히려 역효과가 날 수도 있으므로, 현실적으로 WBS는 내부용과 보고용으로 따로 관리될 수밖에 없다. 어차피 고객은 이슈 없이 아무 문제없는 깨끗한 보고서를 좋아한다.

PM입장에서 보고용 WBS는 진행 단계별로 고객이 해야 하는 부분의 공정(예를 들어, 화면 설계서 고객사 담당자 승인, 통합 테스트 등)에 대해 할 일과 일정을 명시적으로 전달하는 게 가장 큰 목적이다. 고객담당자가 언제 무슨 일을 해야 하는지 미리 알려주고, 고객이 진행해야 하는 특정 부분이 늦어질 경우, 전체 공정에 어떠한 영향이 있는지 사전에 보여주어야 하고, 반복적으로 상기시켜야 한다.

세 번째, 일정은 착수/분석/설계는 타이트하게 잡고 테스트/종료 단계로 갈수록 충분한 기간을 잡자.

WBS에 충분한 테스트 기간을 포함시켜 놓는 것에는 여러 가지 장점이 있다. 일부 개발이 늦어질 경우, 테스트 기간에 만회하는 시간으로 활용할 수 있다. 만일 지연되는 문제가 없다면, 지속적으로 테스트하여 품질을 끌어올릴 수 있다. 또한, 프로젝트 막판에 산출물 정리하는 시간으로 활용할 수도 있다. 즉, 프로젝트 후반에 필요한 PM의 버퍼를 테스트 단계에 숨겨놓는 개념이라고 생각하면 좋을 것 같다.

반대로 착수/분석/설계 단계에서 시간을 충분하게 잡는다고 해서, 프로젝트 일정이 당겨지거나, 분석이나 설계의 품질이 향상되기는 어렵다. 프로젝트 초반~ 분석/설계단계까지는 다소 빠듯한 일정으로 고삐를 단단히 죄고 빠르게 끌고 나가서 각 단계를 진행시켜야 한다. 물론 분석/설계를 대충 해도 된다는 얘기는 아니다. 프로젝트 초반에는 프로젝트의 Ground Rule(*)이 형성되고, 프로젝트에 임하는 이해관계자의 태도가 어느 정도 결정지어지는 시기이다. 따라서, 개발자를 포함한 분석/설계 인원들이 프로젝트에 집중하기 어려운 시기이므로, 프로젝트팀 내부적으로도 의도적인 긴장감을 조성할 필요가 있다.

*Ground Rule : 기본규칙, 프로젝트에서는 팀원들이 공동으로 합의한 가치 및 행동 양식에 대한 정의를 말함. 예를 들어, 주간보고는 매주 금요일 오후에 한다든가, 개발 소스 커밋은 매일 오후 6시에 한다든가 하는 등의 프로젝트 내의 규칙

PM은 그저 흘러가는 프로젝트 상황을 관리만 하는 역할이 아니라, 모든 이해관계자가 관심을 갖고 역할에 맞는 일을 진행하도록 독려하고 리딩 해가는 역할을 수행해야 한다. 프로젝트의 모든 범위를 한눈에 조망할 수 있도록 이미 머릿속에 전체 범위가 정리되어있어야 하고, 그 전체의 범위가 하나하나 제대로 진행되고 있는지 직접 체크해야 한다.

네 번째, 조금 늦더라도 일단은 계획대로 밀고 가자.

앞서 우리나라에서는 대체로 프로젝트 팀 내부용, 고객사 보고용 WBS를 따로 관리하는 경우가 많다고 얘기했다. 보고용 WBS에는 큰 틀에서의 일정만 기입하며, 실제 진행과정 상 일부 지연이 있다 하더라도 웬만해서는 보고용 WBS상의 일정이 변경되지 않도록 관리한다. 

어느 정도의 지연이 있더라도, 굳이 작은 부분의 지연을 언급할 필요는 없다. 예를 들어, 화면 설계서 작성의 일정이 ㅇㅇ월 ㅇㅇ일이라면, 그 날짜까지 일단 초안은 작성된 상태여야 한다. 이후에 추가적인 미팅을 통해 보완하더라도, 초안이 작성된 상태라면 일단 작성은 된 것이므로, 지연된 것은 아니다. 일부 개발이 덜 된 부분이 있더라도, 계획된 날짜가 도래하면 테스트 단계에 진입하고, 테스트 단계에서 테스트를 진행하는 동안 미진한 부분 개발까지 마무리하는 것이다.(오류 수정이라는 이름으로...)

또한, 공식적인 보고서에 "일정 지연", "이슈 발생", "문제 발생" 등의 단어는 되도록 쓰지 않도록 하자. "다소간 미흡한 부분이 발견되어 보완 중", "일부 오류가 발견되었으나, 영향도는 미미함"과 같이 고객이 오해하지 않도록 순화하여 사용할 필요가 있다. PM이 큰 문제라고 얘기하면 고객은 당장 프로젝트가 실패할 것처럼 오해하여, 매일 체크하겠다고 달려들 수도 있다. 고객이 매일 일단위로 체크하는 순간 PM은 그 일일보고를 하기 위해 쓰지 않아도 되는 시간을 쓰게 되는 것이다.

다섯 번째, 프로젝트 일정관리 툴을 사용하자.

MS Project를 사용하는 것이 가장 좋겠지만, 불가능하다면, 오픈소스 기반 프로젝트 관리 툴도 괜찮다. 엑셀로도 불가능한 것은 아니겠지만, 상세한 WBS를 작성한 후, 지속적으로 변화하는 상황에 따라 구체화하여 관리하려면 MS project가 아니고서는 관리상의 어려움이 따른다. 우리나라에서는 아직도 많은 회사들이 일정관리 도구로 엑셀을 사용하지만, 엑셀로는 변화하는 상황에 따라 그때그때 변경해가며 일정관리를 하기는 쉽지 않다. WBS를 엑셀로 관리해야 한다면, WBS를 변경해가며 관리하기는 어려우므로, 그때그때의 상황에 맞추어 별도의 간략 버전으로 해당 공정의 일정관리용 엑셀을 별도로 만들어 의사소통하는 편이 낫다.

여섯 번째, CCM(*)를 적용하자.

*CCM : Critical Chain Method, 자원 가용성을 고려하여 일정의 변경을 예상하고, 이를 토대로 활동 사이에 의존 관계 및 수행기간을 결정하는 방법, 일련된 작업의 순서에 따라 진행하되 각 작업의 버퍼(여유시간)를 제거한 최소 시간만으로 일정을 수립하며, 각 작업별 진행에 따라 후속되는 작업의 시작 일정을 조정해가며 진행한다. 즉, 각 작업자의 개별 작업에 대한 여유시간을 모두 프로젝트 관리자에게 위임하여야 한다. CCM에 대한 더 상세한 내용은 잠깐만 검색해보아도 자료가 많으니, 별도의 자료를 참고하기 바란다.

만일, CCM을 성공적으로 적용하여, 각 개별 단위작업의 버퍼를 모두 PM이 프로젝트 버퍼로 가지고 있고, 각 업무의 진행상황에 따라 그 버퍼를 PM이 활용할 수 있다면, 전체 프로젝트의 납기를 준수할 수 있는 확률은 현저히 높아질 것이다. 그러나, 실제 프로젝트 현장에서 이와 같은 방식을 적용하기에는 많은 제약이 존재한다.

개발자는 본인의 버퍼를 PM에게 내놓는 순간 PM으로부터 일정에 대해 끊임없이 쪼임을 당하게 될 거라는 생각을 한다. 이러한 고정관념을 극복하기 위해서는 착수시점에 CCM의 원리를 모든 참여 개발자들에게 설명하고 동의를 구해야 한다. 아울러, 단위작업의 지연은 언제나 발생할 수 있다는 것을 전제로 하기 때문에, 개발의 진행상황을 PM에게 실시간으로 공유만 한다면, 본인이 애초에 계획한 일정을 지키지 못한 것에 대해 개발자 개개인은 책임이 없다는 것을 강조해야 한다. 하지만, 프로젝트 인력들과 합의하지 않은 상태에서 섣부르게 CCM을 도입 시 더 큰 반발에 부딪칠 수 있다.

내 생각에는 CCM 메서드는 회사차원의 표준 프로세스화해야 그나마 시도해 볼만 할 것으로 생각한다. 그만큼 이상적인 방법이지만, 개발자 개개인의 버퍼를 포기하는 것은 결코 쉬운 일이 아니기 때문이다. 그리고, 무엇보다 프로젝트 팀 내부에 신뢰가 있어야 한다. 그리고, 어디까지나 CCM을 적용한 WBS는 어디까지나 프로젝트팀 내부용으로만 한정해야 한다. 고객이 그 WBS를 본 순간(CCM을 적용한 WBS상에서 프로젝트 초반에는 오픈 목표일이 실제 오픈일보다 훨씬 앞에 있을 것이므로,)  실제 가능한 오픈일이 그 날짜라고 오해할 가능성이 있기 때문이다.

일곱 번째, 프로젝트의 일일 생산성을 측정하자. 

프로젝트 초기에는 일일 생산성을 산정하기 어렵고, 산정하더라도 정확하지 않을 수 있다. 그러나, 개발이 어느 정도 본 궤도에 오르기 시작한 후에는 개발자의 생산성을 측정할 수 있다. 날짜별로 해당 날짜에 완료된 작업의 계획 당시의 작업량(MM)을 합산하면, 대략의 개발 생산성을 확인할 수 있으며, 산술적으로 개발 완료 시점을 예측할 수 있다. 만일, 계획보다 조금 늦더라도 일정 내에 완료 가능한 경우라면, 프로젝트팀 개발자들의 생산성을 개발자들에게 알려주고, 얼마 큼의 지연이 예상되는지 보여주고 좀 더 집중하도록 독려하는 것만으로 충분할 수도 있겠지만, 도저히 납기를 맞추지 못할 것으로 예상되는 경우에는 생각할 수 있는 다른 방법을 즉시 고민해봐야 하며, 최대한 빠른 시점에  그 조치가 이루어져야 한다. 누구에게나 그렇지만, 특히 PM에게 시간은 한정된 자원이며, 그나마 시간이 지난 후에는 쓸 수 있는 방법조차 제한적이기 때문이다.

프로젝트 진행 중 지연이 예상되는 경우 쓸 수 있는 방법

- 업무의 조정 : 개발자가 맡고 있던 업무 중 개발 이외의 업무를 다른 사람에게 넘겨줄 만한 부분이 있는지 검토해보아야 한다. 매뉴얼 작성이라든가, 단위 테스트와 같은 부분을 다른 인원이 도와줄 수 있는지 확인 후, 업무 재배정을 통해 오로지 개발자가 개발업무에만 집중할 수 있는 환경을 만들어주어야 한다. 또는 특정 부분의 개발에 문제가 해결되지 않아 어려운 경우는 PM이 나서서 본사의 연구소, 개발팀, 타 프로젝트팀, 그도 아니면, PM의 개인적인 인맥까지 동원하여 해결방법을 찾아주어야 한다.

- 인력의 추가 투입 : 산술적으로 ㅇ명의 개발자를 ㅇ개월 더 투입하면 될 것으로 예상되는 경우, 실제로 그와 같이 투입해보면, 훨씬 더 많은 기간 동안 투입되는 경향이 있다. 개발환경을 세팅하고 기존에 다른 개발자가 개발 중이던 부분 중에서 일부분을 인수인계해주고 설명해주어야 하기 때문이다. 경험적으로 개발자가 추가로 투입되어 제 역할을 해내기까지 대략 일주일 정도는 소요되는 것으로 느껴진다. (2명*2개월=4MM 추가 필요한 것으로 산정되는 경우, 대략 4.5MM 정도 투입해야 4.0MM 정도의 효과가 나온다.)

- 개발 순서의 조정 : Batch Job(일괄처리 예약 작업)에 대한 설정이라든가, 백업 설정, 관리자 기능의 일부 보완과 같은 부분은 후순위로 미루어 숨겨놓고 보완할 수 있도록 조정한다.

- 단계적 오픈 고려 : 위의 모든 방법을 쓸 수 있는 여건이 안된다면, 서비스 오픈 일정에 오픈하는 범위와 추후에 오픈하는 범위를 단계를 나누어 오픈 일정을 가져가는 것도 방법이다. 다만, 단계적 오픈은 "개발 순서의 조정"과 달리 공식화된 방법이므로, 고객의 스타일이나 프로젝트의 상황에 맞추어 PM이 판단해야 한다. 때로는 단계적 오픈이라는 말이 프로젝트의 지연이라는 느낌을 줄 수도 있으므로,  최후의 수단으로 고려해야 할 것이다.

여덟 번째, 프로젝트 종료 시점까지 이러한 방식으로 WBS를 관리했다면, 그 WBS를 지식자산으로 등록하자. 

다음번 프로젝트에 참고할 수 있는 훌륭한 레퍼런스가 될 것이다.

* 결론

일정관리의 중요성은 두 번 말하면 입이 아플 정도이고, 때로 일정관리 그 자체가 프로젝트 관리로 여겨지기도 한다. 한 번 놓친 일정은 일정 만회 계획을 세우고, 인력을 추가 투입하더라도 따라잡기 어렵고, 더 이상 늦어지지 않도록 하는 것이 최선이다.

일정은 한 번 무너지면 계속해서 연쇄적/반복적으로 무너질 가능성이 있다. 개발 일정 지연으로 인해 서비스 오픈 일정이 한 번 무너진 프로젝트의 고객은 두 번, 세 번 오픈 일정이 연기되는 것에 대해서는 이미 두려움이 없는 상태이고, 차라리 늦더라도 하자 없는 시스템을 만들고자 하는 마음으로 눈에 불을 켜고 들여다보기 시작할 것이고, 그렇게 쳐다보다 보면 고객 스스로도 그 시스템의 전문가가 되어 1년에 한 번 발생할까 말까 하는 경우까지 고려하기 시작할 것이고, 그런 모든 사항들을 추가적으로 요구하기 시작할 것이다. 그 쯤되면 PM은 이미 약속(프로젝트 일정)을 못 지킨 죄인(?)인 데다가, PM의 권위 하락으로 인해 고객의 추가 요구사항에 대해 논리적으로 대응하기 어려워질 가능성이 커진 상태일 것이고, 그러면 한 번 오픈 일정이 미루어진 프로젝트는 계속해서 끝도 없이 늘어져갈 가능성이 있다.

따라서, PM은 일정 수립 시 최대한의 기간을 확보하기 위해 노력하되, 진행 중에는 모든 파트의 모든 단계를 빠르게 진행시킬 수 있도록 고삐를 바짝 죄고 당겨가야 하며, 한 번 정해진 일정은 반드시 지키기 위해 노력해야 한다.