[SI이야기][산출물] 착수보고서 작성하기

SI프로젝트를 제안하고, 협상하고, SOW도 쓰고, 계약도 했다면 이제 다음으로 해야 하는 일은 정식으로 인사하는 일이다. 명함 주면서 악수하고 자기소개하는 것이 아니라 "저희가 이 프로젝트를 수행하게 되었습니다. 제가 이 프로젝트 PM입니다. 이 프로젝트는 이렇게 수행할 예정입니다. 많이 도와주세요. 잘 부탁드립니다." 하는 단계가 필요하다. 

 

물론 이런 인사를 회의실에서 둘러앉아서 도란도란하고 싶을 수도 있고, 계약서/SOW 보고 다 알겠거니 하고 넘어가고 싶을 수도 있지만 안타깝게도 그렇게 되지 않는다. 왜냐?

 

 

1. 협상을 한 고객도 자기 상사에게 보고를 해야 하는데 그 보고를 수행사가 하기를 원하기 때문이다.

 

사업 예산을 받을 때 보고를 실컷 했을 것이고, 제안을 듣고 의사결정 할 때에도 보고를 했을 것이고, 심지어 협상 끝나고 보고를 했을지도 모른다. 하지만, 고객은 '요구사항'을 자기의 목소리를 낼 뿐, 정확히 이 프로젝트가 어떻게 진행될 지에 대해서는 보고를 한 적이 없었을 것이다. 그래서 최종적으로 결정된 내용에 대해서 보고해 줄 사람이 필요하다. 당연히 이 내용을 가장 잘 아는 '수행사'가 발표해 주는 것이 베스트다.

 

 

2. 수행사가 보고를 해야 '발언자'로서의 책임이 발생한다.

 

고객이 '우리 이렇게 할 거예요'라고 백날 보고해도 수행사가 '아닌데?'라고 하면 의미가 없는 것처럼, 수행사가 '우리 이렇게 하겠습니다'라고 알아서 보고를 해줘야 수행사도 자기가 내뱉은 말에 대한 책임을 지게 되기 때문에 수행사가 보고를 하는 게 여러모로 용이하다.

 

 

3. 그냥, 보고 받고 싶으니까.

 

사업이 너무 작거나 실무자가 '그런 거 필요 없고 프로젝트만 잘 되면 됩니다'하면서 서면으로 대체해 주는 경우도 있다. (서면으로 제출하면 직접 고객이 보고하는 경우도 있다.) 이런 상황을 맞이했을 때 내가 느낀 건, '아 착수보고라는 것은 결국, 쇼구나'라는 것이었다. 그래서 '그래, 그만큼 돈을 들였으니 이런 이벤트도 하고 싶은 거겠거니...' 하면서 착수보고에 대응하곤 한다.

 

그래서 착수보고서를 써야 하는 상황이 발생하게 되었을 때, 어떤 내용을 넣어야 할까?

---

목차는 다음과 같다.

 

Ⅰ. 프로젝트 개요

Ⅱ. 프로젝트 추진 범위

Ⅲ. 프로젝트 추진 조직

Ⅳ. 프로젝트 추진 일정

Ⅴ. 협조 사항

---

Ⅰ. 프로젝트 개요

 

보통 프로젝트의 배경/목적을 작성한다. 이 프로젝트가 해결하려고 하는 문제가 무엇인지, 이 프로젝트를 통해서 달성하고자 하는 내용이 무엇인지를 작성한다. 보통 제안서를 썼다면 제안서의 '배경 및 목적'이 이런 내용이 된다고 볼 수 있다. 

 

 

Ⅱ. 프로젝트 추진 범위

 

이 프로젝트의 범위를 명시해 주면 되는데, 제안서를 썼다면 제안 범위가 전체 범위라고 할 수 있다. 보통은 업무 구조도를 넣는 편이고 필요하면 그 뒤로 시스템 구성도, 네트워크 구성도 등 쭉 붙여 넣으면 된다. 이 범위 장표를 보면 전체 범위를 알 수 있어야 하고, 다른 시스템과의 인터페이스까지 포함되는 경우라면 그 시스템까지도 다 그려주고 인터페이스 대상이다 아니다 를 명확하게 표시해줘야 한다.

 

추진 '범위'라는 목차 대신 '프로젝트 구축 상세'라는 조금 더 포괄적인 제목을 넣고 범위와 각 영역별 구축 방안을 설명하는 내용을 넣어도 된다. 결국은 제안-협상하면서 결정된 내용을 브리핑하는 부분인데 보고 대상이 가장 궁금해할 내용이 여기서 소구(Sales)되는 것이 필요하다. 가끔은 '무얼 한다'보다 '어떻게 한다'가 더 중요한 경우가 있으니 프로젝트에 따라 맞춰서 대응하는 것을 추천한다.

 

 

Ⅲ. 프로젝트 추진 조직

 

