프로젝트매니저, PM

프로젝트 매니저(Project manager)는 한시적인 일을 수행하는 데 있어서 관리 방법론(통합, 범위, 시간, 원가, 품질, 인력, 의사소통, 위험, 조달관리)에 따라 가장 효율적으로 추진하는 것으로 프로젝트의 계획과 실행에 있어서 종합적인 책임을 가진 직책 또는 직무이다. (위키피디아)

​

​

PM이라는 업무에 관심있는 사람이라면 PMP라는 자격에 대해서 들어본 것이 있을것이다. 아래는 PMP에 관한 내용이다.(마이크로소프트웨어. 프로젝트매니저로 가는 길)

​

PMP(Project Management Professional)

프로젝트 관리 지식(PMBOK)을 충분히 숙지하고 프로젝트 관리 업무를 전문적으로 수행할 수 있음을 PMI가 인증 한 공인 프로젝트 관리 전문가이다.

​

PMI(Project Management Institute)

프로젝트 관리 지식의 연구와 보급을 위해 1969년에 미국에서 창설된 세계적인 프로젝트 관리 전문 기관으로서, 현재 120 여 개국에서 5만여 명의 PMP가 활동 중이다(http://www.pmi.org 참고). 또한 국내에는 한국 프로젝트 관리 기술회(PROMAT)가 1991년 비영리 공익법인으로 설립되어 활동 중이다(http://www.promat.or.kr 참고).

​

PMBOK(Project Management Body Of Knowledge) Guide 2000 Edition

1987년 PMBOK 초판 이후 지속적으로 개정되어 출간된 프로젝트 관리 기본 서적의 최신판이다. 프로젝트 관리 업무 수행을 위해 필요한 지식을 프로젝트 관리 프레임워크와 9개의 지식 영역, 39개의 프로세스로 구분하고 있다. 또한 PMBOK 은 미국표준협회(ANSI)의 프로젝트 관리 표준으로 지정되어 있다.

​

PMP 응시를 위해서는 학사 학위를 가진 사람을 기준으로 할 때 신청일로부터 최 소 3년의 경력이 필요하며, 또한 6년이 경과하지 않은 기간 내 최소 4,500시간 (36개월) 이상의 프로젝트 관련 경력이 필요하다. 또한 35시간의 프로젝트 관리 교육을 필수적으로 이수하여야 한다. PMP 시험은 CBT로 응시하게 된다. 4시간 동안 사지선다형 200문제를 풀어야 하며, 137점을 획득하면 합격하게 된다 (http://www.pmi.org 참고).

PMP는 1984년에 개발되었으나 처음 시작 6년 동안에는 단지 350명만이 인증을 받았다. 그러나 AT&T가 프로젝트 교과 과정을 만들어 수천 명의 종업원을 훈련시키고 PMP를 지원하면서 대중적 관심이 높아졌다. 현재는 AT&T 뿐만 아니라 IBM, EDS, 시티뱅크, 미국 에너지성, 캐나다 국방부, 마이크로소프트 등의 여러 기업에서 PMP을 지원하고 있다.

국내에서는 1990년대 초에 한국전력을 중심으로 PMP 취득자가 양산되기 시작하였으며, 몇 년 전부터 PMP를 기술사와 동등 대우하는 대기업들이 늘어나면서 PMP에 대한 관심이 고조되었다. 현재는 IT, 건설, 방위산업, 금융 등의 다양한 업종에서 1천여 명 이상의 PMP가 활동 중이며, IT 업종에서는 1990년대 말부터 PMP에 대한 관심이 증대되었다. 특히 최근에는 외국기업/대기업 SI 업체를 중심으로 프로젝트 매니저의 필수 조건으로 PMP를 요구하는 경우가 늘고 있다.

​

프로젝트 매니저는 목적지향성 및 한시성, 독특성을 가진 업무이며, 그 특성을 아래와 같이 정리할 수 있다.

1)목적지향성 : 프로젝트는 특정 결과를 성취하기 위해 수행하는 것이다. 프로젝트 는 처음부터 끝까지 목표들로 이루어져 있다

2)한시성 : 유한성이라고도 한다. 모든 프로젝트는 반드시 시작과 끝을 가져야 한 다. 끝이 없는 업무는 프로젝트가 아니다.

3)독특성 : 프로젝트는 반복성이 없고 단일한 종류의 과업이다. 독특성이 높을수록 위험과 불확실성이 상승한다.

4)관련 활동의 조정 : 프로젝트는 상호 관련이 있는 여러 활동들을 수행하는 것이 다. 이 특성은 프로젝트의 세 가지 특성 - 목적 지향성, 한시성, 독특성 - 을 결합 하는 것이다. 프로젝트는 곧 시스템 자체이다(이 말은 아주 중요하다!).

​

사실 프로젝트 관리 분야는 미국과 같은 선진국에서조차 1980년대 말까지만 해도 지식의 사각지대에 있었다. 상식적으로 생각해봐도 이 러한 지식은 경영학이나 컴퓨터공학 등의 엔지니어링 학문에서도 다 루기 힘든 지식이라고 할 수 있다. 왜냐하면 해당 학문의 본질과는 분 명한 차이가 있으면서도 사실 실무에서는 꼭 필요한 지식이었기 때문 이다. 그래서 지금까지 프로젝트 관리는 단편적 지식 및 실무 경험의 축적에 의해 직관적으로 행해지는 경우가 많았다. 서구에서조차 프로 젝트 관리는 아직까지도 새로운 지식 분야로 분류된다. 그리고 프로젝트 관리는 IT 업종에만 필요한 것이 아니며, 전통적 인 프로젝트 지향 업종인 건설, 방위산업뿐만 아니라 금융, 보험, 제 약 등의 업종에서도 관심을 갖고 있는 지식이다. 근래에 들어 IT 업 종에서는 프로젝트의 규모가 커지고 방대해지면서 체계적인 프로젝 트 관리에 대한 관심이 증대되고 있는 상황이다. 이러한 프로젝트 관 리 지식의 보급에는 PMI(Project Management Institute)가 개발 한 PMP(Project Management Professional) 공인 자격증 프로그램이 커다란 역할을 하였다.

​

그럼, 이제 첫 번째 질문에 대한 답을 살펴보자. 프로젝트 매니저란 무엇일까? 프로젝트 매니저란 프로젝트 관리 업무를 수행하는 사람 이다. 프로젝트 관리란 한 마디로 ‘시간에 맞추어, 예산 범위 내에, 명세에 따라, 업무가 진행되게 하는 것’이다. 또한 PMBOK에 따르면, 프로젝트 관리란 프로젝트의 목적을 달성하기 위하여 관련 지식, 기술, 도구, 테크닉을 적용하는 것이다.

프로젝트 관리는 다음의 다섯 가지 프로세스 그룹을 통하여 성취된다.

1)시작(initiating) : 프로젝트의 정당성을 획득한다.

2)기획(planning) : 목적을 정의하고, 목적을 달성하기 위한 최선의 행동들을 정의 한다.

3)실행(executing) : 계획을 실행하기 위해 사람 및 다른 자원을 조정한다.

4)통제(controlling) : 진행 과정을 측정하여 계획과의 차이점을 식별하고 필요한 교정을 행한다.

5)종료(closing) : 프로젝트가 끝났다는 것을 정식으로 승인한다.

​

프로젝트 매니저는 프로젝트의 업무를 관리하는데, 업무에는 다음 과 같은 것들이 포함된다.

1)범위(scope), 시간(time), 비용(cost), 위험(risk), 품질(quality)에 대한 요구

2)다양한 요구와 기대를 가진 여러 이해관계자들(stakeholders)

3)식별가능한 요구사항들

​

프로젝트를 진행하는 데에 있어 복잡성과 불확실성이 있어 문제없이 잘 관리한다는 것은 상당히 어려운 일이다.

그리하여 프로젝트는 항상 위험관리를 하며 위험성을 줄이려고 하지만 아래의 같은 상황은 늘 도사리고 있다.

​

1)요구사항 변경 : 프로그래머의 입장에서 이미 만들어 놓은 것을 수정하거나 심지 어는 완전히 무시하고 다시 작성하는 것만큼 큰 고통은 없다. 요구사항은 아주 불가피한 경우에만 수정, 추가되어야 하며 요구사항을 관리하는 것이야말로 프로젝트 매니저가 가장 우선 순위를 두어야할 업무 중 하나라고 할 수 있다. 요구사항 변경은 일정 지연, 비용 증가, 품질 문제 등 여러 가지 부작용을 발생시키는 가장 큰 원인 중 하나이며, 다른 산업의 프로젝트에 비해 IT 프로젝트에서 특히 빈번하 게 또한 광범위하게 발생하는 경향이 있다.

