IT 프로젝트 관리 이해 1

< 프로젝트관리 기본 개념 이해 >

ProjectManager: IT 프로젝트 진행 시 전체 프로젝트를 총괄하는 업무

PM의 역할

1.     제안/수주: IT 개발 사업을 수주하기 위한 업무 지원     # 회사입장에서 좋아하는 역할

A.     영업 지원: 영업 담당자의 영업 활동을 지원

B.     제안서 작성 지원: 영업과 사업관리 담당자들의 제안서 작성 지원

C.     제안서 발표

D.     수주

2.    프로젝트 준비: 사업 수주 후 프로젝트 진행을 위한 준비

A.     투입인력 계획: 수주 단계에서는 투입인력을 큰 틀만 계획하기 때문에 더 자세히 계획

B.     투입인력 소싱: 회사 인력보다 더 큰 인력이 필요한 프로젝트를 보통 수주하기 때문에 → 협력사, 프리랜서 등 소싱

C.     사업 수행계획: 공공 필수, 민간 생략 가능

D.     기타 준비: 프로젝트 진행을 위한 장소, 방법 등 다양한 협의

3.     프로젝트 진행 관리: 개발 프로젝트 전체 진행 관리            # PM의 제일 중요한 역할

A.     진행 일정 계획/관리: 전체 일정 계획(WBS)

B.     주요 보고 진행: 주간, 월간 착수, 중간, 종료 보고

C.     개발 진행관리: 기획, 디자인, 개발, 테스트 등

D.     이슈 관리: 다양한 이슈 및 인력 관리

4.    이후 관리: 프로젝트 종료 과정부터 그 이후 관리    # 영업팀, 사업 관리 팀이 지원해줌

A.     검수: 프로젝트 완료 이후, 검사 후 인수인계

B.     안정화 지원: 개발된 IT 시스템 오픈부터 안정화 지원

C.     유지보수 지원: 여기부턴 프로젝트 종료 단계

D.     신규사업 발굴: 고객의 새로운 문제점 해결방안 제안

 

PM 구분 (PM되는 과정)

-      전문 PM            # 10~15% 정도?

n  회사의 규모가 큰 경우 전문 PM육성을 위해 PM그룹을 따로 두는 경우가 있음

n  단, 신입 주니어가 바로 PM을 할 순 없음. PM보조 역할을 하면서 성장

-      기획자 PM         # 기획자 개발자 합쳐서 80%

n  기획자가 PM업무를 같이 진행 (웹 에이전시 업체에서 이런 경우 많음)

-      개발자 PM

n  개발자가 PM업무를 같이 진행 (기술 중심의 프로젝트 경우)

-      기타                  # 5% ?

n  프로젝트가 적은 경우 사업관리, 영업, 디자이너 등이 PM업무를 병행하기도 함

 

IT 프로젝트 프로세스

크게 2개의 관점에서 이해해야 함 (개발 진행 관리 / 사업 관리)

1.     기획/설계

2.     디자인/퍼블리싱

3.     개발

4.     테스트

5.     검수

6.     오픈 및 운영 관리 단계

 

IT 프로젝트 주요 관계자

→ PM은 프로젝트 관리를 하면서 다양한 업무 담당자들과 만나 커뮤니케이션을 하는 것이 가장 큰 업무. 즉, 관련 주요 관계자에 대한 이해가 정말 중요하다.

-      고객사측 주요 업무 관계자

1.     TFT멤버: 프로젝트 수행을 위해 고객사에서 특별히 모은 지원팀

A.     역할: 프로젝트 진행중 PM에게 가장 중요한 멤버

B.     구성

                              i.        고객사 IT 사업팀 (관리자 및 지원담당)

                             ii.        현업 담당자 (분석/설계 지원)

                            iii.        IT 인프라 (시스템 관련 협의 담당, 없을 수도 있음)

C.     소통 내용

                              i.        프로젝트 진행 관련 전반의 협의

                             ii.        주간보고 참석

                            iii.        요구사항에 대한 체계적인 확인

                            iv.        TFT멤버 외의 고객사 현업 미팅 연결 등 지원         # 현업 담당자

D.     소통 방법

                              i.        기본 소통은 주간 보고를 통해서 진행. 원활한 소통 중요

2.     현업 담당자: 개발된 시스템을 직접 사용할 현장에서 실무 업무 담당자

A.     역할

                              i.        구축될 시스템의 주요 요구사항 제공자

B.     구성

                              i.        현업 담당자들 중에서 적극적이고 스마트한 담당자들을 뽑아서 구성

C.     소통 내용

                              i.        구축될 시스템의 기능 및 프로세스 분석

                             ii.        기존의 불편사항 및 개선 방향 확인

                            iii.        시스템을 이용하는 현장의 다양한 사례 정보

