MS Project 대안, PM은 무엇을 보고 고를 것인가

MS Project의 대안을 찾는 일은 대개 더 싼 도구를 찾는 일이 아니다. 지금 팀이 일하는 방식에 맞는 도구를 찾는 일이다. MS Project는 수십 년간 다듬어진 가장 깊은 일정 엔진이다. 그런데도 많은 PM이 대안을 검색한다. 이 글에서는 그 이유를 도구와 상황의 불일치로 정리하고, 대안을 고를 때 실제로 봐야 하는 4가지 기준을 짚는다. 마지막에는 반대로 MS Project가 정답인 경우를 분명히 한다.

MS Project는 왜 표준이 되었나

먼저 인정할 것은 인정하자. MS Project는 CPM 계산, 자원 평준화, 비용 관리까지 갖춘 일정 도구의 원형에 가깝다. 건설·방산·EPC 같은 대형 프로그램에서 수십 년간 표준으로 쓰였고, 일정 관리를 가르치는 교육도 오랫동안 사실상 이 도구를 기준으로 삼았다. 일정 엔진의 깊이만 놓고 보면 지금도 이만한 도구는 많지 않다.

그러니 "MS Project가 나빠서" 대안을 찾는 것이라면 질문이 틀렸다. 도구는 훌륭하다. 다만 그 훌륭함이 지금 내 프로젝트에 필요한 종류인지는 따로 따져 봐야 한다.

그런데 왜 대안을 찾는가

첫째, 깊은 만큼 무겁다. 자원 평준화까지 쓰는 PM은 많지 않다. 대부분은 기능의 일부만 쓰면서 도구 전체를 익혀야 하는 부담을 진다. 도구를 익히는 시간이 계획을 다듬는 시간보다 길어지면 순서가 뒤바뀐 것이다.

둘째, 계획이 다시 문서로 돌아다니기 쉽다. 많은 현장에서 MS Project는 PM 한 사람만 여는 프로그램으로 남는다. 팀원과 고객은 도구를 열지 않고 PM이 뽑아 준 PDF나 엑셀을 본다. 그러면 계획은 계속 갱신되는 모델이 아니라 한 시점을 찍어 둔 문서가 되고, 문서로 일정을 관리할 때 겪던 문제가 그대로 돌아온다.

셋째, 도입 절차가 무겁다. 라이선스 결재를 올리고, 설치하고, 팀원 수만큼 비용을 계산해야 한다. 계획 도구 하나를 쓰려고 밟아야 하는 절차가 프로젝트 착수보다 무거워지기도 한다.

3가지 모두 도구의 결함이 아니라 도구와 상황이 맞지 않아 생기는 문제다. 그래서 대안을 고르는 기준도 기능이 몇 개인지가 아니라 이 불일치를 푸는지에 있어야 한다.

기준 1. WBS를 정본으로 다루는가

경량 도구 상당수는 계획을 "작업 목록과 막대"로 본다. 그런데 일정의 출발점은 범위의 구조다. 해야 할 일이 빠짐없이 분해됐는지(100% Rule), 그 계층을 검증할 수 있는지를 도구가 알아야 빠뜨린 일이 일정에서도 빠지는 사고를 막을 수 있다. 분해하는 방법은 WBS 작성법 5단계에서 다뤘다. 후보 도구를 볼 때 WBS가 장식인지 정본인지부터 확인하자.

기준 2. 베이스라인과 변경 이력이 있는가

실행이 시작되면 계획은 "원래 계획과 견줘 지금 어디쯤인가"에 답할 수 있어야 쓸모가 있다. 승인 시점의 계획을 스냅샷으로 고정하는 baseline, 그 기준과 현재를 비교하는 화면, 누가 무엇을 바꿨는지 남는 이력. 이 3가지가 없으면 계획을 작성하는 도구는 될 수 있어도 계획을 통제하는 도구는 되지 못한다. MS Project가 오래 표준으로 남은 이유 중 하나가 이 통제 기능이다. 대안을 고른다면 같은 질문에 답할 수 있어야 한다.

