계획이 없으면 지연도 없습니다.
프로젝트 일정준수는 프로젝트가 제대로 진행되고 있는지를 판단하는 대표적인 지표이기 때문에 프로젝트 관리자와 이해관계자들의 관심이 많습니다. 그 때문에 일정이 지연될 때 관리자와 팀원 간에 일정 지연에 대한 책임소재를 규명하기 위한 갈등이 자주 발생합니다.
팀원 입장에서는 무리한 일정을 밀어붙이는 관리자가 원망스럽고, 관리자 입장에서는 약속을 지키지 못한 팀원을 탓할 수 있습니다. 관리자와 팀원 간에 갈등이 발생하는 근본원인은 일정목표가 객관적인 생산성에 근거하지 않기 때문입니다. 일정준수는 객관적인 생산성의 달성을 평가하는 것이 아니라 주관적인 계획의 달성을 평가합니다.
따라서 최선을 다하고도 일정이 지연될 수 있고, 쉬면서 해도 일정을 준수할 수도 있습니다. 복불복에 가까운 일정준수의 부작용을 줄일 수 있는 방법은 없을까요? 결론부터 말하면 프로젝트 방식이 아닌 운영으로 수행가능한 업무를 프로젝트처럼 관리하지 않으면 됩니다.
일정준수 평가는 왜 공정하지 않을까?
아래 그림에서 프로젝트 A는 프로젝트 B보다 같은 기간인 10개월 동안 2배의 업무를 수행했음에도 불구하고 2개월 지연이라는 나쁜 평가를 받습니다. 반대로 프로젝트 B는 프로젝트 A보다 절반의 일을 하고도 2개월 단축이라는 좋은 평가를 받습니다.
불공정한 일정준수 평가 사례이러한 문제가 있음에도 불구하고 프로젝트는 일정, 예산, 품질 목표대비 실적으로 평가할 수밖에 없습니다. 계획대비 실적 평가 외에는 모두가 동의할 수 있는 다른 방안이 없기 때문입니다.
흙수저가 금수저를 따라잡기 힘들듯이, 일정 여유가 없는 가난한 프로젝트는 노력을 해도 일정 여유가 많은 부자 프로젝트보다는 일정을 준수할 가능성이 낮습니다. 계획수립에 대한 공정한 룰이 없기 때문에 업무를 열심히 하는 것보다 일정과 예산 버퍼를 많이 확보하는 것이 훨씬 더 중요한 것이 현실입니다. 그 결과 프로젝트 버퍼를 확보하려는 프로젝트 팀과 버퍼를 제거하려는 이해관계자 간에 기싸움을 하기도 합니다.
일정준수 평가의 불공정을 줄이는 방법은?
소프트웨어 정기릴리즈, VoC 처리, 자동차 생산, 배달 서비스 등은 빠를수록 좋으며 정해진 납기가 없는 경우가 대부분입니다. 이런 업무들은 “언제까지 해야 하나요?”라고 물어보면 대부분의 답변은 “빠를수록 좋아요”라고 합니다. 운영업무는 일정준수보다 업무스피드(예:리드타임, TAT(Turn Around Time)가 더 중요합니다. 스피드는 같은 업무를 더 빨리 처리하거나 같은 시간 동안 더 많은 업무를 처리하면 향상됩니다. 따라서 대부분의 운영업무는 주어진 기간(시간) 내에 창출하는 결과물의 양(생산성)을 평가합니다.
상품 출시 후 운영단계에서 상품관리자가 상품개선 요구사항의 우선순위를 정하고 스프린트 계획만 수립하는 것도 비슷한 맥락에서 생각할 수 있습니다. 물론 스프린트라고 해서 일정계획이 없는 것이 아니지만 처음 상품을 출시하는 프로젝트 일정계획에 비해서는 훨씬 단순합니다.
백로그에 있는 요구사항들을 우선순위에 따라 매월 릴리즈 하는 방식에서는 일정준수에 대한 압박이 줄어들고, 이번 스프린트에는 어떤 기능을 개발할지에 대한 의사결정이 중요합니다. 서비스 상품 출시 후 서비스 개선은 지속적으로 통합하고 배포하는 데브옵스(DevOps) 체계를 구축한다면 스프린트보다 더욱 복잡한 계획수립을 최소화할 수 있습니다.
프로젝트 팀이 일정 양의 결과물을 지속적으로 제공한다면 이해관계자들이 프로젝트 팀을 신뢰할 수 있습니다. 프로젝트 팀을 신뢰하면 프로젝트 팀과 이해관계자들이 일정계획을 수립하고 통제할 필요가 없기 때문에 남는 시간을 생산적인 활동에 사용할 수 있습니다. 상대를 신뢰하면 ‘지연’이라는 단어는 사용할 필요가 없습니다. 신뢰하는 후배가 이번달에는 우선순위에 따라 5개의 업무를 하겠다고 했는데 그중 하나를 끝내지 못해도 그럴만한 사정이 있었겠지라고 믿는 것과 같은 이치입니다.
기업의 전산조직과 현업의 사용자들 사이에서도 이러한 신뢰를 만들 수 있습니다. 신뢰가 형성되면 특정일에 꼭 반영해야 하는 업무를 제외한 나머지 업무들은 우선순위에 따라 업무를 처리하면 됩니다. 기업의 정보시스템을 개선하는 대부분의 일들은 빨리 처리할수록 좋지 몇 월 며칠까지 하지 않으면 큰일이 발생하지 않습니다.
프로젝트는 같은 성과를 창출해도 계획에 따라 평가가 달라지지만 운영업무는 계획이 아닌 성과에 기반한 평가가 가능합니다. 그 이유는 다음과 같습니다.
• 과거 실적에 기반하여 목표를 설정합니다.
대부분의 운영업무는 동일한 조직이 동일한 업무를 수행하기 때문에 전년 성과대비 XX% 향상과 같이 수립하는 것이 용이합니다. 따라서 운영업무는 프로젝트처럼 비현실적인 목표를 수립할 가능성은 매우 낮습니다.
• 업무를 요청하는 리더가 담당자의 노력을 알 수 있습니다.
리더와 담당자가 오랫동안 함께 유사한 운영업무를 하는 경우가 많습니다. 이런 상황에서는 작업을 요청하는 리더가 업무의 특성과 담당자의 노력을 가까이에서 파악할 수 있습니다.
프로젝트성 업무와 운영성 업무를 양 끝으로 했을 때 조직에서 수행하는 업무는 그 사이 혼합형 업무가 많습니다. IT 조직에서는 프로젝트와 운영의 경계가 점점 사라지고 있습니다. 프로젝트는‘일정’이 중요하고 운영은 ‘생산성’이 중요합니다. 생산성을 추구해야 할 업무를 일정준수 중심으로 관리하면 안 됩니다. 두 가지의 관리방식은 전혀 상이하기 때문입니다.
https://brunch.co.kr/@kbhpmp/160
김병호 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
