프로젝트는 왜 실패하는가
프로젝트의 성공과 실패에 대한 생각들
10년 좀 넘게 IT업계의 다양한 분야에서 다양한 형태의 PM(Project Manager, 프로젝트 관리자)으로써 프로젝트를 경험해왔다.
프로젝트 경험이 쌓여갈수록 나 스스로에게 만족스러울 만큼 성공적이었던 프로젝트는 손에 꼽을 정도였던 것 같다. 그 몇 안 되는 성공한 프로젝트는 이제 와서 돌아보면 PM인 나의 실력보다도 어떻게 보면 운이 좋았던 것 같다. 프로젝트가 잘 종료되고, 모두에게 좋은 평가를 받았던 그 당시에는 나 스스로도 자랑스러워 여기저기 얘기하고 다닌 적도 있었다. 하지만, 지금 다시 생각해보건대, 만일 실패했던 프로젝트에서 실패의 원인이 되었던 그 사건이 성공했던 프로젝트에서 발생했더라면 과연 그 프로젝트는 성공할 수 있었을까?
생각만 해도 등골이 서늘해지는 느낌이다.
그렇다면, 과연 항상 프로젝트를 성공하려면 어떻게 해야 하며, 무엇이 필요한 것일까, "PMBOK(*)에서 얘기하는 프로젝트 관리방법은 적어도 국내 IT업계에는 적용되지 않는다"라고 나는 감히 얘기하고 싶다. 아니, 일부만 적용된다고 할까? 참고 수준이라고 해야 할까? 생각해보면 전혀 도움이 안 되는 건 아니고, "PMBOK의 내용은 프로젝트 관리에 필요한 기초일 뿐이다."라고 하는 것이 정확한 표현이라고 생각된다.
* PMBOK : Project Management Body of Knowledge, 프로젝트 관리 지식 체계, 프로젝트 관리를위한 일련의 표준 용어 및 지침, Project Management Institute (PMI)에 의해 제공되며, 2017년에 제 6판이 발표되었다.
적어도 내가 경험해온 프로젝트에서는 그랬다.
IT 프로젝트를 수행할 때 범위 관리는 언제나 어렵다. 고객은 언제나 RFP(*)나 요구사항 정의서에도 없던 추가 요구사항을 당연히 해야 하는 것으로 얘기한다. 추가 요구사항을 수용하면, 범위 관리에 실패하고, 그것은 곧 일정의 지연과 원가의 상승, 이익률의 하락으로 이어진다. 추가 요구사항을 미수용하기 위해 모든 회의 내용을 빠짐없이 기록하여 회의록을 남기고, 요구사항 정의서나 화면 설계서에 서명을 받더라도 소용없다. 왜냐면, 그러한 문서를 근거로 고객의 추가 요구사항 수용에 대해 거부하는 일이 반복되면, 발주처 고객은 언제든 PM의 교체를 요구할 수 있고, 고객이 PM의 교체를 요구하는 순간 회사 내부에서는 고객관리에 실패한 PM으로 낙인찍힌다.
*RFP : Request For Proposal, 제안요청서, 발주자가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시함으로써 제안자가 제안서를 작성하는데 도움을 주기 위한 문서
추가 요구사항이 명확한 경우라면, 고객의 추가요구사항에 대해 현실적으로 PM이 할 수 있는 최선은
1) 죄송합니다만 어렵습니다.라고 일단은 해야 할 것이고,
2) 제발 살려주십시오. 저희 이것까지 해드리려면 굶어 죽습니다. 하고 우는 소리를 해서 어떻게든 잘라내거나,
3) 그나마 해줄 만한 건이라면, 프로젝트의 영향이 가장 덜한 형태로 수용하거나,
4) Deal을 해서 기존 요구사항 중 가장 지저분한 한 가지를 제외하고 들어주거나
5) 도저히 안될 경우는 내 윗사람을 끌어들여서 내 책임이 아닌 그 사람의 책임으로 만들어버리는 것이다. (이 방법도 결코 자주 쓰면 안 된다. 내부에서 찍힐 위험이 있다. 회사에서는 어쨌거나 PM 혼자서 아무 이슈없이 깔끔하게 프로젝트를 마무리하고 돌아오기를 바라기 때문이다.)
PMBOK에서는 고객의 추가 요구사항이 발생하면, 변경통제위원회(CCB, Change Control Board)에 넘긴다.라고 되어있지만, 적어도 내가 경험한 프로젝트 중에서는 실제 프로젝트 현장에서 변경통제위원회(또는 그 비슷한 무언가)를 통해 합리적으로 의사결정이 진행되는 경우는 극히 드물다.
내가 경험한 프로젝트들에서 프로젝트가 실패했던(또는 많이 어려워졌던) 원인은 다음과 같다.
첫 번째 사례, 고객이 도입 솔루션의 기능 중 가장 중요한 기능의 프로세스를 변경하기를 원했다.
여러 번의 미팅을 거치는 동안 프로세스의 변경의 악영향에 대해 설득했지만, 결국 고객이 원하는 방식으로 변경 개발을 하는 것으로 결론이 났고, 울며 겨자 먹기 식으로 1개월 넘는 기간 동안 해당 부분을 변경 개발했지만, 테스트를 시작하는 단계에서 솔루션 내의 그와 연관된 다른 기능들에서 예상치 못한 오류가 나기 시작했다. 추가로 2개월여를 테스트 및 오류 수정만 진행했고, 결국 프로젝트는 3개월 넘게 지연되었다.
두 번째 사례, 개발범위가 테스트 단계에 상당히 큰 범위가 확장되었다.
그로 인해 프로젝트의 기한이 연장되었고, 충분한 테스트를 하지 못한 상황에서 오픈을 맞아 고객의 만족도가 심각한 상태로 떨어졌다.
세 번째 사례, 새로운 연동방식의 적용
개발범위가 대략 정해진 상태로 계약 후, PM으로 선정되어 투입된 다음 뚜껑을 열어보니, 고객사의 기존 시스템에서 제공하는 연동방식은 일반적으로 우리 회사가 해오던 방식이 아니었고, 1 종당 개발자 M/M(*)가 대략 3배 정도는 필요한 방식이었다. 그러나 어쩔 것인가, 계약서에 표현되어있는 개발범위를 모두 수행하기 위해 개발자를 추가 투입할 수밖에 없었고, 곧 어마어마한 납기 연장과 수익률 하락으로 이어졌다.
* M/M : man-month, 일의 양을 나타내는 단위, 1M/M는 한 사람이 한달 동안 할 수 있는 일의 양
네 번째 사례, RFP는 고객의 상상 속에서 나온 것이었다.
요구사항 정의서를 확정하지도 못하였지만, RFP에 표현된 내용을 기준으로 나름대로 구현 가능한 형태의 설계를 가져가도 고객은 늘 다른 얘기를 했다. (인공지능과 좀 더 스마트한 등등) 요구사항을 확정하지 못한 상태로 프로젝트 기간이 계속 흘러갔고, 일단 구두상으로 확인한 만큼만이라도 먼저 개발을 시작했지만, 고객은 자신이 승인한 적이 없는 형태라는 말로 전혀 다른 형태의 화면 화면설계를 요구했다.
다섯 번째 사례, 고객사 정보 취득의 어려움
고객사는 늘 구축하던 전문업체들이 협력사로 시스템 운영을 하는 곳이었고, 우리는 SI(시스템 통합) 사업자 역할로써, 굴러온 돌이었다. 고객은 언제나 기존 SI사업자만큼의 퀄리티를 요구했지만, 우리는 경험이 부족했고, 고객사 서버와 네트워크 구성에 대한 모든 현황을 잘 알고 있는 고객사의 기존협력사들은 우리에게 결코 우호적이지 않았다.
여섯 번째 사례, 회사가 엄청나게 이상하게 영업이 된 프로젝트를 수주했다.
고객사는 우리 회사 솔루션의 기능 명세와 경쟁사인 B사, C사의 기능 명세를 제공받아 모두 합집합으로 짬뽕하여 엄청나게 방대한 양의(앞 뒤 맥락이나 분류가 맞지도 않는) 기능 요구사항을 포함한 RFP를 냈다. 경영난을 겪던 우리 회사는 그 사업에 엄청난 저가로 입찰했고, 결국 우리가 수주했다. 고객의 니즈를 분석하여 기능 요구사항을 정제/축소하려는 노력을 하였고, 그러한 각고의 노력으로 상당히 많은 부분 정제된 요구사항 정의서로 합의했으나, 몇 개월 후 테스트 단계에 담당자가 바뀌었고, 바뀐 담당자는 이전 담당자와의 합의사항을 인정하지 않으며, RFP의 모든 기능 요구사항을 구현하기를 요구했다. 맥락이 맞지도 않고, 필요도 없는 기능들도 많이 포함되어 있었지만, 감사에 문제가 될 수 있으므로, RFP에 나열된 모든 기능이 구현되어야 한다는 입장에서 한 발자국도 물러서지 않았다. 결국 백화점식으로 나열된 기능을 메뉴에 삽입하여 모두 구현할 수밖에 없었고, 끝나고 나서도 아무도 사용하지 않는 시스템이 되었다.
반면, 내가 생각하기에 성공했던 프로젝트의 (결정적인) 성공요인은 아래와 같다.
첫 번째, 투입된 개발자들이 개발실력이나, 마인드면에서 너무 훌륭한 멤버들이었다.
무엇보다 같이 일하면 즐거웠고, 프로젝트가 끝나고 나서도 또다시 이 멤버들과 다른 프로젝트를 한다면, 어떤 어려운 프로젝트도 성공시킬 수 있을 것 같은 생각이 들 정도였다. 하지만, 그렇게 성공적인 프로젝트의 멤버들은 어디서나 탐을 내기 마련이고, 나는 힘없는 PM이었기 때문에 보내줄 수밖에 없었다.
두 번째, 고객의 마인드가 너무 좋았고, 시스템에 대해 원하는 바가 명확했다.
시스템 기능의 핵심적인 기능에만 집중하고, 다른 부수적인 것들은 그저 알아서 해도 된다거나, 그 정도면 충분하면 된다는 식이었다. 물론 핵심적인 기능 몇 가지에 대해서는 엄청나게 높은 수준의 퍼포먼스를 요구하긴 했지만...
세 번째, 사업기간 도중 고객사의 담당자가 발령이 났다.
자칫하면 엄청난 문제로 이어질 수도 있는 부분이었는데, 후임자가 정해지기까지 공백이 있는 상황이어서 전임 담당자가 그 정도면 됐다고 만족하고 서둘러 프로젝트를 마무리했다.
이렇게 내가 경험한 프로젝트들에서 성공/실패 요인들을 적어놓고 보니, 프로젝트를 성공하기는 너무 힘들었지만, 정작 성공한 프로젝트도 과연 내가 PM으로써 잘해서 성공한 것이었을까?라는 생각이 든다.
프로젝트는 원래 수행사에게 불리한 기울어진 운동장이다. 금액과 기간은 정해져 있지만, 요구사항은 명확하지 않고, 착수해서 요구사항 분석/상세설계, 어떨 때는 끝날 때가 거의 되어서야 정확한 공수를 산정할 수 있다. 원래부터가 성공하기 힘든 것이 프로젝트인 것이다.
그럼에도 불구하고, PM을 직으로 하고 있는 입장에서 항상 나의 고민은 "모든 프로젝트를 항상 성공할 수는 없는 것일까?", "모든 프로젝트를 성공적으로 마무리하려면 어떻게 해야 할까" 하는 것이었다.
이것이 내가 글을 써보아야겠다고 결심하게 된 이유이다. 프로젝트의 실패에 대한 원인 분석과 고민이 쌓여갈수록 항상 프로젝트를 성공하고자 하는 열망이 강해졌고, 결국 그것은 어느 책에서도 명확하게 나와있지 않다는 생각이 들었다. 프로젝트 관리를 다룬 책에서 얘기하는 내용들은 대부분 PMBOK 이론에 바탕을 두고 있는 내용들이 많고, 현재 대한민국의 상황에서 특히 내가 주로 경험했던 중소, 중견 SW IT 회사의 상황에서는 더더욱 현실적이지 못한 부분이 많다고 생각한다.
한편, 글을 쓰면서 수없이 회의감이 들기도 했다. "내가 뭐라고 이런 걸 쓰나, 기술사나 감리사도 아니고, 프로젝트 관리에 대해 연구를 한 사람도 아니고, BIG 3 SI업체에 다니는 사람도 아니고, 프로젝트를 많이 해왔지만, 나 스스로 생각하기에는 성공보다 실패가 많은데..."
그럼에도 이 글을 끝까지 한 번 써봐야겠다고 생각한 이유는 같은 업계에서 PM으로 일하는 사람들과 의견을 공유하며, 좀 더 발전된 방법에 대한 의견을 나누고 싶었기 때문이다.
나는 내가 앞으로 쓸 글에서 PMBOK이나 다른 프로젝트 관리 이론서에 나온 내용을 중요하게 다루지 않을 예정이다. 물론 참고는 하겠고, 일부 겹치는 부분이 있기도 하겠지만, 어디까지나 내 개인적인 생각을 주된 내용으로 할 것이고, 현재 필드에서 PM을 하고 있는 사람들이 한 번쯤 생각해보기를 바라는 마음으로 쓰려고 한다. 프로젝트 관리의 모든 영역을 다룰 생각도 없고, (무엇보다 그 정도의 능력도 없을뿐더러) 이 글이 프로젝트 관리의 바이블이 되기를 바라지도 않는다. 그저 FM(Field Manual, 야전 교범, 여기서는 표준적인 방법론을 뜻함)에서 조금 벗어난 시각으로 나와 같은 고민을 하는 사람들이 그저 한 번쯤 고개를 끄덕일만한 글이었으면 한다.
그리고, PMP(*)시험을 보기 위한 준비과정에 있는 사람은 절대로 이 글을 보지 말았으면 좋겠다. 개인적인 생각이지만, 이 글을 읽고 나서 PMP시험을 본다면 오히려 오답률이 높아지지 않을까?
*PMP : Project Management Professional, 미국의 비영리 단체인 프로젝트 관리 협회(PMI)가 주최하는 프로젝트 매니지먼트에 관한 국제자격
