다잇소


[비지니스] 나의PM이야기 #3 프로젝트 착수, 프로젝트 계획 수립

2015.11.18
프로젝트는 프로젝트 계획을 수립하면서 시작된다.

이번글은 프로젝트 계획 수립 부분 이지만 프로젝트 계획을 세우는 방법에 대한 내용이 아니라, 계획수립 시 점검 할 내용과 발생 할 수 있는 이슈등을 이야기 하려 한다.

(프로젝트 계획 수립은  ▶ #2 프로젝트 착수, 프로젝트 준비 에서 정한 일정 계획에 따라 수립한다.)

PM_다잇소

⊙ 프로젝트 계획 수립


프로젝트 범위, H/W 및 S/W, 인력투입계획, 개발일정 등 프로젝트 정보를 파악하여 프로젝트 계획을 수립한며, 프로젝트 정보는 제안요청서, 제안서, 제안설명회 발표자료, 계약서 그리고 고객사에서 요청했던 내용과 제출자료들을 이용하여 수집 할 수 있다.

 

 

1. 프로젝트 범위는 제안요청서와 제안서를 매핑하고, 계약서의 구축업무와 맵핑하여 정리하며, 목적은 1)고객과 범위 확정하고, 2)협력업체와의 범위를 확정하기 위한 것이다.

정리된 프로젝트 범위는 요구사항정의 단계부터 테스트, 이행,  오픈까지 추적 관리를 해야 하며, PL들이 명확하게 이해하고 진행 할 수 있도록 가이드가  필요하다.

 

 

2. 자원 점검은  H/W의 수량(운영/개발시스템)과 OS버젼, 메모리 크기, CORE 수 등 사양과 S/W의 수량, 버전, 라이선스등 시스템을 개발하고, 운영하는데 이상이 없는지 철저히 점검, 정리해야 한다.

간혹, H/W의 OS버젼, DBMS 버전, WAS버전, 개발툴 버젼등과 문제가 되거나, S/W가 누락되는 경우가 있기 때문이다.

프로젝트팀에 설치 관리담당자를 반드시 지정한다. 주로 TA, AA등이 담당하지만, 작은 규모의 프로젝트는 없을 수 도 있으니, 반드시 담당자를 지정하여 관리해야 한다.

 

자원(H/W,S/W)의 설치가 지연되면, 프로젝트 일정에 미치는 영향이 크기 때문이다.

PM_다잇소1

3. 개발일정은 프로젝트관리, 개발업무의 단계별 일정, 데이터이행, 시스템 구축등의 일정을 연관성있게 하는 수립하는 작업이다.

프로젝트 관리 일정은 착수보고, 중간보고, 컷오버 검토, 종료보고등의 일정이고,

단계별 일정은 요구사항정의, 분석, 설계, 구현, 테스트(단위, 통합, 인수), 이행, 오픈, 안정화 기간을 포함한 프로젝트 전체 일정으로 동료검토 일정을 포함해야 한다.

데이터이행 일정은 데이터를 이행하기 위한 분석/설계, 개발, 테스트 일정이라고 생각 할 수 있지만,   개발업무의 데이터 분석/설계 일정과 연관하여 일정계획을 수립해야 하며, 데이터 검증은 통합테스트 이전에 완료 할 수 있도록 계획을 수립해야 한다.

 

시스템 구축일정은 구현, 테스트, 데이터/어플리케이션/시스템이행 일정등을 고려하여 진행에 차질없도록 시스템이 사전에 준비하는 일정으로 계획을 수립하고,  어플리케이션 테스트 일정을 고려하여 시스템 테스트 일정을 포함한 계획을 수립해야 한다.

 

 

이러한 모든 일정계획의 결과물이 WBS(Work Breakdown Structure)이다.

WBS를 작성하는 요령은 고객사의 유사 프로젝트의 WBS를 참조하여 프로젝트의 특징을 반영하고 담당업무별 상세화 작업을 하여 WBS를 작성할 수 있다.  PM은 PL들과 일정은 받드시 검토하여 확정하도록 한다.

고객사 WBS를 참조하는  이유는 고객사의 Task 및 Activity를 알 수 있기 때문이다.

 

 

4.인력투입계획은 계약인력과 실제 투입하는 인력의 차이가 있는지 확인하고, 투입하는 인력에 대한 Skill Set등 확인과 개발기간에 정당한 인력이 투입하는지 확인한다.

 

 

