잘 안되는 프로젝트는 어떤 공통점이 있을까?

다양한 기업과 분야에서 기획자로 프로젝트를 하다 보면 여러 경험을 하게 됩니다. 그중 가장 많이 하는 경험이 바로 프로젝트 실패입니다. 일을 하다 보면 성공보다 실패를 더 많이 경험하게 되는 것은 현실입니다. 그래서 왜 실패를 하는 것인지 분석/정리를 하게 됩니다. 기획자의 습관은 무서운 거니까요.

 

 

 

목표 설정 미흡한 경우

 

프로젝트 기획은 목표를 명확히 하는 것에서 시작됩니다. 같은 앱 프로젝트라도 앱 시스템을 기획하는 것과 기능 프로세스를 기획하는 것, 화면을 기획하는 것은 그 기획 목표가 다릅니다.

 

그러나 실패하는 프로젝트에서는 이런 기획 목표에 대한 명확한 구분이 모호한 경우가 대부분입니다.

 

화면 설계와 앱 설계를 동일시하고, 때로는 화면 기획자가 화면 플로우가 아닌 기능 로직 프로세스를 작성하기도 합니다. 이렇듯 목표 설정이 미흡한 경우 프로젝트는 방향성을 잃게 됩니다.

 

방향성을 잃을 프로젝트는 작업을 하면 할수록 새로운 일이 늘어나고, 일을 해도 작업이 누적되지 않습니다. 이는 마치 공부를 해도 다음날 책을 펴면 처음 보는 것과 같은 느낌과 같은 경험을 하게 됩니다. 몇 달 동안 열심히 일을 했는데 지금 하는 일들이 모두 새롭고 정리된 것이 하나 없는 것처럼 느껴집니다.

 

목표 설정 미흡이 프로젝트에 미치는 영향을 일상에서도 경험할 수 있습니다. 흔히 말하는 쓸데없는 일을 너무 열심히 하는 사람에게서 볼 수 있습니다.

 

이는 마치 짐을 옮기는데 짐이 옮겨져야 하는 사무실(목표)로 짐을 옮기는 것이 아닌, 다른 건물 창고로 옮기는 것과 같습니다. 짐을 옮긴 사람은 일을 열심히 했다고 주장하지만 프로젝트를 기획/관리하는 사람 입장에서 이 사람이 열심히 일한 결과 더 많은 일이 새로 생긴 것입니다.

 

이렇듯 프로젝트에서 잘못된 목표 설정은 프로젝트를 앞으로 나가게 하는 것이 아니라 뒤로 가게 합니다. 그리고 이러한 현상은 예상외로 많이 일어납니다. 특히 프로젝트 관리자가 프로젝트에 대해 잘 모르는 경우 프로젝트는 정치와 홍보로 난무하게 되고 이 경우 대부분 올바른 프로젝트 목표가 아닌 보여주기 식의 목표 설정으로 프로젝트를 망치게 됩니다.    

 

 

 

목표 달성 과정을 모르는 경우

 

외주 PM 또는 PL로 프로젝트에 투입되면 WBS 작성을 요청받습니다. 이때 모든 프로젝트가 그런 것은 아니지만 형식적으로 WBS를 작성을 강요받기도 합니다. 이 경우 해당 프로젝트의 구체적 내용 및 진행 과정, 단계에 대한 분석 없이 그냥 일반론에 입각하여 WBS를 작성할 수밖에 없습니다. 프로젝트에 투입되자마자 2~3일 안에 WBS를 내라고 요구받기 때문에 어쩔 수 없습니다.

 

개발 프로젝트 중간에 기획자로 투입되는 경우 이미 프로젝트 진행이 10개월 이상 지났음에도 여전히 분석/설계 단계라고 말하는 경우도 있습니다. 그런데 분석/설계 단계에서 화면 설계를 하라고 합니다. 이 경우 리더 또는 관리자가 프로젝트 분석/설계와 화면 설계를 구분하지 못하고 있는 케이스입니다. 이런 상황이라면 PM/PL이 화면 설계를 위한 정책 및 정의에 대한 정리조차 해 놓지 않은 경우가 대부분입니다.

 

이런 케이스는 프로젝트 목표가 어떤 과정을 거쳐 달성되는지를 모르고 있다고 볼 수 있습니다. 이 경우 프로젝트가 실패하는 이유는 너무나 분명합니다. PM/PL, 기획자 또는 개발자가 프로젝트를 해본 경험이 없기 때문입니다.

 

해본 경험이 없기에 목표 자체를 말 그대로 자의적으로 해석해서 이해합니다. 여기에 그 목표를 달성하기 위해 무엇을 해야 하는지 모릅니다.

 

