IT Life

누구나 전략 기획 고수가 될 수 있다. “업무 속의 전략 기획” ② 목표 달성 방법

2018.02.23 09:30


이번 편은 지난 27편. “업무 속의 전략 기획” ① 회의록 편에 이어 두 번째 이야기를 하고자 합니다. 얼마 전 제조업체에 다니는 친구에게서 연락이 왔는데요. 지난 몇 년간 자신이 속한 조직이 계속해서 목표 달성을 못 해 팀원들이 지쳐 있고, 몇몇 사람들은 거의 포기 상태에 있다는 것입니다.


영업하는 친구의 조직은 조직원들 대부분이 40대고, 일부는 50대 고참도 몇 명 있었습니다. 다들 열심히 뛰고 있는데 이상하게 매년 목표 달성을 못 하게 되고, 다음 해에 목표를 줄여도 결과는 똑같다는 것입니다. 조직원들 대부분 영업을 10년 이상 하신 분들이기에 자신들도 답답한 심정은 이루 말 할 수 없을 정도라고 하네요.


친구의 이야기를 듣고 문득 생각난 방법이 있었습니다. 사실 제가 몸담고 있는 회사에서는 너무나도 익숙한 방법이지만 다른 회사에서는 그렇지 않을 수도 있다고 생각해 저희 회사 이야기를 해 주었습니다. 친구의 반응이 너무 좋아서 그 내용을 여러분들과 나누고자 합니다.


저희 회사는 기업, 정부 기관과 지자체 등을 대상으로 IT 서비스를 제공하는 회사입니다. IT에 익숙하지 않은 분께 저는 항상 건설회사와 비유해서 말씀을 드리는데요. 디테일하게 살펴보면, 여러 가지 차이가 있겠지만 큰 틀에서 저희 회사와 건설의 프로세스는 많이 유사합니다.



건물주는 5층짜리 건물을 50억 원에 건축하고 싶어 합니다. 그러면, 맨 먼저 건물주와 인터뷰를 통해 건물주가 원하는 바를 최대한 만족시키면서 비용에 맞춘 5층짜리 건축물을 설계하게 됩니다.  (분석•설계) 이 설계가 고객의 마음에 들면, 본격적으로 땅을 파는 토목공사부터 시작해서 건축하게 되죠. (시스템 개발)


그 후 완공이 되면, 최종 감리 후(사용자 테스트) 사용 승인을 득한 후(Open) 계약이 종료됩니다. 여기에서 5층짜리 건축물을 “IT 시스템”이라고 생각하시면 그 절차가 거의 유사하다고 하겠습니다. 그런데요. 모든 건축물(IT 시스템)을 건축할 때는 ‘시간’과 ‘비용’이라는 두 가지 제한 요소가 있습니다. (일반적으로는 품질을 포함하여 QCD(Quality, Cost, Delivery)로 불리지만 여기에서 품질은 기본으로 여겨 제외하고 생각해 보겠습니다.)


이 두 가지 제한 요소가 결국 프로젝트의 최종 목표가 됩니다. 그렇다면, 시간(납기)과 비용이라는 목표를 달성하기 위해 건설회사나 IT 서비스 회사가 사용하는 방법이 무엇일까요? 그게 바로 오늘 여러분께 말씀드리고 싶은 내용의 핵심입니다.


실제 프로젝트 현장에서는 무수히 많은 상황이 나오기 때문에 시간과 비용을 맞추려는 방법이 어느 하나라고 말하기는 쉽지 않습니다. 실제 프로젝트 관리 방법론에도 비용, 일정을 포함해 9개 관리 영역이 있으니까요. 그런데도 불구하고, 가장 근본이 되는 것이 있는데요. 바로 그것은 ‘계획’을 세우고 거기에 맞춰서 ‘실행’을 하는 것입니다. 의외로 간단하죠? 이게 전부는 아니지만 바로 ‘계획 수립’에서부터 목표 달성을 위한 방법은 시작됩니다.



여기에서 잠깐 제 친구 이야기로 넘어가겠습니다. 친구에게 목표 달성을 위해 계획을 수립하느냐고 물었습니다. 친구 이야기로는 당연히 계획을 수립한다고 합니다. 친구 회사의 경우(영업)는 월 단위로 목표를 모니터링하고 계획도 월 단위로 수립하고 있었습니다. 내용을 들어보니 ‘누구에게 몇 대’라고 하는 사업티어(기회)가 전부였습니다. 그리고 팀 동료들과 현재까지의 실적만 공유하지 어떤 계획을 하고 있는지 공유하지 않는다고 합니다. 다만, 몇 대까지는 팔 수 있을 것 같다는 예상 정도를 공유한다고 하네요.


