프로젝트 매니저를 위한 방법론 FAQ 18선

IT 업계에서 프로젝트 매니저(PM)가 되는 것은 순식간이다. 어느날 당신의 상관이 프로젝트 하나를 던져 주며 관리하라고 명령하면 그 순간부터 PM이 되는 것이다. 실제 PM 업무에 직면하면 당신이 궁금해 하는 사안에 대해 가능한 한 빨리 해답을 찾는 것이 중요하다. 경험 많은 PM들도 일부 문제에서는 혼란을 느낀다. 여기 정리한 자주 묻는 질문, 답변 목록을 통해 도움을 얻길 바란다.

1. ROI 란?

ROI란 투자대비 수익률을 뜻한다. 기업의 경영자들은 투자한 프로젝트의 결과물(수익)을 수치로 표현하길 원한다. IT의 가치는 금전적일 수도 비금전적일 수도 있다. 어떤 경우는 두가지 모두이다. ROI 분석을 하는 이유는 일반적으로 세가지다. 현재 프로젝트의 정당화, 과거 투자에 대한 정당화 그리고 특정 조치를 취하도록 설득하기 위해서다.

2. 프로젝트의 ROI 계산법

다음은 금전적 ROI를 계산하는데 필요한 정보 목록이다.

프로젝트 비용 : 관리 및 운영비(분석기간에 포함된 연간비용)
금전적 이득 (만약 있다면. 분석기간에 포함된 연간이득)
연간 현금 흐름 (연간 금전이득에서 연간비용을 뺀다)
비금전적 계산에 필요한 숫자는 측정방법에 따라 다르다. 일반적으로는 기간에 대한 비용과 비금전적 사업의 개선에 관련된 비율이나 양(시의성, 품질, 물량)이 포함된다.
대부분의 경우는 금전적 ROI 숫자를 계산하게 될 것이다. 상용 ROI 계산 프로그램을 사용하거나 자체개발한 비슷한 도구를 사용하면 쉽고 간단하게 해결할 수 있다.

3. 비용-편익 분석이란 무엇인가?

모든 사업적 IT 결정에는 선택이 동반된다. PM은 ‘A’나 ‘B’를 선택하거나 혹은 아무 조치도 취하지 않기로 결정할 수 있다. 그러나 분명한 것은 이러한 세가지 선택중 하나만이 ‘최선’이라는 사실이다. ‘비용-편익 분석(cost-benefit analysis)’이란 바로 이 선택의 과정에 사용되는 것으로, 기술이나 프로젝트와 같은 다양한 가능성을 비교 검토한 뒤 최선의 선택이 무엇인지를 보여준다. 잘 수행된 CBA은 현재 진행중인 프로젝트의 효과를 산출하는데 큰 도움이 된다.

CBA은 비용 대비 최대의 효과를 보여주는 두개 이상의 대안 솔루션과 그 비용, 혜택에 대한 체계적인 평가를 의미하기도 한다. 동시에 CBA는 특정 프로젝트에 대한 금전적 기대치를 계산하는데 사용되기도 한다. 여기에는 내부 직원들의 평균 인건비, 시스템의 기대 수명, 자본 비용, 계약직 인건비 등이 포함된다. 여기(영문, 회원가입 필요)를 클릭하면 CBA의 샘플을 받을 수 있다.

4. CBA는 사례연구와 동일한 것인가?

유사하지만 동일하지는 않다. 사례연구(business case)와 CBA는 의사 결정권자들이 보다 많은 정보를 갖고 선택할 수 있도록 하는 기법이라는 점에서는 동일하다. 그러나 사례연구는 관심있는 사람들이 특정 조취를 취하도록 설득하기 위해 만들어진 홍보 문서 같은 것으로, CBA보다 더 이해하기 더 쉬운 문서다.

예를 들어 사례연구는 전략적 제휴를 포함하는 경우가 많지만 CBA는 그렇지 않다. CBA는 몇가지 실용적인 대안에 대한 ‘중립적’ 평가로, 비용, 이익, 투자위험, 다른 대안의 효과 등 중요한 사실들을 도출해 낸다. 또한 어떤 선택이 더 유리한지 확인하기 위해 대안들을 검토한다. 일반적으로 사례연구는 CBA의 결과를 포함한다.

5. 프로젝트 계획이란?

PM은 프로젝트를 시작하기 전에 ‘프로젝트 계획’을 수립한다. 이는 전체 프로젝트에 필요한 리소스와 기간을 산정하는데 도움을 주며, PM들이 수개월 동안의 상세계획을 짜는 방식인 동시에, 모든 구성원들의 역할이 제대로 할당됐는지 확인하는 방법이기도 하다.

프로젝트 관리에 흔히 사용되는 공인 관리 절차가 있다면 큰 도움이 된다. 여기에는 업무범위 관리, 위험, 통신, 인력확충 등이 포함돼야 한다. 중요한 것은 프로젝트에 대한 기대를 잘 관리하기 위해 이런 요소들을 가장 먼저 규정하는 것이다. 예를 들어 목표 변경에 대한 승인 절차를 정의하고 합의하면, 프로젝트가 시작된 후에도 이런 변경사항을 관리하기가 훨씬 수월해진다.

6. 프로젝트 산출물은 얼마나 중요한가?

매우 중요하다. 산출물(Deliverable)은 주주와 스폰서들의 지지를 이끌어 내며, 이들에게 프로젝트의 성과를 가시적으로 보여주는 역할을 한다. 산출물은 당신이 프로젝트에서 어떤 역할을 했는지에 대한 결과물로, 프로젝트 계획 전체 혹은 상황보고서 와 같은 프로젝트 계획의 일부 등을 실제 결과로 제공하는 것이다.

7. 효과분석왜 하는가?

당신의 프로젝트는 업무 절차에 변화를 가져올 것이며, 여기에는 비용이 수반된다. 효과분석이란 바로 이 차이를 해결하기 위한 것이다. 효과분석은 프로젝트의 진행여부를 결정하는 가장 중요한 잣대 가운데 하나다.

8. 위험관리란 정확히 무엇인가?

위험관리란 프로젝트의 어떤 부분에서 문제가 발생할 수 있는지 시스템을 실제 가동했을 때 어디서 잘못될 수 있는지를 조사하는 것이다. 오류가 있을 수 있는 각각의 요소에 대해 그 영향에 대해 예상하고, 각 요소가 잘못될 확률이 얼마인지를 평가한다. 이런 사안들을 종합하면 위험 목록이 만들어진다. 확률이 크거나 부정적 효과가 큰 위험 목록은 프로젝트 계획에서 포함시키고 발생할 확률이 중간 수준인 사항도 함께 기재한다. 그리고 목록의 각 위험에 대해 이를 제거하거나 감소시킬 수 있는 방안을 찾아낸다.

9. 업무범위 관리란 무엇인가?

업무범위를 정의하는 것은 프로젝트의 논리적 경계를 분명히 하고 합의를 이끌어내기 위해서다. 업무범위 관리란 프로젝트의 안에 속하는 업무와 그렇지 않은 것을 결정하는 것이다. 범위에 대해 더 많은 측면을 검토할 수록 프로젝트를 수행하기 수월해 진다. 이와 관련해 다음의 정보를 참고하라.

범위의 안에 있는 산출물의 유형과 그렇지 않은 것 (사업 요구사항, 현황평가)
범위의 안에 있는 주요 생명주기 절차와 그렇지 않은 것 (분석, 설계, 시험)
범위의 안에 있는 데이타 유형과 그렇지 않은 것 (금융, 영업, 직원)
범위의 안에 있는 데이타 소스/데이터베이스와 그렇지 않은 것 (비용 청구서, 일반대장, 급여)
범위의 안에 있는 조직과 그렇지 않은 것 (인사, 제조, 공급업체)
범위의 안에 있는 주요 기능과 그렇지 않은 것 (결정지원, 데이타입력, 관리보고)

10. 업무가 슬금슬금 늘어난다?

많은 PM들이 큰 업무범위의 변화에 대해서는 잘 아는 반면, 작은 변화에는 민감하지 않다. 그저 일을 진행하며 추가 업무를 생각없이 더하는 경향이 있다. ‘은밀한 범위 확장(Scope creep)’이란 이처럼 수많은 소소한 변화들이 프로젝트에 반영될 때 나타나는 현상을 일컫는다. 이 작은 변화들이 합쳐지면 해당 팀은 너무나 많은 일을 떠맡았음을 깨닫게 되고, 예산이나 기한을 맞출 수 없는 상황에 놓이게 된다.

11. 완전성과 정확성의 기준은?

품질 수준을 결정하는 것은 PM이 아니라 고객이다. PM이 어려운 처지에 놓이는 것은 품질 수준을 판단하는 고객의 기대치를 확실히 모르기 때문이다. 바로 이 점 때문에 완전성과 정확성 기준이 필요하다. 이 기준에 따라 프로젝트 팀과 고객은 산출물에 만족할 수 있는 공통적인 기대치를 갖게 된다. 따라서 완전성과 정확성 기준은 프로젝트 계획에 반드시 포함돼야 한다.

12. SLA의 역할은?

SLA(service level agreement)는 서비스 공급자가 고객의 특별한 IT 요구사항을 계약서에 서술하는 것을 말한다. SLA는 지난 몇년간 다른 IT 기능을 포함하도록 발전해 왔으나 그 기본은 네트워크 서비스를 위한 회선과 연결성을 지원하는 것에서 시작된다.

13. 스폰서와 이해당사자의 차이점은?

스폰서는 프로젝트에 돈을 대는 개인이나 조직의 대표를 의미하며, 이해당사자(stakeholder)는 당신의 프로젝트에 관심이 있는 모든 사람을 일컫는다. 당신의 프로젝트가 다른 사람의 업무에 영향을 준다면 그 사람은 이해당사자가 된다. 일부 이해당사자는 프로젝트에 직접적으로 참여하거나 손을 뗄 수도 있고 다른 이들은 그들의 이해를 대변할 사람들을 지정할 것이다.

