brunch

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by ApexQ Nov 02. 2022

프로젝트, 어쩌다 망하는가?

네 번째 이야기. 프로젝트, 왜 실패가 반복되는가?

문제는 개발이 아닌 프로젝트의 경우 프로젝트 성공과 실패에 대한 기준이 명확하지 않다는 것이다.

시스템 개발 프로젝트의 경우와 비교해 보면 더욱 분명하다. 개발 프로젝트는 성공과 실패가 명확하다. 시스템이 요구사항대로 잘 돌아가면 성공이고 돌아가지 않으면 실패이다.

그리나 시스템 개발이 아닌 업무 개선(PI) 프로젝트는 보는 관점에 따라 성공과 실패의 기준이 달라질 수 있다는 점도 판단의 모호성을 더해준다.

대부분 프로젝트를 추진했던 프로젝트 부서는 프로젝트가 성공했다고 주장한다. 그리고 이 성공에 현업 임원의 동의를 구했다는 주석을 단다.

현업 임원 입장에서는 어떠한 가? 프로젝트가 회사의 개선사항을 짚어주고 향후에 나아질 것을 제안만 한 상태이기 때문에 무어라 논평하기가 곤란하다. 그리고 임원 자신의 견해가 반영이 잘 되어 보고서라는 산출물이 나왔을 경우에는 프로젝트가 성공했다는 의견에 주로 동조를 하기 마련이다. 한마디로 한 배를 태우는 전략이다. 이렇게 프로젝트가 산출물의 결과를 현업 임원에게만 맞추는 경우 임원 입장에서는 성공이라고 불러도 문제가 없을 것이다.

그러나 프로젝트의 결과는 개발을 담당하는 시스템 설계자와 개발자에게 전해진다. 이들은 프로젝트의 산출물을 바탕으로 개발을 시작하게 된다. 만약 위의 사례처럼 임원 보고서만 가득하고 To-Be 설계가 부족한 산출물을 보게 되면 개발자의 입장은 난처하다. 개발자 입장에서는 프로그램을 어떻게 개발할지에 대한 지도가 없기 때문이다.

이렇게 되면 어떻게 될까?

시스템 설계자나 개발자가 현업 임원을 찾아갈까? 아니면 이미 떠나고 없는 프로젝트 컨설턴트들을 찾아서 물어볼까? 대부분의 경우 결국 시스템을 사용하게 되는 현업을 찾아갈 수밖에 없게 된다. 그리고 현업이 원하는 시스템 요구사항을 개발자 입장에서 정리를 해야 한다. 다행히 이 과정이 잘 진행이 된다면 시스템은 어떤 식으로 든 만들어질 것이다.

하지만 현업 입장에서는 개발자와 대화하기가 쉽지 않다. 서로 다른 세계에 살고 있기 때문이다. 현업이 생각하는 업무는 업무 활동 중심의 프로세스이다. 하지만 개발자는 업무를 어떻게 하는지는 중요하지 않다. 중요한 것은 어떤 데이터가 어디로 가고 어떤 화면을 구성할 지이기 때문이다.

시스템을 가장 많이 사용하게 될 현업의 입장은 어떨까? 현업들은 프로젝트에 참여하지 않는 경우 본업이 있다. 그런데 컨설턴트들이 프로젝트를 한다고 인터뷰를 요청하면 시간을 빼앗겼다는 생각을 많이 한다. 그래도 회사의 방침이니 시간을 할애한다고 했다. 그런데 프로젝트가 끝나고 말도 잘 통하지 않는 개발자들이 이것저것 물어보기 시작한다. 이때 현업들은 비협조적인 경우가 많다. 개발자들과는 같은 업무를 보더라도 언어가 다르기 때문이다. 이 사이에 통역을 해 줄 프로젝트 컨설턴트들은 이미 프로젝트 종료 선언과 함께 떠나 버렸다.

결국 보고서 중심으로 임원을 주 고객층으로 프로젝트를 하는 경우 시스템 개발자나 시스템 사용자인 현업 입장에서는 프로젝트에 좋은 점수를 주기 어렵다.

이번에는 컨설팅사 파트너의 입장에서 프로젝트를 보자. 컨설팅사에는 프로젝트들을 관리하는 관리자로서 파트너들이 있다. 이들은 프로젝트 수주와 수행 결과, 그리고 팀원 구성 등에 대한 책임을 진다. 파트너 입장이라면 어떨까? 파트너 입장에서는 컨설턴트들이 프로젝트를 잘 수행했다고 평가할 수 있다. 파트너 입장에서 제1고객은 프로젝트를 발주한 팀의 리더이고 그 다음이 임원급이다. 발주 조직의 리더가 컨설턴트를 마음에 안 들어하면 어떻게 될까? 첫 번째는 컨설턴트 교체 요구를 한다. 그래도 마음에 안 든다 싶으면 아예 컨설팅 회사 자체를 교체하는 경우가 생길 수 있다. 이것은 파트너 입장에서는 최악의 시나리오이다. 매출도 문제지만 고객사에서 불명예 퇴진의 명성을 얻을 수 있기 때문이다.

어떤 경우이든, 그러니까 팥으로 메주를 쑤었든 콩으로 만들었든 컨설팅 회사나 컨설턴트들이 “잘리는” 경우가 발생하면 안 된다.

그런데 행여나 고객사 PM이 잘못된 방향으로 이끌고 있다고 하여 “충신”놀이를 하면 어떻게 될까?

“고객님, 그렇게 하시면 안 됩니다. 고객님, 제가 보기에는 맞는 방향이 아닙니다. 고객님, 이렇게 하셔야 합니다” 이 충신의 앞날은 너무나 분명하다. 바로 먼 섬으로 유배를 당하는 것이다.

거기다 상대는 꼰대 마인드와 갑질 마인드가 최상급이라면? 충신의 목숨은 더욱 짧아질 것이 분명하다.

나중에 개발이 잘못되어 문제가 된다고? 그건 개발자나 개발 담당 회사에게 1차 책임이 있다. 상대적으로 컨설팅 프로젝트에게는 상당한 면죄부가 있다. 고객사에서 프로젝트 결과물에 만족하고 검수를 했기 때문이다.

위의 사례는 다소 과장된 극단적인 상황이다. 실제로 위와 같이 황당한 실패 사례는 많지 않을 것이다. 다만 과장은 있었지만 업무 개선(PI) 프로젝트와 개발 프로젝트 간의 단절로 인해서 시스템 개발에 어려움이 있는 경우는 우리 주변에서 많이 찾아볼 수 있다.

keyword