협력업체 선정과 관리
협력업체를 데리고 일해야 하는 경우 생각할 것들
프로젝트 진행상 협력업체 선정이 필요한 경우는 대체로 다음과 같다.
첫 번째, 기술측면에서 전문영역이 존재하는 경우 리스크 회피 차원에서 전문 솔루션을 도입하거나, 특정 분야의 경험이 풍부한 전문업체에 아웃소싱한다.
두 번째, 개발물량이 너무 많아서 우리 회사 단독으로 처리하기 어려운 경우, 투입인력을 보유한 협력업체에 특정 개발부분을 아웃소싱한다.
세 번째, 대기업 IT업체의 경우 그룹사에 IT시스템 도입하기 위해 우리 회사가 업체선정을 하고 사업관리PM 역할로 프로젝트를 수행하는 경우, 즉 내가 발주처PM으로 구축업체를 선정하여 프로젝트를 진행하는 경우이며, 이 경우 대부분의 실제 개발은 협력업체가 진행하게 된다.
갑 : 그룹사, 실제 시스템을 사용하는 고객
을 : 그룹의 IT회사, 대체로 업체선정, 사업관리만 수행하며, 자사 개발인력은 투입하지 않음
병 : 실제 개발수행업체
협력업체와 일을 하는 것은 생각보다 쉽지 않다. 그 협력업체에서도 누군가는 PM의 역할로 나와있는 것이고, 최대한 범위확장을 방어하려고 할 것이다. 의사소통을 할 때 책임자 대 책임자의 입장으로 얘기를 하기 때문에 내가 협력업체의 PM으로 일할 때와는 다른 마인드가 필요하다.
협력업체 선정 시 생각해야 할 부분
1. 보유 기술
구현대상 목표시스템의 전체 기능을 모두 구현해보았는지, 해당 기술을 보유하고 있는지 검증해야 한다.
늘상 경험하는 일반화된 솔루션이 아니라면, 제안서나 문서에 나와있는 내용을 보고 안심하지 말고, 가능하면 실제 데모시스템을 통해 확인해보자.
실제로 데모시스템을 통해서 확인해보면, 데모시스템 상에도 오류가 되어있는 경우도 많고, 빠진 기능이 있는 경우도 많다.
데모시스템에 오류나 누락된 부분에 대해 해당 업체에 문의해보면 명확하게 답을 못하는 경우가 많은데, 이런 부분에 대해서는 일단은 리스크가 있다고 봐야 한다.
2. 업체가 경험해 본 규모
규모 : 시스템을 사용할 사용자 수가 1만명이라면, 1만명이 사용하는 시스템을 구축해 본 업체를 골라야 한다. 그것도 최대한 많은 경험을 보유한 회사일수록 유리하다. 사용자의 규모에 따라서 없던 오류가 생기기도 하고, 대처방법도 달라져야 한다.
사용자의 규모에 관한 나의 경험을 얘기하고자 한다. 예전에 내가 다니던 회사는 새롭게 그룹웨어 솔루션을 개발하여 시장을 개척해가는 중이었고, 이제까지 경험한 최대 사용자수는 600명인 상태였다. 신규로 도입하는 고객사의 직원수는 800명이었고, 나는 200명 정도의 차이는 그리 문제되지 않을 것이라고 생각했는데, 서비스 정식 오픈 첫날부터 출근시간 동시 접속으로 인한 장애가 2~3주간 계속되었다. 연구소에서 그룹웨어 메신저 로그인시에 발생하는 메모리 누수 문제에 대해 해결을 한 이후에야 안정화되었다.
그런 일은 규모가 큰 프로젝트로 넘어갈 경우, 그 다음에도 여지없이 반복되었다. 그 다음으로 경험한 프로젝트는 직원수가 1300명이었고, 이전까지 경험했던 최대 사용자수는 1000명이었기 때문에 이전과 똑같은 일이 반복되었다.
IT시스템에서 사용자 수가 두 배가 될 경우, 단순히 서버를 두 배로 늘리면 해결될 것이라고 생각하는 것은 정말 단순한 생각이다. 서버를 두 배로 늘리더라도 문제는 해결되지 않을 수 있다. 네트워크 대역폭이나, DB서버나, 그 SW자체가 문제일 수도 있고, 그 외 다른 곳이 병목이 될 가능성은 얼마든지 있다. 또한, 그 문제를 해결하기 위해서는 절대적인 시간이 필요하다.
인위적으로 부하를 발생시켜 부하테스트를 해보았고, 그에 따라 발생되는 문제를 모두 해결했다 하더라도 실제 서비스오픈시에는 예상치 못한 문제가 얼마든지 발생할 수 있다.
따라서, 특정 사용자 규모의 IT시스템을 처리해보았다는 것은 SW개발회사 입장에서는 가장 중요한 경험이고, 업체를 선정하는 입장에서는 가장 중요한 평가지표 중 하나이다.
3. 협력업체의 규모
협력업체 자체의 규모가 수행해야하는 프로젝트의 규모에 비하여 너무 작은 경우, 즉 업체가 너무 작으면 발주처 입장에서는 그것도 문제가 될 수 있다.
일정이 지연되거나 범위가 일부 확장될 경우, 원래 투입했던 개발자가 회사를 그만두는 경우 등 이슈가 발생하는 경우라도 너무 작은 회사에서는 투입 가능한 대체인력이나 추가인력 자체가 없을 수 있다.
발주처의 입장에서는 투입된 개발자의 능력이 부족하여 교체를 요구할 수도 있겠지만, 그 업체 입장에서는 그나마 그 인원이라도 지키려고 할 것이고, 대체할 수 있는 인력도 없는 경우가 많다. 그러한 리스크가 발생할 경우, 프로젝트 완료에 대한 책임은 오롯이 발주처(을)이 지게 되는 것이므로, 업체를 선정하는 입장에서는 회사의 규모를 고려하지 않을 수 없다.
4. 업체의 평판
동종업계의 지인을 통해 시장에 떠도는 평판을 들어볼 수도 있을 것이다. 그보다 더 좋은 방법은 해당 협력업체가 실적으로 제시하는 고객사의 담당자를 알아내어 해당 업체와 일해본 경험을 들어보는 것이다. 물론, 뒤를 캐고 다니는 느낌이므로 조심해야 할 것이고, 역효과가 있을 수도 있겠지만, 실제로 일해본 사람의 얘기를 들어보는 것보다 더 정확한 판단은 없을 것이라고 생각한다.
금액은 위 모든 사항이 충족되고 난 이후에 고려해야할 부분이라고 생각한다. 그럼에도 불구하고 업체선정시 저가로 입찰한 업체가 선정될 가능성이 높아지기 마련인데, 그럴 경우, 그에 대한 리스크는 발주처에서 지게 될 것이고, 책임은 발주처의 담당자인 당신이 지게 될 것이다. 따라서, 그 모든 책임을 당신이 질 각오로 업체를 선정해야 할 것이다.
협력업체 관리시 생각할 부분
1. 관리의 기준을 명확히 한다.
프로젝트 초반부터 어떻게 프로젝트를 관리할 것인지에 대한 기준을 명확히 세우고, 그 기준을 협력업체에 명확히 전달하여 보고하도록 해야 한다.
산출물의 작성범위, 일정계획, 인력투입계획, 주간보고 일정/내용, 진척률 산정 기준, 품질관리 기준 등을 프로젝트 초반에 모두 결정하자.
사업초반에 미처 수립하지 못한 기준을 프로젝트 중간에 추가하려고 할 경우, 협력업체의 저항이 발생할 수 있으므로, 프로젝트 관리범위 전체를 되새기면서 빠지는 부분 없이 기준을 세울 수 있도록 하자.
2. 결정한 기준 대로 관리한다.
협력업체 PM 입장에서는 발주처 관리자인 내가 고객이므로, 당연히 조금이라도 더 친해져서, 프로젝트 수행상 유형/무형의 편의를 얻으려고 할 것이다. (내가 협력업체 PM이라도 당연히 그렇게 할 것이다.)
협력업체에서는 가능하다면 인력투입을 늦추려고 할 것이고, 적은 인원을 투입하고자 할 것이고, 되도록이면 비상주로 진행하고자 할 것이다. 이럴 경우에는 당초에 정한 기준과 일정을 고수하는 방향으로 진행해야 한다. 특히 프로젝트 초반일수록 더욱 그래야 한다. 작은 것 하나씩 편의를 봐주다보면, 가랑비에 옷이 젖어가듯이 전체 프로젝트가 망가져갈 가능성이 있으며, 프로젝트 후반부로 갈수록 만회할 기회는 점점 줄어들 것이다.
따라서, 발주처PM은 협력업체의 PM과 어느정도 거리를 두는 것이 좋으며, 결정한 기준대로 프로젝트 수행이 되지 않을 경우 당초에 결정한 기준대로 진행할 것을 강력하게 요구하여야 한다.
3. 미리미리 준비시키자.
당초에 합의한 관리 기준과 전체 프로젝트의 일정, 향후 2~3주간의 계획을 지속적으로 주지시키자.
협력업체는 여러 프로젝트를 동시에 수행중인 경우도 많고, 지금 당장의 개발이슈를 해결하느라 전체 일정에 대해서는 미처 생각하지 못하고 있을 수 있다. 따라서, 발주처 PM은 전체 프로젝트의 일정과 향후 2~3주 내에 이루어져야할 업무들에 대해 지속적으로 주지시키고 미리미리 준비할 것을 알려줄 필요가 있다.
이러한 활동만 잘 해도 대부분의 경우, 협력업체와의 큰 충돌없이 프로젝트를 진행시켜나갈 수 있다.
4. 진척률은 직접 눈으로 본 것에 대해서만 믿는다.
직접 눈으로 보지 않은 사항에 대해서는 실적으로 인정하면 안된다. 협력업체에서 개발이 완료되었다고 보고하는 내용도 실제로 확인해보면 기본적인 오류처리도 되지 않은 경우가 다반사이다. 협력업체의 보고내용을 곧이곧대로 믿지 말고, 되도록 직접 눈으로 확인하기 위해 노력하자.
협력업체에서는 되도록이면 이슈를 수면위로 드러내지 않고 자체적으로 해결하려고 노력할 가능성이 있는데, 이러한 이슈를 미리부터 수면위로 끄집어내서 구체적인 해결방안을 가져오도록 요구해야 한다.
5. 이슈 발생시 취할 수 있는 action들에 대해 미리 준비해놓아야 한다.
만일, 협력업체에서 납기/품질을 지키지 못할 경우 어떻게 할 것인지, 성능/보안/안정성에 대한 기준을 충족하지 못할 경우, 어떻게 할 것인지, 대안은 있는지, 만일 해당 협력업체에서 마무리하지 못한다면, 수행해야 할 행정적인 절차는 어떤 것이 있는지까지 미리 준비해놓을 필요가 있다.
다만, 그와 같은 계획을 실제로 수행하기 위해서는 PM 스스로의 판단보다는 상위관리자의 의사결정에 따라야 하는 경우가 많으므로, 상위관리자가 올바른 의사결정을 할 수 있도록 미리부터 제반 규정, 사례, 실행가능한 대안 등을 만들어놓고 적시에 제공해야 한다.
6. 발주처PM의 마인드
당신이 발주처 PM의 역할을 맡아야 한다면, 프로젝트의 성공을 위해, 협력업체의 입장을 잘 봐주는 사람좋은 갑보다는 다소 깐깐하고 빈틈없이 체크하는 냉정한 갑이 되기로 마음먹자.
그것은 갑질이 아니라, 생존의 문제이다.
한 번 사람좋은 갑으로 인식되면, 협력업체는 야금야금 좀 더 무리한 편의를 요구해올 수 있고, 종국에는 협력업체에 이리저리 휘둘리는 존재감 없는 갑이 될지도 모른다. 협력업체에 이리저리 휘둘리는 관리역량을 보이는 직원에게 회사는 더이상 협력업체 관리를 맡기지는 않을 것이다.
물론 모든 사람이 그렇지는 않겠지만, 필자의 경험에 따르면, 잘해주면 잘해줄수록 좋은 의도로 잘해준 사람의 호의를 악의적으로 이용해먹고 뒷통수치는 사람들이 의외로 꽤 있다.
