안녕하세요, 인터뷰를 통해서 전문가의 관점을 쉬우면서도 구체적으로 끌어내는 고우성의 잇(IT)터뷰입니다.점점 비즈니스가 디지털 경제로 전환되면서, 민첩성과 유연성이 기업 경쟁력의 중요한 요소로 대두되고 있습니다. 아울러 자연스럽게 IT 프로젝트 성공의 기준이나 원칙들도 변하고 있습니다.이번 잇터뷰에서는 과거 우리가 당연시했던 프로젝트 성공의 관점들을 다시 한번 곱씹어 보는 시간을 가져보려 합니다. 국내에서 프로젝트 관리조직이란 PMO 분야를 최초로 만들고, 다양한 DX 컨설팅을 하고있는 투이컨설팅의 신창섭 상무와 김인현 대표의 관점을 살펴보겠습니다. |
◼ 진행자 : 고우성 PD/토크아이티 (wsko@talkit.tv, https://talkit.tv/)
◼ 게스트 : 신창섭 상무/투이컨설팅
◼ 게스트 : 김인현 대표/투이컨설팅
1. 성공 프로젝트에 유능한 PM은 필수인가?
● 신창섭 : 프로젝트 제안 평가를 하면 꼭 PM 발표를 해야 한다고 얘기합니다. 그리고 PM의 이력서를 살펴보고 어떤 프로젝트를 했는지 등 이 사람 능력을 많이 보죠.
그런데 과연 PM이 정말 관리 스킬이 좋고 경험 많은 사람이면 프로젝트가 성공할까요?
여기 한 5만개 프로젝트의 DB를 뒤져서 바로 이걸 조사를 해 본 거예요. 조사를 해봤더니 그 PM 스킬이 매우 높다면 성공률이 23%, 58%, 19%. 이렇게 나옵니다.
반면, 이 PM 스킬이 매우 낮거나 아예 PM이 없으면 오히려 성공 확률이 58%, 33%, 9% 이렇게 나오는 거죠.
놀라운 얘기죠? 하하.
● 고우성 : 하하. 놀라운 얘기네요.
● 신창섭 : 일반적인 워터폴(Waterfall)* 프로젝트 경우가 그렇고요. 애자일(Agile)** 프로젝트에서는 더 합니다. 애자일 프로젝트는 그런 PM이 있으면 성공률이 18%밖에 안 되고요. 아예 PM이 없거나 그렇지 않으면 91%가 된다는 거죠.
*워터폴(Waterfall) : 소프트웨어 개발이나 디자인 프로젝트에서 단계별로 구성되어 한 단계를 완료해야 다음 단계로 넘어가는 방식
**애자일(Agile) : 프로젝트를 작은 단위로 여러 개 나누어 단계별로 피드백을 반영하는 반복적이고 증분적인 개발 방식
● 고우성 : PM이 Agility의 어떤 방해 요소가 될 수도 있다는 얘기네요.
● 신창섭 : 그렇죠. 이유를 살펴보면, 사실 PM의 스킬이 높다는 것은 관리 프로세스나 체계를 잘 매니징을 한다는 뜻이거든요. 그런데 그게 잘못되면, 즉 좀 경직된 어떤 프로세스 체계 등을 끌고 간다는 것은 관료주의로 간다는 것을 의미할 수 있습니다. 그게 오히려 프로젝트 성공에는 마이너스 요인이라는 얘기를 하는 것입니다.
일이 이만큼 있고 인원이 열 명이 있으면, 열 개로 쪼개서 배분해 줍니다. 그러면 각자가 맡은 일을 잘 끝내는지, 안 끝내는지만 관리를 하죠. 그런데 문제는 그렇게 되면 개인이 그냥 맡은 일을 해 나가는 것만 하는 거지 거기에서 뭔가를 배우거나 옆에서 도움을 받는 등 이런 것 자체에 팀플레이가 잘 안 되거든요.
그래서 팀이 어떤 과제를 쉐어링 하고 그것에 대한 수단에 대해서. 이 팀 내 결정 권한이 좀 있어야만 애착이 생기고 프로젝트에 좀 더 재미나 몰입을 느낄 수가 있다는 거죠.
그래서 이제 그런 팀 문화를 잘 만드는 것, 자기 조직적인 팀을 만드는 것이 이제 프로젝트 성공에 상당히 중요한 부분이 된다고 볼 수 있습니다.
2. 프로젝트 성공은 마감 준수?
● 신창섭 : ‘성공이라는 게 과연 뭐냐, 그 성공을 뭐로 측정 하느냐’에 대해 전통적인 방법으로 얘기하자면 세 가지가 있습니다.
먼저 on time, 약속된 시간 내에 끝나는 것이 있습니다. 그다음 on budget, 자원으로 얘기하기도 하죠. 이 시점에 이제 예산대로 끝나는 것. 그다음 on target, 범위 관련된 얘기를 합니다.
원래 예전에는 이제 이 세 가지를 가지고 성공률을 얘기했습니다. 그런데 이제 Chaos Report에서도 2014년도부터는 측정 기준을 Traditional이 아닌 Modern으로 바꿨어요.
Modern이라는 것은 ‘on target의 범위라는 게 중요한 게 아니다. 범위는 바뀔 수 있다. 중요한 것은 고객이 만족했느냐’의 관점으로 접근하는 것입니다. 타겟, 범위 대신 고객 만족(customer satisfaction)으로 바꾸면서 Modern이라는 측정 방식으로 얘기하고 있습니다.
그 외에도 여섯 가지 항목(on time, on budget, on target, on goal, customer satisfaction, return of value)에 대해 측정하고 있는데, 우리가 순수하게 ‘이 프로젝트가 가치가 있었느냐’ 라는 걸 평가할 때는 ROI가 중요합니다. 그다음은 고객 만족. 이게 진짜 중요한 거죠.
그 다음 또 하나로 우리가 흔히 얘기하는 것이 있습니다. 저희는 이제 Bullseye***라고 표현을 해요.
***Bullseye : 황소의 눈. 과녁의 정중앙에 명중함을 의미
우리가 투우하면 황소가 막 이렇게 방향대로 달려오잖아요. 그래서 우리가 원래 하려고 했던 목표 그다음에 비즈니스 Goal. 이것을 얼마나 준수했느냐… 그래서 여기 지금 제가 동그라미를 두 개를 해 놓은 이유는 Traditional 열은 4점 척도를 가지고 3~4점일 때에 이걸 됐다고 달성했다 보는 거고 Pure 열은 5점 척도를 가지고 4~5점이 때 됐다고 표현하는 건데요.
그렇게 봤을 때 보면 사실은 이 Pure가 진짜 가치이지 않습니까? 디지털 시대에는요. 그렇죠? 근데 통계적으로 성공률이 16%밖에 안 돼요.
Traditional 기준으로는 37%인데 Modern 기준으로 31% 밖에 안 나오죠. 그러니까 실패는 다 동일하다고 보면 되는 것입니다.
실패가 19%라는 건, 거의 파레토 법칙(Pareto’s Law)****의 20%에 해당하기 때문에 사실 더 줄지는 않을 것 같고요. 그러니까 이제 ‘Challenged가 얼마나 줄 것이냐?’라는 거죠.
****파레토 법칙(Pareto’s Law) : 이탈리아 사회학자, 경제학자 파레토(Vilfredo Federico Damaso Pareto, 1848~1923)에 의해 발표된 소득분포에 관한 통계적 법칙으로서, ‘80:20 법칙’
우리가 한 번 생각해 볼 만한 것으로 카카오 뱅크의 모바일앱 많이 쓰잖아요. 카카오뱅크는 정말 빅히트를 친 프로젝트라고 생각하거든요. 전통적 기법으로 치면 Challenged 프로젝트입니다. 그 이유는 카카오뱅크의 코어뱅킹 시스템은 이제 주사업자가 LG CNS가 했고요. 그 외 우리가 쓰고 있는 모바일 앱 같은 경우에는 사실 LG CNS 가 만든 게 아닙니다. 카카오페이에서 카카오의 개발팀이 직접 만든 프로그램이에요. 그래서 코어 뱅킹은 원래 일정대로 잘 끝났는데 카카오페이가 만든 그 모바일 앱이 사실 딜레이가 생겼습니다. 그래서 오픈 시기를 카카오 측에서 뒤로 미루고요.
제가 이 얘기를 하는 이유는, 앞의 사례 중 결국은 날짜를 맞춰서 오픈하고 약간 문제가 있거나 고객 만족을 못 하는 것과 필요한 경우에 그 날짜를 좀 지연시키더라도 가지고 가는 것.
어떻게 프로젝트 성공을 바라볼 것인지에 대한 기준은 사실 이제 이 프로젝트 계약서상에 고객과 어떻게 정의하고 갈 것인가가 정말 중요한 문제라고 생각해요.
그래서 요즘에는 그런 관점에서 ‘우리가 성공의 기준을 무엇으로 할 거냐’라는 것을 잘 정의해야 한다는 측면에서 얘기를 좀 합니다.
● 고우성 : 요즘 같은 디지털 경제에서는 한 번 써봤는데 아니면, 아예 끊어버리잖아요.
● 신창섭 : 맞습니다.
● 고우성 : 사용자 경험이 매우 중요할 것 같아요.
● 김인현 : 그래서 제가 놀란 게 고객 경험(Customer Experience) 부서가 요구사항 부서나 IT 부서보다 의사 결정이 맨 위에 있습니다. 그래서 그것이 충분하게 조직 전체에서 승인이 안 되면, 모든 일정이 거기에 디펜던시를 갖고 지연이 되더라고요. 일반적으로 금융사들이 중요한 생각하는 게 일정이라고 생각했는데 특이하더라고요.
제가 볼 때는 이제 그런 관리 포인트를 갖고 있기 때문에 많은 사용자들이 카카오뱅크의 모바일 앱이 제공한 사용자 경험에 굉장히 뜨겁게 반응한 것 같고 그런 점은 토스와 좀 비슷하지 않나 싶습니다.
● 고우성 : 네.
3. 프로젝트 관리 도구는 프로젝트 성공을 좌우할까?
● 신창섭 : 여기에 이제 TOOLS FOR FOOLS라고 하는 리포트가 나왔던 게 있어요. CA의 클레러티라고 하는 유명한 PMS 솔루션이 가트너 랭킹에서 항상 상위권입니다.
그래서 그 CA에서 우리 툴을 쓰는 고객과 안 쓰는 고객의 프로젝트 성공률 차이에 대해서 한번 조사를 좀 해봐 달라고 의뢰했나 봐요.
근데 조사 결과가 아주 놀라웠어요. 그 툴을 쓰는 고객이 성공률이 더 낮은 거예요.
● 고우성 : 하하.
● 신창섭 : 하하. 성공률도 낮고 프로젝트 비용도 더 들고요.
● 고우성 : 아니, 이거 발표했어요?
● 신창섭 : 거기는 아마 그렇게 수행하고 난 다음에 그걸로 더 많은 그런 PPM 사례들을 갖고 별도로 했습니다. 그다음, 그 보고서 제목이 ‘바보들의 도구’입니다. 그래서 실제 그걸 릴리즈했어요.
이 얘기는 무엇이냐 하면, 우리가 어떤 프로젝트 관리를 잘하기 위한 어떤 변경 관리 프로세스, 무슨 프로세스 등을 잘 엄청나게 정교하게 만드는 것에 신경 쓰는데, 그게 오히려 프로젝트는 좋은 효과를 미칠 수 없다는 거죠.
● 고우성 : 그러니까 너무 미시적인 것에만 집중하고 거시적인 걸 놓칠 수 있다는 말이네요.
● 신창섭 : 네, 그런 것도 있고, 어떤 사람의 그 어떤 융통성. 이런 것들이 적용될 수 있게끔 가져가는 게 더 중요하다는 거죠. 그렇다고 PM에서 ‘도구를 쓰지 말아라.’ 이렇게 이제 뭐 권고하지 않아요. ‘좀 가벼운 거를 도구를 써라.’ 이런 얘기들을 하고 있습니다.
4. 프로젝트는 자세한 목표 정의가 필요할까?
● 신창섭 : 또 하나는 우리가 IT-Business Alignment 이런 얘기를 많이 하잖아요.
그래서 비즈니스 목표에 요구사항 이라든지 구현된 것이 잘 준수 해야 된다는 얘기를 하는데 실제로 그럴까요?
물론 이제 목표 자체가 아예 없거나 팀이 하면 실패 확률이 무지하게 올라갑니다. 하지만 의외로 명확한 비즈니스 목표를 가지고 있는 것보다는, 즉 목표의 구체성 보다 목표의 방향성이 명확한 것이 오히려 성공에 더 도움이 된다는 것입니다.
그러니까 그것은 아마도 우리가 뭘 만들고 싶다는 요구서 관점에서 더 디테일하게 ‘A는 어떻게 하고 B는 어떻게 하라’는 것을 쫙 정리하는 것 자체가 오히려 프로젝트 성공에는 마이너스 효과를 일으킨다는 것이고요.
그다음 이제, ‘통계적으로 불완전한 요구사항으로 인해서 프로젝트가 어려워지고 실패하게 된다.’
이것은 이제 사실 많이 얘기했죠. 정부에서도 그래서 요구사항 같은 경우에는 더 구체화해서 사전에 어떤 발주를 해야 한다는 등의 제도들을 만들어 내고 있습니다. 그런데 실제로 여기서 이제 언급한 그 리포트를 읽어보면 우리가 내부적으로 엄청나게 그 요구사항 스펙이 잘된 그런 프로젝트임에도 실제 중간에 실패로 끝난 그런 사례들도 많이 있습니다.
또 하나의 문제로 요구사항을 구체화하면 할수록 범위가 증가합니다.
예를 들면, 요구사항 정의서에 비밀번호 변경이라는 요구사항 하나가 달랑 있는 것에서 이걸 구체화하라고 해보겠습니다. 예를 들어, 패스워드가 이전 5회 것은 쓰지 못하게 해야 된다듣지, 비밀번호가 문자, 특수기호를 어떻게 합쳐야 한다고 하면 이제 늘어나는 거죠.
여기서 중요한 건 예전에는 프로젝트에서 WHAT이 매우 중요했어요. 뭘 만들고 싶은지 명확하게 이해하고 하면 HOW TO를 하면 되는데, 지금 WAHT보다 더 중요한 것은 WHY인 거죠.
● 고우성 : 그렇죠. 방향성이네요.
● 신창섭 : 그렇죠.
내가 원래 하고자 했던 비즈니스 Opportunity가 XX였는데 그것을 요구 사항으로 만들려니까 이렇게 일단 정의를 했다고 가정해 보겠습니다. 우리가 구현하면서 보니 이렇게 하면 더 보수도 줄이고 더 나이스하게 처리할 수 있을 것 같다는 것을 같이 고민하면서 풀어나가는 게 오히려 프로젝트성 고민에는 도움이 되더라는 것입니다. 이렇게 얘기할 수 있는 거죠.
● 고우성 : 그러니까 어떻게 보면 환경이 30년 전과 달라졌고 그 환경이 너무 급변하니까요.
● 신창섭 : 맞습니다.
● 고우성 : 사실 미래를 예측하기 쉽지 않아요. 향후 3년의 모습을 어떻게 압니까? 전혀 모르잖아요. 이런 것과도 맥락이 연결되는 거네요.
● 신창섭 : 맞습니다. 대규모 프로젝트 같은 경우에는 이제 ISP나 이런 컨설팅을 하고 나서 하고 결과가 구현돼서 이제 실행되는 데 짧게는 3년, 길게는 4~5년이 걸리거든요.
그러면 그 당시에 잘 정의됐던 것이 그 시점에도 맞을까요? 이 점에 대해 이제 분명히 생각해 볼 여지가 있는 거죠.
최근 국내 대형 IT 프로젝트가 지연되거나 실패하는 경우가 왕왕 발생하곤 하는데, ▶여기) 최근 대형 IT프로젝트 위기, 무엇이 문제인가◀를 클릭하시면 현황과 원인을 분석하는 영상을 보실 수 있습니다. |
▼영상으로 시청하기!▼
◼ 콘텐츠 & 웨비나 문의 : marketing@talkit.tv, 02-565-0012
Copyright ⓒ 토크아이티 All rights reserved. 무단 전재 및 재배포 금지.