5. 교육계획은 개발자 및 고객사 사용자와  IT담당자의 교육 일정을 정하는 작업으로 개발자 교육은 시스템 구축을 위한 프로젝트 관리 프로세스, 형상관리의 규칙,처리 프로세스와 단계별로 작성해야 할 산출물에 대한 작성가이드가 해당하며,

고객사의 사용자와 IT담당자 교육은 프로젝트 초기에 정의하기 어려운 부분이라 대략적인 교육일정(구현단계, 이행단계 전 정도)과 교육할 내용을 정의하고, 프로젝트가 진행 됨에 따라 상세화 한다.

 

 

6. 그외 품질관리계획, 형상관리계획, 위험관리계획, 변경관리계획, 의사소통 관리계획 등은 정해진 관리 프로세스를 따라 수행하기 때문에 이번 이야기에서는 자세한 내용은 생략한다.

 

 

Project Manager는 프로젝트 계획수립 시 프로젝트 성공에 영향을 줄 수 있는 중요 업무와 핵심과제가 무엇인지 파악하는 것이 중요하며,  파악된 중요 업무와 과제는 프로젝트가 종료 될 때까지 지속적인 관리를 해야 한다.

 

 

이상으로 프로젝트 계획 수립에 대해 간단히 알아 보았다. 프로젝트 계획서 작성을 형식적인 절차로만 생각해서 타 프로젝트의 계획서를 Copy & Paste해서 승인 받으려 생각한다면, 이는 매우 잘못된 생각이다.

 

프로젝트계획 수립은 문서 작업뿐 아니라 개발범위, 제안시 H/W와 S/W가 누락여부, 투입인력 계획과 프로젝트 일정 점검 등을 확인하고,  WBS가 개발산출물을 작성하는 Task와 Activity로 만 작성하였는지 확인하여 실제 작업할 내용으로 세분화하였는지 확인하고,  프로젝트를 종료 시 까지의 모든 일(Task & Activity)을 계획하는 것이기 때문이다.

 

 

특히, 프로젝트계획서 작성을 사업관리나 QA에게 맡기고, 최종 결과물만 확인하는 PM0도 있지만, 직접 챙겨서 계획을 수립하는 것이 바람직 하다.  PM이 직접 계획을 수립해야 업무범위, 개발일정등을 PL들과 함께 고민 할 수 있다.

QA는 산출물 테일러링과 품질관리, 형상관리, 프로젝트 관리 절차 등을 확정하고,  요구사항 정의단계 산출물을 확정하여 공지해야 한다.

PM_다잇소3

프로젝트 계획수립 시 중요 Task

프로젝트계획 수립 중 이슈가 발생할 수 있는 부문은 개발 범위와 일정이다.

 

개발범위는 제안요청서와 제안서, 계약서를 기준으로 정리하면, 고객의 생각과 차이가 있더라도 제한된 자원으로 할 수 있는 범위가 정해져 있기 때문에 고객과 협의하여 해결이 되는 경우가 많다.

 

그러나, 개발일정과 관련한 이슈는 해결하기 어려운 경우가 많다.

당초 정해진 오픈일자가 계약이 늦어짐에 따라 프로젝트 시작이 늦어져 개발기간을 단축해야 하는 경우와 고객사에서 조기 오픈을 요구한 경우 발생한다.

이러한 이슈가 발생하면, PM은 조기 오픈 가능 여부를 검토해야 만 한다.

PM_다잇소4

조기 오픈을 꼭 하겠다는 것은 아니지만, 긍정적인 마인드로 검토하는 것이 좋다.

그래야만, 오픈을 하기 위해 발생 할 수 있는 내/외부 모든 문제점을 모두 도출 할 수 있으며, 문제점에 대한 해결 방안을 찾아야만 하기 때문이다.

문제점과 해결방안 등 모든 경우의 수를 검토하여 PM은 개발PL, 고객PM과 협의하여 최종 결정을 한다.

 

 

PM은 조기 오픈 자체가 리스크이기 때문에 심사 숙고하여 결정해야 하며, 구현이나 통합테스트 1차 종료 시점 최종 오픈여부를 결정하는 조건을 내세우는 것도 필요하다.

고객사와 협의할 때는 검토방법과 절차를 설명하고, 가능한 경우라도, 존재하는 리스크와 해결방안, 오픈을 위한 전제조건 등을 설명하고,

불가능한 경우에는 해결방안이 있는 리스크와 해결방안이 없는 리스크를 구분해서 전달한다.

 

 

만약, 조기 오픈이 불가능한데 고객사에서 수용하지 않는 경우도 발생 할 수 있다.

최악의 시나리오지만,  PM은 당황하지 말고 프로젝트를 계획에 따라  진행하고,

