[프로젝트 관리 실무] C1. 프로젝트 관리 이해

[David Jeong]

그림. 프로젝트 관리 프로세스와 외부 인터페이스

그림. 프로젝트 관리 프로세스

Part1. 프로젝트 관리 이해

1. 프로젝트 관리 이해

1.1 프로젝트 관리 이해

   ☞ Check Point

      - 프로젝트는 어떠한 특징을 갖고 있습니까?

      - 프로젝트, 프로그램, 포트폴리오는 무엇을 말하는 것입니까?

      - 프로젝트 관리는 어떠한 점에서 꼭 필요한 것일까요?

      - 프로젝트 라이프사이클 관리 프로세스는 무엇입니까?

1.1 프로젝트 관리 실무

   - 오늘날 많은 사람들이 조직에서, 또는 자신의 생활에서 프로젝트를 계획하고 실행하고 있다.

      • 일상적으로 하는 말 중에 하나가 된 프로젝트는 어떠한 단어와 조합 해도 잘 어울리는 말이 되었다.

        한번 인터넷에 들어가 ‘프로젝트’ 또는 'project' 라는 검색어로 검색을 해보자.

        ‘OO건축 프로젝트’ 에서 '살빼기 프로젝트'에까지 범주화되지 않고 정의하기 어려운 여러 결과가 나올 것이다.

        그만큼 프로젝트란 말은 일상화되었고, 또한 보편적인 용어가 되었다.
      • 업무에서 프로젝트란 용어는 더욱 많이 사용되고 있다.

        과거에는 건설이나 IT 같은 특정 업종에서 자주 사용되었지만, 이제는 거의 모든 업종에서 프로젝트란 용어가 사용되고,

        프로젝트 관리자(Project Manager)가 존재한다.
   - 프로젝트는 다른 여러 업무와 다르게 도전적이며, 진취적이고 무언가 새로운 것이란 느낌을 갖고 있다.

      • 추가 근무와 스트레스가 연상되기도 하지만, 이는 프로젝트가 지니는 본래 특성에서 기인하는 모습일 것

      • 프로젝트는 주어진 기간에 특정 목표를 달성하는 것으로 정의할 수 있다.

      • 목표와 시간은 서로 연합하여, 과정에서는 열정과 노력을, 결과에서는 성취와 보람을 가져다 준다.

        ‘프로젝트를 하는 사람'은 새로 프로젝트를 시작할 때 부담을 가지며, 프로젝트 중에는 스트레스에 시달리며, 프로젝트가

        끝났을 때 보람과 아쉬움을 느낄 것이다.

      • 이 모든 것은 프로젝트가 이 세상에서 단 하나뿐이라는 특징 때문이며, 모든 프로젝트와 관련된 현상은 바로 이 특징에

        서 비롯된다고 할 수 있다.

      • 유사한 프로젝트를 지속적으로 맡아 수행하며 전문 경력을 쌓아가는 것이 오늘날 프로젝트 실무자들의 모습
      • 모든 프로젝트는 다르기 때문에 아쉬움이 남으며, 이번에 실수했던 것을 다음에 하지 않기 위해, 지금 현재 최선의 선택

        을 하기 위해, 그리고 미래의 다른 프로젝트에서 더 잘하기 위해 개선점을 찾고 미리 대비하는 노력을 기울여야 하는 것

   - 프로젝트에서 가장 큰 책임과 더불어 주체가 되는 자를 우리는 프로젝트 관리자 또는 PM(Project Manager)

      • 프로젝트 관리자는 주업무가 프로젝트 관리이기 때문에 프로젝트 관리자가 하는 일을 프로젝트 관리 실무라 할 수 있겠

        다.

      • PMP자격증으로 널리 알려지게 된 Project Management Body of Knowledge 7th Edition(이하 PMBOK)에서는 프로젝트

        관리를 지식(Knowledge), 기술(Skills), 도구(Tools), 기법(Techniques)를 동원하여 고객의 요구를 충족시키는 방법이라고

        정의

      • 구체적으로 무엇을 관리하며, 어떻게 관리할 것이며, 누가 할 것인가 그리고 그에 필요한 가치는 무엇인가. 바로 이것이

        프로젝트 관리의 실무를 구성하고 있다.
   - "내용은 이해하고 바람직하다고 생각하지만 실제 업무에서는 적용하기에는 어려울 것 같다"는 푸념

      • 자신의 프로젝트는 특수하고 표준 방법론을 적용하기 어렵다고 말한다. 하지만 이것은 전혀 발전적이지 못한 지적              • 기초 지식이 필요 없는 것은 아니며, 응용의 기반이 되는 방법론이 없는 것이 아니란 점이 중요

      • 프로젝트 관리자들이 어려워 하는 것은 까다로운 고객의 요구사항일 것이며, 프로젝트 관리자들이 알고 싶은 것은 합

        리적이고 타당한 계획을 세워서 프로젝트를 성공적으로 수행하기 위한 방법론 일 것

      • 이에 대한 인식과 대응은 상당히 진전되어 미국에서는 PMI에서 PMBOK이라는 훌륭한 표준을 제시했으며, 우리나라

        에서도 많은 조직에서 PMO(Project Management Office)를 설립하고 프로젝트 관리 방법론을 제도화하고 있다.
      • 현실적으로 우리나라 프로젝트 관리자는 방법보다 먼저 경험을 쌓게 된다.

        즉, 체계적 지식 이전에 먼저 정리되지 않은 다양한 경험을 쌓는 것이다.

        프로젝트 실무 현장에서 현실과 부딪혀 가며 경험을 쌓고 그 경험에 의해 오늘도 프로젝트를 수행하고 있는 것이 대

        부분의 우리나라 프로젝트 실무자가 겪는 바다.

        한번이라도 내가 하는 이 방법이 올바른 것인가 생각해 본 적이 있는가? 생산성을 높일 수 있는 방법이 있지 않을까 고

        민해 보았는가? 내가 더 잘 관리해야 할 곳이 있다는 불안한 마음을 가져 보았는지 고민해 보았는가?
        우리가 쓰는 그 말이 제대로 쓰고 필드 경험에 의한 프로젝트 업무는 자칫 주먹구구라는 불명예를 안을 가능성이 높다.

        왜냐하면 체계적인 지식 없이 경험만 많다면, 원칙 없이 개개의 사건과 환경요소에만 집착하여 정형적이고 교조적으로

        프로젝트 수행하게 되기 때문이다.

        이는 처음 프로젝트를 맡았을 경우나 몇 십년이 지난 지금이나 프로젝트를 관리하는 면에서는 그다지 발전하지 않았다

        는 현직 실무자들의 많은 증언으로도 충분히 증명이 된다.

        보다 유연하고 창의적인 접근은, 같은 것이 하나도 없는 프로젝트라는 업무를 진행할 때 필수이며, 체계적으로 정리된

        지식이 원리로 작용할 때 가능하게 된다.

      • 프로젝트 관리의 기본 지식에서 경험은 이런 지식을 보강하고 구체화하여 실무에서 살아있는 지식으로 승격시키는 역할

        따라서 모든 프로젝트 실무자라면 배우고 익혀 자신만의 특수한 프로젝트관리 실무에서 적용하기 위해 노력해야 할 것

   - 프로젝트 하나가 조직의 성패와 방향을 좌우할 정도로 비중이 클 수 있다는 점을 감안하면 조직에서 프로젝트관리 실무

     를 담당하는 프로젝트 관리자는 자신의 역량의 개발에 결코 게으를 수 없다.

      • 프로젝트 관리자로써 역량 개발을 위한 포트폴리오 구성

      • 가장 중요하며 끊임없이 노력해야 하는 것은 기본 지식과 사례 (경험), 개념, 용어 등의 프로젝트 관리 실무 지식이며, 이

        를 중심으로 다양한 기법과 기술 그리고 도구를 개발하고 익히는 것

      • 고객의 요구를 충족시키기 위하여 사용한다면 프로젝트를 반드시 성공시키는 훌륭한 프로젝트 관리자가 될 수 있을 것

1.2 프로젝트의 이해

1.2.1 프로젝트 정의
   - ‘Project' 란 말의 어원은 ‘projicere'란 단어에서 유래한 라틴어'Projectum'

      • 이 단어를 분해하면 'pro' 는 앞으로 나아가는 것을 뜻하는 단어이며, '던지다' 란 뜻을 가진 'jacere' 가 나머지를 구성

      • 원래의 뜻은 이전의 성과로부터 나오는 무언가를 뜻하는 단어

      • 그것은 단지 계획을 말하는 것이었지 실제 실행은 아니었다고 한다. 'object' 가 바로 계획에 따른 결과를 뜻하는 단어
   - 프로젝트란 단어가 현대에 우리가 쓰는 의미로 전환된 것은 불과 반세기전이었다.

      • 1950년대에 Project Management' 가 나온 후부터 'project'와 ‘object' 의 의미가 바뀌어 'object' 를 위한 활동들이

        'project'가 되었다.

      • 단지 계획만을 뜻했던 의미에서 더 많은 역할을 하게 되었고, 이는 뒤에 나온 관리(management)란 단어에 힘입은 바가

        크다. 즉, 현재 우리가쓰는 프로젝트의 의미가 이처럼 관리라는 단어와 밀접한 관련이 있다는 것은 놀라운 일이 아닐 수

        없다.
      • 현대에 이르러 변화된 프로젝트에 대해 정확한 정의를 살펴보면 먼저「Welcome PM Glossary」에서는 “전체적인 목적을

        향한 일련의 활동들, 또는 그 목적의 달성과 관련한 정보의 수집 (A set of activities directedto an overall goal, Also, the

         collection of data relating to theachievement of that goal)" 이라고 했다.

         하지만 이것만으로는 불충분하다. 왜냐하면 모든 목적성을 가진 활동이 프로젝트라고 하기 어렵기 때문이다.

      • 「PMBOK」에서는 "유일한 제품, 용역, 또는 결과를 창출하기 위해 투입되는 일시적인 노력(A temporary endeavor

         undertaken to createa unique product, service, or result)"이라고 설명

         PMBOK의 정의는 현대에 사용되는 프로젝트의 정의를 좀 더 명확하게 보여주고 있다.

      • 두 정의에서 예전의 'project' 와 'object'가 포함되어 있음을 발견할 수 있으며, 더불어 시간과 대상이 좀 더 구체적으로

        정의가 되었음을 알 수 있다. 즉, 프로젝트는 목적을 향한 인간의 행위이며, 유한하며 더불어 정해진 목표가 있다는 것

         바로 이러한 의미에서 프로젝트는 반복되지 않으며, 일상적이지 않고, 관료적이지 않다. 다음의 프로젝트의 특징을 분해

         하여 살펴보면 프로젝트에 대해 더 잘 이해할 수 있다.

▣ PMBOK(A Guide to the Project Management Body of Knowledge)
PM(Prolect Management) 수행 기법의 전반적 내용이 수록되어 있는 대표적인 사업 관리 총괄 도서
프로젝트 관리에 대한 연구의 집대성으로 4년마다 연구내용이 추가되어 갱신

1.2.2 프로젝트의 특징
   □ 프로젝트의 정의를 통해 프로젝트가 가지는 특징

      - '명확한 목적과 목표를 가진다

         • 목표가 있다는 것은 프로젝트의 가장 큰 특징

         • '던지는 행위가 대상을 전제로 하고 있음을 상기할 때 이는 프로젝트의 첫번째 특징으로 전혀 손색이 없는 것

         • 목표가 달성되었을때 프로젝트는 소멸하게 된다.

           흔히 프로젝트 조직을 논할 때 프로젝트를 위한 조직은 임시 조직으로 분류되는데, 이는 프로젝트 자체가 목표 달성

           후 소멸되기 때문이다. 그 후 프로젝트는 과거의 사례나 경험으로 남아있게 되는데, 물론 현재에도 영향을 주는 것

           이 사실이지만, 프로젝트 자체는 과거라 할 수 있다. 때문에 프로젝트의 본질은 목표에 있다라고 말할 수 있다.

         • 목표는 성과로 나타나고 평가된다.

           매일 무슨 일을 하지만 아무런 성과가 없고 그것을 측정하기도 어려운 운영업무에 반해 프로젝트는 명확한 결과물을

           보여준다.

         • 현재 프로젝트가 주목받는 이유는 바로 이러한 점 때문이며, 정부/공공기관이나 경영혁신에 관심을 갖는 기업 등이 프

           로젝트에 관심을 갖고 있다.

      - 한시적이다(Temporary)

         • 시간이 정해진 것이 아니라면 프로젝트라고 부르기 어렵다.

           비록 그것이 몇백년, 몇천년이라 하더라도 엄밀히 말해서 시간적인 제한이 있어야 비로소 프로젝트라고 부르는 것이

           가능하다.

           물론 일반적으로 몇백년 단위로 가면 그것을 하나의 단위 프로젝트로 묶는 것이 쉽지 않을 수 있다.

           하지만, 어떤 건축물들은 짓는데만 몇 백년이 소모된 경우가 있으며, 이를 프로젝트라고 부르는 것 또한 가능하다.

           때문에 한시적이라는 프로젝트의 특징은 오히려 시작과 끝이 있다라는 개념으로 이해하는 것이 더 적합할 것이다.

      - 유일하다(Unique)

         • 목적과 시간으로 프로젝트를 이해하기에는 그 범위가 너무 커진다.

           세상에는 목표를 갖고 시간을 할애하여 노력하는 것들이 너무 많기 때문이다.

           하지만 유일하다라는 특징은 프로젝트를 다른 보편적인 것들과 구분하는 중요한 특징이 된다.

           여기서 말하는 유일하다는 점은 PMBOK에서 말하는 결과의 유일함보다 프로젝트 그 자체, 즉, 환경, 행위, 내용, 결과

           를 모두 다 고려한 유일하다는 특징을 말하는 것임을 잊지 말아야 한다.

         • 결과가 같은 프로젝트는 얼마든지 생각할 수 있다.

           하지만 그 결과를 위해 투입되는 노력이나 환경 등은 모두 다른 것이다.

           이는 세상의 모든 프로젝트는 다르다고 선언적으로 말할 수 있는 특징이며, 일반적으로 프로젝트에 대해 알게 모르게

           인식되고 있는 내용이다.

      - 점진적으로 상세화 된다(Progressive Elaboration)

         • 위의 세가지 특징이 프로젝트의 규범적 속성이라고 한다면, 점진적 상세화의 특징은 프로젝트의 구체적 내용 상의 특

           징이라고 할 수 있다.

           그리고 이 특징이 바로 프로젝트를 가장 어렵게 하는 특징이기도 하다.

         • 많은 PM들이 프로젝트에서 가장 어렵다고 느끼는 것이 고객의 요구사항을 관리하는 것이다.

           흔히 고객은 모호하며 의존적인 요구를 하게 마련이다.

           즉, “마당이 넓고 예쁜 집이었으면 좋겠어요" 라고 한다면 설계자는 구체적으로 어떠한 집이냐 묻기 마련이다.

           그럼 고객은 일반적으로 이렇게 대답한다.

           "제가 그것을 잘 몰라서 전문가인 당신께 맡기는 거잖아요. 그러니 알아서 해주세요. 이는 전형적인 우문우답의 현실

           이지만, 가장 많이 겪는 현실이기도 하다.

           그렇다고 알아서 해줘서 고객이 한번에 만족하는 경우는 별로 없다.

           많은 PM들이 고객이 요구가 정확하지 않고 자주 바뀌어서 프로젝트가 어렵다고 얘기한다.

           이러한 것은 바로 프로젝트의 점진적 상세화의 특징을 갖고 있기 때문이다.

           따라서 계획 단계에서 그 내용을 되도록 구현 가능한 범위내에서 상세하게 파악하고 준비하는 것이 필요하며, 이러한

           이유로 여러 요구사항공학이나 PM의 경험 등이 필요하게 된다.

▣ 운영과 프로젝트의 차이점
   - 운영은 지속적이지만, 프로젝트는 일시적
   - 운영은 종료일이 없고, 동일한 프로세스를 반복하는 지속적인 작업
      • 반면에 프로젝트는 명확한 개시일과 종료일을 갖고 있으며, 목표와 목적이 달성될 때 완료된다.
      •  목표와 목적이 달성될 수 없으면 프로젝트는 중단된다.

1.2.3 프로젝트의 사례

   - 프로젝트는 다양한 분야에서 여러가지 형태로 나타난다.

      • 가장 오래된 프로젝트의 사례는 건축

        건축은 인간의 기본인 의식주 가운데 하나로 고대로부터 인간이 가장 우선순위를 두고 실행한 프로젝트 가운데 하나

        현대에도 건축 분야는 프로젝트가 가장 잘 적용되며, 실제로 방법론이나 기법 등에서 가장 발달한 분야

      • 여러 산업 분야에서 프로젝트는 그 예를 찾기 쉬운데, 신제품 혹은 서비스의 개발 프로젝트로부터 조직의 프로세스 개선

        활동, 전산시스템 개발 등에 적용

        또한 조직 혁신 프로젝트(CMMI 5등급 달성 프로젝트, 6 Sigma 현장 적용 프로젝트), 이벤트 프로젝트(컨퍼런스 개최 프

        로젝트, 선거 운동 프로젝트), 교육 프로젝트(신규 커리큘럼의 개발, 교육 워크샵의 조직) 등이 프로젝트의 좋은 예

CMMI(Capability Maturity Model Integration)
   - 정보 시스템을 구축하는 기업의 능력 수준을 나타내는 기준으로 최근 국제 정보통신 프로젝트의 입찰 가격 기준으
     로 활용되고 있다.
   - 기존 CMM에 프로젝트 관리(PM), 프로큐어먼트(procurement), 시스템 엔지니어링(SE)의 요소를 통합한 것으로서
     시스템과 소프트웨어 영역을 통합시켜 기업의 프로세스 개선 활동을 지원하는 것이 특징

6 Sigma
   - 모든 품질 수준을 정량적으로 평가하고 효율적인 품질 문화와 고객 만족을 달성하기 위해 전사적으로 실행하는 21
      세기형 기업 경영 전략
   - 전통적 품질 관리법이 공장 중심의 방법이었다면 6시그마는 전사적 경영 혁신 운동
   - 전통적 품질관리 기법에서는 고객에게 인도되는 최종 생산품의 불량을 줄인데 반해, 6시그마는 원인을 제거하는 방
     법으로 기업 내전부문의 오류가 발생할 수 있는 구조를 수정한다는 장점을 갖고 있다.

1.3 프로젝트 관리

1.3.1 프로젝트 관리의 이해

   - 앞서 우리는 프로젝트가 현대적 의미를 가지게 된 것이 'management' 란 개념과 연합한 이후라는 것을 살펴보았다.

   - 많은 이들이 일상적으로 프로젝트라는 용어를 사용하면서 관리라는 개념을 염두에 두지 않는다.

      • 계획부터 실행하여 목표를 달성해 가는 과정에 수많은 자원과 시간 그리고 노력이 필요하다는 점을 상기한다면 관리는

        필수적이라는 점에 동의할 것이다.

      • 구체적 업무 방법론으로 프로젝트 관리는 '프로젝트' 와 ‘관리'가 별개의 것이 아닌 하나의 단어로 '프로젝트 관리' 라고

        인식해야 할 것이다.

   □ PMBOK에서는 프로젝트 관리를 다음과 같이 정의
      - “프로젝트 관리는 지식(Knowledge), 기술(Skills), 도구(Tools), 기법(Techniques)을 프로젝트의 요구를 만족시키기 위한 프

        로젝트 활동들에 사용하는 것이다."

   - 요구사항은 이해당사자로부터 나오므로 요구사항을 충족시키는 것은 이해당사자를 만족시키는 가장 중요한 활동

   - 위 그림처럼 프로젝트에 투입되고 또한 관계되는 모든 요소를 잘 이해하고 관리하여 목적하는 바를 달성해 나가는 것이 바

     로 프로젝트 관리라고 하겠다.

1.3.2 프로젝트 관리의 필요성
   - Standish Group의 조사 결과에 따르면 IT 프로젝트의 74%가 실패한다고 한다.

   □ 프로젝트의 주요 실패 요인

      ① 부정확한 요구 사항

      ② 사용자 환경에 대한 이해 부족

      ③ 불충분한 자원

      ④ 비현실적인 사용자의 기대치

      ⑤ 관리 자원의 부족

      ⑥ 변경 관리의 부족

      ⑦ 불충분한 프로젝트 계획

   - 체계적인 관리 부재에 따른 결과로, 프로젝트 관리자 개인의 경험과 노력으로 모든 프로젝트가 성공하기 어렵다는것을 단

     적으로 보여준다고 하겠다.

      • 중요한 것은 프로젝트의 요구사항이 무엇인지 정확히 파악하고 가용한 자원을 효율적으로 사용하며 예기치 않은 상황에

        능동적으로 대응하는 자세가 필요하다는 것

         → 이것이 프로젝트 관리라고 할 수 있으며, 프로젝트에서 관리가 필요하다는 이유

      • 프로젝트 관리자는 자신의 역할과 프로젝트 관리 방법론의 체계적인 습득을 통해 실제 프로젝트에 적용함으로써 프로젝

        트의 성공을 높이고자 노력해야 할 것

      • PMI(Project Management Institute)의 PMP(Project Management Professional) 자격증은 이러한 노력의 일환으로 프로

        젝트 관리 방법론에 대한 체계적인 지식과 기술을 습득했다고 인정되는 자에게 자격을 부여하는 것

         → 많은 기업들이 PMP 자격을 취득한 사람을 프로젝트 관리자로 임명하고 있다.

Standish Group
   - 미국 매사추세츠주 웨스트 야마우스(WestYamcuth) 소재 리서치 컨설팅 회사
   - '94년 8000개 이상의 소프트웨어 개발 프로젝트를 조사한 뒤 최종 사용자를 참여시키는 게 성공의 가장 중요한 요
     소이며 사용자의 의견을 반영하지 않은 것이 프로젝트 실패의 빈번한 요인이라고 발표한 바 있다.

프로젝트 관리의 목표
   - 프로젝트 관리는 하나의 프로젝트의 성공적인 완료를 위한 관리에서 더 나아가 체계적이고 일관적인 방법에 의한
     관리를 통해 조직의 역량(Capability)을 승화시켜야 한다.

프로젝트 관리와 프로젝트에 의한 경영
   - 일상 업무 환경이 갖는 미션을 프로젝트화 하여 달성하는 경영 방식- 조직의 사업 변화와 효율 향상을 지원하기 위
     한 주요 툴로 부각

1.3.3 프로젝트 관리의 3대 제약
   - 범위(Scope), 일정(Time), 원가(Cost)의 세가지를 일컬어 프로젝트 관리의 3대 제약(Triple Constraints)이라고 부른다.

      • 어떠한 프로젝트라도 이 3대 요소로부터 자유롭지는 못하며, 프로젝트의 성공과 실패를 구분하는 기준

   - 범위 : 프로젝트에 존재하는 필요와 기대 사이에서 요구사항

   - 일정 : 프로젝트의 시작과 종결의 시점과 그 기간

   - 원가 : 프로젝트에 할당된 예산

   - 프로젝트 관리를 "주어진 기간 동안 주어진 예산 안에서 이해당사자의 요구를 만족시키는 것이다"라고 말할 정도로 이 3대

      제약 요소는 중요

      • 프로젝트 관리에서의 모든 영역이 중요하겠지만, 이 3대 제약 요소는 중점 관리 대상 정도로 이해하면 되겠다.

      • 품질(Quality)의 경우 3대 요소 모두와 밀접한 관련이 있는 것으로 본다.

1.3.4 프로젝트 성공/실패
   - 프로젝트의 수행에 임하게 되면 많은 사람들이 프로젝트에 대해 성공과 실패를 예측하여 말한다.

      • 금번 프로젝트를 꼭 훌륭하게 성공시켜야 하며, 적어도 실패는 하지 않아야 된다고 말하는 식

      • 정작 그 성공과 실패의 실체가 무엇이며 그 기준이 무엇이냐고 물었을 때, 바로 이것이 성공과 실패라고 핵심을 말 할 수

        있는 사람은 많지 않다.

      • 프로젝트 성공/실패처럼 가장 많이 사용되면서 그 기준이 모호한 것은 보기 드물다.

      • 모든 사람이 흔히 사용하지만 그 실체가 다르게 보일 만큼 상대적인 개념이기 때문
   - 성공/실패는 앞서 기술한 것처럼 3대 제약 요소와 밀접한 관련

      • 주어진 기간 동안 예산 안에서 이해당사자의요구를 만족시키는 것

      • 일정을 지키는 것도 쉬운 것이 아니요, 주어진 예산은 수시로 넘나들기 마련

      • 이해당사자는 항상 자신의 이해만을 내세우며 프로젝트 관리자에게 다양한 요구를 한다.

      • 실무에서는 오히려 그 중 하나만이라도 만족하면 성공했다고 말하기도 한다.
   - 프로젝트 관리자는 시작할 때 자신있는 한가지만이라도 만족하기 위하여 최선을 다하면 되는가? 그것은 오직 팀원의 자세

     일 뿐 프로젝트 관리자의 자세는 아니다.

      • 그런 식으로는 프로젝트를 성공으로 이끈다는 것 자체가 불가능

      • 왜냐하면 앞서 프로젝트 관리의 필요성에서 언급했듯이 프로젝트 관리는 한 두가지 요소만 관리하는 것이 아닌 여러 요

        소를 종합적으로 관리하여 특정 목표를 이루는 것이기 때문
   - 여러 리서치나 전문가의 충고에 따르면, 프로젝트 관리의 성공/실패 여부는 핵심 이해당사자에 달려 있다고 한다.

      • 핵심 이해당사자는 프로젝트와 밀접한 관련을 맺는 경영진이나 고객 등을 말하는데, 그 중 특히 고객이 바로 성공/실패

        의 기준이 된다는 것

      • 고객의 요구에 부응했다고 하여 반드시 성공하는 것은 아니다.

      • 열심히 노력하여 고객의 요구사항을 충족시켰다 하더라도 팀원들을 과도하게 혹사시켰다거나 원가를 초과하여 회사에

        손해를 입히는 것 등은 프로젝트 실패로 간주될 수도 있는 것이다.

      • 때문에 핵심 이해당사자의 이해관계를 정확하게 파악하여 그들의 요구나 기대에서 현실적으로 가능한 부분을 계획 및

        실행 단계에서 추출하여 합의를 도출한 후 이를 요구되는 품질 수준에 부응하는 것이 바로 프로젝트 성공이라고 할 수

        있으며, 이러한 일을 주도적으로 해나가는 프로젝트 관리자의 역량을 'PM리더십' 이라고 한다.

프로젝트의 실패 요인
   - 프로젝트의 실패 요인으로 관련 프로세스의 부재를 들 수 있다.
※ 그러나 프로세스나 방법론의 도입으로 모든 문제가 해결될 수 없다. 프로젝트가 전사적, 중앙집중적으로 관리되고, 항상 개선을 통해 최적화되어야한다. 무엇보다 실제 사용자들이 정직하게 따라야 하며, 업무 수행 절차가프로젝트에 관련된 사람들의 업무 수행에 성숙하게 적용되어야 한다.

1.3.5 프로젝트 관리 조직 체계
   - 프로젝트 업무 수행을 위해 필요한 책임과 역할이나 보고 체계를 정의하기 전에 가장 먼저 고려하여야 하는 것이 프로젝트

     조직 구조를 어떻게 설계할 것인가 하는 문제

   - 프로젝트 조직 구조는 프로젝트의 상황, 프로젝트가 속한 기업의 조직 구조, 방침에 따라 결정

   □ 프로젝트 조직은 기능 조직, 프로젝트 조직, 매트릭스 조직의 3가지로 구분

기능 조직 (Functional Structure)	• 내부 효율성을 강조하는 조직 형태 • 각 기능 부서의 전문성을 최대한 발휘할 수 있는 조직 형태
프로젝트 조직 (Project Structure)	• 외부 효과성을 강조하는 조직 형태 • 외부 환경 혹은 주어진 목표를 달성할 수 있는 조직 형태
매트릭스 조직 (Matrix Structure)	• 내부 효율성과 외부 효과성을 혼합한 조직 형태 • 상기 2가지 조직 형태의 장점을 살린 하이브리드형 조직 형태

   □ 기능 조직
      - 기능 조직(Functional Organization)은 전통적인 조직 구조로서, 생산이나 마케팅, 회계, 인사 등 전문 업무에 따라 분류

        되어 있는 조직

         • 기능 조직에서의 구성원은 정해진 업무와 명확한 상사(=부서장)가 있으며 조직 구조의 변화도 적어서 내부적으로 효

           율적이고 안정적인 성격을 띠고 있다.
         • 기능 조직에서는 주요 업무 형태가 운영이므로 프로젝트가 빈번하지 않으며, 프로젝트가 수행되는 경우도 일반적으로

           특정 부서 내부에서 수행

         • PM을 비롯한 프로젝트의 팀원은 본연의 업무와 함께 프로젝트를 수행하게 되므로 PM의 지시보다는 기능부서장의 지

           시를 우선적으로 따르는 등 프로젝트 자체에 전념하기가 어려우며, 따라서 기능 조직에서의 PM은 보통 회의 장소를

           섭외한다든가 이메일로 진행을 독려하는 등의 촉진자(expeditor)의 역할을 주로 수행

기능조직의 예
포도농장, 자동차공장. 114전화안내 등

   □ 프로젝트 조직
      - 프로젝트 조직(Projectized Organization)에서는 조직의 구성이 부서 위주가 아니라 프로젝트 위주로 되어 있으며, 대부

        분의 구성원도 전담으로 프로젝트 업무만을 수행

         • 프로젝트 조직에서의 구성원은 PM의 지시에 따라 맡겨진 업무를 수행하며, 프로젝트의 한시적인 특성상 구성원의 이

           합집산이 용이하므로 외부 효과적이며 동적인 성격을 띠고 있다.

         • 프로젝트 조직은 주요 업무 형태가 프로젝트이며 PM도 모든 독립적인 권위와 역할을 갖고 있기 때문에, 새로운 프로

           젝트에 대응하여 조직을 구성하고 업무를 수행하기에는 유리하나, 프로젝트 종료 후에 팀원들이 돌아갈 조직이 없어

           서 조직관리가 어려운 단점이 있다.

   □ 매트릭스 조직

      - 매트리스 조직(Matrix Organization)은 기능 조직과 프로젝트 조직의 점을 따서 만들어진 조직

         • 매트릭스 조직에서는 기능 조직처럼 부형태가 이루어져 있으며, 프로젝트가 수행될 경우는 해당 팀원들을 프로, 트로

           발령하여 프로젝트 업무에 전념하도록 하고, 프로젝트가 종료되면, 부서로 돌아오도록 하여 외부 목표 달성에도 효과

           적이면서 효율적인 내부구조를 갖도록 한다.
         • 매트릭스 조직의 구성원은 PM의 지시도 받지만 원 소속 기능부서장의 지시도 받아야 하므로 복잡한 의사소통 체계

           를 갖고, 간접비 부담도 크다.

         • 단점이 있는 반면에, 기능 조직이나 프로젝트 조직의 장점들을 활용할 있기 때문에 많은 프로젝트 중심 조직들에서 활

           용되고 있다.

1.3.6 프로젝트 이해당사자
   - 프로젝트에는 수많은 이해당사자들이 존재

      • 고객, 스폰서, 프로젝트 팀원, 관련 타 프로젝트 팀원 등

      • 프로젝트의 성공은 실제로 이들의 요구를 만족시킬 수 있느냐 없느냐에 따라 결정

그림. 프로젝트 이해당사자의 예

매트릭스 조직에서의 프로젝트 팀원 구성 예
   - 프로젝트 수행 조직의 팀원, PM PM품질관리팀의 QAO, 기술지원팀의 TA/SA 사업지원팀의 사업관리자

이해당사자(Stakeholder)
   - 프로젝트 수행, 성공 여부와 관련하여 긍정적 부정적으로 영향을 받는 개인 혹은 조직

이해당사자의 사전적 정의
※ 어원 : Stake(지주, 막대기) + Holder 받치는 사람) - Stakeholder(지주나 막대기가 무너지지 않게 떠받치는 사람들)
   - 게임이나 경쟁에서 돈을 건 사람(One who holds the bets in agame or contest)
   - 기업체와 같은 곳에서 이익이나 공유된 부분을 갖는 사람 (One who has ashare or an interest, as in anenterprise)

   - 위 그림에서 보듯 특정 프로젝트를 진행할 때 프로젝트 관리자는 해당 프로젝트에 이해 관계를 갖고 있는 수많은 사람들

     을 관리해야 한다.

   - 이해당사자는 프로젝트 수행과 성공 여부와 관련하여 긍정적, 부정적으로 영향을 받는, 또한 그렇기 때문에 적극적으로 프

     로젝트에 영향을 미치고자 하는 개인 혹은 조직을 말한다.

   - 이해당사자는 사전적 정의(stake=지주대, holder=붙잡는 사람)처럼 프로젝트라는 지주대 주위를 무너지지 않게 떠받치면

     서 프로젝트의 실패와 성공에 많은 영향을 주고 받는 사람들(PM, 고객, 상위관리자, 프로젝트 수행 팀, 투자자, 외주업체, 계

     약자 등)을 말한다.

   □ 각 이해 당사자별 역할과 책임
      - 프로젝트 관리자 : 프로젝트 수행에 대한 전반적인 책임
      - 고객 : 결과물을 사용하게 될 개인 또는 조직을 포함
      - 기능 부서 관리자 : 프로젝트 팀원이 속한 부서의 관리자

         • 프로젝트 관리자와 함께 프로젝트 팀원에 대한 권한
      - 경영층 : 프로젝트를 수행하는 조직의 경영층

         • 프로젝트 수행과 관련된 결정권
      - 스폰서 : 프로젝트에 자금을 투자하는 사람 혹은 조직

         • 프로젝트의 성공에 궁극적인 책임
      - 프로젝트 팀 : 프로젝트를 실질적으로 수행하는 사람 혹은 조직

이해당사자별 관점, 측정 지표

