WBS 일정관리시 참고할 사항 8가지

하지만, 당신이 PM이고, 제안서 작성에 참여했고, 제안 발표를 하고 수주를 해서, 현재 WBS를 작성해야 하는 시점이라면, 적어도 개발범위가 어느 정도이고, 어떠한 시스템의 구성을 갖고 있으며, 개발 본 수가 대략 몇 본 정도 될 것인지 산정할 수 있을 것이다. 

요구사항 분석을 하지 않은 시점이라 할 지라도, 일단 추정되는 개발범위만큼을 놓고 WBS에 대입하여 일단위(Daily) 일정표를 작성할 수 있을 것이다. 모든 개발 목록을 뽑을 수 없다면, 기능 1, 기능 2, 화면 1, 화면 2 이런 식으로라도 쪼개서 적어보라는 얘기이다. 

요구사항 분석 4주, 화면 설계 2주, 기능 개발 8주 이런 식의 일정표를 갖고 용감하게 프로젝트 관리를 하겠다고 뛰어들지 말라는 의미이다. 
이와 같이 가상으로라도 Daily 일정표를 수립해보면 프로젝트 단계별로 예상되는 공수를 추정할 수 있으며, 이를 기반으로 인력 투입 계획을 수립하거나, 또는 현재의 인력 투입 계획이나 일정계획이 적절한지 확인할 수 있다.


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

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

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

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


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

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

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

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


어느 정도의 지연이 있더라도, 굳이 작은 부분의 지연을 언급할 필요는 없다. 예를 들어, 화면 설계서 작성의 일정이 ㅇㅇ월 ㅇㅇ일이라면, 그 날짜까지 일단 초안은 작성된 상태여야 한다. 

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


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

MS Project를 사용하는 것이 가장 좋겠지만, 불가능하다면, 오픈소스 기반 프로젝트 관리 툴도 괜찮다. 


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


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


일곱 번째, 프로젝트의 일일 생산성을 측정하자. 
프로젝트 초기에는 일일 생산성을 산정하기 어렵고, 산정하더라도 정확하지 않을 수 있다. 그러나, 개발이 어느 정도 본 궤도에 오르기 시작한 후에는 개발자의 생산성을 측정할 수 있다. 날짜별로 해당 날짜에 완료된 작업의 계획 당시의 작업량(MM)을 합산하면, 대략의 개발 생산성을 확인할 수 있으며, 산술적으로 개발 완료 시점을 예측할 수 있다.


일정은 더 이상 늦어지지 않도록 하는 것이 최선이다. 

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

 

https://brunch.co.kr/@6130710262fb43e/3

03화 일정관리 이야기