이번 프로젝트 수행 조직을 그려주면 된다. PM, PL 레벨은 이름까지 다 들어가야 하며 고객사 조직도도 들어가는 것이 기본이다. 이미 계약하고 같이 일하기로 정했기 때문에 이 장표의 절반은 고객의 지원을 받아서 작성해야 한다. 미안해할 일도 아니고 당연한 사실을 적시한다는 마음으로 적으면 된다. 협상하면서 파악이 되지 않았다면 당당하게 자료를 요청하면 되고, 다 작성한 후에는 고객의 검토를 받으면 된다.(모든 장표가 고객 리뷰 대상이다) 

 

조직의 장표는 우리 조직도를 보고하는 것도 물론 목적이 될 수 있지만 그보다는 이 프로젝트의 이해관계자가 어디서부터 어디까지인지 인지하고 있다는 것을 알려주는 것이기도 하고, 고객사의 누가 우리 수행사의 누구와 동등한 레벨인지 식별하기 위함도 있다. 레벨이 같은 사람들은 이 조직도에서 같은 레벨로 그려지게 되어 있다. (동등하다는 게 다이다이 뜬다는 건 아니고, 어떤 일을 해결함에 있어서 의사결정 체계와 문제가 발생했을 때 누가 누구랑 이야기해서 해결할지를 판단하기 위함이라고 생각하면 될 것 같다.)

 

 

Ⅳ. 프로젝트 추진 일정

 

프로젝트 일정이다. WBS를 넣는 경우도 있지만 이건 프로젝트가 매우 짧은 기간에 이루어지는 거라서 PPT의 여유가 있을 경우에 부릴 수 있는 사치이다. 보통은 프로젝트 마일스톤, 각 단계를 적시하고 단계별 주요 액티비티를 그리면 끝나게 되어있다. 이 장표에서는 마일스톤이 가장 중요한 정보다. 언제 시작하는지, 중간보고/종료보고가 언제인지, 분석/설계/개발/테스트/오픈/운영 이 언제인지 등을 알 수 있게 정리하면 된다. 관리자로서 알아야 하는 주요 날짜를 전달하면 충분하다.

 

 

Ⅴ. 협조 사항

 

착수보고에 들어가는 내용인데, 처음 하는 보고이기도 하고 어떻게 할지 보고하는 자리이기도 하지만 한 편으로는 보고하는 PM이 이 프로젝트를 잘하기 위해 요청할 내용을 말할 수 있는 유일한 기회가 되는 자리이기도 하다. 협상 때도 물론 말하지만 보통은 이 착수보고에 오시는 분들은 협상했던 분들보다 더 높으신 분들일 확률이 높다. 그래서 협상 때 들어온 실무자도 힘이 없어서 못해주는 것들이 있다면 이 자리를 빌어서 요청하는 것도 방법이다. 윗사람이 그걸 보고 '저거 지원해 주세요'라고 말 한마디 하고 가주시면 만사 해결되는 놀라운 경험을 하게 될 수도 있다.

 

물론, 이 협조사항을 고객에 대한 못마땅함을 이르는 용도로 활용해서는 안된다. '쟤네 지금 우리 윗사람에게 뭔 소리 하는 거야?'라는 기분이 들지 않도록 하는 것이 중요하다. 실무자가 자기 윗사람에게 차마 말을 하지 못하는 것을 먼저 말해주는 게 좋다. 어차피 고객 리뷰를 받고 보고를 하게 되어 있어서 대체로 필터가 되겠지만 이 영역을 현명하게 활용하는 것을 추천한다. 설령 말해도 들어주지 않았다 하더라도, 나중에 프로젝트가 문제가 생겼을 때 착수보고에 이걸 쓰고 안 쓰고의 기록이 많은 것을 좌우할 수도 있다. 성공적인 플젝을 위해 해야 할 말이 있다면 협조 사항에 꼭 쓰도록 하자!

---

정리하자면, 착수보고는 제안-협상을 통해서 결정된 최종내용, 즉 계약한 내용을 모두에게 공유하는 자리다. 양사 상견례 자리에 상호 간에 합의한 내용을 공유해 주는 자리라고 할 수 있다. 그러니 공동의 목표를 공유한다는 마음으로 보고를 하면 된다. 그렇기 때문에 고객사도 수행사도 엄청 힘들게 리뷰를 하게 되는 경우도 있으니 참고하기를 바란다. 개인적으로 착수보고에 가장 높은 레벨은 고객사 CIO 정도까지 본 것 같다. (IT 쪽에서 가장 높은 사람이 왔다는 이야기나 다름없다.)

 

종종 헷갈릴 것 같아서 혹시나 하는 마음에 부연 설명을 하자면, 착수보고서에는 '미래'의 이야기는 잘하지 않는다. '이 프로젝트를 하고 나면 다음에 이런 걸 할 수 있습니다'라는 내용은 이 자리에서는 거론하지 않는다고 볼 수 있다. 뒤에 쓰겠지만 그건 '종료보고서'의 영역이다. 그러니 착수보고는 어떻게 이 프로젝트를 잘할 지만 고민하면 된다. 그 이후를 생각하기에 아직 갈 길이 너무 멀다. (아주 드물게 그런 내용을 넣어달라고 하는 고객이 등장하는데 그럴 때에는 '기대효과' 장표에 살짝 터치해 주는 정도로 하면 될 것 같다. ^^)