스폰서
A사에서 발주된 프로젝트를 B사가 수주해 실행한다면 스폰서는 B사의 PM의 상관인 사업부장이 된다.

   □ 이해당사자는 특성과 영향력의 수준에 따라 분류, 관리
      - 특성에 따른 분류 : 이해당사자의 특성에 따라 개인이나 조직을 분류

         • 예를들면 프로젝트 결과물에 직접적인 영향을 받는 사람과 간접적인 영향을 받는 사람, 재무적 기술적 · 정치적 · 법률

           적으로 관계가 있는 사람

      - 영향력 수준에 따른 분류 : 분류된 형태 안에서 영향력의 수준에 따라 관리 대상 우선 순위를 설정함

   - 이해당사자는 각자의 이해 분야가 다르기 때문에 주관적 프로젝트 성공 기준(Critical Success Factor)을 가지며, 통합 스코

      어 카드(Balanced Score Card)를 이용하여 프로젝트 목표 달성 정도를 지속적으로 관리할수 있다.

통합 스코어 카드 (Balanced Score Card)
   - 기존의 재무적 측정 시스템으로는 회사의시장 가치를 적절히 반영하기 어려워짐에 따라 등장한 무형 자산 평가 시
     스템이다.
   - 조직의 사명과 전략을 측정하고 관리할수 있도록 하는 포괄적인 측정 지표로서, 성과 평가와 전략을 연계함으로써
     전략실행력을 확보하는 틀로 쓰이고 있다.
   - 산출 방법은 재무, 고객, 내부 프로세스, 학습과 성장 등 4분야로 구분하여 기업별특성에 맞는 지표를 선정하고 각
     지표별로 가중치를 적용하여 산출한다.
   - 조직의 비전과 전략 수립의 실질적인 성과 측정을 통하여 성장을 위한 핵심 역량에 자원을 집중하는 데 그 목적이
     있다.

1.4 프로그램, 포트폴리오

1.4.1 프로그램(Program)

   - 프로그램은(Program)은 성격이 비슷하고 관련 있는 복수의 프로젝트를묶어 놓은 그룹으로, 통합 관리를 통해 추가적인

     효과를 얻기 위한 것을 말한다.

   - 프로그램 단위의 관리는 조직의 현재 또는 새 역량을 개발할 수 있도록 하고, 그를 통해 개별적인 프로젝트 관리로는

     얻을 수 없는 이득이나 통제를 얻게 된다.

   - 조직은 프로그램들을 통해서 조직의 목표 및 목적, 또는 전략적 계획을 달성하게 된다.

   - 프로그램 관리(Program Management)에서는 각 프로그램의 목적과 이득을 달성하기 위해서 크게 프로그램 거버넌스,

     이해당사자 관리, 이익 관리로 나누어 볼 수 있다.

   - 잘 관리된 프로그램은 원가, 일정, 또는 노력을 최적화하여 점차 수익이 증가하도록 하고, 프로그램 전체 관점에서 자원을

     최적화하게 된다.

그림. 프로젝트, 프로그램, 포트폴리오 예

프로그램과 서브 프로젝트
   - 프로그램(Program) 여러 프로그램의집함으로서, 하나의 그룹으로 관리
   - 서브 프로젝트(Subproject) : 한 프로젝트의 일부분을 분리한 것이며, 하나의 프로젝트는 여러 개의 하위 프로젝트
                                         로 구분될 수 있다.
프로그램 그룹핑 예
   - 조직에 따른 그룹핑 : 공공 사업부, 금융 사업부, 제조 사업부, 유통 사업부
   - 고객에 따른 그룹핑 : A사 B사 C사 D사
   - 지역에 따른 그룹핑 : 아시아, 미주, 유럽

1.4.2 포트폴리오(Portfolio)
   - 포트폴리오(Portfolio)는 전략적 목표 달성을 위해서 프로젝트나 프로그램들을 효율적으로 관리할 수 있도록 적절히 묶

     어 놓은 그룹으로, 프로그램이 어떻게 잘 할 것인가의 관점이라면 포트폴리오는 어떻게 올바른 일을 선택할 것인가의 관점

     이다.
      • 프로젝트를 그룹화하여 프로그램으로 관리하는 것은 모든 프로젝트에 대하여 전체적으로 조망할 수 있는 보고 자료

        나 통계 분석의 제공을 위한 것

      • 하나의 프로젝트가 다른 프로젝트에 미치는 영향을 분석하기 위해, 복수 프로젝트가 하나의 인력 집단(Resource Pool)에

        서 인력들을 공유할 때 자원 사용도를 측정하기 위한 것

   - 프로젝트는 타 프로젝트와 많은 상호 작용을 통해 영향을 주고 받는다.

      • 자원 점유 부분에서 다양한 이슈들이 발생

      • 조직의 전략적 차원에서 우선 순위가 높은 프로젝트에 할당 우선 순위를 부여하고, 자원의 복수 프로젝트 할당에 대한

        관리를 위해 프로젝트들을 프로그램으로 묶어서 관리할 필요가 있다.

프로그램 관리의 예
   - 공공 사업부에서 새로운 프로젝트를 수주하였는데, 예상되는 경상 이익이 상당히 높고 파급 효과 때문에 반드시 성공
     으로 이끌어야 하는 프로젝트이다.
      • 이 경우 양질의 리소스를 확보하여 프로젝트의 성공을 높이기 위해 타 프로젝트들과 Trade-off 하여 양질의 인력을
        보충하는 방법 등으로 조직 차원에서의 ROI를 높일 수 있다.

1.5 전사적 프로젝트 관리(EPM, Enterprise Project Management)

1.5.1 전사적 프로젝트 관리(EPM)

   - 비즈니스 환경이 점점 복잡해짐에 따라 프로젝트 관리는 단순히 1개의 프로젝트를 관리하는 범주를 벗어나, 회사의

     전략에 맞는 프로젝트 선정 및 실행이나 사업전략의 성공적 구현을 위한 조직적인 프로젝트 관리를 필요로 하게 되었다.

   - 조직환경도 단순한 운영환경 위주에서 복잡하고 다양한 조직으로 변화되었으며, 프로젝트도 경영 혁신이나 MBP등의

     형태로 다양하게 나타나, 비 반복적 업무인 프로젝트를 반복적으로 수행하는 조직이 늘어났다.

   - 전사적 프로젝트 관리는 전략과 실행의 연결을 강화하고 프로젝트 결과물을 조직의 성공과 동일시하는 관점으로, 전사

     차원에서 프로젝트들이 기업의 전략적 목표를 향하도록 조율하는 것을 말한다.

MBP (Management By Projects)
회사의 운영을 위한 세부과제들을 프로젝트화하여 관리하는 방법론