D.     소통 방법

                              i.        TFT멤버들을 통해서 최초 소개 및 연결

                             ii.        기본적인 업무 일정은 TFT 멤버를 통해서 확정

                            iii.        소통 결과는 가능한 회의록 작성 후 e-mail 공유, 경청의 자세 필요

3.     IT 인프라 관리: 고객사의 IT인프라(H/W, 네트워크)를 관리하는 담당자

A.     역할

                              i.        인프라 관련 요청을 들어줌. PM이 부탁하는 경우가 대부분

B.     구성

                              i.        보통은 TFT 멤버로 들어오지 않으나, 프로젝트 규모가 큰 경우 포함

C.     소통 내용

                              i.        사업 초기, H/W 및 네트워크 구성 협의

                             ii.        H/W: 장비 계획, 선정, 구매, 설치까지 협의

                            iii.        네트워크: 사용성과 보안을 고려한 구성 협의

D.     소통 방법

                              i.        현업 담당자와 동일

                             ii.        반드시 먼저 메일로 요구사항 정리해서 보내고 소통

-      감리: 수행사가 고객사의 요구사항을 잘 지켜서 사업을 수행하는지 검사해주는 조직

A.     구성

                              i.        통상은 고객사가 프로젝트 입찰을 할 때 감리 입찰을 함께 진행하여 외부 전문 업체를 선정

B.     소통 내용

                              i.        프로젝트 구축 주요 단계가 끝나는 시점에 감리 인원들이 1주일 정도 방문하여 업무 진행

                             ii.        프로젝트 산출물, 사업관리 상태, 프로그램 설계, DB설계, 개발 상태 등 점검

C.     소통 방법

                              i.        보통 설계, 개발이 끝나는 시점에 설계감리와 종료 감리 형태로 방문

                             ii.        그들이 요청하는 자료 제공 및 의견 수렴

                            iii.        관계가 좋고 나쁘다의 개념이 필요 없음

-      PMO: Project Management Office

A.     역할

                              i.        프로젝트를 진행하는 팀의 업무 지원

                             ii.        프로젝트 관리 지원, 산출물 관리 지원, 품질 관리

B.     구성

                              i.        수행사(자사) PMO: 품질 관리 업무 지원, 든든한 사업의 조력자

                             ii.        고객사 PMO: 고객 업무 지원 및 수행사 관리, 감리의 역할을 할 때도 있음

C.     소통 내용

                              i.        자사 PMO: 사업관리 및 품질 관리를 위한 산출물 작성, 관리 업무 지원

                             ii.        고객사 PMO: 사업관리 및 품질 관리를 하라고 가이드를 주는 것이 보통

D.     소통 방법

                              i.        자사 PMO: 서로 협력 관계. 상호간 업무 요청 시 명확한 가이드와 정보 전달

                             ii.        고객사 PMO: 요청사항에 대한 대응 중심, 적당한 거리를 두고 협력관계 유지

-      IT 컨설턴트: IT 시스템 구축을 위한 전략 및 방법을 가이드

A.     역할

                              i.        고객사에 IT 시스템 도입 전략 계획 수립 (ISP)

                             ii.        고객사가 구축할 특정 시스템의 구축 전략 및 주요 프로세스 설계 (PI, ISMP)

B.     구성

                              i.        전문 컨설팅 업체가 입찰 수주를 통해 확정

C.     소통 내용

                              i.        IT 시스템 구축에 대한 전략 및 프로세스 협의

D.     소통 방법

                              i.        같은 사업에 들어올 경우 상호 존중을 기본으로 필요한 정보들을 공유 및 논의

 

 

 

 

< IT 시장과 개발 방법론 이해 >

→ IT 시장에 따라 개발 방법론은 다양하게 존재.

1.    워터폴

A.     개념

                       i.        전통적 방법론. 폭포가 떨어지듯이 순차적으로 단방향으로 진행

B.     수행 방법

                       i.        프로젝트 기간 동안 개발 사이클을 크게 1번만 진행

                      ii.        분석/설계 → 디자인 → 개발 → 테스트 → 오픈/안정화

C.     장/단점

                       i.        장점: 안정적이고 관리가 용이함

                      ii.        단점: 변화에 대한 대응이 어려움. 고정적

D.     적용 분야

                       i.        프로젝트형 개발, SI성 개발, 외주 개발에 적합

                      ii.        안정적 운영을 필요로 하는 조직              # 중간에 담당 인원이 바껴도 안정적

2.    애자일(스크럼)

A.     개념

                       i.        정확히는 마인드셋 또는 철학을 의미 → 즉, 컨셉               # 방법론이 스크럼

                      ii.        구성원/고객과의 원활한 소통, 빠른 변화에 대응

B.     수행 방법

                       i.        스크럼(SCRUM)              # 백로그 관리가 제일 중요

                      ii.        백로그 → 스프린트 계획 회의(스프린트 백로그) → 스프린트 → 일일 스크럼 회의 → 스프린트 검토회의 → 스프린트 회고

