프로젝트관리

Project management
무료 사전인 위키사전에서 프로젝트 관리를 찾아보세요.
제품 관리와 혼동하지 않도록 합니다.
경영학
기업의 경영
경리
사업체
기업지배구조
회사법
법인명
경제학
자금
관리종류
조직
거래

프로젝트 관리는 주어진 제약 조건 내에서 모든 프로젝트 목표를 달성하기 위해 팀의 작업을 이끄는 과정입니다.[1]이 정보는 보통 개발 프로세스 초기에 작성된 프로젝트 문서에 설명되어 있습니다.주요 제약 조건은 범위, 시간 및 예산입니다.[2]두 번째 과제는 필요한 입력의 할당을 최적화하고 이를 적용하여 미리 정의된 목표를 달성하는 것입니다.

프로젝트 관리의 목적은 고객의 목표에 부합하는 완전한 프로젝트를 생산하는 것입니다.많은 경우 프로젝트 관리의 목적은 또한 고객의 목표를 실현 가능하게 달성하기 위해 고객의 개요를 형성하거나 수정하는 것입니다.고객의 목표가 명확하게 설정되면 프로젝트 관리자, 설계자, 계약업체 및 하청업체 등 프로젝트와 관련된 다른 사람들의 모든 결정에 영향을 미치게 됩니다.프로젝트 관리 목표가 잘못 정의되어 있거나 너무 엄격하게 규정되어 있는 것은 의사 결정에 해롭습니다.

프로젝트(Project)[3][4]는 특정한 목표와 목적을 달성하기 위해 수행되는 정의된 시작과 끝(일반적으로 시간에 제약이 있고 종종 자금이나 인력으로 제약이 있는)으로 제품, 서비스 또는 결과를 생산하기 위해 설계된 일시적이고 독특한 노력입니다.프로젝트의 일시적 성격은 제품이나 서비스를 생산하기 위한 반복적, 영구적 또는 반영구적 기능적 활동인 [5]통상적(또는 운영)인 비즈니스와 대비됩니다.실제로, 이와 같이 서로 다른 생산 접근 방식을 관리하기 위해서는 서로 다른 기술적 기술과 관리 전략을 개발해야 합니다.[6]

역사

1900년까지, 토목 공학 프로젝트들은 일반적으로 창조적인 건축가들, 기술자들, 그리고 명 건축가들 자신들에 의해 관리되었습니다, 예를 들어, 비트루비우스 (기원전 1세기), 크리스토퍼 렌 (1632–1723), 토마스 텔포드 (1757–1834), 그리고 아이삼바드 왕국 브루넬 (1806–1859).[7]1950년대에 조직들은 복잡한 엔지니어링 프로젝트에 프로젝트 관리 도구와 기법을 보다 체계적으로 적용하기 시작했습니다.[8]

계획과 통제 기술의 아버지, Henry Gantt (1861–1919)

프로젝트 관리는 토목, 엔지니어링, 중방위 등 여러 응용 분야에서 발전했습니다.[9]계획과 통제 기술의 아버지라고 불리는 헨리 갠트는 프로젝트 관리의 두 조상입니다.[10]프로젝트 관리 도구로서 Gantt 차트를 사용한 것으로 유명한 Harmonogram(하모노그램);[11] 그리고 프로젝트 및 프로그램 관리와 관련된 지식의 기초를 형성하는 5가지 관리 기능을 만든 Henri Fayol.[12]Gantt와 Fayol 둘 다 Frederick Winslow Taylor의 과학 경영 이론의 학생들이었습니다.그의 작업은 업무 분류 구조(WBS)와 자원 할당을 포함한 현대적인 프로젝트 관리 도구의 선구자입니다.

1950년대는 핵심 공학 분야가 하나로 뭉친 현대 프로젝트 관리 시대의 시작을 알렸습니다.프로젝트 관리는 엔지니어링 모델을 통한 관리 규율에서 발생하는 별개의 규율로 인식되었습니다.[13]1950년대 이전의 미국에서는 프로젝트를 임시방편으로 관리했는데, 대부분 Gantt 차트와 비공식적인 기술과 도구를 사용했습니다.당시 두 가지 수학적 프로젝트 스케줄링 모델이 개발되었습니다.CPM(Critical Path Method)은 공장 유지보수 프로젝트 관리를 위해 듀폰 코퍼레이션(DuPont Corporation)과 레밍턴 랜드 코퍼레이션(Remington Rand Corporation)의 합작으로 개발되었습니다.프로그램 평가 및 검토 기법(PERT)은 미 해군 특수사업청이 북극성 미사일 잠수함 프로그램의 일환으로 록히드사 및 부즈 앨런 해밀턴과 함께 개발한 것입니다.[14]

PERT와 CPM은 접근 방식이 매우 유사하지만 여전히 약간의 차이가 있습니다.CPM은 결정론적 활동 시간을 가정한 프로젝트에 사용되며, 각 활동이 수행될 시간은 알려져 있습니다. 반면 PERT는 확률적 활동 시간을 허용합니다. 각 활동이 수행될 시간은 불확실하거나 다양합니다.이러한 핵심 차이 때문에 CPM과 PERT는 서로 다른 맥락에서 사용됩니다.이러한 수학적 기법은 많은 사기업으로 빠르게 확산되었습니다.

5개의 마일스톤이 있는 7개월 프로젝트의 PERT 네트워크 차트

동시에 프로젝트 스케줄링 모델이 개발되면서 프로젝트 비용 추정, 비용 관리 및 엔지니어링 경제학 기술이 발전하고 있으며, Hans Lang 등이 선구적인 작업을 수행하고 있습니다.1956년, 미국 비용 공학 협회(현재 AACE International; Association for the Advancement of Cost Engineering)는 프로젝트 관리의 초기 실무자들과 계획 및 스케줄링, 비용 추정 및 비용/스케줄 제어(프로젝트 제어)의 관련 전문 분야에 의해 설립되었습니다.AACE는 선구적인 작업을 계속하여 2006년에 포트폴리오, 프로그램 및 프로젝트 관리를 위한 최초의 통합 프로세스(Total Cost Management Framework)를 출시했습니다.

1969년 미국에 PMI(Project Management Institute)가 설립되었으며,[15] 1996년에는 William Duncan을 주 저자로 하여 PMI(Project Management Body of Knowledge)의 원본 A Guide(PMBOK Guide)를 발간하여 "대부분의 프로젝트"에 공통적인 프로젝트 관리 관행을 설명하고 있습니다.[16]

프로젝트관리종류

프로젝트 관리 방법은 모든 프로젝트에 적용할 수 있습니다.프로젝트 규모, 특성, 산업 또는 부문에 따라 특정 유형의 프로젝트에 맞추어 조정되는 경우가 많습니다.예를 들어, 건축물, 도로, 교량 등의 인도에 중점을 둔 건설업계는 건설 프로젝트 관리라고 지칭하고 프로젝트 관리자가 교육 및 인증을 받을 수 있는 고유한 프로젝트 관리 형태를 개발했습니다.[17]또한 IT 프로젝트 관리라고 불리는 자체 프로젝트 관리 형태를 개발하고 계획, 설계, 개발, 테스트 및 구축과 같은 다양한 라이프사이클 단계를 거쳐야 하는 기술 자산과 서비스를 전문적으로 제공하는 IT 프로젝트 관리 형태로 발전하고 있습니다.생명공학 프로젝트 관리는 생명공학 연구개발의 복잡성에 초점을 맞추고 있습니다.[18]현지화 프로젝트 관리에는 번역 작업에 많은 표준 프로젝트 관리 관행을 적용하는 것이 포함됩니다. 비록 많은 사람들이 이러한 유형의 관리를 매우 다른 분야라고 생각하지만 말입니다.정부의 모든 공공사업을 망라하는 공공사업관리가 있는데, 이는 정부기관이 수행하거나 시공사에 위탁할 수 있습니다.프로젝트 관리의 또 다른 분류는 하드(물리적) 또는 소프트(비물리적) 유형을 기준으로 합니다.

모든 프로젝트 관리 유형의 공통점은 시간, 품질 및 비용이라는 세 가지 중요한 목표에 중점을 둔다는 것입니다.성공적인 프로젝트는 예산 범위 내에서 예정대로, 그리고 이전에 합의된 품질 기준에 따라, 즉 프로젝트가 성공 또는 실패한 것으로 간주되기 위해 철의 삼각형 또는 삼중 제약 조건을 충족합니다.[19]

프로젝트 관리자는 프로젝트 관리의 각 유형에 대해 자신이 다루고 있는 산업에 특화된 반복 가능한 템플릿을 개발하고 사용합니다.이를 통해 프로젝트 계획이 매우 철저하고 반복 가능성이 높아지며 품질을 높이고 배송 비용을 절감하며 프로젝트 결과를 제공하는 시간을 단축할 수 있습니다.

프로젝트 관리 방법

2017년 연구에서는 프로젝트의 성공 여부는 프로젝트에 영향을 미치는 상황별 역학과 네 가지 주요 측면이 얼마나 잘 일치하는지에 달려 있다고 제안했습니다. 이를 네 가지 P라고 합니다.[20]

  • 계획 : 계획 및 예측 활동.
  • 프로세스:모든 활동과 프로젝트 거버넌스에 대한 전반적인 접근 방식.
  • 사람들: 그들이 어떻게 협력하고 소통하는지에 대한 역학을 포함합니다.
  • 권력: 권한, 의사 결정권자, 오르가노그램, 실행을 위한 정책 등.

프로젝트 활동을 구성하고 완료하는 데에는 단계적, 희박한, 반복적, 점진적 등 다양한 접근 방식이 있습니다.프로젝트 계획에는 결과(제품 기반) 또는 활동(프로세스 기반)을 기반으로 하는 등 여러 가지 확장 기능도 있습니다.

사용하는 방법론에 관계없이 프로젝트의 전반적인 목표, 일정, 비용 및 모든 참여자와 이해관계자의 역할과 책임을 신중하게 고려해야 합니다.[21]

복리후생 실현 관리

주요 기사:편익실현관리

BRM(Benefits Realization Management)은 제품이나 산출물보다는 프로젝트의 결과(Benefits)에 초점을 맞춘 다음, 프로젝트를 추적하기 위해 발생하는 정도를 측정함으로써 정상적인 프로젝트 관리 기술을 향상시킵니다.이를 통해 합의된 요구사항(산출물), 즉 프로젝트 성공은 제공하지만 이러한 요구사항의 이점(결과), 즉 제품 성공은 제공하지 못함으로써 완료된 프로젝트가 실패할 위험을 줄일 수 있습니다.양호한 요구사항 관리를 통해 이러한 이점을 프로젝트의 요구사항으로 파악할 수 있으며 프로젝트 전체에서 그 성과를 모니터링할 수 있습니다.

또한 BRM 실천은 프로젝트 결과와 비즈니스 전략 간의 전략적 정합성을 보장하는 것을 목표로 합니다.이러한 관행의 효과는 다양한 국가와 산업에 걸쳐 전략적 관점에서 프로젝트 성공에 영향을 미치는 BRM 관행을 입증하는 최근의 연구에 의해 뒷받침됩니다.이러한 광범위한 효과를 전략적 효과라고 합니다.[22]

요구 사항에 맞는 프로젝트를 제공하는 예로는 직원 데이터를 처리하고 급여, 휴일 및 직원 인사 기록을 보다 짧은 시간 내에 오류를 줄여 관리하는 컴퓨터 시스템을 제공하는 것에 동의하는 것을 들 수 있습니다.BRM 하에서는 시스템을 사용하지 않을 경우 시스템 설치 후 직원 데이터를 처리하고 유지하는 데 필요한 직원 시간과 오류를 명시적으로 줄이는 것이 합의가 될 수 있습니다.

임계경로법

본문 : 임계경로법

CPM(Critical Path Method)은 프로젝트 활동의 일정을 결정하는 알고리즘입니다.예측 기반 프로젝트 계획에 사용되는 전통적인 프로세스입니다.CPM 방법은 필요한 프로젝트 지속 기간을 결정하기 위해 활동 순서, 필요한 작업 노력, 상호 의존성 및 라인 시퀀스 당 결과 유동 시간을 평가합니다.따라서 중요한 경로는 사용 가능한 추가 시간이 없는(또는 추가 시간이 거의 없는) 네트워크 다이어그램 상의 작업 경로입니다."[23]

크리티컬 체인 프로젝트 관리

주요 기사 : 중요 체인 프로젝트 관리

Critical Chain Project Management(CCPM)는 프로젝트를 계획하고 관리하는 데 제약 이론(TOC)을 적용하는 것으로, 제한된 가용성(물리적, 인적 기술, 자원)을 고려하여 프로젝트를 관리하는 데 내재된 불확실성을 다루도록 설계되었습니다.프로젝트를 실행하는 데 필요한 관리 및 지원 능력).

목표는 조직에서 프로젝트의 흐름(throughput)을 늘리는 것입니다.TOC의 다섯 가지 중점 단계 중 처음 세 가지를 적용하여 모든 프로젝트에 대한 시스템 제약과 자원을 파악합니다.제약 조건을 이용하기 위해 중요한 체인의 작업이 다른 모든 작업보다 우선 순위를 부여됩니다.

근로가치관리

주요 기사 : 근로 가치 관리

EVM(Earned Value Management)은 프로젝트 모니터링을 개선하는 기술로 프로젝트 관리를 확장합니다.[24]작업 및 가치(비용) 측면에서 완성을 향한 프로젝트 진행 상황을 설명합니다.Earned Schedule은 EVM의 이론과 실천을 확장한 것입니다.

반복적이고 점진적인 프로젝트 관리

참고 항목:반복적이고 점진적인 발전

프로젝트 관리에 대한 중요한 연구에서 단계적 접근 방식은 대규모 및 다중 기업,[25] 정의되지 않거나 모호하거나 빠르게 변화하는 요구 사항이 있는 프로젝트 또는 [26]높은 위험, 종속성 및 빠르게 변화하는 기술을 가진 프로젝트에는 적합하지 않다고 지적했습니다.불확실성 원뿔은 프로젝트의 초기 단계에서 이루어지는 계획이 불확실성이 높기 때문에 이 중 일부를 설명합니다.소프트웨어 개발은 종종 새로운 제품이나 새로운 제품을 실현하기 때문에 더욱 그렇습니다.

이러한 복잡성은 보다 탐색적이거나 반복적이고 점진적인 접근 방식을 통해 보다 효과적으로 처리됩니다.[27]민첩한 프로젝트 관리, 동적 시스템 개발 방법, 극한 프로젝트 관리, Innovation Engineering® 등 여러 반복적이고 점진적인 프로젝트 관리 모델이 발전해 왔습니다.

희박한 프로젝트 관리

주요 기사 : 린 프로젝트 관리

린 프로젝트 관리는 린 제조의 원칙을 사용하여 낭비를 줄이고 시간을 단축하면서 가치를 제공하는 데 집중합니다.

프로젝트 라이프사이클

프로젝트 수명 주기에는 프로세스 그룹이라고 하는 다섯 단계가 있습니다.각 프로세스 그룹은 완료해야 할 일련의 개별 단계를 통해 작업을 관리하는 일련의 상호 관련 프로세스를 나타냅니다.이러한 유형의 프로젝트 접근 방식을 "전통적"[29] 또는 "물벼락"이라고도 합니다.[30]5개의 공정 그룹은 다음과 같습니다.

엔지니어링 프로젝트의 일반적인 개발 단계
  1. 시작하기
  2. 계획.
  3. 실행중
  4. 모니터링 및 제어
  5. 클로징

일부 산업에서는 이러한 프로젝트 단계의 변형을 사용하여 조직에 더 적합하도록 이름을 변경할 수도 있습니다.예를 들어, 벽돌과 모르타르의 설계와 시공을 할 때, 프로젝트는 일반적으로 사전 계획, 개념 설계, 도식 설계, 설계 개발, 시공 도면(또는 계약 문서), 시공 관리 등의 단계를 거쳐 진행됩니다.

단계적 접근 방식은 소규모의 잘 정의된 프로젝트에서는 잘 작동하지만, 규모가 큰 프로젝트에서는 도전이나 실패로 이어지는 경우가 많거나, 복잡하거나 모호성, 문제 및 위험이[31] 더 큰 프로젝트에서는 '큰 프로젝트의 6단계' 패러디를 참조하십시오.

프로세스 기반 관리

주요 기사 : 프로세스 기반 관리