1.5.2 EPM을 위한 프로젝트, 프로그램, 포트폴리오 관리
   - 전사적 프로젝트 관리를 위해서는 업무 처리 규모에서 프로젝트, 프로그램, 포트폴리오 관리가 가능해야 한다.

   - 포트폴리오 관리에서는 회사의 전략과 사업의 영향, 추진방향에 따라 포트폴리오를 선택하고 자원을 집중하며 그에

     맞는 프로그램들을 착수할 수 있는 역량이 필요하다.

   - 프로그램 관리에서는 해당 사업 분야의 프로젝트들을 착수시키는 동시에 프로젝트들에서 표준화하거나 공통으로

     활용될 수 있는 부분을 발굴하고 개발함으로써 수익 창출을 극대화하고 조직의 역량을 개발할 수 있어야 한다.

   - 프로젝트 관리에서는 프로젝트 자체의 범위, 일정, 원가를 체계적으로 관리하되, 프로그램과 연관이 있는 lessons

     learned 공유나 원가관리, 포트폴리오와 연관이 있는 자원, 위험 이슈 등을 상위단계 통합 프로세스와 통합시킬 수

     있어야 한다.

Lessons Learned
프로젝트에서 발생한 변경과 그 원인 및결과를 기록한 문서

1.5.3 EPM의 핵심 3요소
   - 전사적 프로젝트관리 체계를 위해 필요한 핵심 3요소는 방법론, 조직, 솔루션이다.

   □ 방법론(Methodology)
      - EPM을 경영혁신 관점에서만 바라본다면, 회사의 운영을 좀더 세밀하게 관찰하고 자료를 취합하여 체계적으로 

        관리하는 한편 의사결정에도 지원을 받는 것이 목표이다.

         • 어떤 경영혁신이든 아래로부터의 변화 없이 위로부터의 변화로는 성공하기 어렵듯이, EPM도 성공을 위해서는 프로젝

           트 관리자들의 참여가 핵심적

      - 프로젝트 관리자가 조직의 목표보다도 프로젝트의 성공을 위해 노력해야 하는 위치이며, 특히 수주형 프로젝트 위주의

        회사에서는 제1 이해당사자를 고객으로 인식하고 있는 것이 일반적이기 때문에 어떻게 프로젝트 관리자들을 참여시킬

        것인가가 관건이다.
      - 프로그램 관리 목적의 하나인 이득 창출은 조직의 역량을 향상시켜 프로젝트가 원활하게 수행될 수 있도록 하는 것

         • 그 방법으로써 유사 프로젝트를 위한 템플릿 작성, 중복 업무에 대한 협업을 통한 진행, 핵심인력 공유, lessons

           learned 취합 및 전파 등의 방법이 있을 수 있다.

         • 이러한 방법들로 프로젝트 관리자들이 EPM을 통해 프로젝트 수행에 실질적인 도움이 된다는 확신을 얻게 만들 수 있

           다면, 좀더 개선 및 발전시킬 부분을 찾는데 동참할 수 있을 것이며, 그에 따라 EPM도 성공적으로 이끌 수 있다.

         • 향후 자발적인 정보 공유가 되기 위한 토대로 필요한 것이 초기 정보제공 및 자료취합 등에 대한 프로세스

   □ 조직(Organization)
      - 작은 규모의 회사에서는 PMO 조직을 따로 두지 않고 팀이나 사업부 단위로 프로젝트들을 관리하거나, 또는 유능한 프

        로젝트 관리자에게 맡겨둔 채 종료시점과 손익예측 등만 관리하는 경우를 보게 된다.

      - EPM의 성공을 위해서는 EPM 도입까지의 추진을 담당할 조직이 필요하며, 도입 이후에도 포트폴리오 기초자료

        수집이나 포트폴리오 선택, 포트폴리오에 맞는 프로그램 착수~종료, 전략 변경에 따른 프로그램 변경, 프로그램 운영을

        통한 프로젝트 성과 향상 등을 담당할 조직, 즉 PMO가 필수적이다.

         • 이러한 일은 EPM의 도입 초기에 도구와 절차 뿐 아니라 프로젝트 관리의 전사적 접근과 자료 토대의 의사결정, 결정

           사항에 대한 실행 권한이 있는 PMO(Project Management Office) PMT(Portfolio Management Team)를 설치하고 권

           한을 적절히 분배함으로써 이룰 수 있다.

   □ 솔루션(Solution)
      - EPM에서는 포트폴리오 선택을 위해 사용했던 비즈니스 영향력 등의 평가 요소가 프로그램 또는 프로젝트 착수 시 성공

        지표 및 프로젝트 헌장 등으로 연계 반영되어야 한다.

         • 프로젝트에서의 진척상황 및 수행 성과가 프로그램으로, 또 포트폴리오로 집계되어 현재 조직의 전략 달성 상태 및 필

           요한 의사결정사항 및 지원할 자원 등의 파악을 도울 수 있어야 한다.

         • 이러한 실시간 정보 취합 및 배포가 가능하게 하기 위한 도구가 EPM Solution이다.

1.6 프로젝트 라이프사이클과 관리 프로세스

1.6.1 프로젝트 라이프 사이클

   - 프로젝트 라이프 사이클은 프로젝트의 여러 단계(Phase)를 통합적으로 지칭하는 용어

   - 프로젝트를 수행하는 조직은 하나의 프로젝트를 다시 여러 개의 단계로 구분하여 관리

      • 프로젝트 단계(Project Phase)는 프로젝트를 구성하는 단위이며, 중요한 산출물이 완료되는 시점을 기준으로 한다.

   - 단계 종료 검토(Phase-end Reviews)는 프로젝트의 다음 단계로 넘어갈 것인지를 결정하는 것으로, 각 단계별로

     산출물이 성공적으로 완성되었는지 확인하는 업무

프로젝트 라이프 사이클 (Project Life Cycle)
프로젝트를 수행하기 위한 프로젝트의 탄생에서부터 소멸에 이르는 전체 과정

   - 모든 프로젝트는 단계로 나누어지며, 큰 프로젝트이던 작은 프로젝트이던 일정한 생애주기 구조를 갖는다.

   - 프로젝트는 최소한 시작 또는 착수 단계, 중간 단계와 종료 단계를 거치며, 각 단계의 개수는 프로젝트의 복잡성이나

     그것의 산업 특성에 의존

      • 프로젝트가 진행되는 모든 단계를 프로젝트 라이프 사이클(프로젝트 생애 주기)라고 한다.
   - 프로젝트 라이프 사이클은 업종마다 다르다.

      • 건설 업체의 라이프 사이클은 실행 가능성을 분석하는 일로부터 계획, 설계, 건설, 인수, 스타트업에 이르는 과정을

        갖는다.

      • IT 프로젝트의 라이프 사이클은 요구 사항을 분석하는 일로부터 개략 설계, 상세 설계, 코딩, 테스팅, 설치, 컨버젼,

        운영의 단계를 거친다.

그림. 프로젝트 라이프 사이클의 예