14. 프로젝트 수준 감사란?

프로젝트 수준 감사(project-level audit)에서 PM은 적절한 방법과 절차에 부합되는지를 확인하기 위해 일련의 질문을 던진다. 예를 들면 다음과 같은 유형의 질문들이다.

주요 이해당사자가 프로젝트 계획에 참여했는가?
스폰서와 주요 이해당사자가 정식으로 프로젝트를 승인했는가?
작업계획은 팀이 수행한 작업을 관리하기 위해 사용되고 있는가?
작업계획이 남은 업무를 정확히 반영하는가?
PM은 프로젝트의 현재 상태와 이상적인 상태를 명확히 설명할 수 있는가?
프로젝트 정의에 명시된 모든 산출물이 완성됐는가?
프로젝트는 비용, 일정, 품질면에서 제대로 진행되고 있는가?
오래된 위험이 관리되고 있으며 새로운 위험은 식별되고 있는가?
문제점들이 시의 적절하게 다뤄지고 해결되고 있는가?

대부분의 기업들이 내부 PMO를 통해 이러한 서비스를 실시하지만 프로젝트 감사는 서비스 제공자도 수행할 수 있는 독립적인 서비스이다. 감사를 전문으로 하는 컨설팅 업체들도 있다. 일부의 경우 외부업체가 감사를 수행하면 고위 경영진이 더 주목할 수 있는 추가 정당성을 부여하게 된다.

15. 프로젝트의 ‘의존성’을 조사해야 한다. 어디서 시작해야 할까?

의존성(Dependency)은 완성을 위해 서로 의존하고 있는 직무들을 일컫는다. 예를 들어 인트라넷의 시각적 설계 작업이라면, 시작 전에 사업요구사항을 알아야 하는 것이다. 의존성은 주로 다음 두가지 형태로 나타난다.

엔드투스타트(end to start) 타인이 특정 업무를 끝내기 전에 당신 일을 시작할 수 없는 경우
엔드투엔드/스타트투스타트(end to end/start to start) 당신의 일을 끝내고 다른 사람에게 넘겨 일을 시작하게 하는 경우. 시각적 설계를 마친 후에야 HTML 템플릿을 생성할 수 있는 경우가 대표적이다.

16. 프로젝트 이정표는?

이정표는 의존성에만 기반하며 계획의 ‘뼈대’를 잡도록 해준다. 이정표는 프로젝트 계획에 표시돼 이해당사자들이 언제 프로젝트의 주요직무가 끝나는지를 알수 있게 한다.

17. 프로젝트와 관련된 단계들은?

다음과 같은 단계들이 있다.

발견 단계 조직 차원에서 프로젝트 자체가 필요한지를 판단하는 단계이다. 현재 상황에 대한 필요성을 분석하고 필요한 자원이 있는지를 검토한다.
시작 단계 최초 계획을 잡고 이해당사자들에게서 동의를 받고, 남은 프로젝트를 수행할 예산을 확보하는 단계다.
설계 단계 현황을 분석하고 원하는 것을 정의하며 이를 위해 어떤 일을 해야하는지 정의하는 단계다.

대부분의 프로젝트에서 이해당사자는 요구사항을 정의하고 필요한 것을 확실히 명시하고, 그 이후 기술팀이 이를 어떻게 개발할지 정의한다. 이러한 절차는 프로젝트가 사업상 필요에 따라 진행될 수 있도록 보장하는데 필수적이다.

구축 단계 어떻게 개발할지 명시하는 단계다.
시험 단계 제품 출시전에 실제로 잘 동작하는지 테스트 하는 단계다.
출시 단계 새로운 시스템에 대해 기업 사용자들을 교육하고 다른 이해당사자들과 의사소통을 하며 제품을 생산단계로 이전시키는 단계이다.
평가 단계 평가전에는 이 새로운 시스템이 기업의 요구를 충족하는지 알 수 없다. 따라서 바로 이 단계에서 시스템을 수정할지, 유지할지, 확장할지 그것도 아니면 폐기할 것인지를 결정한다.

18. 품질제어는 무엇이며 품질보증과 어떻게 다른가?

품질제어절차(quality control process)와 품질보증절차(quality assurance process)는 결과물 점검, 부구성요소 시험, 완성도 점검목록 등 모두 결과물의 품질이 좋은지 확인하는 프로젝트 팀의 지속적 활동을 의미한다는 점에서는 동일하다.

그러나 자주 간과되는 사실은 품질보증 없는 품질제어는 오류를 사전에 막지 못하고 사후에야 발견할 수 있다는 사실이다. 프로젝트 팀구성원 모두는 처음부터 최소의 실수로 일을 완성해야 한다는 마음가짐을 가질 필요가 있다. PM와 팀은 품질관리의 제1의 목표가 오류없는 결과물은 만들어 내는 것이라는 점을 이해해야 한다. 제2의 목표는 가능한한 빨리 오류를 찾는 것이다. @

프로그래밍 갤러리

답글 남기기 응답 취소