프로세스 기반 관리의 통합은 OPM3 및 CMMI(capability matness model integration; 이미지 참조:공정 능력 성숙도 모형.jpg

프로젝트생산관리

주요 기사:프로젝트생산관리

프로젝트 생산 관리는 자본 프로젝트의 전달에 운영 관리를 적용하는 것입니다.프로젝트 생산 관리 프레임워크는 프로젝트가 투입물(원료, 정보, 노동력, 플랜트 및 기계)을 산출물(상품 및 서비스)로 변환하는 생산 시스템 관점으로서의 프로젝트를 기반으로 합니다.[32]

제품기반기획

주요 기사 : 상품 중심 기획

제품 기반 계획은 프로젝트 목표 달성에 기여하는 모든 제품(프로젝트 성과물)을 식별하는 것을 기반으로 프로젝트 관리에 대한 구조화된 접근 방식입니다.따라서 성공적인 프로젝트를 활동이나 작업 중심이 아닌 산출 중심으로 정의합니다.[33]이 접근 방식의 가장 일반적인 구현은 PRINCE2입니다.[34]

공정그룹

프로젝트 개발 단계[35]

전통적으로, 프로젝트 관리는 (어떤 프로젝트 관리 방법론을 사용하는지에 따라) 4~5개의 프로젝트 관리 프로세스 그룹, 그리고 통제 시스템 등의 다양한 요소를 포함합니다.사용하는 방법론이나 용어에 관계없이 기본적인 프로젝트 관리 프로세스나 개발 단계는 동일하게 사용됩니다.주요 공정 그룹은 일반적으로 다음과 같습니다.[36]

  • 시작
  • 계획.
  • 생산 또는 실행
  • 모니터링 및 제어
  • 클로징

중요한 탐색적 요소가 있는 프로젝트 환경(예: 연구 개발)에서 이러한 단계는 프로젝트의 지속성을 논의하고 결정하는 의사결정 지점(Go/No Go 결정)으로 보완될 수 있습니다.한 예로 위상-게이트 모형이 있습니다.

시작하기

프로세스 그룹 프로세스[35] 시작

시작 과정에 따라 프로젝트의 성격과 범위가 결정됩니다.[37]만약 이 단계가 잘 수행되지 않는다면, 이 프로젝트는 비즈니스의 요구를 충족시키는 데 성공할 수 없을 것입니다.여기서 필요한 핵심 프로젝트 제어는 비즈니스 환경을 이해하고 필요한 모든 제어를 프로젝트에 통합하는 것입니다.부족한 점은 보고하고 이를 해결하기 위한 권고를 해야 합니다.

개시 단계는 다음과 같은 영역을 포괄하는 계획을 포함해야 합니다.이러한 영역은 프로젝트 개시 문서라고 불리는 일련의 문서에 기록될 수 있습니다.프로젝트 시작 문서는 프로젝트 기간 동안 주문을 작성하는 데 사용되는 일련의 계획 문서입니다.다음과 같은 경향이 있습니다.

계획.

시작 단계 이후, 프로젝트는 적절한 수준의 세부 사항으로 계획됩니다(흐름도의 예 참조).[35]주요 목적은 시간, 비용 및 자원을 적절히 계획하여 필요한 작업을 추정하고 프로젝트 수행 중에 리스크를 효과적으로 관리하는 것입니다.시작 프로세스 그룹과 마찬가지로 계획을 적절하게 수립하지 못하면 프로젝트가 성공적으로 목표를 달성할 가능성이 크게 줄어듭니다.

프로젝트 계획은 일반적으로 다음과[38] 같이 구성됩니다.

  • 프로젝트 관리 방법론에 따라 결정(예: 계획이 전면적으로 선행, 반복적으로 정의될 것인지 아니면 물결이 일 때 정의될 것인지).
  • 범위 설명문 개발;
  • 기획팀 선정;
  • 산출물을 식별하고 제품 및 작업 내역 구조를 작성합니다.
  • 산출물을 완성하는 데 필요한 활동을 식별하고 논리적 순서에 따라 활동을 네트워킹합니다.
  • 활동에 필요한 자원 요건 추정.
  • 활동에 소요되는 시간과 비용의 추정
  • 일정 개발;
  • 예산 개발;
  • 리스크 계획.
  • 품질 보증 조치 개발.
  • 일을 시작하기 위해 정식 승인을 얻는 것.

커뮤니케이션 계획 및 범위 관리, 역할 및 책임 파악, 프로젝트를 위해 무엇을 구입할지 결정하고 킥오프 회의를 개최하는 등의 추가 프로세스도 일반적으로 권장됩니다.

신제품 개발 프로젝트의 경우, 프로젝트 기획 활동과 병행하여 최종 제품 운영에 대한 개념 설계를 수행할 수 있으며, 산출물 및 기획 활동을 파악할 때 기획팀에 알리는 데 도움이 될 수 있습니다.

실행중

프로세스 그룹 프로세스[35] 실행

실행하는 동안 실행해야 할 계획된 용어가 무엇인지 알아야 합니다.실행/실행 단계에서는 프로젝트 관리 계획의 성과물이 그에 따라 실행되도록 보장합니다.이 단계에서는 인력과 재료 및 예산과 같은 기타 자원의 적절한 할당, 조정 및 관리가 포함됩니다.이 단계의 산출물은 프로젝트 성과물입니다.

프로젝트문서

프로젝트 내의 모든 것을 문서화하는 것이 성공의 열쇠입니다.예산, 범위, 효과성 및 속도를 유지하려면 프로젝트에 각 특정 작업과 관련된 물리적 문서가 있어야 합니다.정확한 문서화를 통해 프로젝트의 요구사항이 충족되었는지 여부를 쉽게 확인할 수 있습니다.이와 함께 문서화는 해당 프로젝트에 대해 이미 완료된 내용에 대한 정보를 제공합니다.프로젝트 전반에 걸친 문서화는 과거로 돌아가서 작업을 참조해야 하는 모든 사람에게 종이 흔적을 제공합니다.대부분의 경우 문서화는 프로젝트의 특정 단계를 모니터링하고 제어하는 가장 성공적인 방법입니다.정확한 문서를 통해 프로젝트의 성공을 추적하고 프로젝트가 진행됨에 따라 관찰할 수 있습니다.올바르게 수행된 경우 문서화는 프로젝트 성공의 중추가 될 수 있습니다.

모니터링 및 제어

프로세스 그룹 프로세스[35] 모니터링 및 제어

모니터링 및 제어는 프로젝트 수행을 관찰하기 위해 수행되는 프로세스로 구성되어 있으며, 이를 통해 잠재적인 문제를 적시에 파악하고 필요한 경우 프로젝트 수행을 제어하기 위해 시정 조치를 취할 수 있습니다.주요 이점은 프로젝트 성과를 정기적으로 관찰하고 측정하여 프로젝트 관리 계획과 차이를 파악한다는 것입니다.

모니터링 및 제어에는 다음이 포함됩니다.[39]

  • 진행 중인 프로젝트 활동 측정('were we are')
  • 프로젝트 관리 계획 및 프로젝트 성과 기준선(우리가 있어야 할 곳)과 비교하여 프로젝트 변수(비용, 노력, 범위 등) 모니터링
  • 문제 및 위험을 적절히 해결하기 위한 시정 조치 확인 (어떻게 하면 다시 정상 궤도에 오를 수 있을까)
  • 승인된 변경 사항만 실행되도록 통합 변경 관리를 회피할 수 있는 요소에 영향을 미칩니다.

두 가지 주요 메커니즘은 프로젝트에서 모니터링 및 통제를 지원합니다.한편으로 계약은 일련의 규칙과 인센티브를 제공하는데, 이는 종종 잠재적인 벌칙과 제재에 의해 뒷받침됩니다.[40]한편, 경영학자들은 프로젝트의 목적을 달성하기 위한 통합자(프로젝트 남작이라고도 함)[41][42]의 역할에 주목해 왔습니다.한편, 최근의 프로젝트 관리 연구는 계약과 통합자 간의 상호작용의 유형에 대해 의문을 제기하고 있습니다.어떤 사람들은 한 조직 유형이 다른 조직을 사용하는 장점을 감소시키기 때문에 이 두 가지 모니터링 메커니즘이 대체 기능으로[43] 작동한다고 주장합니다.

다단계 프로젝트에서 모니터링 및 통제 프로세스는 프로젝트 단계 간에 피드백을 제공하여 프로젝트가 프로젝트 관리 계획을 준수할 수 있도록 시정 또는 예방 조치를 시행합니다.

프로젝트 유지보수는 지속적인 프로세스이며 다음과 같은 내용을 포함합니다.[36]

  • 최종 사용자에 대한 지속적인 지원
  • 오류수정
  • 시간 경과에 따른 제품 업데이트
모니터링 및 제어주기

이 단계에서 감사인은 사용자 문제가 얼마나 효과적이고 신속하게 해결되는지에 주목해야 합니다.

건설 프로젝트의 진행에 따라 작업 범위가 변경될 수 있습니다.변화는 건설 프로세스의 정상적이고 예상되는 부분입니다.변경은 필요한 설계 수정, 다양한 현장 조건, 자재 가용성, 계약자 요청 변경, 가치 엔지니어링, 제3자의 영향 등의 결과로 이루어질 수 있습니다.필드에서 변경사항을 실행하는 것 외에, 변경사항은 일반적으로 실제 구성된 내용을 표시하기 위해 문서화되어야 합니다.이를 변경 관리라고 합니다.따라서 소유자는 일반적으로 모든 변경 사항 또는 더 구체적으로 완성된 작업의 유형적인 부분을 수정하는 변경 사항을 표시하기 위해 최종 기록을 요구합니다.이 기록은 계약 문서에 작성되는데, 일반적으로 반드시 이에 국한되는 것은 아닙니다.이러한 노력의 최종 산출물은 업계에서 애즈-빌트 도면, 더 간단히 "애즈-빌트(As-Built) 도면"이라고 부르는 것입니다.그들을 제공하기 위한 요건은 건설 계약에서 기본입니다.건설 문서 관리는 온라인 또는 데스크톱 소프트웨어 시스템의 도움으로 수행되거나 물리적 문서화를 통해 유지되는 매우 중요한 작업입니다.건설업계의 올바른 문서 유지와 관련된 합법성의 증가는 문서 관리 시스템의 필요성을 증가시켰습니다.

프로젝트에 변경 사항이 도입되면 프로젝트의 실행 가능성을 다시 평가해야 합니다.프로젝트의 초기 목표와 목표를 놓치지 않는 것이 중요합니다.변화가 누적되면, 예측된 결과가 프로젝트에 대한 원래의 제안된 투자를 정당화하지 못할 수 있습니다.성공적인 프로젝트 관리는 이러한 구성 요소를 식별하고 진행 상황을 추적 및 모니터링하여 프로젝트 시작 시 이미 설명된 시간과 예산 범위 내에서 유지합니다.정확한 방법은 프로젝트의 진행 상황과 예상 기간과 관련하여 프로젝트 수명 주기에 따라 가장 유용한 모니터링 지점을 식별하기 위해 제안되었습니다.[44]

클로징

프로세스그룹프로세스를마감하고있습니다.[35]

종결에는 프로젝트의 공식적인 수락과 종료가 포함됩니다.관리 활동에는 파일을 보관하고 배운 내용을 문서화하는 것이 포함됩니다.

이 단계는 다음과 같이 구성됩니다.[36]

  • 계약 종료:각 계약을 완료하고 정산하며(공개된 항목에 대한 해결 포함), 프로젝트 또는 프로젝트 단계에 적용되는 각 계약을 종료합니다.
  • 프로젝트 마감:프로젝트 또는 프로젝트 단계를 공식적으로 종료하기 위해 모든 프로세스 그룹에 걸친 모든 활동을 마무리합니다.

또한 구현 후 검토도 이 단계에 포함됩니다.이것은 프로젝트 팀이 경험을 통해 배우고 향후 프로젝트에 적용하기 위한 프로젝트의 중요한 단계입니다.일반적으로 실행 후 검토는 잘 된 것을 살펴보고 프로젝트에서 잘 되지 않은 것을 분석하여 교훈을 도출하는 것으로 구성됩니다.

프로젝트 관리 및 프로젝트 관리 시스템

프로젝트 관리에서 프로젝트 관리(Cost Engineering)는 독립적인 기능으로 설정되어야 합니다.확정된 성과 및 형식적 목표를 강화하기 위한 프로젝트 진행 중 검증 및 제어 기능을 구현합니다.[45]프로젝트 관리 업무도 다음과 같습니다.

  • 올바른 정보의 공급과 그 갱신을 위한 기반시설의
  • 프로젝트 파라미터의 차이를 전달하는 방법의 확립
  • 인트라넷 기반의 프로젝트 정보 기술 개발 또는 프로젝트 핵심 성과 지표 시스템(KPI) 결정
  • 잠재적인 프로젝트 규제에[46] 대한 발산 분석 및 제안 생성
  • 적절한 프로젝트 구조, 프로젝트 워크플로우 조직, 프로젝트 관리 및 거버넌스를 달성하기 위한 방법 수립
  • 프로젝트 매개변수[47] 간 투명도 생성

프로젝트 관리의 구체적인 방법과 도구를 적용함으로써 이러한 작업의 수행과 실행을 달성할 수 있습니다.다음과 같은 프로젝트 제어 방법을 적용할 수 있습니다.

  • 투자 분석
  • 비용-편익 분석
  • 가치편익분석
  • 전문가 조사
  • 모의 계산
  • 리스크 프로파일 분석
  • 할증료 계산
  • 마일스톤 추세 분석
  • 원가동향분석
  • 대상/ actual 비교

프로젝트 제어는 프로젝트를 제 시간에 맞춰 예산 내에서 정상적으로 유지하는 요소입니다.[39]프로젝트 관리는 프로젝트 초기에 계획과 함께 시작되고 프로젝트 후반에 실행 후 검토와 함께 종료되며 각 단계를 프로세스에 철저하게 참여합니다.프로젝트가 진행되는 동안 프로젝트를 감사하거나 검토할 수 있습니다.공식 감사는 일반적으로 리스크 또는 컴플라이언스 기반이며 경영진이 감사의 목표를 지시합니다.승인된 프로젝트 관리 프로세스와 프로젝트가 실제로 어떻게 관리되고 있는지를 비교하는 것이 심사에 포함될 수 있습니다.[49]각 프로젝트는 필요한 적절한 수준의 관리를 평가해야 합니다. 너무 많은 관리는 시간이 많이 걸리고 너무 적은 관리는 매우 위험합니다.프로젝트 관리가 제대로 이루어지지 않을 경우, 오류 및 수정 측면에서 비즈니스에 미치는 비용을 명확히 해야 합니다.

비용, 리스크, 품질, 커뮤니케이션, 시간, 변경, 조달, 인력 등에 대한 통제 시스템이 필요합니다.또한 감사인은 프로젝트가 재무제표에 얼마나 중요한지, 이해관계자가 통제에 얼마나 의존하는지, 통제가 얼마나 많이 존재하는지를 고려해야 합니다.감사인은 개발 과정과 절차를 검토하여 구현 방법을 검토해야 합니다.개발 과정과 최종 제품의 품질 또한 필요하거나 요청할 경우 평가할 수 있습니다.기업은 보다 쉽게 문제를 해결할 수 있도록 프로세스 전반에 걸쳐 감사 회사가 참여하기를 원할 수 있습니다.감사인은 개발팀의 일원으로서 통제 컨설턴트로 활동할 수도 있고, 감사의 일부로서 독립 감사인으로 활동할 수도 있습니다.

기업은 때때로 공식적인 시스템 개발 프로세스를 사용합니다.이를 통해 시스템이 성공적으로 개발될 수 있습니다.공식적인 프로세스는 강력한 통제장치를 만드는 데 더 효과적이며, 감사인은 이 프로세스가 잘 설계되어 있고 실제적으로 준수되고 있는지 확인하기 위해 이 프로세스를 검토해야 합니다.좋은 공식적인 시스템 개발 계획은 다음과 같은 것입니다.

  • 개발을 조직의 광범위한 목표와 일치시키는 전략
  • 신시스템 표준
  • 시기 및 예산 편성을 위한 프로젝트 관리 정책
  • 프로세스를 설명하는 절차
  • 변화품질평가

프로젝트의 특성

프로젝트에는 다섯 가지 중요한 특성이 있습니다.

(i) 항상 특정한 시작일과 종료일이 있어야 합니다.

(ii) 한 무리의 사람들에 의해 공연되고 완성됩니다.

(iii) 산출물은 고유한 제품 또는 서비스를 제공하는 것입니다.

(iv) 그들은 본질적으로 일시적입니다.

(v) 그것은 점진적으로 정교화되어 있습니다.

예를 들면, 새 차를 디자인하거나 책을 쓰는 것입니다.

프로젝트복잡도

주요 기사:프로젝트복잡도

복잡성과 그 특성은 프로젝트 관리 영역에서 중요한 역할을 합니다.이 주제에 대해 많은 논의가 있었음에도 불구하고, 연구들은 복잡한 프로젝트의 관리와 관련하여 복잡성에 대한 정의와 합리적인 이해가 부족함을 시사합니다.[50][51]

프로젝트 복잡성은 프로젝트 시스템에 대해 상당히 완전한 정보가 주어져도 전체적인 행동을 이해하고 예측하며 통제하기 어려운 프로젝트의 속성입니다.[52]

복잡한 프로젝트의 식별은 다중 프로젝트 엔지니어링 환경에서 특히 중요합니다.[53]

사업의 복잡성과 사업성과는 밀접한 관계가 있다고 판단되므로, 사업관리가 효과적으로 이루어지기 위해서는 사업의 복잡성을 정의하고 측정하는 것이 중요합니다.[54]

복잡성은 다음과 같습니다.

  • 구조적 복잡성(세부적 복잡성 또는 복잡성이라고도 함), 즉 여러 가지 다양한 상호 관련된 부분으로 구성됩니다.[55]일반적으로 프로젝트 구성요소의 규모, 다양성, 상호의존성으로 표현되며, 기술적 요소와 조직적 요소로 설명됩니다.
  • 동태적 복잡성은 모호성, 불확실성, 전파, 출현, 혼돈 등의 현상, 특성, 발현을 말합니다.[52]

Cynefin 프레임워크를 기반으로 복잡한 프로젝트를 다음과 같이 분류할 수 있습니다.[56]

Cynefin 프레임워크를 기반으로 한 단순하고 복잡하며 매우 복잡한 프로젝트.
  • 단순한(또는 명확한, 명백한, 알려진) 프로젝트, 시스템 또는 컨텍스트.이들은 알려진 것, 안정성 및 명확한 인과관계를 특징으로 합니다.표준 운영 절차와 모범 사례로 해결할 수 있습니다.
  • 복잡함: 알려지지 않은 것을 특징으로 합니다.복잡한 시스템은 부품의 총합입니다.원칙적으로, 그것은 더 작은 단순한 구성요소로 분해될 수 있습니다.어렵고 복잡한 문제는 이론적으로 추가 리소스, 전문적인 전문 지식, 분석, 축소론자, 단순화, 분해 기술, 시나리오 계획 및 모범 사례를 통해 해결할 수 있습니다.[57][58]
  • 복잡성은 알려지지 않은 미지와 출현으로 특징지어집니다.패턴은 밝혀질 수 있지만, 명확하지는 않습니다.복잡한 계는 전체가 부분의 합 이상이라는 유클리드의 진술로 설명될 수 있습니다.
  • 매우 복잡한 프로젝트, 일명 매우 복잡하거나 혼란스러운: 알 수 없는 것이 특징입니다.정말 복잡한 프로젝트에서는 어떤 패턴도 식별할 수 없습니다.돌이켜봐도 원인과 결과가 불분명합니다.아리스토텔레스를 의역하면, 정말 복잡한 체계는 그 부분들의 합과는 다릅니다.[59]

Elliott Jaques는 Requisite Organization and Stratified Systems Theory에 설명된 작업 복잡도 측정에 발견된 것을 적용하여 프로젝트와 프로젝트 작업(단계, 작업)을 프로젝트 산출물의 시간-기간 및 복잡성과 같은 기준에 따라 프로젝트 복잡도의 7가지 기본 수준으로 분류합니다.[60][61]

  • 레벨 1 프로젝트 – 비즈니스 프로세스 내에서 활동(수량, 품질, 시간)의 직접 산출량을 최대 3개월까지 개선합니다.
  • 레벨 2 프로젝트 – 목표 완료 기간이 3개월에서 1년인 비즈니스 프로세스에 대한 컴플라이언스를 개발하고 개선합니다.
  • 레벨 3 프로젝트 – 비즈니스 프로세스를 개발, 변경 및 개선하고 목표 완료 기간은 1~2년입니다.
  • 레벨 4 프로젝트 – 목표 완료 기간이 2~5년인 기능 시스템을 개발, 변경 및 개선합니다.
  • 레벨 5 프로젝트 – 목표 완료 기간이 5~10년인 기능 시스템/비즈니스 기능 그룹을 개발, 변경 및 개선합니다.
  • 레벨 6 프로젝트 – 목표 완료 기간이 10년에서 20년인 기업의 전체 단일 가치 사슬을 개발, 변경 및 개선합니다.
  • 레벨 7 프로젝트 – 목표 완료 기간이 20년에서 50년인 기업의 여러 가치 사슬을 개발, 변경 및 개선합니다.[62]

프로젝트 복잡성 측정의 이점은 프로젝트의 복잡성 수준과 효과적인 목표 완료 시간을 프로젝트 관리자 및 프로젝트 구성원의 각 역량 수준과 일치시킴으로써 프로젝트 인력의 실현 가능성을 향상시키는 것입니다.[63]

긍정적, 적절한(필수적), 부정적 복잡성

Stefan Morcov가 제안한 Positive, Opitive, Negative complexity 모델

필요 다양성의 법칙 및 필요 복잡성의 법칙과 마찬가지로 프로젝트가 목적에 도달하기 위해서는 프로젝트의 복잡성이 필요할 때도 있고 유익한 결과를 가져올 때도 있습니다.Stefan Morcov는 복잡성의 영향을 바탕으로 Positive(긍정적), 적정(적절) 또는 Negative(부정적)으로 분류할 것을 제안했습니다.[64][59]

  • 긍정적인 복잡성은 프로젝트에 가치를 더하는 복잡성이며, 프로젝트 성공에 대한 기여도가 관련된 부정적인 결과보다 더 큽니다.
  • 적절한(또는 필수적인) 복잡성은 프로젝트가 목표를 달성하는 데 필요한 복잡성이거나, 프로젝트 성공에 대한 기여도가 부정적인 영향의 균형을 맞추거나, 완화 비용이 부정적인 표현을 능가하는 복잡성입니다.
  • 부정적인 복잡성은 프로젝트의 성공을 방해하는 복잡성입니다.

프로젝트매니저

주요 기사:프로젝트매니저

프로젝트 매니저는 프로젝트 관리 분야의 전문가입니다.프로젝트 관리자는 프로젝트에 참여하는 사람들을 담당합니다.성공적인 프로젝트는 사람이 관건입니다.적재적소에 적재적소에 적재적소에 적재적소에 적재적소에 적재적소에 적재적소에 적재적소에 적재적소에 적재적소에 적재적소에 적재프로젝트 관리자는 일반적으로 건설 산업, 엔지니어링, 건축, 컴퓨팅 및 통신과 관련된 모든 프로젝트의 계획, 실행, 제어 및 종결을 담당할 수 있습니다.생산 공학, 디자인 공학 그리고 중공업의 많은 다른 분야들은 프로젝트 관리자들을 가지고 있습니다.

프로젝트 관리자는 프로젝트의 수행 순서와 프로젝트 내의 각 개별 작업을 수행하는 데 필요한 시간을 이해해야 합니다.프로젝트 관리자는 고객을 대신하여 명시된 프로젝트 목표를 달성할 책임이 있는 사람입니다.프로젝트 관리자는 자신의 분야에서 다년간의 경험을 가지고 있는 경향이 있습니다.프로젝트 관리자는 프로젝트와 함께 작업자를 감독하면서 프로젝트 안팎을 알아야 합니다.일반적으로 대부분의 건설, 엔지니어링, 건축 및 산업 프로젝트에서 프로젝트 관리자는 다른 관리자와 함께 작업을 매일 수행합니다.이 직책은 경우에 따라 교육감으로 알려지기도 합니다.교육감과 사업담당자가 협력하여 일상적인 사업과제를 수행합니다.프로젝트 관리의 주요 책임은 명확하고 달성 가능한 프로젝트 목표를 수립하고, 프로젝트 요구 사항을 수립하며, 프로젝트에 대한 트리플 제약(이제 더 많은 제약 조건을 포함하여 경쟁 제약 조건이라고 부름)을 관리하는 것입니다. 비용, 시간,현재 프로젝트 관리에서 처음 3개의 품질과 범위를 제외하고 약 3개의 추가 항목을 포함합니다.일반적인 프로젝트는 시간과 예산 목표 내에 과제를 완료하기 위해 프로젝트 관리자 아래에서 작업하는 작업자 팀으로 구성됩니다.프로젝트 관리자는 일반적으로 프로젝트의 완성과 성공에 대해 높은 지위에 있는 사람에게 직접 보고합니다.

프로젝트 매니저는 종종 고객의 대표이며, 고객이 대표하는 회사에 대한 지식을 바탕으로 고객의 정확한 요구를 결정하고 실행해야 합니다.계약 당사자의 다양한 내부 절차에 적응하고 지명된 대표자들과 긴밀한 관계를 형성할 수 있는 능력은 비용, 시간, 품질 및 무엇보다 고객 만족이라는 핵심 문제를 실현할 수 있도록 보장하는 데 필수적입니다.

Randall L. Englund와 Alfonso Bucero는 그의 시뮬레이션에서 Robert J. Graham이 처음 만든 용어인 완전한 프로젝트 매니저를 확장했습니다.그들은 완벽한 프로젝트 매니저를 리더십, 영향력, 협상, 정치, 변화와 갈등 관리, 유머 등 다양한 분야를 포용하는 사람으로 묘사합니다.이들은 모두 프로젝트 리더가 보다 효과적이고 최적화되고 일관된 결과를 얻을 수 있도록 지원하는 "소프트" 인력 기술입니다.

다단계 성공 프레임워크 및 기준 - 프로젝트 성공 대 프로젝트 성과

프로젝트 성공과 프로젝트 관리 성공을 혼동하는 경향이 있습니다.그것들은 서로 다른 두 가지입니다."프로젝트 성공"에는 두 가지 관점이 있습니다.

  • 프로세스의 관점, 즉 효율적인 산출물을 제공하는 것. 일반적으로 프로젝트 관리 성과 또는 프로젝트 효율성이라고 불립니다.
  • 결과의 관점, 즉 유익한 결과를 제공하는 것. 일반적으로 프로젝트 성과(때로는 프로젝트 성공)라고 불립니다.[65][66][67][self-published source?]

프로젝트 관리 성공 기준이 프로젝트 성공 기준과 다릅니다.주어진 프로젝트를 합의된 시간 내에 완료하고, 합의된 범위를 충족하며, 합의된 예산 내에 완료하면 프로젝트 관리가 성공적이라고 합니다.3중 제약 이후 프로젝트 성공을 보장하기 위해 여러 제약 조건을 고려해 왔습니다.그러나 3중 또는 다중 제약 조건은 프로젝트의 효율성 측정만을 의미하며, 이는 실제로 프로젝트 라이프사이클 동안 프로젝트 관리 성공 기준이 됩니다.

우선순위 기준은 제품 수명 주기 동안의 산출물(제품) 성공, 결과(혜택) 성공, 영향(전략) 성공 등 네 가지 수준으로 구성되는 프로젝트의 완료 후 더 중요한 결과를 제외합니다.이러한 사후 성공 기준은 프로젝트 완료 및 인계 후 프로젝트 제품, 서비스 또는 결과의 유효성 측정을 나타냅니다.프로젝트, 프로그램 및 포트폴리오의 이와 같은 중대한 다단계 성공 프레임워크는 2008년 Paul Bannerman이 개발하였습니다.[68]즉, 개발 단계를 시작하기 전에 프로젝트 시작 및 선택 과정에서 명확하게 파악하고 정의해야 하는 예상 비즈니스 사례를 달성할 때 프로젝트가 성공적이라고 합니다.이러한 다단계 성공 프레임워크는 의도한 값을 생성하기 위해 투입-프로세스/활동-산출-결과-효과로 묘사되는 변환으로서 프로젝트 이론에 부합합니다.2011년의 Emanuel Camilleri는 비즈니스 가치를 제공하기 위해 모든 중요한 성공 및 실패 요인을 그룹으로 분류하고 각 그룹을 다단계 성공 기준과 일치시킵니다.[69]

프로젝트 관리와 관련하여 사용되는 성과 지표의 예로는 "커미션된 프로젝트의 백로그" 또는 "프로젝트 백로그"가 있습니다.[70]

리스크관리

주요 기사:프로젝트리스크관리

미국 국방부는 국방부 인수 전문가들이 트레이드오프를 만들고 프로그램 상태를 추적하는 4가지 요소로 '비용, 일정, 성과, 위험'을 꼽고 있습니다.[71]국제적인 기준도 있습니다.리스크 관리는 미래의 문제를 사전에 파악하고 그 결과를 이해함으로써 프로젝트에 대한 예측적 의사결정을 가능하게 합니다.ERM 시스템은 전반적인 리스크 관리 역할을 수행합니다.[72]

작업붕괴구조 및 기타붕괴구조

주요 기사:작업구분구조 및 범위(프로젝트관리)

WBS(Work Breakdown Structure)는 목표(예: 포트폴리오, 프로그램, 프로젝트 및 계약)를 달성하는 데 필요한 활동을 세분화하여 보여주는 트리 구조입니다.WBS는 하드웨어, 제품, 서비스 또는 프로세스 중심일 수 있습니다(NASA 보고 구조(2001)).[73]프로젝트 범위 관리를 위한 WBS 이외에도 조직 분해 구조(차트), 비용 분해 구조, 리스크 분해 구조 등이 있습니다.

WBS는 최종 목표에서 시작하여 목표 달성에 필요한 모든 단계를 포함하는 크기, 지속 기간 및 책임(예: 시스템, 서브시스템, 구성요소, 태스크, 하위 태스크 및 작업 패키지) 측면에서 관리 가능한 구성요소로 순차적으로 세분화하여 개발할 수 있습니다.[31]

작업 내역 구조는 계약의 전반적인 계획 및 통제의 자연스러운 발전을 위한 공통적인 틀을 제공하며 작업 내역서를 개발하고 기술, 일정, 비용 및 노동 시간 보고를 수립할 수 있는 명확한 증분으로 작업을 나누는 기반이 됩니다.[73]작업 내역 구조는 작업을 세분화한 표 또는 가장 낮은 노드를 "작업 패키지"라고 하는 조직도와 같이 두 가지 형태로 표시할 수 있습니다.

계획의 품질을 평가할 때 필수적인 요소이며, 프로젝트 계획 중에 사용되는 초기 요소입니다.예를 들어 프로젝트가 예약될 때 WBS가 사용되므로 작업 패키지의 사용을 기록하고 추적할 수 있습니다.

업무 파괴 구조(WBS)와 유사하게, 다른 분해 기술 및 도구는 조직 파괴 구조(OBS), 제품 파괴 구조(PBS), 비용 파괴 구조(CBS), 위험 파괴 구조(RBS) 및 자원 파괴 구조(ResBS)입니다.[74][59]

국제표준

프로젝트 관리 표준에는 다음과 같은 여러 가지가 있습니다.

  • ISO 표준 ISO 9000, 품질 관리 시스템 표준 계열, ISO 10006:2003, 프로젝트 품질 관리 시스템 및 지침.
  • ISO 21500:2012 – 프로젝트 관리에 대한 지침.ISO에서 발표한 프로젝트 관리 관련 최초의 국제표준입니다.21503:2017 프로그램 관리 지침; 21504:2015 포트폴리오 관리 지침; 21505:2017 거버넌스 지침; 21506:2018 어휘; 21508:2018 프로젝트 및 프로그램 관리의 근로 가치 관리; 21511:2018 프로젝트 및 프로그램 관리의 작업 내역 구조.
  • ISO 21502:2020 프로젝트, 프로그램 및 포트폴리오 관리 — 프로젝트 관리에 대한 지침
  • ISO 21503:2022 프로젝트, 프로그램 및 포트폴리오 관리 — 프로그램 관리 지침
  • ISO 21504:2015 프로젝트, 프로그램 및 포트폴리오 관리 – 포트폴리오 관리 지침
  • ISO 21505:2017 프로젝트, 프로그램 및 포트폴리오 관리 - 거버넌스에 관한 지침
  • ISO 31000:2009 – 리스크 관리.
  • ISO/IEC/IEEE 16326:2009 – 시스템 및 소프트웨어 엔지니어링—라이프 사이클 프로세스—프로젝트 관리[75]
  • 국제 프로젝트 관리 협회(IPMA)의 ICB(개별 역량 기준).[76]
  • 소프트웨어 엔지니어링 연구소의 CMM(Capability Matility Model).
  • GAPPS, Global Alliance for Project Performance Standards – 프로젝트 및 프로그램 관리자를 위한 역량을 설명하는 오픈 소스 표준.
  • 룩셈부르크 및 국제기구에서 사용하기 위해 선정된 HERMS 방법, 스위스 일반 프로젝트 관리 방법
  • 국제개발기구에서 많이 사용되는 논리적 프레임워크 접근법(LFA).
  • PMI(Project Management Institute) PMBOK 가이드
  • AXELOS의 PRINCE2.
  • PM²: [유럽연합 집행위원회]가 개발한 프로젝트 관리 방법론.[77]
  • 인도 국방부의 프로젝트 공식화 및 관리 절차
  • 소프트웨어 엔지니어링 연구소의 TSP(Team Software Process).
  • Total Cost Management Framework, AACE International의 통합 포트폴리오, 프로그램 및 프로젝트 관리 방법론.
  • V-Model, 독창적인 시스템 개발 방법

프로그램 관리 및 프로젝트 네트워크

주요 기사 : 프로그램 관리

일부 프로젝트는 프로그램 관리로 관리할 수 있습니다.프로그램은 공통된 목표와 목표 집합을 지원하는 프로젝트 모음입니다.개별 프로젝트에는 명확하고 구체적인 범위와 일정이 정의되어 있지만 프로그램의 목표와 기간은 보다 세분화된 수준으로 정의됩니다.

프로그램과 포트폴리오 외에, 서로 다른 특성을 결합하는 추가적인 구조는 프로젝트 네트워크, 메가 프로젝트 또는 메가 프로그램입니다.

프로젝트 네트워크는 조직의 경계를 넘나드는 몇 가지 다른 진화 단계로 이루어진 일시적인 프로젝트입니다.메가 프로젝트와 메가 프로그램은 규모, 비용, 대중 및 정치적 관심, 필요한 역량 등에서 예외적으로 정의됩니다.[59]

프로젝트 포트폴리오 관리

주요 기사:프로젝트 포트폴리오 관리

점점 더 많은 조직이 적합한 프로젝트를 선택하는 수단으로 프로젝트 포트폴리오 관리(PPM)라고 불리는 것을 사용하고 있으며, 그 후 프로젝트 관리 기법을[79] 수행하는 공공, 민간 또는 비영리 조직에 혜택을 제공하는 수단으로 사용하고 있습니다.

포트폴리오는 유사한 프로젝트의 모음입니다.포트폴리오 관리는 프로젝트 관리 전문가 그룹이 공통 도구와 지식을 공유함으로써 포트폴리오의 모든 프로젝트에 유사한 표준화된 기법을 적용함으로써 규모의 효율성을 높이고 성공률을 높이며 프로젝트 위험을 줄일 수 있도록 지원합니다.조직에서는 프로젝트 포트폴리오 관리를 체계적으로 지원하기 위한 조직 구조로서 프로젝트 관리 사무소를 만드는 경우가 많습니다.[59]따라서 PPM은 대개 기업 프로젝트 관리 사무소(PMO) 내에 조직된 관리자들로 구성된 전담 팀에 의해 수행되며, 대개 조직 내에 기반을 두고 PMO 책임자 또는 최고 프로젝트 책임자에 의해 이끌어집니다.조직의 전략적 이니셔티브가 PPM의 대부분을 구성하는 경우에는 PPM의 책임자를 최고 이니셔티브 책임자로 칭하기도 합니다.

프로젝트 관리 소프트웨어

주요 기사:프로젝트 관리 소프트웨어 및 프로젝트 관리 정보 시스템

프로젝트 관리 소프트웨어(Project Management Software)는 자원 풀을 계획, 조직 및 관리하고 자원 견적을 개발하고 계획을 구현하는 데 사용되는 소프트웨어입니다.소프트웨어의 정교함에 따라, 기능에는 추정 및 계획, 스케줄링, 비용 통제 및 예산 관리, 자원 할당, 협업 소프트웨어, 커뮤니케이션, 의사 결정, 워크플로우, 리스크, 품질, 문서화 및/또는 관리 시스템이 포함될 수 있습니다.[80][81]

가상 프로젝트 관리

가상 프로그램 관리(VPM)는 가상 팀에서 수행하는 프로젝트를 관리하는 것이지만, 가상 환경을[82] 구현하는 프로젝트를 지칭하는 경우는 거의 없습니다. 가상 프로젝트를 관리하는 것은 원격 작업 및 글로벌 협업(문화, 시간대, 글로벌 협업)에 대한 우려를 결합하여 [83]기존 프로젝트를 관리하는 것과는 근본적으로 다르다는 점에 주목합니다.언어).[84]

