"팀장님이 프로젝트의 걸림돌이에요"   

2010. 5. 18. 09:00
반응형

여러분이 30일 짜리 프로젝트를 수행하게 됐다고 생각해 보세요. 그렇다면 여러분이 '순수하게' 프로젝트를 수행할 수 있는 기간은 얼마나 될까요?

"30일 짜리라고 했으니 당연히 30일이 답이잖아. 이거 너무 쉽잖아?" 라고 생각했을지 모르겠군요. 그러나 애석하게도 30일 짜리 프로젝트에서 여러분이 순수하게 프로젝트 수행(문제 해결)을 위해 쓸 수 있는 시간은 30일보다 훨씬 작을 수 있습니다.

그 이유는 바로 '보고와 리뷰' 때문입니다.

(프로젝트가 힘들 때 시원한 약수 한잔을 쭉~)


만일 여러분의 직속상사가 위로 4명이 있다면(예를 들어, 팀장, 담당임원, 사업부장, 사장), 30일 짜리 프로젝트에서 여러분이 문제 해결에 쓸 수 있는 시간은 얼마일까요? 반드시 30일 안에 끝내야 하는 프로젝트라면, 아마도 17일 밖에 안 될 겁니다. 프로젝트의 거의 1/2이 되는 기간이죠.

1~17일차 : 문제 해결
18일차 : 팀장 보고
21일차 : 담당임원 보고
24일차 : 사업부장 보고
27일차 : 사장 보고
30일차 : 최종 보고


프로젝트를 수행할 때 이런 식의 말들이 오고가지 않습니까?

팀장 : 프로젝트 결과물이 언제 나오나?
프로젝트 책임자 :  26일차 정도에 프로젝트 결과가 나옵니다.
팀장 :  안돼, 임원님과 사업부장님이 충분히 검토할 시간이 없잖아.
           그리고 나도 검토를 해야 하니까, 17일차 까지 끝내도록 해.
           그게 어려우면 초안이라도 17일차까지 보고해.

위로 4명의 상사가 있다면, 각각에게 보고를 하고 '리뷰 결과'를 반영해서 보고서를 고치는 일을 4번이나 반복해야 합니다. 문제는 상사들에게 각각 리뷰(혹은 결재)를 받는 시간이 3~4일씩 걸리기 일쑤라는 겁니다. 바쁜 탓인지, 게으른 탓인지 보고서를 올리면 즉각 검토해주는 경우는 별로 없습니다. 마음 먹고 앉아서 리뷰하면 1시간도 안 걸릴 일이 그렇게 함흥차사처럼 늘어집니다.

더욱 허무한 경우는 기껏 3~4일이나 기다렸더니 "별로 고칠 것 없이 이대로 됐다. 윗선에 보고하자"란 말을 들을 때입니다. 또 어떨 때는 휴가나 출장을 이유로 "그때는 시간이 안 되니까 미리 한번 보여 달라"고 말하는 통에 밤을 새워서 보고서를 작성해야 합니다.

직속상사가 한 명이 생길 때마다 '검토'라는 이유로 문제 해결에 쓰일 프로젝트 기간을 갉아 먹는 현상은 일종의 '채찍 효과(Bullwhip Effect)'에 해당됩니다. 각 상사는 안정장치라는 이유로 3~4일 정도의 리뷰 시간을 확보하는 게 아무렇지도 않겠지만, 보고 단계가 많아지면 그것이 쌓이고 쌓여서 프로젝트의 후반부를 '보고하고 검토하는 데'에 시간을 소모하도록 만듭니다. 배보다 배꼽이 더 크게 되죠.

요즘 회사 내에서 자체적으로 여러 프로젝트를 할 텐데, 위와 같은 현상 때문에 문제 해결에 많은 공을 들이기보다는, 보고를 잘하고 결재를 잘 받는 일에 힘을 소모하는 모습을 자주 듣습니다. 30일 짜리로 계획됐다가 결재자들의 검토가 늦어지는 바람에 일정을 훌쩍 넘겨버리는 일도 흔합니다.

특히 전통적으로 위계질서가 강조되는 기업일수록 그러한데, 속도가 중요시되는 기업환경에서 이러한 '늘어짐 현상'은 조직을 정체시키는 끈적끈적한 병폐로 자리잡고 맙니다.

프로젝트는 단기간 내에게 힘을 집중시켜 문제를 해결하는 과정입니다. 따라서 윗선에 보고하고 검토를 받는 기간을 최소화함으로써 문제 해결에 매진하게 해야 합니다. 프로젝트의 보고 단계는 다음과 2단계면 충분합니다.

1~26일차 : 문제 해결
27일차 : 프로젝트 매니저 검토
28일차 : 프로젝트 오너 보고
30일차 : 최종 보고

프로젝트가 실행되면 반드시 프로젝트 매니저와 프로젝트 오너(프로젝트 결과물을 최종적으로 의사결정하고 실행의 책임을 지는 사람)를 선정하고, 중간에 다른 의사결정자들이 끼지 못하게 해야 합니다. 모든 의사결정은 프로젝트 매니저와 프로젝트 오너가 책임지고 내리도록 프로젝트 추진조직을 구조화해야 불필요한 '보고와 리뷰' 때문에 역량이 흐트러지는 일을 방지할 수 있습니다.

제 경험상, 중간에 '검토자' 혹은 '결재자'가 많아질수록 프로젝트가 늘어질뿐더러 애초에 시도했던 '예리하고 과감한' 해결책이 초점을 잃고 뭉뚝하게 변하는 일이 많습니다. 중간 결재자들이 위험을 최소화하려는 시도가 더해지는 바람에 그렇게 돼 버리죠. 프로젝트 수행자들이 미처 생각하지 못한 뛰어난 아이디어를 던져주는 경우는 거의 없습니다.

그들이 위험을 최소화하려는 의도는 해결책의 위험을 헷지하려 한다기보다는, 자신들에게 튈지 모를 불똥을 사전에 없애기 위해서인 경우가 아주 많습니다. 소위, '윗선에게 깨지지 않으려는' 시도에 불과합니다.

프로젝트의 성공요인은 여러 가지가 있지만, 의사결정(보고와 결재) 단계를 최대한 단축시키는 것도 문제 해결의 질과 속도를 높이는 데 매우 중요한 방법임을 기억하기 바랍니다.

여러분의 프로젝트는 어떻습니까?


인퓨처컨설팅 & 유정식의 포스트는 아이폰 App으로도 언제든지 볼 수 있습니다.  여러분의 아이폰에 inFuture App(무료)을 설치해 보세요. (아래 그림 클릭!)
                
inFuture 앱 다운로드 받기

반응형

  
,