이 상황을 IT 프로젝트에 비유해 보겠습니다. 현재 프로젝트에 개발자가 20명이 있습니다. 프로젝트 입장에서 이번 달 총 100개의 프로그램을 개발 완료해야 합니다. 평균적으로 보면, 인당 5개의 프로그램을 개발한다면 목표 달성을 할 수 있는 수치입니다. 


프로젝트 매니저(PM)가 회의를 소집하여 20명의 개발자에게 각자 몇 개씩 할 수 있겠느냐고 물었습니다. 이때 대답의 합이 총 60개라면 어떨까요? 100% 목표 달성을 못 하는 상황이 발생하게 됩니다. 그런데, 개발자 간 어떤 상황인지 정보 공유도 제대로 안 된다면 실제는 60개도 달성 못 할 가능성이 큽니다. 그 이유는 각자 의지치를 담아서 이야기하기 때문입니다.


 맨 먼저 큰 틀에서 목표를 명확히 해야 한다.


계획을 수립할 때 가장 먼저 할 일은 큰 틀에서 단계를 나누고 목표를 명확히 정의하는 일입니다. IT 시스템 구축의 경우, 이미 시스템 Open 일자라는 최종 목표가 정해져 있는 경우가 대부분이기 때문에 이를 단계로 나누고, 각 단계를 언제까지 완료할 것인지 일정 목표를 수립하게 됩니다.


아래 그림1의 경우, 제가 12년 전에 참여했던 프로젝트의 단계와 마일스톤 예시입니다. 9월 5일에 시작해서 최종 Final Report(종료보고)를 다음 해 4월 13일까지 완료해야 합니다. 그것을 총 3단계(RS, BA, SD)로 나누고, 각 단계를 언제까지 완료할지 정하고, 그와 연동해서 의미 있고 중요한 이벤트 일정 목표도 함께 수립하게 되면 첫 단추는 잘 끼운 게 됩니다.


l 그림1. IT 시스템 구축 단계 및 마일스톤 예시


사실, 대부분 일반적인 업무에서는 이 정도까지 세우고 일하는 경우가 대부분입니다. 제 친구 회사도 이 정도 계획을 세운 것이니까요. 그러나, 여기서 멈추면 안 됩니다. 이제부터 시작입니다.


 계획은 월 단위, 주 단위 레벨로 디테일(Detail)해야 한다.


위 그림1을 기준으로 설명해 보면, 계획 수립의 두 번째 단계는 각 단계를 더 세분화하는 작업입니다. 즉, 위 그림1에서 [Stage 1 RS]가 9월 5일부터 10월 말까지인데요. 이 단계를 더 세분화하는 겁니다. 그렇다면, 어느 정도 레벨까지 세분화해야 할지 막막할 텐데요. 가장 좋은 것은 ‘일 단위’ 레벨까지 세분화하는 것입니다. 현실적으로 어렵다면 최소한 주 단위 Task와 일정 목표는 수립되어야 합니다. 


실제 IT 프로젝트의 경우 아주 디테일하게 작성을 해야 하므로 보통 MS Project 라는 전문 도구를 사용하게 됩니다. 여러분들의 경우 엑셀로도 충분히 작성하실 수 있을 겁니다. 아래 그림2는 IT 시스템 구축 프로젝트에서 일반적으로 관리하는 계획 수준을 보여주기 위해 제가 임의로 일부만 작성해 본 예시입니다.


그림2. IT 시스템 구축 일정 계획 예시(WBS)


IT 프로젝트의 경우, 많은 이들이 투입되기 때문에 디테일하게 관리되지 않으면 대부분 일정 목표를 준수하지 못하는 경우가 많습니다. 그리고 한 사람만 잘 한다고 목표 달성을 할 수 있는 것이 아니기에 각 업무는 일정 목표와 함께 누가 하고, 어떤 산출물을 만들어야 하는지를 명확히 합니다.


그렇다면, 제 친구와 같이 영업의 경우에는 어떨까요? 저희 회사 모 상무님께서 항상 영업들에 하시는 말씀이 있는데요. “영업들도 1년짜리 프로젝트 PM(프로젝트 관리자)이 되어야 한다.”입니다. 즉, 앞서 제가 말씀드린 상세한 계획을 세우고 움직여야 한다는 의미입니다. 물론, 영업과 시스템을 구축하는 일은 다르므로 관리되는 항목이나 목표는 다를 것이나 맥락은 똑같다는 의미입니다. 디테일하게 계획하고, 실행하라는 것이죠.



좀 더 설명해 드리면, 영업은 목표가 재무적인 숫자일 겁니다. 제 친구의 경우, 제품 판매 대수가 목표인데요. 연간 100대를 팔아야 한다고 가정해 보겠습니다. 그럼, 100대라는 년 단위 목표를 월 단위로 쪼개야 합니다. 아마도 사람마다 방식은 다를 거라고 생각합니다.


