'웹프로젝트 방법론'에 해당되는 글 3건

  1. 2013.11.21 03. 프로젝트의 시작과 준비
  2. 2013.11.21 02. 프로젝트 매니저의 프로젝트 시작 유형
프로젝트 고해소2013.11.21 21:59

지난 글에는 PM의 프로젝트 시작 유형 (http://www.magicdoor.co.kr/140) 에 대해 알아보았습니다.

이제 본격적으로 프로젝트가 시작되는 시점에서 PM은 무엇을 준비해야 하고 어떠한 것들에 대해 체크를 해야 하는지에 대해 

알아보도록 하겠습니다.


 

프로젝트 준비단계에서의 산출물 (무순서)


01. 프로젝트 착수보고서

02. 투입인력 계획서

03. Stakeholder (프로젝트 이해관계자) 또는 프로젝트 조직도

04. 프로젝트 인프라 신청서

05. 구축범위 정의서

06. WBS 1차

07. 수행계획서

08. 산출물목록 정의서


 

프로젝트 준비 단계에서 PM의 업무 순서는 통상적으로 다음과 같습니다.


프로젝트 착수보고 → 구축범위 확정 → 수행계획서 컨펌


프로젝트 수주가 확정된 후 인벌브 된 PM은 본격적인 프로젝트 준비 작업에 착수하게 됩니다.

대체로 이 시점에서는 기획파트를 제외한 프로젝트 전체 TFT가 구성되기에는 다소 어려운 단계입니다.

그래서 PM은 서브 기획자 (또는 기획 PL) 와 동시에 챙겨야 할 것들이 상당히 많은 시점이기도 합니다.



프로젝트 착수보고


가장 먼저 프로젝트 시작을 알리는 착수보고를 진행합니다.

고객사 마다 다소 차이가 있지만 보통 아래와 같은 세가지 경우로 착수보고를 진행합니다.


1. 착수보고서 문서를 작성하여 (이메일 또는 서면으로) 보고하는 간단한 형식

2. 수행계획서를 바탕으로 한 디테일한 착수보고 형식

3. 고객사와 수행사가 서로 프로젝트가 시작되었음을 인지한 상태로 별도 보고회 없는 형식


저의 경우에는 고객사에서 2번의 경우가 아니라면, 간단한 양식의 착수보고서를 작성 한 뒤 이메일로 보고하는 형식으로 착수보고를 진행하는 편입니다.



구축범위 확정


프로젝트 착수보고가 끝나면 이제 본격적으로 고객사와 전체적인 큰 틀에 대한 프로젝트 구축 범위에 대해서 협의하는 단계로 넘어가게 됩니다.


프로젝트 구축 범위를 초기에 고객사와 협의하지 않고 진행하게 되면 한번 이상은 난감한 상황에 직면하게 됩니다.

바로 고객사의 요구사항 변경 시 최초 협의한 구축 범위를 넘어선 신규 개발 요건이 발생할 수 있기 때문입니다.

이런 경우에 직면하게 되면 사업담당자와 PM은 매우 난감한 상황이 되겠죠. 이와 같은 이슈를 미연에 방지하고자 반드시 프로젝트 구축 범위에 대해 고객사와 최종 협의를 해야 합니다.

그래야지만, 프로젝트가 진행되는 도중에 고객사의 요청으로 구축범위 변경이 일어날지라도 차후 협의가 수월합니다.


프로젝트 구축 범위를 확정 짓고 나면, 해당 개발 스펙에 맞는 투입인력 계획을 수립하고 WBS 1차 작성,  프로젝트 최종 산출물 목록을 포함한 수행계획서 작성 단계로 넘어가게 됩니다.



수행계획서 컨펌


수행계획서는 제안서 요약본이라고 생각하시면 됩니다.

즉 제안서의 많은 내용들이 수행계획서에 포함되어 작성되어 집니다.

수행계획서는 가능한 빠른 시간안에 큰 틀에 대한 내용을 포함하여 작성하시면 됩니다.

제가 작성하는 수행계획서의 목차는 아래와 같습니다.


1. 프로젝트 개요

  1.1 프로젝트 개요

  1.2 프로젝트 목표

  1.3 분석과 이해

  1.4 시사점 도출

  1.5 프로젝트 범위


2. 구축전략

  2.1 디자인 컨셉

  2.2 구축 방향

  2.3 개발관리방안

  2.4 사용자 메뉴 구조도

  2.5 관리자 메뉴 구조도


3. 프로젝트 관리

  3.1 프로젝트 일정

  3.2 투입인력 계획

  3.3 수행조직

  3.4 산출물 목록


위 목차를 보시면 아시겠지만, 대부분의 내용이 제안서 작성 시 작성되는 내용들 입니다.

이 중 제안서 내용과 틀린 항목은 ‘프로젝트 범위’ , ‘프로젝트 일정’ , ‘투입인력 계획’, ‘수행조직’, ’산출물 목록’ 정도가 되겠습니다.


다시 한번 말씀 드리지만, 수행계획서는 제안서의 요약본이면서 ‘앞으로 어떠한 내용을, 어떻게, 얼마만큼, 언제까지, 누구와 하겠다’ 라는 내용이 빠짐없이 작성하시면 됩니다.


그럼 프로젝트 준비와 시작 단계에 대한 전체적인 내용을 짧게나마 마무리하며, 다음편에서는 본 단계에서 작성되어지는 산출물 포맷과 작성에 대해서 알아보도록 하겠습니다.



Posted by 꿈많은소년
프로젝트 고해소2013.11.21 19:00

프로젝트 고해소의 첫 내용은, PM으로써 프로젝트에 인벌브 되는 유형에 대해 이야기해 보고자 합니다.

우리가 말하는 웹에이전시 또는 SI 회사마다 PM이 프로젝트에 인벌브 되는 유형은 크게 차이가 없는 듯 싶습니다.

왜냐하면 프로젝트 시작 전 단계인 제안 단계는 웹에이전시나 SI 회사나 차이가 없기 때문입니다.

(차이가 있다면 알려주세요. 제가 모르는 그 무엇인가가 있을 수 있겠죠)


차이라면 일정 경력이 되어야 PM 인벌브가 되는 것 그리고 혼자 북치고 장구치는 유형이라고 할 수 있겠네요.

이 부분에 대해서는 별도로 이야기를 해보도록 할 예정입니다. 개인적으로 할 이야기가 많기에


 

자 그럼 첫 이야기 시작합니다.

프로젝트 매니저(이하 PM) 로써 프로젝트에 인벌브 되는 유형은 다음과 같습니다.

 

첫째. 경쟁 제안 → PT 발표 → (수주) 계약 → 프로젝트 인벌브

둘째. 경쟁 제안 → (수주) 계약 → 프로젝트 인벌브

셋째. 견적 제안 → (수주) 계약 → 프로젝트 인벌브

넷째. 인바운딩 영업 → 계약 → 프로젝트 인벌브


PM으로써 프로젝트에 인벌브 되는 위 4가지 유형의 차이점을 아시겠습니까?

선듯 이해가 안되실 분들이 있을 듯 싶어 유형별로 좀 더 이야기를 해보겠습니다.


첫째. 경쟁 제안 → PT 발표 → (수주) 계약 → 프로젝트 인벌브


이와 같은 경우가 PM 입장에선 해당 프로젝트 시작 시점 기준으로 가장 많은 정보를 알고 시작하는 경우입니다.

그 중요 이유가 무엇인지 아시겠습니까?


바로 제안에 참여하고 PT 발표를 통해 발주처의 요구사항 숙지, 자사의 제안내용에 대해 모두 숙지할 수 있기 때문입니다.

간혹 프로젝트 발주처의 RFP에 보면 “본 사업의 제안 발표자는 실제 수행 시 프로젝트 매니저 (PM)가 반드시 발표해야 한다”

라는 전제조건이 있는 경우가 있습니다.


둘째. 경쟁 제안 → (수주) 계약 → 프로젝트 인벌브


위의 경우에는 제안담당자(보통 컨설팅 파트) 또는 영업 담당자를 통해 제안내용(제안서), RFP를 인계 받아 프로젝트 정보를 처음 접하면서 프로젝트를 시작하게 되는 경우입니다.


주요 체크 포인트로써는, 고객사의 RFP에 명시되어 있는 요구사항 내용을 숙지하면서 자사에서 제안한 내용을 동시에 크로스 체크를 해야 한다는 것 입니다.

이런 유형의 프로젝트 시작은 대체로 1~2회 내부 미팅을 통해서 간략한 정보만 전달 받기 때문에 간혹 중요 포인트를 놓칠 염려가 있다는 점입니다.


중요 포인트를 놓치지 않으려면 반드시 RFP에 명시된 요구사항을 엑셀에 넘버링을 통한 리스트업 작업을 하면서 제안서의 제안 내용이 그에 맞게 빠짐 없이 제안 되었는지를 매칭해 보시길 권합니다. 때론 위 작업을 다소 귀찮게 여기는 PM분들도 보았는데 이 작업을 초반에 하면 바로 뒤 이어서 작업해야 할 프로젝트 구축범위 협의 시 작성할 문서로도 많은 내용을 대체할 수 있다는 장점이 있습니다.

괜한 귀차니즘 발동해 나중에 고생하지 말고, 꼭 작업하시길 다시한번 권합니다.


셋째. 견적 제안 → (수주) 계약 → 프로젝트 인벌브


넷째. 인바운딩 영업 → 계약 → 프로젝트 인벌브


셋, 넷째의 경우에는 제안서 작업은 없이 구축비용 견적(물론 발주처 요구사항 문서는 대부분 있습니다.

RFP와는 다소 다른 형태지만요) 협의로만 프로젝트에 인벌브 되는 경우입니다.

차이라면 견적 비딩을 거친 인벌브이냐? 인바운딩으로 요청이 들어와 계약을 통해 인벌브 되느냐 차이일 뿐입니다.


이는 첫, 둘째 사례와 조금 다르게 프로젝트가 시작되고 인벌브 되는 경우입니다.

진행을 보면 아시겠지만, 단지 ‘A사가 있는데 대략 이런거 하고 싶다고해서 얼마 견적으로 계약했어’ 로 초기 정보를 듣습니다.


즉, 인벌브 된 PM은 가장 먼저 고객사의 구축 요구사항에 대한 디테일한 재확인 작업이 선행되어야 합니다.

재확인 된 요구사항 규모와 내용에 따라 실계약 금액의 변동이 발생하기 때문입니다.

간혹 이 단계에서 개발사가 프로젝트 진행을 포기하는 경우도 왕왕 발생하기도 합니다.

PM으로 프로젝트에 인벌브 되는 경우는 다양하다면 다양하고 큰 케이스로 묶으면 또 2가지 정도로 좁힐 수 있기도 합니다.

제안 작업을 했느냐? 안했느냐? 로 말이죠.


어떠한 경우로 PM 인벌브 되던지, 시작은 대체로 동일합니다.

고객사의 요구사항 재확인, 자사의 제안 내용 재확인 (제안 시)에 따른 세부 내용 확인이죠.



보통 제안 단계에선 아래 산출물 리스트가 발생합니다.

1. 회사소개서

2. 요구사항질의서 (RFI)

3. 제안서 (요약본 포함)

4. 프레젠테이션용(PT) 파일

5. 제안 견적서

6. 디자인 시안 컨셉서

7. 디자인 시안 (보드 포함)


프로젝트의 시작은 제안을 하던지 안하던지 앞서 발생하는 단계인지라 처음으로 관련 내용을 다루어 봤습니다.

이제 다음 포스팅 부터는 본격적으로 프로젝트의 시작인 “프로젝트 준비” 단계에 대한 내용을 이야기해 보도록 하겠습니다.

프로젝트 준비 단계에서는 무엇을 체크해야 하고, 또 어떤 산출물과 작업 문서가 있는지 알아보도록 하겠습니다.



용어설명.

RFP (Request For Proposal) 란,

업무요구, 기술요구, 운영요구에 해당하는 3대 요구사항을 명시한 프로젝트 발주처에서 작성하여 제시하는 문서


RFI (Request For Information) 란,

RFP에 명시된 주요 요구사항에 대해 제안 참여 업체에서 해당 요구사항별로 질의를 통해 답변을 요청하는 문서



Posted by 꿈많은소년

티스토리 툴바