사업부 부서장에게 보고하고, 이슈처리 절차에 따라 처리한다.

 

 

이슈란 갑자기 발생하는 것이 아니기 때문에 PM은 이슈화되기 전에  사전보고를 해야 한다.

이유는 이슈 발생 시 대응이 늦어지지 않도록 하기 때문이다.

PM_다잇소5

아기가 몸을 뒤집고, 기어 다니고, 일어서고, 걷기까지 걸리는데 필요한 시간이 있듯이, 시스템 구축에 필요한 절대적인 시간이 필요하다.

 

 

프로젝트 계획 수립은 투입 후 2주 이내 완료하고, 승인은 요구사항 정의단계 이전까지 완료 목표로 하는 것이 현실적이다. (요구사항정의 단계를 4주 이내로 가정 시)

이유는 개발산출물 테일러링을 고객사 담당자와 하는 경우 긴 시간이 소요될 수 있으며, 품질관리, 형상관리 방법 등 관련 팀들과 협의 및 승인에 시간이 많이 걸릴수 있고, 또한 프로젝트계획 승인을 받는 절차상의 문제와  프로젝트와 관련된 이해관계자가 많은 경우도 시간이 많이 걸릴수 있기 때문이다.

프로젝트계획수립과 요구사항정의를 병렬로 진행하기 때문에  계획수립을  빨리 진행하여, 요구사항을 정의를 하는데 문제가 없도록 해야 한다.

 

 

프로젝트계획을 수립했으면, 정리해서 착수보고를 해야 한다.

 

 

PM은 이슈 해결을 위한 노력보다 

이슈 예측을 위한 노력을 더 많이 하라.

 

 

다음회에는 “#4 프로젝트착수-착수보고회”가  계속됩니다.

Tip_img 프로젝트 정보 파악

계획수립을 하기 전에 프로젝트 정보를 파악하는 목적은 프로젝트의 범위, 자원도입, 일정을 다시 한번 확인하여 프로젝트 계획 초안 작업을 하기 위함이다.

1.자원(H/W, S/W)의 수량, 사양, 버전등을 확인하고, 프로젝트내 설치담당자를 확인하고, 주로 TA, AA등기 담당하지만, 작은 규모의 프로젝트의 경우에는 없을 수 도 있느니, 반드시 담당자를 직정하여 관련업체 담당자 및 고객사 담당자를 확인하도록 해야 한다

2.개발범위는 제안요청서와 계약서상의 구축업무와 맵핑하여 정리하고, 제안서와도 맵핑하여 추적 관리가 가능하도록 하고, 각 업무PL이 명확하게 이해하고 진행하도록 가이드가 필요

3.개발일정은 우선 제안요청서에 단계별 일정과 투입인력을 확인

4.프로젝트의 성공에 영향을 주는 중요업무와 핵심 과제가 무엇인지 파악하고, 내/외부 인터페이스를 파악

Tip_imgWBS (Work Breakdown Structure)

1. 정의 :  WBS는 프로젝트 전체 작업의 범위관리하기 위해 수행할 업무내역을 관리 가능한 단위로 세분하여 작업(TASK) 중심으로 구조화 한 것이다.

 

2.WBS의 중요성

– 프로젝트내 의사소통의 수단 (고객, 팀원간)

– 프로젝트의 업무내역을 가시화하여 관리가능하도록 정의

– 프로젝트 팀윈의 책임과 역할을 표시

 

3. WBS작성 원칙

-진척관리를 할 수 있는 수준으로 분해하여 일정계획을 수립한다.

(최하위 Activity에 대한 시작과 종료일은  1주일 이내로 정의한다.)

 

4. WBS작성 방법

– 고객과 합의된 마일스톤 (단계별 일정)을 기준으로 각 부문 (프로젝트관리, 개발, 인프라, 데이터이행 등)별로 특성을 반영하여 작성한다

-작성방법은 점진적으로 다음단계 Task를 상세화 시키는 방법과 가까운일정은 Bottom-Up방식을 사용하여 자세히하고, 먼 일정은 Top-Down형식을 작성하는 방법이 있다.

-장기프로젝트의 경우는 점진적으로 Top-Down방식의 일정수립을 하며, Task와 Activity가 누락하지 않도록 작성한다.

 

 

이전글 바로가기 ▶ 나의 PM 이야기를 시작하며….

                               ▶ #1 프로젝트 착수 -인력투입

                               ▶ #2 프로젝트 착수 -프로젝트준비

 
유경근의 프로필 사진
| 경영진
관심분야

카테고리 레이어 닫기