참고 항목

관련 필드

관련과목

목록

참고문헌

  1. ^ Phillips, Joseph (2004). PMP Project Management Professional Study Guide. p. 354. ISBN 0072230622.
  2. ^ Baratta, Angelo (2006). "The triple constraint a triple illusion". PMI. Retrieved December 22, 2020.
  3. ^ Nokes, Sebastian; Kelly, Sean (2007). The Definitive Guide to Project Management: The Fast Track to Getting the Job Done on Time and on Budget. ISBN 9780273710974.
  4. ^ "What is Project Management?". Project Management Institute. Retrieved June 4, 2014.
  5. ^ Dinsmore, Paul C.; Cooke-Davies, Terence J. (November 4, 2005). Right Projects Done Right: From Business Strategy to Successful Project Implementation. p. 35. ISBN 0787971138.
  6. ^ Cattani, G.; Ferriani, S.; Frederiksen, L.; Florian, T. (2011). Project-Based Organizing and Strategic Management. Advances in Strategic Management. Vol. 28. Emerald. ISBN 978-1780521930.
  7. ^ Lock, Dennis. Project Management (9 ed.). ISBN 9780566087721.
  8. ^ Kwak, Young-Hoon (2005). "A brief History of Project Management". In Elias G. Carayannis (ed.). The story of managing projects. ISBN 1567205062.
  9. ^ Cleland, David; Gareis, Roland (May 25, 2006). "1: The evolution of project management". Global Project Management Handbook. ISBN 0071460454.
  10. ^ Stevens, Martin (2002). Project Management Pathways. p. xxii. ISBN 190349401X.
  11. ^ Marsh, Edward R. (1975). "The Harmonogram of Karol Adamiecki". The Academy of Management Journal. 18 (2): 358–364. doi:10.2307/255537. JSTOR 255537.
  12. ^ Witzel, Morgen (2003). Fifty Key Figures in Management. pp. 96–101. ISBN 0415369770.
  13. ^ Cleland, David; Gareis, Roland (May 25, 2006). Global Project Management Handbook: Planning, Organizing and Controlling International Projects. pp. 1–4. ISBN 0071460454. It was in the 1950s when project management was formally recognized as a distinct contribution arising from the management discipline.
  14. ^ Malcolm, D. G.; Roseboom, J. H.; Clark, C. E.; Fazar, W. (1959). "Application of a technique for research and development program evaluation" (PDF). Operations Research. 7 (5): 646–669. doi:10.1287/opre.7.5.646.
  15. ^ Harrison, F. L.; Lock, Dennis (2004). Advanced Project Management: A Structured Approach. p. 34. ISBN 0566078228.
  16. ^ Saladis, F. P. (2006). "Bringing the PMBOK® guide to life". PMI Global Congress. Seattle, WA: Project Management Institute.
  17. ^ "Certified Construction Manager". CMAA. Archived from the original on November 28, 2013. Retrieved November 23, 2013.
  18. ^ "Certificate in Biotechnology Project Management". University of Washington. Retrieved November 23, 2013.
  19. ^ Esselink, Bert (2000). A Practical Guide to Localization. Amsterdam/Philadelphia: John Benjamins Publishing Company. p. 428. ISBN 978-9-027-21956-5.
  20. ^ Mesly, Olivier (December 15, 2016). Project Feasibility: Tools for Uncovering Points of Vulnerability. ISBN 9781498757911..
  21. ^ Cf. The Bridger(블로그), "프로젝트 관리: PMP, Prince 2 또는 반복적 또는 민첩한 변형"
  22. ^ Serra, C. E. M.; Kunc, M. (2014). "Benefits Realisation Management and its influence on project success and on the execution of business strategies". International Journal of Project Management. 33 (1): 53–66. doi:10.1016/j.ijproman.2014.03.011.
  23. ^ "Going Beyond Critical Path Method". www.pmi.org. Retrieved December 27, 2021.
  24. ^ Mahmoudi, Amin; Bagherpour, Morteza; Javed, Saad Ahmed (2021). "Grey Earned Value Management: Theory and Applications". IEEE Transactions on Engineering Management. 68 (6): 1703–1721. doi:10.1109/tem.2019.2920904. ISSN 0018-9391. S2CID 202102868.
  25. ^ Hass, Kathleen B. (Kitty) (March 2, 2010). "Managing Complex Projects that are Too Large, Too Long and Too Costly". PM Times. Retrieved June 27, 2017.
  26. ^ Conforto, E. C.; Salum, F.; Amaral, D. C.; da Silva, S. L.; Magnanini de Almeida, L. F (June 2014). "Can agile project management be adopted by industries other than software development?". Project Management Journal. 45 (3): 21–34. doi:10.1002/pmj.21410. S2CID 110595660.
  27. ^ Snowden, David J.; Boone, Mary E. (November 2007). "A Leader's Framework for Decision Making". Harvard Business Review. Retrieved June 27, 2017.
  28. ^ "Stanford Research Study Finds Innovation Engineering is a true "Breakout Innovation" System". IE News. June 20, 2017. Retrieved August 11, 2017.
  29. ^ Wysocki, Robert K. (2013). Effective Project Management: Traditional, Adaptive, Extreme (Seventh ed.). John Wiley & Sons. ISBN 978-1118729168.
  30. ^ Royce, Winston W. (August 25–28, 1970). "Managing the Development of Large Software Systems" (PDF). Technical Papers of Western Electronic Show and Convention (WesCon). Los Angeles. Archived from the original (PDF) on March 15, 2016.{{cite journal}}: CS1 메인 : 일자 및 연도 (링크)
  31. ^ a b Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN 978-0-596-00948-9. Archived from the original on February 9, 2015.
  32. ^ McCaffer, Ronald; Harris, Frank (2013). Modern construction management. Wiley-Blackwell. p. 5. ISBN 978-1118510186. OCLC 834624541.
  33. ^ 정부통상국(1996) PRINCE2를 통한 성공적인 프로젝트 관리, p14
  34. ^ "OGC – PRINCE2 – Background". Archived from the original on August 22, 2011.
  35. ^ a b c d e f "Project Management Guide" (PDF). VA Office of Information and Technology. 2003. Archived from the original on January 14, 2009.{{cite web}}: CS1 maint : URL(링크) 부적합
  36. ^ a b c PMI (2010).지식의 프로젝트 관리 주체 안내서 27-35페이지
  37. ^ Nathan, Peter; Gerald Everett Jones (2003).더미에 대한 PMP 인증, 페이지 63.
  38. ^ Kerzner, Harold (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling (8th ed.). Wiley. ISBN 0-471-22577-0.
  39. ^ a b 루이스, 제임스 P. (2000)프로젝트 관리자 데스크 레퍼런스: 프로젝트 기획, 일정, 평가 및 시스템에 대한 종합 안내서 p. 185
  40. ^ Eccles, Robert G. (1981). "The quasifirm in the construction industry". Journal of Economic Behavior & Organization. 2 (4): 335–357. doi:10.1016/0167-2681(81)90013-5. ISSN 0167-2681.
  41. ^ Davies, Andrew; Hobday, Michael (2005). The Business of projects: managing innovation in complex products and systems. Cambridge University Press. ISBN 978-0-521-84328-7.
  42. ^ Gann, David; Salter, Ammon; Dodgson, Mark; Philips, Nelson (2012). "Inside the world of the project baron". MIT Sloan Management Review. 53 (3): 63–71. ISSN 1532-9194.
  43. ^ Meng, Xianhai (2012). "The effect of relationship management on project performance in construction". International Journal of Project Management. 30 (2): 188–198. doi:10.1016/j.ijproman.2011.04.002.
  44. ^ Cohen Kashi S., Rozenes S. & Ben-Gal, I. (2016). "Project Management Monitoring Based on Expected Duration Entropy" (PDF). In Entropy 2020, 22, 905.{{cite web}}: CS1 유지 : 여러 이름 : 저자 목록 (링크)
  45. ^ Becker, Jarg; Kugeler, Martin; Rosemann, Michael (2003). Process Management: A guide for the design of business processes. p. 27. ISBN 9783540434993.
  46. ^ 슐라게크, 베른하르트(2000).Objektorientierte Referencezmodelle für das Prozess - und Projekt 제어: Grundlagen - Konstroction - AnwendungsmöglichkeitenISBN 978-3-8244-7162-1, 페이지 131
  47. ^ 리들, 조세프 E. (1990)Forschung and Entwicklung의 Projectkt-Control.ISBN 978-3-540-51963-8, 페이지 99.
  48. ^ 스타인, 브루치, 라와 (1995).프로젝트 관리.FAZ Verlagsbeich Wirtschaftsbücher, 페이지 136-143
  49. ^ 스나이더, 신시아; 프랭크 파스 (2006).IT 프로젝트 관리 입문 393-397페이지
  50. ^ Abdou, Saed M; Yong, Kuan; Othman, Mohammed (2016). "Project Complexity Influence on Project management performance – The Malaysian perspective". MATEC Web of Conferences. 66: 00065. doi:10.1051/matecconf/20166600065. ISSN 2261-236X.
  51. ^ Morcov, Stefan; Pintelon, Liliane; Kusters, Rob J. (2020). "Definitions, characteristics and measures of IT Project Complexity - a Systematic Literature Review" (PDF). International Journal of Information Systems and Project Management. 8 (2): 5–21. doi:10.12821/ijispm080201. S2CID 220545211.
  52. ^ a b Marle, Franck; Vidal, Ludovic‐Alexandre (2016). Managing Complex, High Risk Projects - A Guide to Basic and Advanced Project Management. London: Springer-Verlag.
  53. ^ Vidal, Ludovic-Alexandre; Marle, Franck; Bocquet, Jean-Claude (2011). "Measuring project complexity using the Analytic Hierarchy Process" (PDF). International Journal of Project Management. 29 (6): 718–727. doi:10.1016/j.ijproman.2010.07.005. S2CID 111186583.
  54. ^ Vidal, Ludovic-Alexandre; Marle, Franck (2008). "Understanding project complexity: implications on project management" (PDF). Kybernetes. 37 (8): 1094–1110. doi:10.1108/03684920810884928.
  55. ^ Baccarini, D. (1996). "The concept of project complexity, a review". International Journal of Project Management. 14 (4): 201–204. doi:10.1016/0263-7863(95)00093-3.
  56. ^ Snowden, David J.; Boone, Mary E. (2007). "A Leader's Framework for Decision Making". Harvard Business Review. 85 (11): 68–76.{{cite journal}}: CS1 유지 : 여러 이름 : 저자 목록 (링크)
  57. ^ Maurer, Maik (2017). Complexity Management in Engineering Design – a Primer. Berlin, Heidelberg: Springer.
  58. ^ Kurtz, C. F.; Snowden, David J. (2003). "The new dynamics of strategy: Sense-making in a complex and complicated world". IBM Systems Journal. 42 (3): 462–483. doi:10.1147/sj.423.0462. S2CID 1571304.{{cite journal}}: CS1 유지 : 여러 이름 : 저자 목록 (링크)
  59. ^ a b c d e f Morcov, S. (2021). "Managing Positive and Negative Complexity: Design and Validation of an IT Project Complexity Management Framework". KU Leuven University.
  60. ^ Morris, Peter (1994). The management of projects. London: T. Telford. p. 317. ISBN 978-0727725936. OCLC 30437274.
  61. ^ Gower handbook of people in project management. Lock, Dennis., Scott, Lindsay, 1974-. Farnham, Surrey: Gower Publishing. 2013. p. 398. ISBN 978-1409437857. OCLC 855019788.{{cite book}}: CS1 메인 : 기타 (링크)
  62. ^ "PMOs". www.theprojectmanager.co.za. Retrieved March 1, 2018.
  63. ^ Commission, Australian Public Service. "APS framework for optimal management structures". Retrieved March 1, 2018.
  64. ^ Morcov, Stefan; Pintelon, Liliane; Kusters, Rob J. (2020). "IT Project Complexity Management Based on Sources and Effects: Positive, Appropriate and Negative" (PDF). Proceedings of the Romanian Academy - Series A. 21 (4): 329–336.
  65. ^ Daniel, Pierre A.; Daniel, Carole (January 2018). "Complexity, uncertainty and mental models: From a paradigm of regulation to a paradigm of emergence in project management". International Journal of Project Management. 36 (1): 184–197. doi:10.1016/j.ijproman.2017.07.004.
  66. ^ Pinto, Jeffrey K.; Winch, Graham (February 1, 2016). "The unsettling of 'settled science:' The past and future of the management of projects". International Journal of Project Management. 34 (2): 237–245. doi:10.1016/j.ijproman.2015.07.011.
  67. ^ Morcov, Stefan (April 6, 2021). "Project success vs. project management performance".
  68. ^ Bannerman, P. L. (2008). "Defining project success: a multilevel framework". Defining the Future of Project Management. Warsaw, Poland: Project Management Institute.
  69. ^ 카밀레리, 이매뉴얼 (2011)프로젝트 성공: 중요한 요인과 행동.가워출판사
  70. ^ KPI 연구소, "오늘의 KPI – 비즈니스 컨설팅(BC): 위탁 프로젝트의 $백로그"2021년 3월 16일 퍼포먼스 매거진.2022년 12월 23일 접속.
  71. ^ "DoDD 5000.01" (PDF). United States Department of Defense. Archived from the original (PDF) on August 25, 2009. Retrieved November 20, 2007.
  72. ^ "Taking the risk out of risk management: Holistic approach to enterprise risk management". Strategic Direction. 32 (5): 28–30. January 1, 2016. doi:10.1108/SD-02-2016-0030. ISSN 0258-0543.
  73. ^ a b 나사 NPR 9501.2D. 2001년 5월 23일.
  74. ^ Levine, H. A. (1993)."Webis and obis: 프로젝트 관리자를 위한 새로운 춤?" PM Network, 7(4), 35–38
  75. ^ ISO/IEC/IEEE Systems and Software Engineering--Life Cycle Processes--Project Management. doi:10.1109/IEEESTD.2009.5372630. ISBN 978-0-7381-6116-7.
  76. ^ Individual Competence Baseline for Project, Programme & Portfolio Management (PDF). International Project Management Association (IPMA). 2015. ISBN 978-94-92338-01-3.
  77. ^ 유럽 위원회.PM²: 유럽연합 집행위원회가 개발한 프로젝트 관리 방법론.
  78. ^ Mohindra, T., & Srivastava, M. (2019)."프로젝트 관리 프레임워크 비교 분석 및 프로젝트 추진 조직 제안" PM World Journal, VIII(VIII).
  79. ^ 해밀턴, 앨버트 (2004).프로젝트 관리 절차 핸드북.주식회사 TTL 출판사ISBN 0-7277-3258-7
  80. ^ PMBOK 4h Ed. 2008. p. 443. ISBN 978-1933890517.
  81. ^ 켄드릭, 톰 (2013).프로젝트 관리 도구 키트 : 일을 바르게 하는 100가지 팁과 기술, 제3판AMACOM Books.ISBN 9780814433454
  82. ^ Curlee, Wanda (2011). The Virtual Project Management Office: Best Practices, Proven Methods. Management Concepts Press.
  83. ^ Khazanchi, Deepak (2005). Patterns of Effective Project Management in Virtual Projects: An Exploratory Study. Project Management Institute. ISBN 9781930699830. Archived from the original on October 23, 2013.
  84. ^ Velagapudi, Mridula (April 13, 2012). "Why You Cannot Avoid Virtual Project Management 2012 Onwards".

외부 링크

위키미디어 커먼즈에는 프로젝트 관리와 관련된 미디어가 있습니다.
위키 인용문에는 프로젝트 관리와 관련된 인용문이 있습니다.
라이브러리 리소스정보
프로젝트관리
라이브러리 리소스정보
프로젝트관리
  • Wikimedia Commons의 Project Management