brunch

You can make anything
by writing

C.S.Lewis

by 김진서 Jan 07. 2021

가장 실패한 프로젝트는 무엇일까?

실패, 그다음을 생각하자.


프로젝트의 성공과 실패의 기준에 대해 생각해보자.


일반적으로 프로젝트의 성공과 실패의 기준이 무엇이냐고 PM들에게 물어보면, Q(Quality, 품질), C(Cost, 원가), D(Delevery, 납기)를 얘기한다. 세 가지를 다 만족해야 성공이라는 것이다. 혹자는 고객의 만족(Customer's Satisfaction, 이하 CS로 표기)이 성공의 기준이라고 얘기하기도 한다. (Q, C, D 다 놓쳐도 고객만 만족하면 성공이라는 것이다.) 그 의견에 나도 일정 부분 동의하는 입장이다.


나는 거기에 한 가지를 더하고 싶다. 그것은 프로젝트 투입 인원의 만족도(Member's Satisfaction, 이하 MS로 표기)이다. 따라서, 프로젝트 성공/실패의 기준은 Q, C, D, CS, MS을 바탕으로 평가되어야 한다고 생각한다. 물론 내가 만들어낸, 나 혼자만의 이론이긴 하다.


Q, C, D를 모두 지키고, 고객도 만족하는 시스템을 만들었더라도 내부 인원이 버티지 못하고 모두 떠났다면, 과연 그 프로젝트는 성공했다고 할 수 있을까? 물론 그런 일은 일어나기 힘들다. 대부분의 경우, 내부 인원이 버티지 못할 정도로 힘든 프로젝트는 품질도 엉망이고, 납기 지연으로 원가는 엄청나게 상승한 상황일 것이며, 고객은 고객 나름대로 엄청나게 불만에 가득 차 있는 상황이어서 거의 매일 밤을 새우다시피 일을 해도 도무지 탈출구가 보이지 않는 HELL OF HELL(또는 죽음의 행진 프로젝트)일 것이기 때문이다. 


만일, Q, C, D, CS, MS 다섯 가지 요소 중에서 가장 중요한 한 가지를 꼽으라면 무엇을 골라야 할까? 예전에 PM 양성과정 강의를 들을 때 Q, C, D 중에서는 그래도 D를 지켜야 한다고 강사님이 얘기했었다. "납기는 생명이고, 품질은 자존심"이라는 말과 함께... 


반대의 경우를 생각해보자. 어느 프로젝트가 더 실패한 것인지, 그 기준은 무엇일지 따져보려는 것이다. 내 생각은 그 다섯 가지 요소 중에서 가장 중요한 것은 MS(Member's Satisfaction)라고 생각한다. 모든 걸(Q, C, D, CS) 다 놓친 프로젝트라도 내부 인원(MS)을 지켰다면, 적어도 희망이 있다. 품질도 많이 부족하고, 기간도 많이 지연되어 이익률이 엉망이라도 내부 인원들이 똘똘 뭉쳐 프로젝트를 끝까지 마무리했다면, 그렇게 고생했던 프로젝트에서 얻은 교훈은 조직의 자산이 될 수 있다. 고생한 만큼 개발자들은 성장할 것이다.


솔루션을 보유하고 있든 없든, 서비스만 제공하는 회사이든 아니든, 프로젝트를 수행하는 조직은 프로젝트를 통해 조직 구성원들의 성장을 이끌어낼 수 있어야 한다. 결국 프로젝트는 사람이 하는 것이고, 사람의 역량을 성장시키지 못하는 회사는 미래가 어둡다. 이번에 한 실패가 다음번에 또 일어날 것이고, 그렇게 내부 인원이 지쳐가면 결국 버티지 못하고 이직을 생각하게 될 것이다. 이직하는 인원이 많아질수록 회사의 역량은 떨어질 것이고, 또다시 실패가 반복된다. 악순환의 고리이다.


그래서 내가 생각하기에 가장 크게 실패한 프로젝트는 물론 Q, C, D, CS, MS 모두 무너진 프로젝트일 것이고, 그다음으로 덜 실패한 프로젝트는 그나마 MS라도 지켜낸 프로젝트라고 생각한다. 그러므로, 당신이 지금 "죽음의 행진 프로젝트" 한가운데 있는 PM(Project Manager)이라면, 내부 개발자들한테 만이라도 잘해주어야 한다. 조금이라도 빨리 이 HELL을 벗어나기 위해 무한 야근의 늪에 팀원들을 몰아넣지 말고, 어쩔 수 없는 경우 야근을 지시하더라도 프로젝트의 현재 상황과 이슈를 공유하고, 현재 문제가 되고 있는 부분을 해결하기 위해 어느 정도의 기간 동안 야근이 필요할 것 같다는 얘기와 함께 양해를 구해야 할 것이다.


프로젝트를 진행하고 있는 중이라면, 프로젝트를 진행하면서 어려워진 원인이 무엇이었는지, 같은 실수를 반복하지 않으려면 어떻게 해야 할지, 현재 우리 회사의  부족한 부분은 무엇인지 정리해보자. 그리고, 이런 내용을 정리함에 있어 함께 고생하고 있는 개발자들과 생각을 공유해보자. 그런 생각을 공유할 수 있다는 것만으로도 희망은 있다.


Q, C, D, CS, MS가 모두 무너진 실패한 프로젝트 중에서도 가장 큰 실패는 PM자신이 버티지 못하고 나온 경우이다. 아무리 모색해보아도 도무지 탈출구가 보이지 않는 프로젝트라 하더라도, PM이라면 끝까지 버텨야 한다. 프로젝트를 끝까지 책임지는 것이 PM이기 때문이다. PM이 포기하면, 내부 인원들도 동요가 일어나고, 회사 입장에서도 교체 PM을 투입해야 하므로, 금전적인 면에서 엄청난 손해이다. "회사 입장에서는 프로젝트를 책임지지 못하는 PM은 더 이상 가치가 없다." 무엇보다 실패한 프로젝트에서 배울 교훈을 정리하여 회사에 도움이 되도록 정리하고 전달할 사람이 없는 것이 가장 큰 문제다.


도무지 탈출구가 보이지 않는다는 생각이 든다면 하루만이라도 혼자만의 시간을 가져보기 바란다. 굴 속에 들어가서 프로젝트의 처음부터 끝까지 치열하게 복기해보고, 이렇게 힘들어진 원인과 현재 상황에서 이 문제를 해결할 방법들이 무엇이 있을지 생각해보자. 지금 하고 있는 이 경험이 나를 더 강하게 만들 거라고 믿자. 흔들리는 멘털을 부여잡고, 전체 프로젝트를 조망하며, 여기서 살아남을 방법을 생각해내자. 끝까지 버틴 PM은 그래도 무언가 얻는 게 있지만, 중간에 포기한 PM은 중간까지의 모든 과정이 쓰디쓴 실패의 기억으로만 남을 것이며, 다른 누군가에게 교체된 PM으로 들어와서 프로젝트를 마무리짓고 능력을 인정받을 기회를 만들어 줄 뿐이다.


어느 정도 생각이 정리되었다면, 하나하나 실행하자. 작은 실마리 하나부터 풀어가다 보면 어떻게든 마무리는 할 수 있을 것이다. 결국 일은 끝나게 되어있는 것이다. 하지만, 거기서 얼마 큼의 교훈을 얻을지는 본인 하기 나름이다. 중요한 것은 문제를 해결해가는 과정 하나하나를 모두 기록하여, 두 번 다시 같은 상황을 만들지 않도록, 나 스스로의 경험치로 만들어가자.


처음부터 완벽하게 준비된 PM은 없다. 만일, 세상 어딘가에 모든 면에서 완벽하고 능수능란한 완성된 PM이 있다면, 그 사람은 그만큼 많은 어려움을 경험한 것이며, 그 어려움을 극복하기 위해 치열하게 노력한 결과 현재 그 정도의 내공을 갖게 된 것이라고 보아야 한다. 



이전 01화 프로젝트는 왜 실패하는가
brunch book
$magazine.title

현재 글은 이 브런치북에
소속되어 있습니다.

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari