Dependency가 많은 프로젝트의 스케줄 관리 방법
Network Diagram을 활용한 Project 스케줄링
Project Management에 있어서 Network Diagram의 활용 방안과 방법에 대하여 글을 써볼까 한다.
실제로 Network Diagram은 매우 활용도가 높고, 또 중요하기 때문이다.
나의 직업이 Project manager 혹은 Program manager인데 Network Diagram에 대하여 잘 모른다면 study해보고 실무에 활용해 보기를 권장한다 ;)
간단한 Network Diagram의 예위 그림은 소풍을 가기 위한 Network Diagram (Plan)이다.
일단 어느 호수로 소풍을 갈 것인지를 정하고, 얼마가 들지 생각하여 돈을 구한다. 이 때 계란을 삶는 것은 동시에 진행 가능하다. 그런데 Egg샌드위치를 만드려면 계란을 넣어야 하므로 계란을 삶는 것이 선행되어야 한다. 마찬가지로 돈이 있어야 기름을 넣으므로, Get money가 Buy gasoline에 선행한다.
이것이 Network Diagram의 기본 concept이다.
그런데, 이 Diagram이 Scheduling에 왜 중요할까?
아래 다른 그림을 한번 보자.
일정이 포함된 간단한 Network Diagram의 예위 Diagram에서 각 Activity별 일정이 day 단위로 표기되어 있다.
여러 flow중에서 선으로 표기된 부분이 바로 Critical Path이다. 즉, 프로젝트 기간을 결정하게 되는 Path인데, 가장 긴 Path가 Critical Path가 된다.
위 표에서는 A-B-C는 순차적으로만 진행 가능하나, D/E/F는 동시 진행 가능하고, E를 마쳐야 G/H를 진행 가능하며, G/H는 동시 진행 가능하고, I는 H를 마쳐야만 진행 가능하다.
위 표를 보면 각 Activity별로 dependency를 쉽게 알 수 있으며, 어떤 Activity에서 delay가 발생할 경우 전체 Project에 delay를 가져오고 큰 impact를 주는지 쉽게 알 수 있다.
이제 왜 Network Diagram을 활용해야 하는지 이해가 될 것이다.
필자가 진행했던 프로젝트 중에서 서로가 서로에게 dependency가 매우 많던 프로젝트가 있었다.
각자 본인의 모듈이 진행이 잘 안되는 이유를 다른 모듈이 끝나지 않아서라고 말했고, 서로가 서로에게 미루는 동안 프로젝트는 계속 지연되었다.
이런 이야기를 하다보면 서로간 긴장감도 생기게 마련이고, 상황이 안좋아지면 감정도 상할 수 있다.
그럴 때는 서로 말만 하기보다는 WBS를 작성하고 Network Diagram을 만들어서 이를 서로 공유하면 훨씬 상호간 이해가 쉽고 일이 원활하게 풀린다.
심지어 서로 작성한 Network Diagram에 동의가 안되더라도, 함께 논의하고 합의점을 찾아갈 수 있으며, 각 Activity에 Importance를 주어 동일한 resource로도 상호간 만족할 수 있는 더 좋은 효과를 거둘 수도 있다.
물론, 이 과정은 전체 프로젝트 진행을 책임지고 있는 PM이 lead하고 이끌어야 한다.
각 모듈 담당자나 담당팀은 아무래도 own하고 있는 모듈위주로 보게 될 수 밖에 없다. 프로젝트 전반을 이해하고 있는 PM의 역할이 중요하다.
Network Diagram을 그리는 방법에는 아래 3가지 방법이 주로 쓰이는데, 일반적으로는 PDM을 가장 많이 사용한다.
1) Precedence Diagramming Method (PDM)
2) Arrow Diagramming Method (ADM)
3) Graphical Evaluation and Review Technique (GERT)
PDM(Precedence Diagramming Method)에는 다음과 같은 4가지의 logical relationship이 있다.
1) Finish-to-start (FS) : A task가 끝나야 B task 진행 가능
2) Start-to-start (SS) : A task가 시작해야 B task 시작 가능
3) Finish-to-finish (FF) : A task가 끝나야 B task도 종료 가능
4) Start-to-Finish (SF) : A task가 시작해야 B task 종료 가능
PDM의 logical relation types우리가 일반적으로 가장 많이 생각하는 것은 FS(Finish-to-start) type이다. 예를 들면, board를 구매해야 board에 post-it을 붙이며 daily scrum을 진행할 수 있는 것이다. 하지만, Scheduling을 하다 보면 SS, FF도 꽤 볼 수 있다. SF는 좀 드문 것 같다.
이제 이를 간단히 실무에 활용해 보자.
특히 activity별 dependency가 많고, 서로에게 영향을 주고 있다면 반드시 Network Diagram 작성이 필요하다.
너무 복잡하게 만들 필요도 없고, 프로젝트 전 과정을 Diagram으로 그릴 필요도 없다.
일단 현재 필요한 부분부터 만들어보고, 활용도를 보면서 확대해 보면 나름 꽤 쓸모가 있다는 것을 알게 될 것이다. :)
TIP1:
WBS 작성 시 각 Activity duration의 기준
R&D 프로젝트에서 개발팀은 흔히 WBS(Work Breakdown Structure)를 사용하여 개발 스케줄을 작성한다.
WBS 에 각 item을 작성하였는데, item별 스케줄이 바로 나오지 않는다면 해당 item은 더 break되어야 한다. 즉 더 많은 Activity들로 세분화되어야 한다. 충분히 세분화 되었다면 해당 스케줄이 산정이 될 것이다.
WBS의 Activity단위가 너무 길거나 너무 짧아 애매하다면 8:80 rule을 활용해보자.
각 Activity가 최소 8시간을 넘어야 하며, 최대 80시간을 넘기면 안된다는 원리이다. 모든 프로젝트에 적용할 수는 없지만, 기준이 없을 때 8:80로 시작하고, 추후 조금씩 조정해가면 수월하게 프로젝트 기준을 잡아갈 수 있다.
TIP2:
WBS를 산정하는데 필요한 추가 정보
만약 개발자들이 각 Activity별로 정확한 스케줄을 산정하는데 추가적인 data가 필요하다면, 해당 data를 제공하는 것은 PM의 역할이다. Project background가 될 수도 있고, Project Charter가 될 수도 있으며, 이와 연계된 타 팀의 schedule일 수도 있다. 무엇인지는 상관이 없다. PM은 Project가 원활히 initiate, planning, execute될 수 있도록 leading하는 역할을 해야 하며, 지속적 mornitoring and control로 risk 및 schedule관리를 해야 한다.
