PM의 마인드
CEO의 마인드를 갖자.
내가 생각하는 PM의 마인드는 CEO의 마인드를 갖자는 것이다.
내가 좋아하는 글이 있다. 2015년 전자신문에 나온 글인데, 스크랩해서 코팅해놓은 이후로 아직도 내 책상에는 이 글이 놓여있다. 관심 있는 분들은 한 번쯤 읽어보시길....
- 전자신문 칼럼 이강태의 IT경영 한수 <55>어떻게 하면 CEO가 될 수 있나
이 글처럼 CEO가 되기 위해 노력하는 것도 중요하지만, PM은 CEO가 되기 전부터 이미 CEO처럼 생각해야 한다.
우리나라 IT 시장에서 프로젝트를 해서 돈을 번다는 것은 결코 쉽지 않은 일이다. 적어도 중소기업에서는 말이다.
프로젝트 투입인력의 노임단가는 정해져 있지만, 계약관계에 따라 을-병-정으로 내려오면서 그 대가를 정당하게 그대로 받지 못한다. 또한, 회사는 수주 확률을 높이기 위해 경쟁사보다 낮은 가격으로 참여할 수밖에 없다. 프로젝트 초반 사업성을 검토하여 어느 정도 수준의 이익률이 예상되는 사업만 참여할 경우, 회사는 수주 확률이 낮아질 것이고, 본사에서 대기하는 인력이 생길 수밖에 없다. 이런 본사 대기인력을 솔루션 개발에 잘 활용하면 좋을 텐데, 그 대기인력은 언제든 프로젝트가 생기면 다시 나갈 수 있기 때문에 본격적으로 솔루션 개발에 참여시키기도 애매해진다. 그 결과, 대기인력이 늘어갈수록 회사는 사업성이 떨어지는 프로젝트라도 일단 먹고살기 위해서 수주하게 되고, 결국 점점 SW의 시장 가격은 낮은 가격대로 형성된다. 저가로 수주한 프로젝트들이 많아질수록 개발자들은 계속되는 야근으로 지쳐갈 것이고, 이직을 고민하는 개발자가 늘어난다. 개발자들의 이직이 많아질수록 회사의 역량은 떨어질 것이고, 이러면 계속되는 악순환이다.
악순환의 고리그럼에도 불구하고 IT업체에게 한 번에 몇 억의 매출을 안겨주는 프로젝트는 피할 수 없는 유혹이다.
10년 남짓 프로젝트 관리자(PM)로 일해 오면서 내가 프로젝트에 대해 느낀 점은 역설적이게도 프로젝트를 하지 않아도 먹고살 수 있는 IT회사를 만들어야만, 안정적으로 성장을 도모할 수 있다는 것이었다. 하지만, 프로젝트를 하지 않고 안정적인 매출을 올리기 위해서는 시장에서 꾸준하게 사용되는 서비스를 만들어야 하는데, 새로 론칭한 서비스가 처음부터 안정적인 매출을 일으키기는 쉽지 않으므로, 일단은 프로젝트를 통해 회사를 유지하고 개발자들을 성장시키면서 동시에 서비스 모델을 개발해가야 한다. 서비스를 하나, 둘 론칭해서 성공적으로 정착이 되면, 점차 프로젝트의 비중을 줄여가면서 서비스 중심의 회사로 전환할 수 있다고 생각한다.
중소 IT회사가 프로젝트를 통해 얻어야 할 것
- 일단 매출을 올려서 먹고 산다.
- 개발자들의 실력을 키운다.
- 프로젝트의 경험을 통해 서비스 개발을 위한 아이디어를 얻는다.
프로젝트 수행 효율화
프로젝트를 통해 이익을 극대화하는 노력은 프로젝트 수행을 효율화하는 것과 일맥상통한다. 예를 들어,
솔루션 기능의 커스터마이징을 쉽게 한다거나,
프로젝트마다 매번 개발하게 되는 주요 케이스를 옵션화하여 설정만으로 사용할 수 있게 한다든가,
타 시스템 연계 구축 시 해당 케이스별로 구현 사례를 사내 지식으로 만들어놓는다든가,
프로젝트별 이슈 및 해결사례를 사내 지식으로 만들어 유사 사례 발생 시 참고할 수 있도록 한다든가,
하는 것들이 대표적인 활동이다.
즉, 프로젝트 투입인력을 줄여가는 방향으로, 매번 좀 더 적은 인원으로 프로젝트를 수행 가능하도록 개선해나가야 한다. 이러한 노력들이 쌓여서 프로젝트를 좀 더 효율적으로 수행할 수 있게 되면, 신규 서비스를 개발하기 위한 투자여력이 생길 수 있다.
프로젝트 중심 회사에서 서비스 중심 회사로 전환하기 위한 로드맵만일 당신이 한 개 프로젝트의 PM에 불과하다 할지라도 CEO의 마인드를 갖고 회사의 발전을 위해
프로젝트를 통해 직원의 역량을 향상시키고,
프로젝트를 수행하는 방법을 효율화를 통해 프로젝트 이익을 극대화하고,
프로젝트로부터 얻어진 아이디어와 노하우로 신규 서비스 개발에 주도적인 역할을 수행한다면,
프로젝트에만 국한된 PM이 아니라, 회사 내에서도 더욱 인정받는 PM이 될 수 있지 않을까?
원래는 연말까지 두고두고 읽고 생각하면서 완성도를 높여가고 싶었지만, 내가 얻은 교훈을 적기 위해서는 성공사례보다는 실패사례에 대해 더 많이 생각해야 했기 때문에 그만큼 정신적으로 괴로운 시간이었고, 많이 힘들었다. 그러한 이유로 이번 "PMBOK에 안 나오는 PM 이야기"는 이쯤에서 마무리하려고 한다.
내가 처음 PM을 시작한 해(12년 전쯤이었던 것으로 기억한다.)에 그때 다니던 회사에서 30년 경력의 초특급 PM을 외부에서 초빙하여 전 직원 대상으로 강의를 했던 적이 있다.
전문적으로 강의를 하시는 분은 아니었던 것으로 기억난다. 그분의 강의 방식은 다소 특이했는데, 먼저 프로젝트를 하면서 어떤 부분이 어려운지, 궁금한 부분이 무엇인지 손을 들고 얘기해보라고 했다. 직원들이 처음에는 망설였지만, 한 명이 질문을 시작하자 수없이 많은 질문이 쏟아져 나왔고, 강사님은 직원 한 명에게 엑셀을 열어서 질문들을 다 받아 적으라고 했다. 개수의 제한도 없었기에 나중에는 100개 가까운 질문이 나왔던 것 같다. 솔직히 나는 강사님이 저걸 다 어떻게 답변하려고 하시나 궁금하기도 했고, 제대로 답변하기 어려운 프로젝트 진행상의 애매한 상황에 대한 질문들이 많았기 때문에 반신반의하면서 지켜보고 있었다.
더 이상 질문이 안 나오자, 그분은 엑셀 파일에 질문 옆칸에 질문별로 구분 값을 넣으라고 했다. 예를 들면, 이 질문은 일정관리 얘기고, 이 질문은 고객관리 얘기네요. 이건 범위관리고... 이런 식으로 PMBOK의 9대 관리 영역에 해당하는 이름으로 질문들을 분류하여 카테고리를 구분하였다. 이렇게 질문받고 분류하는데만 거의 30분은 족히 걸렸던 것 같다.
모든 질문에 대한 분류가 끝나자, 이번에는 구분 값을 넣은 열에 필터를 걸어서, "자 일정관리부터 얘기해볼까요."라고 하면서, 각 영역별로 본인의 생각을 얘기하기 시작했다. 정말 놀라운 것은 시작부터 끝까지 내용 하나하나가 모두 1년 차 초보 PM인 나의 가슴에 와 닿는 얘기들이었고 하나같이 실제 경험에서 터득한 얘기들이었다. 영역별로 공통적인 방법을 얘기 하지만, 각 영역의 질문들에 모두 적용할 수 있는 답변들이었고, 답변이 안 되는 질문이 있는지 체크하고 다음 영역으로 넘어갔다.
그분의 강의를 들으면서 미친 듯이 다이어리에 적었던 기억이 난다. 나는 그 다이어리를 아직도 갖고 있다. 참고로, 이 글의 내용 중에는 그분이 했던 얘기들도 많이 포함되어있다.
그때부터였던 것 같다. 나도 저런 PM이 되고 싶다는 생각이 들었던 것은... 프로젝트 관리의 모든 영역에 대해 그 정도의 통찰력을 갖고 그렇게 막힘없이 얘기할 수 있는 것이 멋있어 보이기만 했던 것 같다. 그 이후로 나의 목표는 "모든 프로젝트를 성공시킬 수 있는 완성된 PM"이었고, 그 목표는 현재도 동일하다. 아마도 미래에도 크게 바뀌지는 않을 것 같다.
이제까지 내가 PM으로 경험해온 바를 글로 적으면서 참으로 많은 생각을 했고, 많은 것들을 느꼈던 것 같다. 가장 크게 느낀 점은 내 능력의 부족함이었다. 그렇게 많이 프로젝트를 해놓고도 아직도 PM은 매번 어려운 것 같다. 어떤 프로젝트든 무조건 성공시킬 수 있다고 자신 있게 말할 수 있는 날은 영원히 오지 않을지 모르지만, 적어도 어떻게 하면 성공확률은 높일 수는 있는지는 조금은 말할 수 있을 것 같다.
앞으로 또 어떤 식으로든 PM으로 일하겠지만, 이제까지 그래 왔듯 좀 더 나은 PM이 되려고 노력할 것이고, 프로젝트를 통해 얻은 경험을 잊지 않으려고 노력하며 살아가려고 한다.
* 여기까지 부족하고 재미없는 글 읽어주신 독자분들께 진심으로 감사드립니다. 더 내공이 깊어지면 더 좋은 글로 돌아오겠습니다.