​

2)일정 지연 : 일정 지연의 가장 큰 요인 중 하나가 요구사항 변경이기는 하지만 요구사항의 변경이 있지 않은 경우에도 일정이 지연되는 경우는 많이 생긴다. 그 이유는 목적 달성을 위하여 필요한 작업 파악이 제대로 안되었거나 시간 예측의 잘못, 부적절한 자원 관리 등이 원인이 된다.

​

3)비용 증가 : 프로젝트 완료 전에 주어진 예산이 바닥나는 것만큼 곤란한 경우는 없다. 프로젝트시 지출할 비용 항목을 정확히 파악하고 산정하는 것과 그것을 적절하게 집행하는 것 또한 프로젝트 매니저의 중요한 책임이다.

​

4)기술적 난관 봉착 : 다른 산업의 프로젝트에 비하여 특히 IT 프로젝트에 많이 발생 하는 문제점이다. IT 프로젝트는 대개 비교적 짧은 개발 기간, 신기술 또는 베타버전의 사용, 산업 표준 또는 가이드라인의 부재로 인하여 상당한 기술적 위험이 내재되어 있다. 이러한 문제점에 대비하여 프로젝트 매니저는 프로젝트 팀에 관련 전문가를 배치하거나, 관련 업체의 기술 지원, 외부 컨설턴트 확보 등 여러 가지 해결 방안을 마련해야 한다. 실제 IT 프로젝트가 지연되는 경우를 분석해보면 일반적 업무가 지연되는 경우보다는 기술적 문제에 봉착한 특정 업무가 전체 지연의 80% 이상을 차지함을 알 수 있다.

​

5)품질 문제 : 소프트웨어 제작을 마무리하고 프로젝트 종료 단계에 들어선 다음에야 소프트웨어 품질 문제를 발견하는 것만큼 난감한 일은 없다. 이러한 문제는 프로젝트 과정에서 클라이언트의 승인이 제대로 이루어지지 않았거나 QA 정책의 미비 또는 테스트의 불충분으로 인해 발생한다. 이것은 결국 일정 지연을 유발하거나 패널티를 물게 되는 원인이 된다.

​

클라이언트는 대개 “나는 내가 무엇을 원하는지 잘 모르지만, 그것 을 눈으로 보면 알 수 있다.”는 입장을 견지한다. 그리고 개발이 다 끝난 소프트웨어를 보고서는 그것이 자신이 원하는 것이 아니라고 얘기한다. 그렇기 때문에 프로젝트 매니저는 프로젝트 팀과 함께 프로 젝트의 범위를 더욱 정확하고 상세하게 디자인하고 그것을 체계적으 로 관리해야 하는 것이다. 그러한 소프트웨어 프로젝트의 구조적 한계와 더불어 클라이언트 (의뢰인), 사용자, 개발자가 서로 자신이 해당 프로젝트의 주인공이라는 생각을 갖고 있는 것 또한 프로젝트에 있어 갈등을 유발하는 요 인 중 하나이다. 그것은 빈번히 요구사항의 상충을 초래한다. 요구사 항 정의시 주의해야 할 함정은 다음과 같다.

1) 미묘한 욕구 또는 잘못 이해된 욕구 : 고객이 자신의 욕구를 구체적으로 알고 있지 못하고 막연하게 인식하고 있음으로 해서 생길 수 있는 문제점이다. 프로젝트 팀은 그러한 고객을 정확한 곳으로 인도해서 고객이 스스로 원하는 바를 정확하 게 판단할 수 있도록 도와줘야 한다.

2)동적 욕구 : 욕구는 본질적으로 변하는 특성을 갖고 있으며, 그것은 환경과 관련 되어 있다. 욕구가 변하게 되는 이유에는 여러 가지가 있다. IT 업종에서는 이직이 빈번하게 일어나고 있고, 관계자가 바뀌면 요구사항도 바뀐다. 또한 예산 때문에 특정 업무가 취소되는 일은 프로젝트에 있어 빈번하게 발생하는 문제이다. 신기술이 나타나면 사람들의 욕구도 변한다. 그외 기업의 내부/외부 환경의 여러 변화 들이 프로젝트의 요구사항에도 변화를 요구하는 경우가 많다.

​

​