이는 마치 서울에서 부산(목표)을 가야 하는 것은 알지만 어떻게 가는지는 모르는 경우라 할 수 있습니다. 이 경우 부산(목표)에 도달하지 못할 가능성이 큽니다. 시간과 비용의 제약이 있다면 실패 가능성은 더 커집니다. 마치 모르는 동네에서 집으로 오는 길을 찾는 것과 같습니다.

 

 

 

과정 생략

 

회사에서 신규 사업 프로젝트를 하다 보면 이런 경우를 많이 겪게 됩니다. 어떤 것에 꽂히신 대표님이 우리도 당장 그 사업을 하자고 하는 상황 말입니다.

 

만약 어떤 앱에 꽂히셨다면 그 앱을 사용해 보고 바로 그 앱 사업을 하자고 하십니다. 그런데 우리 기업은 그 앱을 개발할 개발자도, 운영 노하우도 없습니다. 

 

때로는 대표님은 우리가 왜 작은 스타트업이 하는 것도 못하냐고 역정을 내기도 합니다. 그러나 우리 기업에 맞는 비즈니스 모델링을 하고 개발자를 새로 뽑거나 개발 네트워크를 구축하는 데도 시간이 걸립니다. 아니 이 경우 개발자가 뽑히지 않아 전체를 외주 개발을 해야 할 수도 있습니다. 비용이 넉넉하면 바로 외주 개발사를 선정할 수 있겠지만, 대부분 이 경우 비용이 넉넉하지 못합니다. 여기서 또 시간은 흘러갑니다.

 

이런 상황에서 대표님 마음에 드는 결과를 내야 하는 경우 많은 중간 과정이 생략됩니다. 그냥 레퍼런스 앱을 보여주고 이거 비슷하게 개발해 달라고 해야 할 수도 있습니다.

 

이러한 경우라면 이 프로젝트는 분명 실패하게 됩니다. 물론 대표님 마음에 드는 앱 개발물은 그래도 빠르게 개발할 수 있으니 절반의 성공은 될 수도 있습니다. 단지 이런 앱으로 서비스한다든지, 경쟁한다든지 등은 이루어질 수 없습니다.

 

앱 개발 프로젝트 기획자로 중간에 투입되면 과정 생략 진행을 요구받는 경우도 많습니다. 심지어 앞에 해놓은 설계를 바탕으로 기획을 진행해야 하는 상황인데 이것을 거꾸로 한다든지, 나와 있는 화면을 참고로 화면 설계서를 작성해야 할 수도 있습니다. 당연히 이 경우 요구사항 상세화나 기능/화면정의, 정책 정리 등이 있을 리는 없습니다. 

 

앞의 과정이 생략되고 프로젝트가 진행되었기에 중간 이후 과정이 되었을 때 문제가 불거지는 것입니다. 보통 앞의 설계/부분석 과정은 초창기에는 그 중요성과 없을 시 문제점을 알지 못합니다. 중간 이상 특히 프로젝트 말미에 문제가 크게 불거지는 것입니다.

 

마치 마모된 바퀴로 달려도 초기 도심지에서는 문제가 없지만 고속도로를 달리는 시기가 되어 고속주행이 길어지고 비까지 오면 바퀴가 터지거나 미끄러지는 문제로 사고가 나는 것과 비슷합니다.

 

프로젝트 과정 생략은 초창기에는 프로젝트 속도가 빠른 듯 느껴지지만, 진짜 일을 해야 하는 순간이 되면 어떻게 개발해야 하는지 정리된 것이 없어 혼란을 겪게 됩니다. 심하면 같은 일을 여러 명이 하고 있고, 그렇게 하면 안 되는 형식으로 작업을 하고 나중에 이를 발견하고 지금까지 한 일을 전부 다시 해야 하는 상황이 발생하기도 합니다.

 

이런 프로젝트에서 성공을 기대하는 것은 학교에 나가지 않으면서 개근상을 받기 원하는 것과 같습니다. 그래서 프로젝트는 점점 정치화되고, 남아 있던 일을 잘하는 사람들은 프로젝트를 탈출하게 됩니다.   

 

 

 

잘 안 되는 프로젝트와 잘되는 프로젝트 차이

 

제가 20여 년 자체 프로젝트, 대행사로 진행한 프로젝트, 프리랜서 프로젝트 등 여러 입장에서 다양한 분야에서 경험으로는 이렇듯 잘 안 되는 프로젝트는 분명한 공통 징후가 있습니다. 이러한 프로젝트 문제 징후는 프로젝트 초기, 중기, 후기에서 신호가 나타납니다.

 

그러나 잘 안 되는 프로젝트는 이 신호를 무시합니다. 조금 어렵지만 이를 극복하여 성공하는 프로젝트는 이 신호를 캐치하여 문제를 보완하는 차이가 있습니다.