기준 3. 일정을 계산하는가, 그리는가

간트차트를 그리는 도구와 계산하는 도구는 다르다. 종속성을 입력하면 날짜가 나오는지, 선행이 밀리면 후행도 따라 밀리는지, critical path가 표시되는지를 봐야 한다. 근무일과 공휴일 캘린더를 반영하는지도 마찬가지다. 계산 원리는 간트차트 만드는 법에서 다뤘고, 하루 지연이 전체 일정을 얼마나 미는지는 한 작업이 3일 밀리면에서 실제 데이터로 확인했다. 확인 방법은 간단하다. 체험판에서 선행 작업 하나를 일부러 며칠 밀어 보자. 후행 막대가 제자리에 있다면 그 도구의 간트는 계산 결과가 아니라 그림이다.

기준 4. 팀이 실제로 쓰는가

도구를 익히는 부담은 두 갈래로 나눠 봐야 한다. 계획을 편집하는 PM이 지는 부담과, 계획을 열어 보고 진척을 입력하는 팀원이 지는 부담이다. 앞쪽은 투자할 가치가 있다. 문제는 뒤쪽이다. 팀원 쪽 부담이 크면 도구는 다시 PM 혼자 쓰는 프로그램이 되고, 계획은 다시 뽑아낸 문서로 돌아다닌다. 브라우저에서 바로 열리는지, 읽기 전용으로 공유되는지, 진척을 클릭 한 번으로 입력할 수 있는지를 확인하자. 앞에서 말한 두 번째 문제는 여기서 갈린다.

접근 방식 비교: 데스크톱 도구와 브라우저 도구

오른쪽이 늘 정답인 것은 아니다. 왼쪽 열의 깊이가 실제로 필요한 프로젝트에서 오른쪽을 고르면, 이번에는 반대 방향으로 불일치가 생긴다.

그래도 MS Project가 맞는 경우

다음 상황이라면 대안을 찾는 일 자체가 비용이다.

• 자원 평준화, 비용 관리 같은 깊은 기능을 실제로 매주 쓰는 대형 프로그램
• 발주처나 업계 관행이 MS Project 산출물을 표준으로 요구하는 경우(건설·방산·EPC)
• 조직에 이미 라이선스와 숙련된 전담 플래너가 있는 PMO
• 수백 개 작업과 여러 프로젝트에 걸친 자원 배분을 한 사람이 계산해야 하는 경우

도구를 바꾸는 일도 하나의 프로젝트다. 위 조건에 해당한다면 지금 쓰는 도구를 더 깊이 익히는 편이 낫다.

함께 살펴볼 만한 도구들

대안을 찾기로 했다면, 후보마다 강점이 놓인 자리가 다르다.

• Microsoft Planner는 같은 Microsoft 생태계 안에서 쓰는 가벼운 협업 작업 관리 도구다.
• Smartsheet는 스프레드시트 문법 위에 간트와 자동화를 얹었다.
• OpenProject는 오픈소스다. 직접 운영할 수 있는 조직에 맞다.
• GanttPRO·TeamGantt 계열은 간트 중심의 경량 협업 도구다.
• wbsgantt는 우리가 만드는 도구다. WBS 트리를 정본으로 두고, 거기서 계산되는 간트와 baseline, 읽기 전용 공유 링크로 위 4가지 기준을 정면으로 겨냥했다. 대신 자원 평준화는 없다. 그 기능이 매주 필요하다면 MS Project가 맞는 선택이다.

기능표를 늘어놓고 항목 수를 세는 비교는 대개 실패한다. 4가지 기준 가운데 지금 프로젝트에서 가장 아쉬운 곳이 어디인지부터 정하면, 후보는 생각보다 빨리 좁혀진다.