1.6.2 프로젝트 관리 라이프 사이클
   - 프로젝트 관리 프로세스라고도 하며, 착수(Initiating), 계획(Planning), 실행(Executing), 감시 및 통제

      (Monitoring & Controlling), 종료 (Closing)로 구성

   □ 각 단계에 대한 주요 내용

   □ 착수(Initiating)

      1. 프로젝트 개요 작성 및 목표(goals) 설정

      2. 프로젝트 요구사항(Requirements) 분석

      3. 예비 범위기술서 작성

      4. 일정(Milestone) 및 예산(Budget) 산정

      5. 프로젝트 제약 조건(constraints)을 문서화

      6. 프로젝트 가정(assumptions)을 문서화

      7. 이해당사자(Stakeholders) 분석 및 주요 이해당사자 파악

      8. 성과 기준(performance criteria)을 식별

      9. 자원 요건(resource requirements)을 결정

      10. PM과 PM의 권한(Authority) 설정

      11. 프로젝트 팀 구성

   □ 계획(Planning)

      1. 프로젝트 관리 계획서 작성

      2. 범위기술서 작성

      3. 작업분할체계도(WBS: Work Breakdown Structure) 작성

      4. 액티비티(Activities) 정의 및 우선순위 설정

      5. 액티비티에 기간(Duration) 산정 및 자원(Resource) 할당

      6. 비용(Cost) 산정

      7. 품질(Quality) 계획 수립

      8. 인력(Human Resource) 관리 계획 수립

      9. 의사소통(Communication) 계획 수립

      10. 위험(Risk) 관리(식별, 분석, 대응) 계획 수립

      11. 외주(Outsourcing) 관리 계획 수립

      12. 변경(Scope Creep) 관리 계획 수립

   □ 실행(Executing)

      1. 팀원 교육 및 배치

      2. 외주 업체 선정 및 작업 진행

      3. 품질 보증(Quality Assurance) 활동 수행

      4. 정보 수집 및 배포

   □ 감시 및 통제(Monitoring & Controlling)

      1. 성과(Performance) 측정 및 진척 관리

      2. 시정조치(Corrective Action) 수행

      3. 시정 조치의 효과(effectiveness of corrective)를 평가

      4. 변경(Scope Creep) 사항에 대응

      5. 비용 및 품질 통제

      6. 프로젝트 팀 통제

      7. 주요 이해당사자(Key Stakeholders) 관리

      8. 위험 사건 유발 요인(risk or event triggers) 대응

      9. 프로젝트 활동 감시

   □ 종료(Closing)

      1. 인도물(Deliverables) 승인을 획득

      2. 프로젝트 교훈(Lessons Learned)을 문서화

      3. 제품 기록(Records)과 도구(Tools)를 보관

      4. 자원 해제 (Release resources).

1.6.3 프로젝트 관리 프로세스

   - 프로젝트 관리자는 프로젝트를 관리하는 사람

   □ 프로젝트 관리자는 어떻게 관리할까?
      - 일반적인 업무에서 관리의 프로세스는 흔히 PDS라고 하는 Plan-Do-See의 과정을 거친다.

      - 프로젝트의 관리 프로세스는 다르다.

         • 프로젝트와 일반 업무의 다른 점은 시작과 끝이 있으며, 프로젝트의 특성에 따라 각기 다른 라이프 사이클을 지닌다는

           점이다.

         • 프로젝트 관리 프로세스는 착수(Initiating), 계획(Planning), 실행(Executing), 감시 및 통제(Monitoring & Controlling),

            종료(Closing)의 5개 프로세스 그룹으로 나누어진다.

         • 각 단계는 세부 프로세스들로 나누어지는데, 총 44개의 프로세스가 존재한다.

         • 프로젝트 라이프 사이클은 업종마다 다르지만, 프로젝트 관리 프로세스는 업종에 관계없이 동일하고 보편적

프로젝트 라이프사이클과 프로젝트관리 Process 그룹 비교
   - 프로젝트 라이프사이클과 PM processgroup은 다름
   - PLC 각 단계별로 PM process group들이 포함될 수 있음
   - PMBOK 참고

그림. 프로젝트 관리 프로세스

1.6.4 프로젝트 관리 영역

   □ 무엇을 관리할까?
      - 프로젝트 관리자의 관리 대상은 원가, 일정, 업무 범위, 품질, 인력, 의사소통, 위험, 아웃소싱

         • Core 프로세스 : 프로젝트의 목표 달성을 위한 영역과 프로젝트의 목표 달성을 위한 수단 영역으로 나누어서 프로젝

                                트의 목표인 원가, 일정, 업무 범위

         • Facilitating 프로세스 : 목표를 달성하기 위한 수단영역인 품질, 인력, 의사소통, 위험, 아웃소싱

         • core 및 facilitating은 프로세스들의 중요성을 말하는 것은 아니며, 각 영역은 동등한 중요성을 갖고 있다.

프로젝트 3대 제약 사항
시간, 예산, 품질

▣ Summary

POINT1 프로젝트의 개념과 특징 
   - 프로젝트 : 전체적인 목적을 향한 일련의 활동들 또는 그 목적의 달성과 관련한 정보의 수집, 유일한 제품, 용역 또는 결
                   과를 창출하기 위해 투입되는 일시적인 노력
   - 프로젝트의 특징 : 명확한 목적과 목표를 가진다, 한시적이다(Temporary), 독특하다(Unique), 점진적으로 상세화 된다
                             (Progressive Elaboration)를 들 수 있다.

POINT2 프로젝트 관리의 개념과 필요성
   - 프로젝트 관리는 지식(Knowledge), 기술(Skills), 도구(Tools), 기법(Techniques)을 프로젝트의 요구를 만족시키기 위
     한 프로젝트의 활동들에 사용하는 것
   - 프로젝트 관리는 프로젝트 관리자가 프로젝트를 관리하는 방법론의 체계적인 습득을 통하여, 실제 프로젝트에 적용함
     으로써 프로젝트의 성공을 이루기 위해 필요
   - 프로젝트 관리의 3대 제약 : 범위, 원가, 일정 말하며, 이는 프로젝트 성패의 기준이 되므로 중요하게 다루어야 한다.
   - 이해당사자(Stakeholder) : 프로젝트 수행과 성공여부와 관련하여 긍정적, 부정적으로 영향을 받는 개인 혹은 조직
      • 프로젝트의 성공은 실제로 이들의 요구를 만족시킬 수 있느냐 없느냐에 긴밀히 관련
   - 프로그램 : 묶어서 관리하여 이익을 얻는 프로젝트들
   - 포트폴리오 : 조직의 비즈니스 전략과 연관된 프로그램의 집합

POINT3 프로젝트 관리의 주요 개념
   - 모든 프로젝트는 단계로 나누어지며 큰 프로젝트이던 작은 프로젝트이던 일정한 생애 주기(Project Life Cycle) 구조를
     갖는다.
   - 프로젝트 관리 프로세스는 착수(Initiating), 계획(Planning), 실행(Executing), 감시 및 통제
      (Monitoring & controlling), 종료(Closing)로 구성

▣ KeyWord
   - 프로젝트, 프로젝트 관리
   - 이해당사자(Stakeholder)
   - 프로젝트 관리 프로세스
   - 프로젝트 라이프 사이클