PMBOK, 프로젝트 관리/프로젝트 관리 - 기술
콘텐츠로 건너뛰기

PMBOK, 프로젝트 관리/프로젝트 관리

PMI(Project Management Institute)는 프로젝트 관리에 대한 표준 순서와 기준을 확립하려는 조직입니다.

광고

이를 위해 PMI는 모든 프로젝트 관리자가 알고 적용해야 하는 전체 도구와 모범 사례가 확립된 PMBOK(프로젝트 관리 지식 책)를 유지 관리합니다.

다른 방법론(예: 스크럼과 같은 민첩한 방법론)과 달리 PMBOK는 예측 프로젝트 관리를 지향합니다. PMBOK는 프로젝트의 여러 단계를 선형 방식으로 제시하며(한 단계가 완료되면 다시 돌아갈 수 없음), 여기서 요구사항/솔루션, 범위 및 계획(예: 각 작업의 비용 및 기간)이 표시됩니다. 실행)이 초기 단계에서 확립됩니다(이것이 예측 관리라고 불리는 이유입니다).

따라서 PMBOK는 보다 고전적인 프로젝트 관리 분야(영국에서 널리 사용되는 보완적인 PRINCE2 표준도 포함)에 속하는 것으로 간주할 수 있습니다. 그러나 이 사실이 제공하는 일부 도구를 보다 민첩하고 유연한 다른 방법론과 함께 사용할 수 없다는 의미는 아닙니다.

본 주제에 들어가기 전에 PMBOK에 따른 프로젝트의 정의와 특성을 설정하는 것이 필요합니다.

  • 프로젝트는 문제 해결(필요 사항 충족)을 시도합니다.
  • 일시적이야
  • 이는 시간적으로 고유하며 동일한 상황에서는 반복할 수 없습니다.
  • 불확실성을 안고 있다
  • 자원을 소비합니다: 시간, 돈, 재료, 노동.

프로젝트에는 다음 단계로 구분되는 자체 수명 주기가 있습니다.

  • 시작 : 필요성이 확인되고 프로젝트 수행이 가능한지 여부가 문제입니다.
  • 계획:
    • 솔루션이 더 자세히 개발되었습니다.
    • 작업 정의, 달력.
    • 시간과 돈의 비용 추정.
    • 문제는 다시 프로젝트가 실행 가능한지 여부입니다.
  • 실행: 계획 모니터링 및 조정.
  • 마무리: 프로젝트가 해결해야 할 요구 사항을 충족하는지 확인합니다.

이러한 모든 단계에는 다음과 같은 일반적인 프로세스가 포함됩니다.

  • 문제 또는 기회 식별
  • 이상적인 솔루션 식별 및 정의
  • 필요한 작업과 리소스를 식별합니다.
  • 일정 준비 및 자원 확보
  • 프로젝트 비용 추정 및 예산 준비
  • 리스크 분석 및 이해관계자(프로젝트에 직·간접적인 이해관계가 있는 사람)와의 관계 구축 : 주기적인 리스크 관리
  • 실행 중 적절한 수준에서 제어 및 의사소통 유지: 편차를 감지하고 전달하기 위한 정기적인 회의
  • 성공적인 마무리 관리
    • 펀치 리스트(Punch list): 프로젝트를 완료하기 위한 작업 목록입니다.
    • 프로젝트가 거의 종료되면 팀원들이 분산되는 경향이 있습니다.

그러나 프로젝트는 대인 관계의 관점과 같은 다른 관점에서 볼 수 있습니다.

  • 팀에 동기를 부여하세요: 올바른 분위기 조성
    • 각 역할이 프로젝트에 어떻게 기여하는지 설명하는 데 시간을 투자하세요.
    • 회원들의 긍정적인 기여를 강조하기 위해 회의에 시간을 투자하십시오.
    • 위임된 업무를 신뢰하세요
    • 개인에게 목표를 할당하고 경로를 선택하도록 허용합니다.
    • 요청된 것 이상의 노력을 인식하십시오.
    • 예를 들면
  • 다양성을 관리하다
    • 가능한 개인 목표를 식별하여 최소화하거나 그룹 목표로 전환하세요.
    • 집단 결속력을 추구합니다(관습, 문화 등의 조화).

차례로 내부 프로젝트 관리 및 대인 관계 프로세스 외에도 조직의 범위 내에서 프로젝트가 개발되고 실행됩니다. 현재 우리는 컨설팅 및 감사 부문과 같이 프로젝트 실행을 주요 업무로 하는 회사를 찾을 수 있습니다. 전체 조직이 프로젝트 관리에 집중하고 있기 때문에 이는 가장 긍정적인 시나리오입니다.

그러나 대부분의 회사는 다양한 기능을 가진 부서와 특정 작업을 수행하는 직원으로 구성된 계층 구조를 갖고 있어 이동성이 매우 산발적인 경향이 있습니다. 이러한 유형의 시나리오에서는 내부 공동 작업자와 함께 프로젝트(임시 프로젝트)를 실행하면 관리하기가 더 어려워집니다(이것이 프로젝트가 종종 외부 컨설턴트 및 감사자와 계약을 맺는 이유 중 하나입니다).

이 두 번째 상황은 직원들에게 "사일로 사고방식(Silo Mentality)"을 제공할 수 있습니다. 즉, 목표가 할당된 프로젝트가 아닌 기능 영역과 연결되어 있는 사람들입니다. 그들은 프로젝트의 성공에 관심을 두지 않고 안정적인 부서 단위 의무를 이행하는 것을 선호할 수 있습니다. 이 문제는 작업팀의 협력(수평적 사고)을 방해할 수 있습니다.

즉, 조직의 성숙도와 확립된 내부 절차가 프로젝트의 성공 또는 실패에 기여할 수 있습니다.

  • 조직이 일반적으로 프로젝트를 수행하는 경우 이미 정의된 지침이 있습니다.
  • 공식적인 의사소통 채널: 너무 경직되면 업무에 지장을 줄 수 있음
  • 비공식적 의사소통 채널(친구, 지인 등) : 너무 빈번하면 잘못된 정보를 생산할 수 있음

마지막으로 PMBOK는 프로젝트가 성공하려면 다음 기대 사항이 충족되어야 한다고 규정합니다.

  • 레벨 I. 프로젝트 목표 달성
  • 레벨 2. 프로젝트 효율성.
    • 고객의 작업이 중단되는 수준입니다.
    • 자원 활용의 효율성
    • 팀원 수의 증가
    • 경영 갈등
  • 레벨 III. 최종 사용자/클라이언트를 위한 유틸리티입니다.
    • 초기 문제는 해결되었나요?
    • 혜택이 증가했거나 실제로 비용이 절감되었습니까?
    • 사용자가 현재 제품을 사용하고 있습니까?
  • 레벨 IV. 조직 개선: 경험을 통해 배우기

프로젝트 책임자

프로젝트 관리자 또는 프로젝트 관리자에게는 다음과 같은 책임이 있습니다.

  • 프로젝트: 비용, 일정, 기능 및 품질 목표.
    • 조직
    • 투자 수익.
  • 정보 흐름: 사전에 제공합니다. 감독자가 일부 정보에 놀랐다면 이는 우리가 올바르게 알리지 않았다는 의미입니다.
  • 팀: 피드백과 인정을 제공합니다.
  • 자신에 대해: 개인적인 성장.

반면에 프로젝트 관리자는 끊임없이 어려움에 직면하며 그 중 다음을 찾을 수 있습니다.

  • 책임과 책임 권위의 부재
    • 높은 수준의 책임.
    • 나는 나에게 직접적인 권한이 없는 사람들과 함께 일합니다.
  • 비현실적인 목표
    • 가장 일반적인 문제 중 하나입니다.
    • 프로젝트 범위를 올바르게 분석하고 계획하는 아이디어를 강화합니다.
  • 기능적 방향
    • 사람들은 자신의 기능적 지식 영역에 집중하는 경향이 있습니다.
    • 시간성을 고려할 때 기능적 영역이 프로젝트보다 더 중요합니다.
  • 불확실성을 둘러싼 근본적인 갈등
    • 적은 정보로 빠른 결정을 내립니다.
    • 범위 추정(예: 비용)
    • 상사와 팀원이 추정의 어려움을 이해할 수 있도록 노력하십시오.

프로젝트 관리에 따른 책임과 과제를 성공적으로 해결하려면 프로젝트 관리자는 다음 기술을 지속적으로 향상시켜야 합니다.

  • 프로젝트 관리: 계획 및 모니터링을 위한 도구입니다.
  • 대인관계
    • 리더십, 협상 및 위임 기술.
    • 구두 및 서면 의사소통 능력
    • 갈등 해결.
    • 멘토(코칭) 역할을 발전시키기 위한 기술
  • 기술 지식
    • 산업 및 기술 분야에 대한 지식
    • 제품 및/또는 프로세스에 대한 지식
    • 디자인 기술
  • 개인적인 능력
    • 정직, 성실
    • 글로벌하게 생각하기
    • 불확실성과 모호성에 대한 높은 관용
    • 설득력이 있고 주장이 강하다
    • 개방적이고 접근 가능
    • 결정적인
    • 광고. 아이디어나 프로젝트의 장점을 판매하는 능력.
    • 선생님. 팀원들에게 지식을 전달합니다.

프로젝트 정의

프로젝트 정의는 다음 단계로 구성됩니다.

  • 1단계. 문제나 기회를 이해합니다.
  • 2단계. 가장 최적의 솔루션 식별
  • 3단계. 솔루션 개발 및 계획 수립
  • 4단계. 프로젝트 시작

1단계. 문제나 기회를 이해합니다.

프로젝트가 충족시키려는 실제 요구 사항을 식별하는 것이 중요합니다. 작업은 이러한 요구 사항이 만족스럽게 충족되었는지 여부에 따라 평가됩니다.

