RFP(제안요청서) 쓰는데
자격이 필요하다.
#1 슬기로운 PM 생활 - 실패하지 않는 프로젝트 관리
프랑켄슈타인(Frankenstein) 같은 프로젝트 요구사항으로 우리 시스템 정말 성공할 수 있을까?
'갑'이라는 이유로 마음대로 써서 던져진 RFP(Request for Proposal)의 폐해
이사짐센터 불렀더니 화장실 고치고 부엌 확장해 달라하는 '갑'님들
수시로 바뀌는 요구사항은 프로젝트 비용과 시간 같이 고려 필요
프로젝트하는 데 나만 일하고 옆에서 보고 있는 현실 너무 힘들다 정말
현실적인 RFP(제안요청서)와 현실적인 프로젝트 조직이 답이다.
프랑켄슈타인(Frankenstein) 같은 프로젝트 요구사항으로
우리 시스템 정말 성공할 수 있을까?
회사에서 프로젝트를 할 때 가장 먼저 하는 것은 2가지 있습니다. 정보요청서(Request for Information, 이하 RFI)와 제안요청서(Request for Proposal, 이하 RFP)를 통해 정보요청이나 제안요청을 할 수 있습니다. RFI는 RFP를 작성하기 전에 프로젝트 계획 및 수행에 필요한 정보를 수집하기 위해 복수의 공급업체에게 요청하는 정보 요청서 입니다. 이를 기반으로 RFP의 요구사항을 정리하여 제안 업체에게 프로젝트 제안 요청을 하는게 일반적인 절차입니다.
하지만 RFI(정보요청서)를 통해 각 솔루션 벤더 또는 SI 업체로 부터 받은 정보를 기반으로 RFP(제안요청서)를 작성하게 되지만 실제 현실성이 없는 RFP(제안요청서) 명확히는 터무니 없는 요구사항이 만들어 집니다. 마치 프랑켄슈타인과 같이 세상에 없는 세상에 좋은 것만 모아 놓은 요구사항이 만들어집니다. 프랑켄슈타인은 메리셸리가 과학 실험에 의해 만들어진 괴물 입니다.
이렇게 만들어진 RFI에 모아진 관련 업체의 솔루션의 장점들만 모아서 만들어진 요구사항 리스트의 RFP는 많은 업체에서 부담을 가지고 받을 수 밖에 없는 요청입니다. 정말 이렇게 만들어진 요구사항이 정말 좋은 시스템으로 이어진다면 필요한 일이지만 현실은 안맞는 솔루션을 요구사항에 끼워 맞춘다고 정말 목표 시스템이 필요한 부분이 간과 되는 게 너무 안타깝습니다.
'갑'이라는 이유로 마음대로 써서 던져진
RFP(Request for Proposal)의 폐해
여러 업체에서 RFI(정보요청서)를 통해 모아진 비현실적인 요구사항 리스트는 각 솔루션 / SI (System Integration) 업체에 RFP(제안요청서)로 보내져서 많은 고민을 하게 만듭니다.
RFP를 받은 업체 엔지니어들의 반응은 어떨까요?
뭘 만들고 싶어하는지 이해가 안가네
이건 뭐지 세상에 없는 것을 만들어 달라고 하네
이 시간 안에 만들 수 있을까?
바보 아냐? 반대가 되는 요구사항을 같이 넣어 놓았네
영업들은 어떻게든 하라고 하겠지 어떻게 대응하지?
이러한 요구사항에 대한 제안서를 쓰는데 더 많은 시간과 인력이 소요됩니다. 우리나라와 같이 제안서 요청할 때 비용을 주지 않는 구조라면 업체들은 프로젝트에서 이러한 비용을 추가하거나 하청업체에게 더 많은 부담을 주게 됩니다. '제안요청서 업체수 X 제안기간'은 국가적으로 많은 시간을 소요하게 되고 이렇게 쓰여진 시간과 인력은 다른데 쓸 수도 없는 버려지는 공수입니다.
이러한 목표모델이 없는 시스템은 단지 업체에만 주는 부담이 아닌 발주사(고객)에게도 되돌아오는 폐해가 되기에 서로를 위해서 사전 스터디를 통해 실제 목표 시스템을 고민하고 RFP(제안요청서)를 요청하는 것이 필요합니다.
이사짐센터 불렀더니
화장실 고치고 부엌 확장해 달라하는 '갑'님들
위에서는 너무 많은 요구사항을 취합하여 RFP를 보내는 문제점을 이야기 했지만 이번에는 너무 작은 요구사항을 요청한 후 프로젝트에서는 전혀 다른 요구를 하여 당황하게하는 '갑'님들은 프로젝트의 또 다른 리스크 중 하나 입니다.
아래는 실제 고객의 요구와 프로젝트팀이 동상이몽하는 각 역할별 이미지를 그려 놓은 케이스입니다.
(출처. How to Build a Tire Swing - A Case for Agile Development)
How to Build a Tire Swing - A Case for Agile Development (출처. blogs.perficient.com)프로젝트를 진행하다 보면 고려하지 못한 여러가지가 있을 수 있습니다. 하지만 준비를 하지 않고 두리뭉실한 문구 하나로 다 포함된 것이라고 하면 실제 프로젝트하는 업체는 날림으로 프로젝트를 수행할 수 밖에 없는 것이 현실이고 이렇게 수행된 프로젝트는 실제 지원도 못받으며 실패한 프로젝트로 남게 됩니다. 결국 '갑'과 '을' 모두 피해를 입게 됩니다.
프로젝트 초기에 요구사항에 대해 명확하게 하고 프로젝트 관련자(Stakeholder)들과 합의를 하고 진행하는 것이 필요합니다. 필요에 따라서는 파일럿 프로젝트를 진행하며 실제 구현 이미지를 통해 방향성을 같이 합의하고 진행하는 것이 프로젝트 막바지에 "이 산이 아닌가 봐" 라는 이벤트를 피할 수 있습니다. (프로젝트 초기에 시끄러운 프로젝트가 성공할 확률이 더 높아지는게 현실입니다.)
수시로 바뀌는 요구사항은 프로젝트 비용과 시간 같이 고려 필요
프로젝트는 구축 업체만의 문제가 아닙니다. 프로젝트의 성공에 따라 발주사와 수행사의 담당자 모두 중요한 사항임을 명심해야 합니다. 우리는 턴키 계약이니 당신들이 책임져야지 하는 이야기는 이전에 무책임한 이야기입니다. 같이 동반 성장하지 않으면 서로 눈가리고 아웅하는 식의 프로젝트 결과로 지속적인 비지니스 모델이 될 수 없습니다.
일반적으로 발주사 PM과 수행사 PM이 초기 요구사항에 대해 합의하고 추가적인 요구사항에 대해서는 중요도, 난이도, 공수 등을 반영하여 진행하는 것이 필요합니다. 또한 발주사에는 프로젝트 진행시 발생하는 추가 요구사항이나 변경사항을 위한 추가예산(Additional Budget)을 초기 계획에서 5~15% 정도를 잡아두면 현업들에 요구에 부합하는 결과를 도춣하는데 도움이 될 것입니다.
프로젝트하는 데 나만 일하고
옆에서 보고 있는 현실 너무 힘들다 정말
프로젝트하는 데 왜 나만 밤새고 있고 다들 옆에서 지시만 하는지 답답한 느낌일 때 다들 있을 거예요. 일복이 많은 나에게만 일어나는 일인지 너무 프로젝트 관리자(Project Manager, 이하 PM)은 너무 힘든 역할인 것 같습니다.
특히 해외와 같이하는 프로젝트에서는 이러한 시누이 노릇하는 분들 때문에 프로젝트는 더 많은 부담을 가지게 됩니다. 일하는 사람은 혼자인데 프로젝트의 온갖 매니저가 감 나와라 배 나와라 하는 현실은 국내외 모든 프로젝트에서 벌어지고 있는 현실입니다.
Project Worker (출처. 인터넷 유명 프로젝트 삽질 관련 이미지에 한국 프로젝트에 역할 맵핑 이미지)프로젝트에서 개발자(작업자)가 일할 수 있는 환경을 조성하는게 프로젝트 관리자의 중요한 역할 중에 하나입니다. 잔소리 쟁이가 아닌 실제 작업자들이 편하게 프로젝트를 진행할 수 있도록 하는 것이 중요합니다.
현실적인 RFP와 현실적인 프로젝트 조직이 답이다.
정말 마음 같아서는 RFP 쓰는 데 자격증을 부여하고 싶은 마음이 들 정도로 엉망인 RFP(제안요청서)가 난무하지만 조직의 현실에서도 해보지 않은 프로젝트에 대해 잘 정리해서 RFP를 요청하는 작업은 쉬운 작업이 아닙니다. ISP(정보 전략 계획) 수립 후 단기 과제 도출할 때 RFP 요건을 만들어 내는 곳도 컨설턴트를 통해 체계적으로 요구사항들을 정리하는 방법도 하나의 안이 될 수 있습니다.
또한 현실적인 RFP(제안요청서)를 쓰기 위해서는 현업들에게 요구사항을 취합하고 IT에 맞게 재해석하는 IT 기획팀의 역할도 중요한 역할 중에 하나입니다. IT 기획 부서에서는 현업의 요구를 일부는 운영팀에 반영하고 일부는 프로젝트화 하여 프로젝트팀으로 전달하는 형태의 요구사항 관리(Demand Management)를 할 수 있는 체계를 구성하는 중견 이상의 회사에서는 필수 사항이 될 수 있습니다.
Demand Management현업의 요구사항은 거의 기능과 화면 중심의 요구가 기반이 됩니다. 이러한 요구의 백그라운드(Background)에는 데이터 모델링, 데이터 표준화, 인터페이스 요건, 배치 프로그램 등 보이지 않는 부분의 요구사항을 도출하여 RFP에 적용하는 부분에 반영되어야 됩니다.
만약 새로운 분야의 RFP를 만든다면 타사 사례 등을 수집하여 고려하지 못한 부분이 있는지 미리 체크하는 것도 상단에서 이야기한 여러가지 리스크 부분을 방지할 수 있습니다.
※ 슬기로운 PM 생활 - 실패하지 않는 프로젝트 관리
#1 RFP(제안요청서) 쓰는데 자격이 필요하다. https://brunch.co.kr/@df79991e83ed416/22
#2 프로젝트에서 가장 중요한 것은 작업분류체계(WBS) https://brunch.co.kr/@df79991e83ed416/26
#3 폭포수 Vs 애자일 방식 프로젝트 https://brunch.co.kr/@df79991e83ed416/25
#4 등산과 비슷한 프로젝트 여정 https://brunch.co.kr/@df79991e83ed416/28
#5 인테리어업체 사장과 IT PM의 공통점 https://brunch.co.kr/@df79991e83ed416/29
#6 프로젝트에서 중요한 것은 구축 업체 선정과 인력 구성 https://brunch.co.kr/@df79991e83ed416/32
#7 소 잃고 외양간 고치지 말자 - 실패하는 프로젝트의 전조 현상 https://brunch.co.kr/@df79991e83ed416/24
※ 글이 도움되시면 브런치 작가 "구독"과 "좋아요" 부탁드립니다.
글의 공유 및 인용은 가능하며 반드시 출처를 밝혀 주세요.