만약, 2월 목표를 8대로 했다고 가정하면, 이것을 다시 주 단위로 쪼개서 관리하는 것입니다. 제 친구 회사의 경우에는 주 단위로 목표를 관리하는 것보다는 월 단위로 관리하는 것이 더 효과적일 것 같았습니다. 기간 단위는 여러분 업무 특성에 맞게 스스로 판단하시면 됩니다.


대신, 월 목표를 달성하기 위한 중간의 주요 단계가 있을 겁니다. 이 단계는 목표 달성을 위해 잘 가고 있는지 점검할 수 있는 단위로 이해하시면 됩니다. 이런 내용은 영업 전략과 맞물려 있으므로 실제 여러분들이 해야 하는 일들을 가능하면 일 단위, 정 어렵다면 주 단위까지 세분화해서 적고, 그 일들의 일정과 산출물(Output) 목표를 정의해야 합니다.


그리고 그 계획에 맞춰 실행해야 합니다. 즉, 목표를 세분화하는 것보다 더 중요한 것은 그 세분화 된 목표의 달성 가능성을 점검할 수 있는 의미 있는 Task 단위로 일정과 산출물(Output)을 정의하는 것입니다.


영업이 5대의 제품을 팔 수 있는 사업 기회가 있다고 가정할 때, 5대를 최종 계약하기 전까지의 단계가 있을 겁니다. ‘최초 고객 방문’이라는 Task가 있다면, 이 Task를 언제 할 것인지, 그리고 이 Task를 통해 얻어지는 산출물(Output)이 무엇이 되어야 하는지를 정의해야 합니다. 2월 28일(수)에 방문하는 것으로 하고, 산출물(Output)을 ‘고객의 예산 및 요구사항’을 알아내는 것이라고 정의하면 될 것입니다. 


그 후에는 고객의 예산과 요구사항에 맞는 제품을 어떻게 제안할 것인지 전략을 정하고, 다음 고객을 방문해서 제안하거나 입찰에 참여하거나 등등의 후속 Task들이 있을 겁니다.



이것을 작성하다 보면, 여러 사업 기회에 대해 F/up 해야 하므로 내가 가지고 있는 시간 자원을 어떻게 배분할 것인지 고민하게 될 것이고, 그 고민을 통해 더욱 효율적으로 일을 할 수 있게 되는 효과도 함께 얻게 됩니다.


물론, 관리자로서는 이러한 일정들이 통합적으로 관리되고 정기적인 회의에서 공유된다면, 어떤 직원은 여유가 있지만, 다른 직원은 중요한 업무가 많아 오히려 일부 사업 기회를 놓치는 상황에 있을 때 팀원들 간의 업무 조정을 통해 조직 전체가 효율적인 영업 활동을 전개할 수 있어 최소한 중요한 사업 기회를 놓치는 일은 막을 수 있게 됩니다.


 계획 수립 시, 단기 목표 외에 중요한 업무는 모두 작성되어야 한다. (MECE 관점)


계획을 수립할 때 MECE(Mutually Exclusive, Collectively Exhaustive)적 접근을 하라고 추천합니다. 


이 의미는 모든 업무를 빠뜨리지 않고 작성하라는 의미가 아니고, “중요한 업무를 빠뜨리지 말고 계획에 반영하라.”라는 것입니다. 특정 기간 해야 할 일은 그 기간의 단기 목표 달성을 위해서만은 아닐 겁니다. 다음 단계 목표 달성을 위한 선행 작업일 수도 있고, 내년 목표를 위한 선행 작업일 수도 있을 겁니다. 이것을 놓치게 되면 장기적인 목표 달성은 어렵게 됩니다.


영업의 경우, 당장 제품을 판매할 수 없을지라도, 새로운 고객을 만들거나, 새로운 사업 기회를 찾으려는 일들은 계속되어야 합니다. 또한, 기존의 고객들을 관리하는 것도 중요할 겁니다. 예를 들어, 매월 고객 이벤트를 챙기거나, 고객을 정기적으로 방문해서 제품 사용상의 불편함은 없는지 확인하는 케이스일 겁니다. 또한, 우리가 계획 수립 시 예상하지 못했던 긴급하고 중요한 일 들이 생길 수 있으므로 어느 정도 일정상의 여유를 반영하는 것도 필요합니다.



이런 세세한 계획이 없다면, 사람은 어느 순간 방황하게 됩니다. 자신이 어느 위치에 와 있는지, 무슨 일을 하고 있는지 모르게 됩니다. 특히, 일이 잘 풀리지 않을 때는 더욱 그렇게 되죠. 자신이 먼저 해야 할 일이 여러 개가 있는데도 이를 망각한 채 과감하게 포기해도 되거나 다른 이에게 맡겨도 될 하나의 풀리지 않는 일에 집중하게 되는 경우가 많습니다. 이런 상황은 우리가 주위에서 너무나 흔하게 보게 됩니다.


