성공적인 프로젝트를 위해 많은 기업은 먼저 실패 프로젝트를 분석합니다. 즉, 과거의 실패 원인을 찾아서 개선하면 성공할 수 있다고 믿기 때문입니다. 프로젝트 관리 협회(Project Management Institute)에 따르면, 기업이 프로젝트를 적시에, 정해진 예산으로 완료하거나 목표와 비즈니스 목적을 충족할 가능성은 60%가 안 된다고 합니다. 그렇다면, 프로젝트 실패의 주요 요인은 무엇일까요?
Moira Alexander(CIO)가 쓴 ‘한눈에 보는 프로젝트 관리의 세계(IDG)’를 보면, ‘프로젝트 관리 방법론’에 투자 여부가 상당한 영향을 준다고 기술하고 있습니다. 80%가 적시에 예산 내에서 정해진 목표를 달성한다고 주장합니다. (즉, 성공 확률이 20%나 증가하게 됩니다.)
프로젝트 관리 방법론이 핵심 성공 키워드?
필자도 이 부분에 대해서 부정하지는 않습니다. 특히, 초보 PM(Project Manager)이나 경험이 많지 않은 PM은 이 ‘프로젝트 관리 방법론’이 “내비게이션(Navigation)”과도 같은 존재로 느껴질 것입니다. 아무것도 수정하지 않고, 고민 없이 그대로 따라가기만 해도 최소한 헤매지 않고 목적지에 도착할 수 있기 때문입니다. 이 의미는 프로젝트 최소한의 위기는 막아 준다는 의미입니다.
그러나, 안타깝게도 실제 현장에서는 대부분의 프로젝트가 ‘관리 방법론’을 사용합니다. 그 방법론 적용이 Tight 하지 않을 수도 있고, 일부 항목들만 관리하는 경우도 있으나, 아예 사용하지 않는 경우는 드물다는 겁니다. 그렇다면, 대부분의 프로젝트는 성공해야 하지 않을까요? 그런데, 현실은 그렇지가 않습니다. 제가 가지고 있는 자료를 보면, 아래와 같은 다양한 프로젝트 실패 원인이 나옵니다.
위의 “프로젝트 실패 이유”를 보시고 공감이 잘 안 가는 부분도 많을 거라는 생각이 듭니다. 아무래도 필자의 경험으로 비추어 볼 때, 해외 프로젝트 환경과 국내 프로젝트 환경 사이에는 상당한 GAP이 존재하기 때문입니다.
실제 IT 서비스 기업에서 19년 가까이 근무한 필자의 직간접 경험을 기준으로 국내 프로젝트의 실패 요인을 관리 방법론과 연결하여 이야기해 보면 아래와 같습니다. 오히려, 해외 케이스가 기반한 위의 “프로젝트 실패 이유”보다는 더 공감이 가지 않을까 생각합니다.
물론 사람마다 다른 의견이 있을 수 있습니다. 또한, 전문 기관에서 분석한 내용과 일부 다를 수도 있습니다. 그러나, 필자의 생각은 ‘무리한 계획과 변경’에서 시작되어 ‘비현실적인 생산성 강요’ → ‘높은 결함률’ → ‘예산 낭비 및 납기 지연’으로 이어진다고 생각합니다.
위의 표를 좀 더 풀어서 이야기해 보면, “1. 범위 통제”의 경우, 생각보다 상당히 많은 고객(발주자)이 자신들이 목표로 하는 시스템이 무엇인지, 목표 이미지가 무엇인지를 명확하게 정의하고 알고 있는 경우가 없습니다. 이러다 보니, 처음 요구 사항부터 명확하지 않게 시작되게 되고 프로젝트 중간에 본인들이 인지할 수 있는 화면 설계가 된 후 또는 통합 테스트 시점이 되어서야 자신들의 요구 사항이 구체화되고 정리가 되어 실제 계약 범위보다 대부분 그 범위가 늘어나는 경우가 빈번합니다.
해외의 경우, 초반에 투자 심의를 받을 때 요구사항이 명확하지 않아 추가 요구나 변경 요구가 발생할 수 있는 경우에 대비하여 본 사업 예산의 약 20% 정도를 예비비로 별도 책정하여 활용하는 경우가 많습니다. 그러나, 국내의 경우에는 필자가 이런 경우를 본 적도 들은 적도 없었습니다.
결국, 이 추가 요구 사항이나 변경 요구에 대한 비율이 높을수록 프로젝트 실패 확률이 높아지며, 설사 외형적으로 납기 내에 시스템을 오픈하였다고 할지라도 내부 품질은 결코 목표 수준을 달성했다고 보기 어려울 것입니다. 여기에서 슬픈 현실은 이런 과도한 범위 확대 요구가 품질 및 납기지연 등으로 이어질 것을 알고 있음에도 불구하고 관행처럼 IT 서비스 기업들은 일정 부분 이를 받아들이고 있다는 점입니다.
또한, 필자가 프로젝트 관리 방법론의 관리•통제 항목 중에서 가장 중요하게 여기는 항목이 “위험 관리(리스크•이슈 통제)”인데요. 의외로 리스크와 이슈를 구분하지 못하는 분들이 현장에 많았습니다.
아직 일어나지는 않았지만 향후 발생할 경우, 그 영향이 클 것으로 예상되는 문제를 “리스크(Risk)”라고 합니다. 그리고, 실제 이 리스크가 발생하게(현실화) 되면 그때부터 “이슈(Issue)”가 되는 것입니다. 즉, 리스크는 터질 가능성이 있는 폭탄과 같고, 이슈는 폭탄이 터진 상태를 의미하는 것이죠.
그렇다면, “위험 관리”를 잘하려면 어떻게 해야 할까요?
위험 관리를 잘하려면, 최대한 ‘리스크(Risk)’를 많이 인식할 수 있어야 합니다. 이는 프로젝트에 참여하는 모든 이들이 함께 찾아야 합니다. 특히, 사람들의 심리 특성상, 리스크를 감추려는 경향이 많습니다. 그래서, 리스크를 오픈하는 사람들을 질책해서는 절대 안 됩니다.
이렇게 많은 리스크를 인식했다면, 다음은 인식된 리스크들이 절대 “이슈화” 되지 않도록 통제하는 것입니다. 즉, 리스크를 조기에 찾아서 이슈가 되지 않도록 방지하는 것이 위험 관리의 핵심입니다. (이를 폭탄으로 비유하자면, 사전에 지뢰와 폭탄을 찾아내서 터지지 않도록 제거하는 것입니다.)
이슈가 되었다는 것은 이미 일정, 범위, 리소스, 비용, 품질 등 여러 영역에 이미 부정적인 영향을 줬다는 것이므로, 이슈가 되었을 때는 그 피해를 최소화하는데 집중해야 합니다.
예를 들어, 어떤 설계자가 3개의 기능을 설계하기로 계획했는데, 첫 번째 기능이 생각보다 진도가 나가지 않아 이미 수요일 퇴근 시점에도 끝나지 않았다고 가정해 보겠습니다. 이 경우, 이 설계자는 목요일, 금요일 이틀간 야근을 하고, 토요일에 특근하면 할 수 있을 것이라 예상하여 이를 리스크로 인식하지 않았습니다.
이 설계자의 행동은 옳은 걸까요? 어떤 분들은 결과적으로 토요일까지 일을 해냈다면 문제가 안 된다고 생각하실 수도 있습니다. 그러나, 관리적 측면에서 보면, 이는 절대적으로 “리스크”로 인식하고 보고해야 합니다. 왜냐면, 못할 수도 있으니까요. 그리고, 일정 계획이라는 것은 월~금, 일 8시간 근무를 기준으로 작성하게 됩니다. 이 계획이 전체적으로 잘못되었을 수도 있으므로 반드시 리스크로 보고를 해야 추후 이슈가 되지 않도록 할 수 있습니다.
글을 쓰다 보니 마치 ‘프로젝트 관리 방법론’을 주제로 글을 쓰고 있는 듯한 착각에 빠지게 되네요. 여기까지만 읽으신 독자분들은 프로젝트나 Task를 성공시키는 핵심 열쇠는 “프로젝트 관리 방법론”이라고 오해할 수도 있을 것 같습니다. 그러나, 아무리 좋은 관리 방법론을 가지고 관리를 한다고 하더라도 실제 현장에서는 이게 여러 가지 이유로 이것이 제대로 작동되지 않아 프로젝트를 실패로 몰아가게 됩니다.
그렇다면, 도대체 필자가 말하고자 하는 “Task•Project를 성공시키는 단 한 가지”는 무엇일까요?
필자의 경우, Task가 되었든 프로젝트(Project)가 되었든 항상 시작 시점부터 지속해서 전체 인원들을 대상으로 “오너십(Ownership)”에 대한 변화 관리를 꾸준히 진행합니다. 맞습니다. 필자가 이야기하고자 하는 Task•Project를 성공하게 할 수 있는 가장 근본적인 단 한 가지는 “오너십(Ownership)”입니다. 이게 있는 것과 없는 것의 차이는 극명합니다.
PM(Project Manager)이나 TM(Task Manager)의 핵심 역할은 참여 인원 모두에게 “오너십(Ownership)”을 갖게 하는 것입니다. 여기에는 ‘발주자’와 ‘지시자’까지 전부 포함됩니다. 앞서 중요하게 다뤘던(여러분들을 헷갈리게 했던) 프로젝트 관리 방법론은 PM이나 PMO(Project Management Office)만 인식해야 하는 게 아닙니다.
가능한 Task•Project에 참여한 전체 인원들이 동일한 개념을 인지하고 함께 관리하고, 실행하고, 성공시켜야 할 대상으로 인식해야 합니다. 이것이 생산성을 높이게 하고, 프로젝트 중반 이후에 나올 요구 사항 변경이 프로젝트 초반 Baseline 지정 전에 도출될 수 있게 하며, 잠재적 리스크(위험 요소)를 사전에 도출하여 이슈화되지 않도록 해 줍니다.
“오너십(Ownership)”의 정체?
“오너십(Ownership)”이란 ‘주인 의식’, ‘주인의 자격’을 의미합니다. 즉, 스스로 알아서 일하는 것을 말합니다. 그렇다면, 제가 말씀드리고 싶은 “오너십”이 있다는 것은 어떤 의미일까요? “리더십인가? 오너십인가?(이정규 비즈니스 IT 칼럼니스트, 2011)”라는 칼럼에서는 이렇게 표현하고 있습니다.
오너십을 가진 직원은 (1) 고민해 창의적 아이디어를 지속적으로 냅니다. 이 경우, 지시하지 않아도 자기 일 외에도 다른 사람의 일까지 살펴 가며 문제를 해결한다고 합니다. (2) “제가 한번 해 보겠습니다.”라는 선구자적 태도를 보입니다. 즉, 어떤 리스크가 발생되었을 때 이를 회피하지 않고 구체적 복안이 당시에 없더라도 이를 해결하겠다는 도전의 의지가 보인다는 것입니다. (3) 실수 또는 실패를 했을 때 남에게 책임을 전가하지 않고 “제 책임입니다.”라고 말합니다.
필자도 이 세 가지에 100% 공감합니다. 여기서 필자의 경험을 공유하자면, 필자는 과거 프로젝트 또는 Task PM을 했을 때 직원들에게 아래 그림처럼 “오너십”을 이해하고 행동할 것을 주문하였습니다.
‘A’가 만든 산출물을 받아서, 이를 기반으로 내가 작업을 하고, 그 작업 산출물을 다시 ‘B’에게 전달해야 한다고 가정해 보겠습니다. 나는 “’A’가 계획된 날짜가 되면 알아서 주겠지!”라고 기다리지 않고, 일주일 전에 ‘A’에게 다음 주에 나에게 전달해 줘야 할 것이 무엇이고, 이게 지연될 경우 어떤 영향이 있으며, 만약, 지연될 것으로 예상되면 최소한 3일 전에는 공유해 줄 것을 구체적으로 알려 줘야 한다는 것입니다.
또한, B에게도 마찬가지로 내가 언제까지 무엇을 전달해 줄 것이며, 내가 계획보다 빨리 줄 수 있는지 지연되는지를 사전에 알려 B가 일정을 조정하여 더 생산성을 낼 수 있도록 하던지, 아니면, 지연될 경우 다른 업무와 일정을 조정해서 전체적인 일정에는 영향이 없도록 사전 조치를 할 수 있게 커뮤니케이션해야 합니다.
커뮤니케이션 외에 리스크•이슈 관리 측면에서도 자신 영역의 리스크를 오픈하거나 자신의 영역이 아닐지라도 자신과 연관성이 있어서 커뮤니케이션한다면 그 영역까지도 리스크를 적극적으로 오픈할 것을 주문했습니다.
또, 리스크 단계에서 오픈은 환영하나, 이슈가 된 후에 오픈한다든지, 이슈화 하루 전에 리스크를 오픈하는 경우에는 그 책임을 분명히 지우겠다는 의지를 피력함으로써 가급적 리스크를 인식하게 되면 곧바로 오픈하고 공유할 것을 주문하였습니다. 관리 방법론 전체적인 관리 항목 측면에서 “오너십”을 견지하되, 특히, 커뮤니케이션과 위험관리 측면에서 강조했었습니다.
“오너십”을 자제해야 할 때
그러나, 오히려, “범위 관리” 측면에서는 절대로 개인적 “오너십”을 발휘하지 말 것을 주문하였습니다. “오너십”을 자신이 맡은 영역으로 제한한다면 (즉, 오너십을 적용하는 데 자신만을 생각하고 자신 영역만 생각하게 된다면) 오남용될 가능성이 있습니다. 이런 경우, 오히려 ‘폭탄’이 될 수 있다는 의미입니다.
예를 들어, 시스템 구축 프로젝트에서 설계가 끝나고 ‘단위 테스트’를 진행하는데 고객(발주자)이 추가 요구 사항을 이야기한다고 가정해 보겠습니다. 이때, 이를 들은 담당자가 이 정도의 추가 요구 사항은 본인이 조금만 신경 쓰면(약 2주 정도만 야근하면) 대응할 수 있을 것으로 판단해 추가 요구 사항을 받아들였습니다.
그런데, 이런 경우, 이렇게 받은 추가 요구 사항이 자신이 담당하는 전체 영역의 약 10% 정도 초과해도 별문제가 없다고 판단할 가능성이 높습니다. 즉, 화면 10개를 개발하는 데 한 개 정도 더 개발해 줄 수 있다고 판단했을 가능성이 높다는 겁니다. 그런데요. 각 담당자가 모두 이런 식으로 받아들이다 보니 프로젝트 전체 범위의 약 10%가 증가했고, 기존의 요구 사항 중에서 변경된 부분이 약 20%에 해당해 거의 30% 가까이 더 작업해야 하는 상황이 되었습니다.
관리자의 관점, 기업의 관점에서 보면, 작은 다이너마이트와 같은 폭탄이 한 개, 두 개 모여서 이게 100층짜리 건물 하나를 통째로 날려 버릴 정도의 위력적인 폭탄으로 변화된 것이죠. 그렇지 않아도 잠재된 수많은 위험 요인(Risk)들을 찾아서 이게 터지지 않게(이슈화되지 않게) 관리를 해야 하는데…, 반드시 터질 것이 확실한 엄청난 위력의 폭탄을 (아무 생각 없이) 내부에서 제조했다고 한다면 어떻겠습니까?
그럼, 이런 경우 어떻게 대응해야 할까요?
이런 경우, 추가 요구 사항을 듣는 순간, 이를 “오너십”을 가지고 본인이 수용할 것인지, 거부할 것인지를 판단할 것이 아니라, 바로 수용 여부를 결정하지 말고, 이를 ‘리스크(Risk)’로 인식하고, 보고해야 합니다.
“오너십”과 “역량” 둘 중 선택을 해야 한다면?
좀 더 큰 상위 레벨에서 “오너십”을 이야기해 보겠습니다. 아래 그림은 두 가지 형태의 계약 방식을 도식화한 그림입니다.
“A. 주 사업자가 없는 경우(개별 계약)”의 경우에는 전체 사업(프로젝트)을 책임지는 사업자가 없습니다. 결국, 발주자가 책임을 지고, 전체 업체들을 통제하고 조율해야 합니다. 그러나, 사실 업체별로 각자가 잘하는 분야가 있기 때문에 발주자 입장에서는 영역별 최고의 전문 업체를 선정해 계약하는 방식이 더 나은 결과물을 얻을 수 있을 것으로 기대합니다. 특히, 경영층보다는 “팀장급”에서 이런 방식을 선호하는 경향이 높습니다.
반면, “B. 주 사업자가 있는 경우”는 협력 업체 중에서 한 개 업체를 선정하여 “주 사업자”로 선정하고, 책임 이행을 하게끔 하는 방식입니다. 이 경우, 중간에 “주 사업자”가 들어가기 때문에 주 사업자의 이익(Profit)으로 인해 다른 협력 업체에 돌아갈 비용이 줄어들어 투입 인력들의 질이 떨어지거나 투입 기간이 줄어들 가능성도 존재합니다.
위의 두 가지 계약 방식 중에 여러분들이라면 어떤 방식을 선택하시겠습니까?
실제 사례를 비추어 보면, “주 사업자”가 그 밑으로 들어가는 다른 협력 업체들보다도 역량이 다소 떨어진다고 할지라도 성공 확률은 “오너십”을 가진 사업자가 존재하는 “B” 쪽이 더 높았습니다.
오히려, “A” 방식의 경우, 각 사가 자신들의 영역에 “벽”을 치고 그 이상은 자신들의 책임이 없는 영역이라고 선을 긋다 보니 4개 사업자가 애매하게 얽혀져 있는 영역에 대한 책임 문제가 발생하게 되고, 특히, 각 업체가 협력을 통해 구축해야 할 경우라든지 서로 복합적 요인에 의한 문제가 발생했을 경우, 상대편 업체에 책임을 떠넘기려는 경향을 자주 보였습니다.
결국, 이러한 요인들이 프로젝트의 발목을 잡아 실패하는 사례가 많이 발생하였고, 특히 대형 사업의 경우 “오너십”을 가진 주 사업자가 없는 경우, 더욱 실패 확률이 높았습니다.
물론, 전체 프로젝트와 Task가 절대적으로 “오너십”을 가진 사업자가 있어야 성공할 수 있다고 주장하고 싶지는 않습니다. 다만, 성공의 확률을 높이기 위해서는 “역량”보다는 “오너십”을 선택하는 편이 성공 확률이 더 높다는 점입니다.
오늘의 글을 정리해 보겠습니다. 제가 글 서두에 프로젝트 실패 이유에 대해서 이야기를 했었습니다. 그런데, 그 어디에도 “오너십”에 대한 직접적인 언급은 나오지 않습니다. 아주 근본적이고 중요한 요소임에도 불구하고 우리가 프로젝트의 실패 원인을 분석할 때는 이러한 부분은 분석 대상에서 제외된다는 점입니다.
그러나, 실제 오랫동안 프로젝트나 Task를 직접 경험하고, 매년 몇 백 개의 프로젝트 및 Task를 수행하는 회사에서 분석 활동 등을 통해 간접 경험한 관점에서 보면 “오너십”은 그 어떤 방법론, 실패 요인, 업체의 역량보다도 프로젝트 성공 여부에 영향을 크게 미쳤습니다.
결론적으로, 프로젝트나 Task의 성공 확률을 높이는 요인을 딱 한 가지만 선택하라고 한다면, ”오너십”을 맨 앞에 두라고 추천해 드리고 싶습니다.
글 l LG CNS 홍보팀
[‘누구나 전략 기획 고수가 될 수 있다’ 연재 현황]
[1편] 전략적 사고의 중요성
[2편] 문제 해결을 위한 자질과 기본 원칙
[3편] 문제 해결을 위한 기본 원칙
[4편] 문제 해결 방법•논리적 사고 기법
[5편] 커뮤니케이션 역량의 중요성
[6편] 창의적인 사고방식
[7편] 창의적인 사고 기법 #1
[8편] 문서 작성의 오해와 진실
[9편] 창의적인 사고 기법 #2
[10편] 문서 작성 훈련법
[11편] 내 생각 출력법
[12편] 문서 작성 프로세스
[13편] 문제 해결 프로세스 #1
[14편] 문제 해결 프로세스 #2
[15편] 문제 해결 프로세스 #3
[16편] 문제 해결 프로세스 #4
[17편] 문제 해결 프로세스 #5
[18편] 경쟁력 분석 도구
[19편] 잘못된 분석은 잘못된 전략을 낳는다.
[20편] 환경 및 기술 분석 도구
[21편] 고객 중심 사고
[22편] 거시적 환경분석과 4P
[23편] 내부 역량 분석 #1
[24편] 내부 역량 분석 #2
[25편] 디지털 시대엔 전략 기획 역량은 필수?
[26편] 2017년을 보내며 전략 기획 재조명
[27편] ‘업무 속의 전략 기획’ #1 전략적 회의록 작성
[28편] ‘업무 속의 전략 기획’ #2 목표 달성 방법
[29편] ‘업무 속의 전략 기획’ #3 미래 역량과 의사소통의 중요성
[30편] 기술에 앞서 문제에 집중하라.
[31편] 초심을 잃지 않은 Amazon
[32편] 브로슈어(Brochure) 직접 만들기
[33편] ‘초청장’ 파워포인트로 만들기
[34편] 백종원의 골목식당 속의 ‘디자인 씽킹’
[35편] 고수의 팁 ‘공감’과 ‘검증’
[36편] 신사업 정책 #1
[37편] 신사업 정책 #2
[38편] 신사업 시 재무 분석 #1
[39편] 신사업 시 재무 분석 #2
[40편] 함정에 빠진 Digital Transformation 회피 방법
[41편] 기업이 놓치기 쉬운 가트너의 메시지
[42편] 장기 목표 달성을 위한 전략•전술 수립하기
[43편] 올해의 목표와 달성 전략 수립하기
[44편] 기본에 충실하라
[45편] 전략 기획자가 본 기업의 인사 전략(HR)은?
[46편] 기업 전략에서 ‘이거 두 가지’는 이제 그만!!!
[47편] 프로젝트를 성공시키는 단 한 가지
[48편] 프로세스 혁신을 성공시키기 위한 조건
[49편] 5G 시대 통신사의 B2B 전략
[50편] 누구나 알아야 할 회계 지식 ①
[51편] 누구나 알아야 할 회계 지식 ②
[52편] 내년도 재무 계획 수립하기 ①
[53편] 전략 기획자가 본 기업의 인사 전략 두 번째 이야기
[54편] 누구나 알아야 할 회계 지식 3 그리고 사업 계획 TIP