첫째, 요구사항(Needs)과 솔루션(Solution)을 구별할 필요가 있다.

필요성:

  • 고객에게 목표를 설명합니다.
  • 목표와 목표 지정
  • 그것을 수행하는 방법에 대한 질문을 열어 두십시오.
  • 이것이 수행되는 이유에 대한 대답은 비즈니스 정당성을 지적해야 합니다.

대신 해결책은 다음과 같습니다.

  • 팀을 위한 수단을 설명합니다.
  • 목표와 목표를 달성하기 위한 전략과 아이디어를 지정합니다.
  • 수행 방법을 지정하십시오.
  • 이 작업을 수행하는 이유에 대한 대답은 고객의 요구 사항을 지적해야 합니다.
  • 실제 요구 사항을 확인하도록 요청하면 제3자가 귀하의 기준을 신뢰하지 않기 때문에 불편함을 느낄 수 있습니다.

이러한 정의를 기반으로 이 단계에서는 솔루션을 제공하지 않고 필요성만 설명하는 프로젝트 요구 사항 문서를 생성해야 합니다. 이 문서에는 다음 섹션이 포함되어야 합니다.

  • 문제나 기회에 대한 설명
  • 문제의 영향 또는 효과
  • 문제의 영향을 받는 사람 또는 대상을 식별합니다.
  • 문제 무시의 영향
  • 원하는 상황
  • 원하는 상황 달성과 관련된 이점
  • 조직의 전략과의 연계
  • 조직의 다른 영역과의 호환성 충돌
  • 불확실성
  • 주요 가정
  • 솔루션의 한계
  • 환경 고려 사항
  • 역사적 지원 정보

이 모든 정보를 수집한 후에는 문제를 해결할 가치가 있는지 재평가하고 잠재적인 해결책이 있는지 판단해야 합니다.

2단계. 가장 최적의 솔루션 식별

식별된 요구 사항을 충족하는 솔루션을 식별하려면 다음 절차를 따를 수 있습니다.

  • 미래의 작업 팀 구성원 또는 이해관계자와 그룹 브레인스토밍을 합니다.
  • 프로젝트 요구사항 문서의 내용을 어느 정도 충족하는지 확인하세요.
  • 2~5개의 후보 솔루션 중에서 선택하세요.

선택한 후보 솔루션에 대해 상세한 분석을 수행하여 어느 솔루션이 적용 대상 요구 사항에 가장 적합하고 합리적인 비용인지 식별해야 합니다.

재무 분석(비용 x 이익):

프로젝트의 재정적 실행 가능성을 검증하려면 프로젝트 시행으로 얻을 수 있는 이익(매출 증가, 비용 절감 등)과 비용 등 창출할 수 있는 현금 유입을 식별해야 합니다. 스타트업은 프로젝트 진행 및 관리를 나타냅니다.

따라서 다양한 현금 흐름의 규모를 추정하고 4가지 기본 지표를 계산함으로써 어떤 프로젝트가 더 큰 재정적 수익성을 제공하는지 확인할 수 있습니다.

최소한 다음 지표를 연구해야 합니다.

  • 순현재가치(NPV). 돈의 시간 가치를 고려하여 프로젝트가 얼마나 많은 돈을 창출할 것인지 결정하십시오.
  • 내부수익률(IRR) ​​. 투자 수익을 결정합니다.
  • 기간 반품. 투자금이 회수되는 시기를 결정합니다(NPV = 0).
  • 돈 구멍 . 필요한 최대 투자액을 결정합니다.

비재무적 분석(가중 요소 점수 모델 – 결정 매트릭스)

가중 요인 점수 모델("의사 결정 매트릭스")을 사용한 분석은 평가할 속성 목록을 준비하는 것부터 시작됩니다. 각각에 대해 가중치가 설정되고 각 후보 솔루션에 대한 준수 정도를 나타내는 점수가 지정됩니다.

이점:

  • 금융 데이터를 포함한 다양한 데이터 활용이 가능합니다.
  • 경영진의 참여와 민감도 분석이 가능합니다.

단점:

  • 매우 주관적인 과정입니다.
  • 이는 프로젝트의 매력을 보여주지만 상업적인 정당성을 나타내지는 않습니다.

재무 또는 매트릭스 분석 외에도 선택할 솔루션에 대한 최종 결정은 다른 도구의 사용을 기반으로 할 수 있습니다.

  • 시장 조사
  • 파일럿 테스트. 제한된 지역에서 테스트하십시오.
  • 프로토타이핑. 올바른 예측을 검증하기 위해 프로젝트의 작은 부분을 구성합니다.
  • 컴퓨터 시뮬레이션.

간단히 말해서 수행된 분석은 솔루션 선택에 도움이 될 뿐만 아니라 솔루션이 실행 가능한지, 프로젝트를 계속할 가치가 있는지 판단하는 데도 도움이 됩니다.