그래서, 우리가 중요한 일과 중요하지 않은 일, 그리고 먼저 해야 할 일과 나중에 해도 되는 일을 나눠보는 작업을 통해 효과적으로 일하는 훈련을 제안하기도 합니다. 너무 중요해서 한 번 더 언급합니다. “중요한 업무가 무엇인지 정의되고, 그 업무는 절대 계획 수립 시 빠뜨리면 안 됩니다.”


 가까운 미래일수록 디테일하게 계획을 수립하되, 계속해서 업데이트 되어야 한다.


계획을 한 번 수립해서 끝까지 가는 경우는 없습니다. 그렇게 된다면 100% 목표 달성을 못 하게 됩니다. 예를 들어, 이번 주 목요일이 되어서 팀원들과 금주 실행계획에 대해 점검을 합니다. 이때 반드시 리스크(Risk)가 나오기 마련입니다.


다행히 그 리스크가 이슈가 되지 않고 사전에 해결이 된다면 문제는 없겠지만, 대책도 없는 상태에서 이슈가 된다면 목표 달성에 치명적인 걸림돌이 되게 됩니다. 그래서, 리스크가 이슈화되었을 때를 가정하여 Plan ‘B’를 수립하거나 전체 계획을 수정해야 합니다.


예를 들어, 개발자 20명 중 한 명이 감기에 걸려 하루 휴가를 사용했는데, 이게 독감일 가능성이 제기되었다면 최악의 경우, 이 개발자는 일주일 동안 출근을 하지 못하는 상황에 부닥치게 되고 이를 그대로 내버려 둘 경우 목표 달성에 차질을 빚게 됩니다. 


이러한 상황을 고려해 해당 개발자의 개발 분을 다른 여유 있는 개발자들에게 재분배 또는 일부 개발자에게 양해를 구하고 초과근무를 하도록 한다든지, 그것도 안 된다면 일부는 금주에 소화하고, 나머지는 차주에 소화하는 것으로 계획을 수정하는 방법 등이 계획에 반영되어 업데이트되어야 합니다.



제 친구 회사처럼 영업도 마찬가지일 것입니다. 리스크(Risk) 발생은 사람일 수도 있지만, 제조업일 경우 공장일 수도 있고, 자재 수급의 문제일 수도 있을 겁니다. 다양한 예측 불가능한 상황들이 계속되기 때문에 팀원 모두는 공동의 목표 달성을 위해 서로의 상황을 공유하고, 때에 따라 서로 협조를 구하고, 서로 도와야 리스크나 이슈들을 극복하고 목표 달성을 이룰 수 있는 것입니다.


또한, 몇 개월 후의 일을 디테일하게 계획 세우기는 불가능합니다. 그래서, 처음에는 전체적으로 러프(Rough)하게 계획을 수립하고, 월 단위는 좀 더 구체적으로 수립하고, 다음 주는 정말 상세(Detail)하게 작성되어야 합니다. 즉, 최소한 매주 단위로 계획에 차질은 없는지 점검하고, 현실에 맞게 계획 업데이트와 동시에 차주 계획은 상세하게 업데이트되어야 하겠습니다.


실질적으로 제가 제 친구에게 권했던 것은 기존의 일하는 방식에 변화를 주라는 것입니다. 철저히 계획에 따라 일을 진행하게 되면 효과적으로 일 할 수 있게 되고, 각 시점에 중요하게 처리해야 하는 일들을 놓치지 않게 됩니다. 그리고, 이러한 방식을 조직 전체가 함께 활용하게 되면 조직 내 팀원들 간 업무 시너지도 나게 되어 조직의 목표 달성뿐 아니라 결국 개인 목표 달성의 가능성도 커지게 됩니다.


제가 앞서 설명한 저희 회사 사례는 특정 기간 내에 IT 시스템을 구축하는 일에만 집중해야 하면 되기 때문에 더 구체적이고, 더 조직적이며, 오로지 IT 시스템 구축과 관련된 계획만으로 구성되어 있습니다. 그러나, 제 친구의 경우나 여러분들의 경우 특정 TF에 들어가 일정 기간 동안 그 일에만 집중하지 않는 한 IT 시스템 구축의 경우와 다른 부분들이 많을 것입니다. 그래서, 각자에 맞게 적용하시면 될 것 같습니다. 중요한 것은 ‘계획’ 기반으로 일해야 한다는 점만 기억하시면 됩니다.


글 l 김영주 책임 l LG CNS 블로거 



* 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 LG CNS 블로그에 저작권이 있습니다.

* 해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.



Posted by IT로 만드는 새로운 미래를 열어갑니다 LG CNS
위로