프로젝트 제안이라는 게 처음에 할 때는 어렵지만, 몇 번 경험이 쌓이고 나면 콘텐츠만 다를 뿐 같은 내용의 목차를 채워나가는 작업이기에 그다지 어렵지 않다. 프로젝트 제안 경력이 몇 년 이상이 되면 제안서를 쓴다는 게 부담이 없는 일이지만, 프로젝트 제안의 백전노장도 체력이 딸릴 때가 있다. 바로 데드라인이 정해지지 않는 프로젝트 제안 작업을 할 때다.
예전 회사에서 경험담이다. 프로젝트를 처음 기획했을 때, 2차까지 염두에 두고 프로젝트를 시작했다. 1차 프로젝트에서 PM을 맡았기 때문에 1차 프로젝트가 마무리 될 쯤에 자연스럽게 후속 프로젝트의 제안 작업도 맡게 되었다. 2차 프로젝트의 제안을 시작했을 때는 무척 간단한 작업이 될 것이라고 생각했다. 1차 프로젝트를 시작할 때 전체 프로젝트의 계획을 세웠기 때문에, 1차 프로젝트를 하면서 상세화된 내용을 보강해서 2차 프로젝트의 제안서를 쓰는 수준이었기에 말이다. 최초에 제안서를 쓰는 데 그렇게 오래 걸리지 않았다. 제안서 초안을 고객에게 보내고 나서, 프로젝트 완료를 위해서 다시 프로젝트에 전념했다.
프로젝트 완료 때문에 한참 바빴기 때문에, 고객이나 나나 모두 후속 프로젝트에 대한 제안을 잊고 지냈다. 프로젝트가 마무리되면서, 드디어 후속 프로젝트가 수면 위로 떠오르게 되었다. 한동안 잊고 지낸 제안서를 꺼내서 고객과 같이 협의하였다. 제안서에 대해서 몇 가지 피드백을 받고 1주일 내로 제안서를 갱신해달라는 요청을 받았다. 고객의 요청에 따라서 제안서를 수정해서 보내주고, 다시 1주일 정도가 지났다. 시간이 꽤 지났는데도 제안서에 대해서 별 반응이 없자, 고객에게 전화를 걸어 진행상황을 문의했다. 고객은 내부 사정 때문에 프로젝트 범위를 다시 협의하고 있다고 말했다. 협의 내용에 따라서 제안서가 조금 수정되어야 할 것 같다는 말도 했다.
1차 프로젝트를 시작하기 전에 생각했던 2차 프로젝트의 범위를 두고서 고객사 내부적으로 의견이 분분했던 것 같았다. 제안을 담당하는 고객사 파트너는 고객사 내부에서 협의가 새롭게 될 때마다 제안서의 수정해달라고 요청했다. 제안서의 버전을 0.1씩 올리면서 관리하고 있었는데, 제안을 시작하고 나서 1달 정도 지나자 4.0버전이 되어 버렸다. ‘제안서_v4.0.ppt’라는 프로젝트 제안서 파일 이름을 보고 있자니, 왠지 프로젝트 제안이 빨리 마무리되지 않는 이유는 버전의 끝이 안 보이기 때문이라는 생각이 들었다. 합리적인 판단은 아니라고 생각됐지만 더 이상 제안서를 수정하지 않았으면 좋겠다는 바람을 담아서, 제안서 파일 이름 끝에 ‘최종’을 붙였다.
그러나 내 바람은 바람으로만 남았다. 제안 작업이 계속 지연되자 0.1씩 버전을 올린 제안서의 파일 이름이 어느새 ‘제안서_최종2.0.ppt’버전이 되어버렸다. 최종 뒤에 붙은 ‘2.0’이라는 숫자를 보고 있자니, ‘최종’이라는 단어를 붙인 게 상당히 민망해 보였다. 그런 민망함을 없애고자 약간의 꼼수를 써서 ‘최종’을 ‘Finish’로 바꾸었다. 제안서 파일 이름으로 주목해서 보는 사람이 없을 것이기 때문에, 그다지 중요한 상황은 아니었지만. 자고 나면 제안서 버전을 올려야 하는 제안자로서 하루빨리 제안 작업이 마무리되기를 간절히 바랬기 때문이다.
프로젝트에서 중요한 것은 정말로 많지만, 가장 중요한 것은 데드라인이라고 생각한다. 우리가 하는 프로젝트는 대개 데드라인을 중심으로 일정을 짜고 인력을 배분하고 계획을 관리하기 때문이다. 오죽하면 프로젝트 완료 날짜를 데드라인이라고 부를까? 그날 지나면 죽는다는 정신으로 프로젝트를 대해야 하기 때문이 아닐까 하는 생각이 든다. 그런데 데드라인의 중요성은 제안 작업에서도 마찬가지 수준이다. 흔히 제안작업이나 제안작업과 비슷한 기획작업은 서비스 업무라고 생각하는 경향이 있다. 실질적인 무언가를 만들어내지 않지만 정말로 손에 잡히는 것을 만들기 위한 프로젝트의 사전작업이기 때문이다.
물론 시간과 정열 받쳐서 제안작업을 하는 제안자나 기획을 하는 기획자 입장에서, 자신들이 내놓는 결과물에 대해서 공짜라는 인식으로 바라보는 게 마음에 들지 않는다. 하지만 그런 기초 작업 덕분에 의미 있는 프로젝트가 시작된다면, 그것으로도 만족할 수 있다. 하지만 한 그루의 사과나무를 심는 농사꾼의 마인드로 제안서를 쓰더라도 주의할 게 있다. 바로 데드라인이 없는 제안작업이나 기획작업을 할 때다.
몇 시간 째 물을 마시지 못하고 사먹을 건너고 있다고 해보자. 목마름에 신경이 곤두선 그 시점에 저기 멀리 오아시스가 보인다. 조금만 더 가면 목을 축일 수 있다는 생각으로 온 힘을 다해 그곳으로 갔지만, 오아시스가 아닌 신기루였다는 걸 알게 된다면, 어떻게 될까? 아마도 열의 아홉은 그 자리에서 다리가 딱하고 풀릴 것이다.
이것이 바로 사막횡단증후군이라고 부르는 현상이다. 저기만 가면 끝이라고 생각했는데, 막상 그곳에 갔더니 끝이 아닐 때, 우리는 맥이 풀리고 만다. 데드라인이 없는 제안서 작업을 할 때는 항상 사막횡단증후군을 경계해야 한다. 고객이나 상사가 건네는 이번 버전이 제안서의 마지막 버전이 될 것이라는 말에 혹해서 온 힘을 다해 달리고 나면, 고객이나 상사가 “이 산이 아닌가 보다!”라는 말을 할지 모르기 때문이다. 고객이나 상사가 이번이 마지막 제안서라는 말을 꺼낼 때 신발끈을 바짝 동여매고 전속력으로 그곳으로 달려 나갈 생각을 하지 말자. 앞으로 몇 번의 경기가 남은 것처럼 몸을 풀 정도로만 달리자. 그렇지 않다면 나처럼 ‘최종’이나 ‘Final’ 아니면 ‘최최종’처럼 불굴의 의지가 담긴 제안서 이름을 사용할지도 모른다.
그렇다면 예전 회사에서 끝도 없는 제안 작업을 했을 때, ‘Final’이라는 이름을 붙이면서 제안 작업은 완전히 종결되었을까? 아니다. ‘Fianl’이라는 이름에 걸맞지 않게 몇 번의 버전이 올라갔다. 그리고 난 이게 하루 이틀에 끝날 문제가 아니라는 생각이 들었다. 그리고 속 편하게 버전 이름을 떼어 버리고 날짜를 붙였다. 날짜를 붙인 날부터 난 단거리 선수가 아닌 마라톤 선수의 마인드를 갖게 되었다. 그리고 프로젝트는 어느새 시작하게 되었다.
이 글은, 제가 쓴 ‘도와주세요! 팀장이 됐어요’에서 다루지 못한 프로젝트의 경험법칙(물론 제 경험을 기준으로 한 법칙입니다)에 관한 이야기입니다. 프로젝트 관리자로서, 이제 막 시작하셨는데 방향을 잡지 못하신다면 ‘도와주세요! 팀장이 됐어요’를 통해서 도움을 얻어 보세요!
글 : 신승환
출처 : http://www.talk-with-hani.com/archives/1388