안과장은 프로젝트 일정 계획만 가지고 상당한 시간을 소비했다. 그런데 고치고 또 고쳐도 마음에 쏙 드는 그런 모습은 아니었다. 각 팀이 수행하는 작업들 사이에는 의존성을 가진 부분도 있고, 그렇지 않은 부분도 존재했다. 결국 일을 잘게 쪼개서 배치해보아야 이른바 Critical Path를 찾을 수 있다. 전체적으로 시스템 개발이 가능하도록 작업을 쪼개서 WBS(Work Breakdown Structure)를 작성했다. 그 위에 주요 지점을 찾아 마일스톤으로 표기한다. 팀별로 작성한 WBS의 작업들을 의존성과 우선순위에 따라 재배치하고 여러 차례 검토를 해서 통합 일정을 만들었다. 안과장은 초기 프로젝트 관리의 한 축인 WBS 작성을 마무리하고 뿌듯한 마음에 퇴근을 한다.

다음날 고객사 표준화팀에서 강제하는 PMS(Project Management System) WBS를 등록했다. 안과장이 맡고 있는 프로젝트는 다수의 다른 프로젝트와 함께 진행되고 있기 때문에 고객들은 엑셀이나 MS프로젝트가 아닌, PMS 시스템을 통해 전체적인 진척도를 감독했다. 워낙에 프로젝트를 동시다발적으로 진행하고 있으니 필요한 시스템이다 싶긴 한데 등록하고 살펴보는 과정이 MS프로젝트를 쓰는 것에 비해 불편한 느낌이 드렀다. 주간보고 시점에서 그때까지의 진척도를 입력해주지 않으면 고객이 보는 화면에는 해당 작업이 지연으로 나타났다. 따라서, 주간보고 시점에는 반드시 진척도를 입력해야 했다. 그런데 한 가지 애매한 점이 있었다. 전사 주간보고가 금요일 오전에 있고, 고객들도 준비 시간이 필요하기 때문에 안과장은 목요일 오전에 주간보고를 해야 했다. 진척도는 금요일을 기준으로 작성해야 하는데, PMS에는 수요일 저녁에 입력해둬야 했다.

퇴근 길에 좋은 방법이 없을까 골똘히 생각해봤다. 지난 몇 년간 프로젝트에서도 번번히 동일한 문제가 있었다. 일정 측정 시점과 보고 시점의 불일치는 근본적으로 서로 다른 두 개의 시간에서 비롯한다. 하나는 프로젝트를 측정하는 시간이고, 다른 하나는 조직의 시간이다. 프로젝트는 상대적으로 단기간에 구체적인 목표를 가지고 일어나는 활동이다. 반면에 조직 특히, 기업의 경우는 영속성을 지향한다. 안과장은 내심 '역동성을 가진 프로젝트의 특성을 무시하고, 지나치게 조직의 시간에 맞추다 보면 병목이 생기겠다'는데 생각이 미쳤다. 흥미로운 사실은 하나의 조직만 있지 않다는 것이다. 안과장은 고객에게만 보고하는 것이 아니라 자신의 회사에도 조직차원의 주간 보고를 해야했다. 두 조직의 시계는 또 미묘하게 다르다. 다름을 이해하고 나니, 이들의 불일치를 만회할 수 있는 방책들이 떠올랐다.

점검과 피드백을 위해 구분해놓은 '반복(Iteration)' 이라고 부르는 특정 주기가 지났다. 안과장은 팀이 쏟아부은 시간이 알차게 쓰여졌는지 돌아보는 시간을 가졌다. 그리고 계획과 실천이 얼마나 일치하고 있는지도 살펴봤다. 특정 기능을 개발하는 구체적인 작업에 있어서 계획과 실천은 물론 수치 오차는 컸지만, 상대적인 비율은 많이 틀리지 않았다. 그런데 전체적으로 마치 가정에서 설겆이에 비유할 수 있는 지원 작업들에 들어가는 공수는 WBS에서 대부분 누락하고 있었다. 또한, 갑자기 발생한 위험요소나 불거져나온 기술 이슈에 따른 회의로 예측하지 못한 시간이 많이 쓰였다. 다음 반복에 대한 계획에는 이들을 대비하여 일정 공수를 '지원 작업'과 '회의/의사소통' 시간으로 배정해두었다. 이를 통해 다음 반복 이후부터는 회의시간이 차지하는 비중을 통제할 예정이다.