# 백로그 = 우선순위가 있는 아이디어 통

# 스프린트 = 2~4주 동안 짧고 굵게 단기간 개발, 배포

C.     장/단점

                       i.        장점: 개발 효율이 최대화, 품질 안정, 변화 대응

                      ii.        단점: 각 구성원의 성숙도에 따른 리스크

D.     적용 분야

                       i.        프로덕트형 개발, 시스템 운영 개발, 내부 개발

                      ii.        구성원이 성숙도가 높고, 원팀의 개념으로 일 하는 곳

E.     요구사항 우선순위

→ 스크럼의 핵심은 스프린트 단위 개발 구조가 아니라 어떻게 서비스에 성과를 낼 수 있는 요구사항을 바람직한 타이밍에 스프린트로 진행할지 결정하는 것

                       i.        MOSCOW

▪ 가장 단순한 방법론 중 하나로 아주 쉽게 사용 가능

▪ 우선 순위를 4개의 기준으로 나누어 담아서 관리

(MUST HAVE, SHOULD HAVE, NICE TO HAVE, WON'T HAVE)

                      ii.        Value vs. Complexity

▪ 노력대비 가치의 효율성 기준

▪ 고가치&저복잡성 / 고가치&고복잡성 / 저가치&저복잡성 / 저가치&고복잡성

                     iii.        Weighted Scoring

▪ 협의된 평가 기준을 놓고 백로그가 들어올 때마다 점수를 매겨 우선 순위 작성

▪ 합리적이고 이견이 적지만, 반대로 정량적 오류가능

                     iv.        Kano 모델

▪ 고객 가치 기준의 지표로 우선 순위

▪ 필수적인 기능(Basic), 흥미로운 기능(Excitement), 고성능 기능(Performance),

관심 없는 기능(Indifferent), 불만족스러운 기능(Dissatisfaction)

 

< WBS 작업 분해 및 일정 관리 이해 >

WBS 기본 개념

→ IT 프로젝트 관리에서 가장 중요한 문서가 WBS이다.

→ Work Breakdown Structure의 약어 = 작업 분류 체계

→ 프로젝트 진행중 해야 할 업무를 상세하게 분류하고 관리를 위해 구조화시킨 것

-      역할

1.     업무 식별: 관리할 업무를 식별하는 역할

2.     일정 계획: 식별된 업무별 작업 일정 계획

3.     업무 배분: 각 일정 별 업무 담당자와 산출물 등록 관리

4.     진척 관리: 작성된 일정에 따른 진행 경과 등록 및 관리

 

WBS 초안 작성 방법

진척확인 기준일 중요! → 보통 주간보고 날마다 갱신됨

WBS는 단순 보여주기 용도가 아님 (실제 작업 관리를 위한 용도, 시간을 들여 상세히)

사업이 시작된 후 분석 설계가 끝나면 반드시 ‘개발’의 일정을 상세하게 세분화 해야함.

 

개발의 상세 일정은 절대 PM이 자기 임의로 작성하면 안됨 (개발자들의 의견을 수렴)

1. 식별된 업무를 개발 리더와 검토

2. 개발 리더의 의견을 반영한 1차 배정 및 검토

3. 개발팀 전체 WBS 개발 일정 및 배분 검토

4. 검토 확인 후 확정

 

WBS 관리 방법

1.     사업 초기 작성 WBS는 고객에게 메일로 공유

2.     고객과 리뷰 회의를 통해 확정 1.0 버전

3.     기획(분석-설계) 단계까지 유지하며 진척 업데이트

4.     기획 단계 이후 WBS 상세화 후 고객에게 메일 공유

5.     고객과 리뷰 회의를 통해 상세화 확인 2.0 버전

6.     이후 일정에 따른 진척 사항 업데이트 관리

WBS는 고객과 협의 없이 임의 변경 불가

담당자의 말만 믿고 진척을 관리하면 안됨. 반드시 PM이 직접 혹은 간접적으로 진척을 점검

 

WBS 기반 개발 점검 방법

1.     WBS일정에 따라 직접 점검 필요

2.     기획 문서와 동일하게 개발이 잘 되었는지 확인

3.     가벼운 오류 사항은 PASS하고 별도의 테스트 기간에 수정

4.     핵심 기능 자체가 동작 안 할 때는 확인

 

WBS 기반 개발 지연 대응 방법

1.     1차적으로 개발PL등 개발 리더와 협의 대응

2.     개발 리더가 이슈에 대한 명확한 방안 및 합리적인 일정 기반의 계획안 가져올 경우

-      인정해주고 지속적인 모니터링 진행

3.     개발 리더 및 개발 팀의 이슈 대응이 부족할 경우

-      반복적인 이슈 대응 안 요청 및 점검

4.     개발 리더 및 팀의 대응 약속 미 이행 혹은 지속적 문제 시

-      사업 관리 담당자에게 이슈 알림 및 대응 방안 상의