The Project Management Context
프로젝트 및 프로젝트 관리는 프로젝트 그 자체보다는 광범위한 환경 내에서 수행되고 있다. 프로젝트 관리팀은 이러한 광범위한 내용을 알아야 한다 - 프로젝트의 하루하루 활동들을 관리하는 것도 성공적인 사업 수행을 위해 필요하지만 그것만으로 충분하지는 않다. 이번 장에서는 교재의 다른 곳에서 언급하고 있지 않는 프로젝트 관리의 핵심적인 부분을 기술하고 있다. 주요 내용은 다음과 같다.
- 2.1 프로젝트 단계 및 프로젝트 수명 주기
- 2.2 프로젝트의 이해관계자
- 2.3 조직적 영향
- 2.4 주요 일반 관리 기법
- 2.5 사회적-경제적-환경적 영향
2.1 프로젝트의 단계 및 프로젝트 수명 주기
프로젝트는 유일한 사업들이므로 이들은 어느 정도의 불확실성(uncertainty)에 관련된다. 조직의 수행 프로젝트들은 보통 관리 통제를 향상시키고 현재 진행중인 운영과의 연결(link)을 제공하기 위해 각 프로젝트를 여러 개의 프로젝트 단계(phase)로 나눈다. 종합적으로 프로젝트의 단계는 프로젝트 수명 주기(project life cycle)로 알려져 있다.
2.1.1 프로젝트 단계의 특성
각 프로젝트 단계는 한 개 이상의 산출물(deliverable)의 완성으로 나타난다. 산출물은 타당성 조사(feasibility study), 상세 설계, 혹은 작업 프로토타입과 같은 유형의(tangible), 검증 가능한 작업 결과이다. 이 산출물들은 프로젝트 제품의 적절한 정의를 보장하기 위해 일반적으로 설계된 연속적인 논리(logic)의 부분이다.
프로젝트 단계의 종결은 일반적으로 주요 산출물 및 해당 일자까지의 프로젝트 성과(performance) 모두를 검토하는 것에 의해 나타나며 이는 (a)프로젝트가 다음 단계로 연속될 지를 결정하는 것과 (b)효과적인 비용으로 결함을 발견하고 수정하기 위함이다. 이러한 단계-종료(phase-end) 검토(review)는 종종 phase exits, stage gates 또는 kill point로 불린다.
각 프로젝트 단계는 보통 관리 통제의 요구되는 수준을 설정하기 위해 설계되어진, 정의된 산출물 집합을 포함한다. 이러한 항목들(items)의 대부분은 초기 단계 산출물과 관계가 있으며, 그 단계들은 전형적으로 다음과 같은 항목들로부터 적당하게 그들의 이름을 가져온다 : 요구사항, 설계, 구축, 시험, 착수(startup), 인계(turn over) 등. 여러 가지 대표적인 프로젝트 수명 주기는 2.1.3절에 기술되어 있다.
2.1.2 프로젝트 수명 주기의 특성
프로젝트 수명 주기는 프로젝트의 시작과 끝을 정의하기 위해 사용된다. 예를 들어, 어떤 조직이 대처해야 할 기회를 판단할 때, 종종 프로젝트 수행 여부를 결정하기 위해 평가(assessment) 또는 타당성 조사(feasibility study)에 권한을 부여한다. 프로젝트 수명 주기 정의는 타당성 조사를 프로젝트의 첫번째 단계로 취급할지 또는 분리된, 독립적인 프로젝트로 취급할 지를 결정할 것이다.
프로젝트 수명 주기 정의는 프로젝트의 시작과 끝에서 어떤 과도기적 행동(transitional action)이 포함되어야 할지 아닐지를 결정한다. 이러한 방법으로 프로젝트 수명 주기 정의는 프로젝트를 실행 조직의 진행중인 운영에 연결(link)시키는 데 사용될 수 있다.
대부분의 프로젝트 수명주기에 의해 정의된 프로젝트 단계 순서(sequence)는 일반적으로 요구사항으로부터 설계로 변경, 건설로부터 운영으로 변경, 또는 설계로부터 제조로 변경과 같은 어떤 형식의 변경(transfer) 또는 이관(handoff) 기술과 관련된다. 이전 단계로부터 나온 산출물은 보통 다음 단계 작업을 시작하기 전에 승인된다. 하지만 후속(sub-sequent) 단계는 가끔 이전 단계 산출물이 승인되기 전에 시작할 수 있는데 이는 관련된 위험이 허용 가능하다고 간주될 때 이다. 이러한 중첩된(overlapping) 실행 단계를 “Fast Tracking”이라 한다.
프로젝트 수명 주기는 일반적으로 아래와 같이 정의된다.
- 어떤 기술적인 작업이 각 단계에서 수행되어야 하는가?(즉, 건축 작업은 정의 단계 부분인가, 아니면 실행 단계의 부분인가?)
- 각 단계에서 누가 관련되어야 하는가?(즉, 요구사항 및 설계에 필요한 구현자)
프로젝트 수명 주기 설명은 매우 일반적일 수도, 매우 상세할 수도 있다. 매우 상세한 설명은 구조와 일관성(consistency) 제공하기 위해 많은 양식, 차트 및 체크리스트들을 가지고 있을 것이다. 이러한 상세한 접근 방법을 종종 프로젝트 관리 방법론(project management methodologies)이라고 부른다.
대부분의 프로젝트 수명 주기 기술은 많은 특징을 공유한다.
- 비용과 직원의 설명 수준(level)은 시작 단계에서는 낮다가 완료 단계로 가면서 높아지고 프로젝트가 종결될 때 급히 떨어진다. 이런 형태가 그림2-1에서 보여진다.
- 프로젝트의 시작 단계에서는 프로젝트의 성공적인 종결 가능성은 가장 낮고, 위험도와 불확실성은 가장 높다. 성공적인 종결의 가능성은 프로젝트가 진행될수록 점진적으로 높아진다.
- 프로젝트 제품의 최종 특성 및 최종 가격에 영향을 주는 이해관계자의 능력은 시작 단계에서 가장 높다가 프로젝트 진행이 되면서 점진적으로 낮아진다. 이런 현상의 주요 원인은 프로젝트가 진행되면서 가격 변동 및 결함 수정이 일반적으로 증가되기 때문이다.
프로젝트 수명 주기와 제품(product) 수명 주기를 구분하기 위해 주의를 기울여야 한다. 예를 들어, 새로운 데스크탑 컴퓨터를 시장에 출시하기 위해 수행되는 프로젝트는 제품 수명 주기의 오직 한 단계(phase or stage)일 뿐이다.
비록 많은 프로젝트 수명 주기가 요구되는 산출물과 비슷한 이름을 가지고 있지만, 동일한 것은 아주 드물다. 대부분 4~5개의 단계를 가지고 있지만 어떤 것들은 9개 이상도 가지고 있다. 비록 단일 응용 분야라 할지라도 많은 편차(variance)들이 있다 – 한 조직의 소프트웨어 개발 수명 주기는 다른 개발 수명 주기가 기능 및 상세 설계 등 분리된 단계를 가지고 있는 반면, 하나의 설계 단계만을 가질 수도 있다.
프로젝트내의 서브프로젝트도 역시 명확한 프로젝트 수명 주기를 가질 수 있다. 예를 들어, 새로운 오피스 빌딩을 설계하기 위해 고용된 건축 회사는 설계 수행 중에는 고용주의 정의 단계에 처음 연관되고, 건설을 지원할 시점에는 오너의 실행 단계 연관된다. 하지만, 건축가의 설계 프로젝트는 개념 개발로부터 정의, 구현 종결까지의 일련의 자신만의 단계들을 가질 것이다. 건축가는 시설물을 설계하고 건설을 지원하는 것을 그들만의 분명한 단계로 분리된 프로젝트로 취급할 것이다.
2.1.3 대표적인 프로젝트 수명 주기
다음의 프로젝트 수명 주기는 사용 방법의 다양성을 설명하기 위해 선택되었다. 보여준 예들은 전형적이다; 이들은 추천된 것도 선택된 것도 아니다. 각 경우마다 단계의 명칭과 주요 산출물은 저자에 의해 기술된 것이다.
Defense acquisition. 미 국방성 지시 5000.2(최종 조정 문서, 2000년 4월)는 그림2-2에 일련의 획득(acquisition) 이정표 및 단계를 기술하였다.
- 개념 및 기술 기발 – 임무 요구를 만족시키기 위한 대안적인 개념에 대한 paper study; 새로운 시스템 개념에 대한 서브시스템/구성요소 개발 및 개념/기술 검증(demonstration). 사용될 시스템 구조 및 기술 선택 후 종료
- 시스템 개발 및 검증 – 시스템 통합; 위험 감소; 엔지니어링 개발 모델의 검증; 개발 및 초기 운용 시험 및 평가. 운영 환경에서 시스템 검증 후 종료
- 제품 출시 및 전개(deployment) – 초기의 낮은 생산율(low rate initial production(LRIP)); 제조 능력의 개발 완성; 진행중인 운영 및 지원과 단계 중첩.
- 지원 – 이 단계는 제품 수명 주기의 한 부분이지만 실제 진행 관리이다. 다양한 프로젝트들이 능력 향상, 결함 수정 등을 위해 수행된다.
- Construction. Morris는 건설 프로젝트 수명 주기를 그림 2-3와 같이 기술하였다.
- 실행가능성(feasibility) – 프로젝트 공식화(formulation), 실행가능성 연구, 전략 설계 및 승인. 진행/중단 여부 결정이 이 단계의 끝에서 만들어 진다.
- 계획 및 설계 - 기본 설계, 비용 및 일정, 계약 기간 및 조건 그리고 상세화 된 계획. 주요 계약들이 이 단계의 끝에서 맺어진다.
- 건설 – 생산, 납품, 토목 공사, 설치 및 시험. 시설물(facility)은 이 단계의 끝에서 대부분 완성된다.
- 인도(turnover) 및 가동시작 - 최종 시험 및 유지. 시설물은 이 단계의 끝에서 완전 가동된다.
- Pharmaceuticals. Murphy는 미국 신약 개발의 프로젝트 수명 주기를 그림2-4와 같이 기술하였다.
- 조사 및 선별 - 임상 시험 지원자 확인을 위한 기본 및 응용조사가 포함된다.
- 초기 임상 개발 - 연구적인 신약(IND) 신청의 준비 및 서류화 뿐만 아니라 안정성과 효능을 결정하기 위한 실험실 및 동물 시험을 포함한다.
- 등록작업 – 신약 등록(NDA)의 준비 및 서류화 뿐만 아니라 임상 시험 Ⅰ,Ⅱ,Ⅲ 단계를 포함한다.
- 제안 후 활동 – NDA에 대한 식품 의약국의 검토를 지원하기 위해 요구되는 부가적인 작업을 포함한다.
- Software development. 소프트웨어 수명 주기 모델에는 폭포수 모델과 같은 많은 모델들이 있다. Muench는 그림2-5와 같이 4개의 주기와 4개의 분원(quadrants)을 가진 소프트웨어 개발을 위한 나선 모델을 기술하였다.
- 개념 입증 주기(proof-of concept cycle) - 사업 요구사항 획득, 개념 입증을 위한 목적 정의, 개념적 시스템 설계 및 논리적 설계 작성, 개념 입증 구성, 인수 시험 계획 수립, 위험 분석 수행 및 권고사항 제시 등
- 첫번째 빌드 주기(first-build cycle) - 시스템 요구사항 도출, 첫번째 빌드 목표 정의, 논리적 시스템 설계 생성, 첫번째 빌드 설계 및 구성, 시스템 시험 계획 수립, 첫번째 빌드 평가 및 권고사항 제시 등
- 두번째 빌드 주기 - 서브시스템 요구사항 도출, 두번째 빌드 목표 정의, 물리적인 설계 생성, 두번째 빌드 생성, 서브시스템 시험 계획 수립, 두번째 빌드 평가 및 권고사항 제시 등
- 최종 주기 – 단위 요구사항 및 최종 설계 완성, 최종 빌드 생성 및 단위, 서브시스템, 시스템 및 인수 시험 수행
2.2 프로젝트 이해관계자
프로젝트 이해관계자는 프로젝트에 적극적으로(actively) 연관된 개인 및 조직이거나 그들의 관심이 프로젝트 수행 또는 프로젝트 완성의 결과로써 긍정적 또는 부정적인 영향을 미칠 수 있는 사람을 말한다; 그들은 또한 프로젝트 및 그 결과에 영향을 미칠 수 있다. 프로젝트 관리팀은 성공적인 프로젝트를 확신하기 위해 이해관계자를 식별하고, 그들의 요구사항을 결정하고, 이러한 요구사항을 관리하여야 한다. 이해관계자 식별은 종종 특히 어렵다. 예를 들면, 새로운 제품의 설계 프로젝트의 결과에 따라 장래의 고용이 달려있는 조립 라인의 작업자가 이해관계자인가?
모든 프로젝트에서 주요 이해관계자는 다음을 포함한다.
n 프로젝트 관리자 - 프로젝트를 관리하는데 책임이 있는 개인
n 고객(customer) - 프로젝트의 제품(product)을 사용하게 될 개인이나 조직. 고객에는 여러 계층이 있을 수 있다. 예를 들어, 새로운 신약 제품의 고객은 그 약을 처방 하는 의사들, 복용할 환자, 이를 지불할 보험업자들이 있다. 어떤 응용 분야에서 고객과 사용자(user)는 같은 의미로 사용되지만, 다른 응용 분야에서는 고객은 프로젝트 결과를 구매하는 실체(entity)로 언급되고 사용자는 프로젝트 제품을 직접 사용하는 사람을 말한다.
n 수행 조직 – 프로젝트 작업을 수행하는데 대부분 직접적으로 연관된 고용자를 가진 기업
n 스폰서 - 프로젝트를 위해 현금 등의 재정적 자원을 제공하는 수행 조직 내부 또는 외부의 개인이나 그룹
여기에 덧붙여, 프로젝트 이해관계자에는 많은 다른 명칭 및 분류가 있다 – 내부 및 외부, 소유자(owner) 및 자금주(funders), 판매자(seller) 및 계약자, 팀 구성원 및 그들의 조직, 정부 대리인 및 매체 수단, 임시적·영구적 조직, 그리고 크게는 사회이다. 이해관계자의 명칭 및 조직화는 처음 그들 자신을 이해관계자라고 보는 개인이나 조직을 확인함으로써 만든다. 엔지니어링 회사가 공장에 재정을 제공하는 것 자체가 설계인 것처럼 이해관계자의 역할과 의무는 중첩될 수 있다.
이해관계자들은 종종 매우 다른 목적을 가지고 있어 이에 의한 충돌이 발생될 수 있기 때문에 이해관계자들의 기대를 관리한다는 것은 매우 어려울 수 있다. 예를 들어,
n 새로운 관리 정보 시스템을 요구하는 어떤 부서의 관리자는 낮은 가격을 원할 수 있고, 시스템 설계자는 기술적인 우수성을 강조하고, 프로그래밍 계약자는 그 시스템의 이윤을 극대화하는 데에 가장 흥미를 가지고 있을 것이다.
n 어떤 전기회사에서 연구 분야 부사장은 새로운 제품의 성공을 최고의 기술로 정의하고, 생산 분야 부사장은 그것을 세계 수준의 생산으로, 판매 분야 부사장은 새로운 제품의 숫자에 관심을 가진다.
n 부동산 개발 프로젝트의 소유자는 적시 수행에 초점을 맞추며, 지방 정부 조직은 조세 수입의 극대화를 바라게 되며, 환경 단체는 환경 피해의 영향을 최소화하는 것을 원할 것이다. 그리고 인근의 주민들은 그 프로젝트의 위치를 변경하는 것을 희망할 것이다.
일반적으로 이해관계자간의 의견 차이는 소비자 선호에 의해 해결될 수 있다. 하지만, 이것은 다른 이해관계자의 요구와 기대가 무시된다거나 고려되지 않는 것을 의미하지는 않는다. 이런 의견 차이에서 적절한 해결책을 찾는 것이 프로젝트 관리자의 주요 숙제 중의 하나가 될 수 있다.
2.3 조직의 영향
프로젝트들은 전형적으로 프로젝트보다 더 큰 조직의 한 부분이다 - 회사, 정부 조직, 건강 의료 시설,국제 기구, 사회 전문가 등. 프로젝트가 공동 벤처나 협력 형태로 조직적으로 수행될 경우라도, 프로젝트는 여전히 조직이나 프로젝트를 수립한 조직의 영향을 받는다. 프로젝트 관리 시스템, 문화, 형태, 조직적인 구조 및 프로젝트 관리 사무실 등에 관한 조직의 성숙도 또한 프로젝트에 영향을 줄 수 있다. 다음의 섹션에서 프로젝트에 영향을 줄 수 있는 이러한 넓은 조직적인 구조의 주요 관점들에 대해 기술하고 있다.
2.3.1 조직 시스템
프로젝트 기반(project-based) 조직은 주로 프로젝트를 수행하는 사람들로 구성된다. 이러한 조직은 다음 2개의 종류로 나눠진다.
n 실행 프로젝트로부터 주 수입을 얻는 조직 – 건축 회사, 엔지니어링 회사, 컨설턴트, 건설 계약자, 정부 계약자, 비정부 조직 등
n 프로젝트에 의한 관리를 채택하고 있는 조직(1.3절 참조)
이러한 조직들은 프로젝트 관리를 원활히 하기 위하여 관리 시스템을 가지려는 경향이 있다. 예를 들면,그들의 재정 시스템은 종종 특히 여러 동시적인 프로젝트에 대한 회계 처리, 추적 및 보고를 위해 설계되었다.
프로젝트 기반이 아닌(nonproject-based) 조직은 종종 프로젝트 요구를 효율적이고 효과적으로 지원하기 위해 설계된 관리 시스템이 부족하다. 프로젝트 전용(project-oriented) 시스템의 부재는 보통 프로젝트 관리를 더욱 어렵게 한다. 어떤 경우에, 프로젝트 기반이 아닌 조직은 시스템과 매치하기 위해 프로젝트 기반 조직처럼 동작하는 부서 또는 다른 서브단위를 가질 것이다.
프로젝트 관리팀은 조직의 시스템이 프로젝트에 어떻게 영향을 미칠 것인지 예리하게(acutely) 알고 있어야 한다. 예를 들어, 만일 조직이 프로젝트의 직원 소요 부문의 관리자를 구할 때 프로젝트 관리팀은 할당된 직원이 효과적으로 프로젝트에 쓰일 것이라는 것을 확신하게 하기 위해 실행 통제가 필요할 것이다.
2.3.2 조직의 문화 및 양식(style)
대부분의 조직은 독창적이고 묘사할 수 있는(describable) 문화를 개발해 왔다. 특성을 가지고 있다. 이런 문화는 그들의 공유된 가치, 표준(norm), 신념 및 기대; 그들의 정책 및 절차; 그들의 권한 관계의 관점; 그리고 다른 요소들에 반영되어 있다. 조직적인 문화는 종종 프로젝트에 직접적인 영향을 줄 때가 있다. 예를 들어,
n 한 팀이 일반적이지 않고 위험이 큰 접근 방법을 제안할 때는 적극적이거나 사업주적인 조직 내에서는 승인이 보장될 경우가 많을 것이다.
n 모든 것을 관여하는 스타일을 가진 프로젝트 관리자는 경직된 계급 조직의 문제에 부딪치게 되는 경향이 있고, 반면에 프로젝트 관리자가 권위적인 스타일을 가질 때 역시 참여 조직 내에서 도전을 받을 것이다.
2.3.3 조직의 구조
수행 조직의 구조는 종종 프로젝트에 하에서 어떤 자원이 이용 가능한지에 대한 가용성 또는 용어를 제한한다. 조직의 구조는 기능 조직에서 프로젝트 전담 조직 까지, 그 사이의 다양한 메트릭스 구조 등 다양하게 특성화될 수 있다. 그림2-6은 기업 조직 구조의 주요 형태의 프로젝트에 관련된 핵심적인 특징을 보여준다. 프로젝트 조직은 9.1절 조직 계획에서 논의하였다.
그림2-7에서 보여주는 전통적인 기능 조직(functional organization)은 각 고용자가 분명한 한 상급자를 가지고 있는 조직이다. 직원 구성원은 최상의 단계에서 생산, 판매, 엔지니어링 및 회계 등과 같은 특성(specialty)에 의해 그룹이 지워 지고 엔지니어링 부문은 커다란 조직의 사업을 지원하기 위한 기능적인 조직으로 다시 세분화된다.(예, 기계적 및 전기적) 기능적인 조직은 여전히 프로젝트를 가지지만 프로젝트의 감지된 범위(scope)는 기능의 경계(boundary)로 제한된다; 기능적인 조직에서 엔지니어링 부분은 제조 또는 판매 부분과 독립적으로 업무를 수행할 것이다.
예를 들어, 새로운 제품 개발이 순수하게 기능적인 조직에서 수행될 때, 설계 단계는 종종 "설계 프로젝트"라고 불리며 오직 엔지니어링 부문 조직원만 포함한다. 만일, 생산에 대한 의문이 생긴다면, 엔지니어링 직원들은 그것들을 생산 부문의 책임자에게 넘긴다. 이에 대한 답변은 엔지니어링 부문의 책임자가 엔지니어링 프로젝트 관리자에게 전달한다.
그림2-8은 프로젝트 전담 조직(projectized organization)을 보여준다. 프로젝트 전담 조직에서는 팀 구성원은 종종 재배치(collocated)된다. 조직 자원 대부분은 프로젝트 작업에 관련되어 있고 프로젝트 관리자는 많은 독립성과 권한을 가지고 있다. 프로젝트 전담 조직은 종종 부서(department)라고 불리는 조직 단위를 가지지만, 이러한 그룹들은 프로젝트 관리자에게 직접 보고하거나 다양한 프로젝트에 대한 서비스 지원을 제공한다.
그림 2-9에서 2-11까지 보여주는 "메트릭스 조직"은 기능 조직과 프로젝트 전담 조직 특성을 혼합한 것이다. "취약한(weak) 메트릭스" 조직은 많은 기능 조직의 특성을 가지고 있으며, 프로젝트 관리자의 역할은 관리자이기 보다는 조정자(coordinator)이거나 홍보 담당자(expediter)이다. 유사한 방식으로 "강한(strong) 메트릭스" 조직은 프로젝트 전담 조직의 특성을 많이 가진다 – 상당한 권한을 가진 전담(full-time) 프로젝트 관리자 및 전담 프로젝트 집행 직원
대부분의 현재 조직은 다양한 수준에서의 모두 이런 구조에 관련되어 있고, 이는 그림2-12에서 보여주고 있다. 예를 들어, 근본적으로 기능 조직 일지라도 중요 프로젝트를 처리하기 위해서는 특별한 프로젝트팀을 생성할 수 있다. 이러한 팀은 프로젝트 전담 조직의 프로젝트 특성을 많이 가질 것이다. 이 팀은 다른 기능적인 부서로부터 전담 직원을 포함할 수 있으며, 이 팀은 자신의 운영 절차를 개발할 수도 있고 표준, 공식화된 보고 구조 외에서 운영될 수 있다.
2.3.4 프로젝트 오피스(PMO)
무엇이 프로젝트 오피스를 구성하는 것에 대한 사용의 범위가 있다. 프로젝트 오피스는 기능 지원 제공에서부터 훈련, 소프트웨어 도입, 모형(template) 등의 형식으로 프로젝트 관리자에게 지원 기능을 제공하여 지속적인 운영을 도와주는 조직으로 실제적으로 프로젝트 결과를 책임진다.
2.4 핵심적인 일반 관리 기법
일반적 관리는 진행중인 사업 관리의 모든 측면들을 다루는 넓은 주제이다. 다른 주제들 사이에서 일반적인 관리는 다음을 포함한다.
n 재정 및 회계, 판매 및 마케팅, 연구 및 개발, 생산 및 분배
n 전략적 계획, 전술적(tactical) 계획, 운영 계획
n 조직적인 구조, 조직적 행동, 개인 행정, 보상, 이윤, 이력(career) 경로
n 동기, 위임(delegation), 감독(supervision), 팀 구성, 분쟁 관리 및 다른 기법 등 작업 관계 관리
n 개인 시간 관리, 스트레스 관리 및 다른 기법 등 자신의 관리
일반적인 관리 기법은 프로젝트 관리 기법을 구축하는데 많은 기반을 제공한다. 이들은 종종 프로젝트 관리자에게는 필수적이다. 어떤 주어진 프로젝트에서 일반적 관리 영역의 많은 기법들이 필요할 수 있다. 이 절에서는 대부분의 프로젝트에 많은 영향을 줄 수 있는 핵심적인 일반 관리 기법에 대해 기술하였으며 이 내용은 이 문서의 다른 부분에서는 다루지 않았다.
이러한 기법은 일반 관리 문헌에 잘 문서화되어 있으며 그들의 응용은 프로젝트에 있어서도 근본적으로 동일하다.
역시 많은 관리 기법이 오직 특정한 프로젝트와 특정한 응용 영역에만 관련되어 있다. 예를 들어, 팀 구성원의 안전은 모든 건설 프로젝트에서는 사실상 중요하지만 대부분의 소프트웨어 개발 프로젝트에서는 거의 관계가 없다.
2.4.1 지도(leading)
Kotter[4]는 지도(leading)와 관리(managing) 모두의 필요성을 강조하면서 둘 사이의 차이를 구분하였다; 다른 나머지가 없을 때 한가지는 나쁜 결과를 초래하기 쉽다. 그는 관리라는 것은 기본적으로 "이해관계자들에 의해 기대되는 핵심적인 결과를 일관적으로 생산"하는 것에 관련이 있다고 하였다. 반면 지도는 다음에 관련된다.
n 방향 설정(establishing direction) – 미래의 비전 및 그 비전을 달성하기 위해 필요한 변화를 생성하기 위한 전략을 개발함
n 팀원 할당(aligning people) – 비전 달성을 위해 협동을 필요로 하는 사람들에게 언어 및 업적(deeds)에 의한 비전에 대한 의사소통 수행
n 동기부여(motivation) 및 의욕고취(inspiring) - 사람들 자신을 변경에 대한 정치적, 관료적(bureaucratic) 및 자원 장벽을 극복하기 위한 활력을 주도록 도와주는 것
프로젝트에서, 특히 대단위 프로젝트에서, 프로젝트 관리자는 일반적으로 프로젝트의 리더로 기대된다. 리더쉽은 프로젝트 관리자에게만 한정되어 있는 것이 아니라, 프로젝트 기간 동안 시시때때로 많은 각자 개인들에게 보여질 수 있다. 리더쉽은 프로젝트의 모든 단계에서 보여져야 한다.(프로젝트 리더쉽, 기술적 리더쉽, 팀 리더쉽)
2.4.2 의사소통(communication)
의사소통은 정보를 교환하는데 관련된다. 전달자(sender)는 정보를 분명하게, 애매하지 않게, 완전하게 전달할 의무가 있으며 이에 따라 인수자(receiver)가 정확하게 전달 받을 수 있다. 인수자는 정보를 전체적으로 받고 정확하게 이해해야 할 책임이 있다. 의사소통에는 많은 범위가 있다.
n 문서화 및 구두, 듣기와 말하기
n 내부(프로젝트 내부)와 외부(고객, 대중매체, 대중 등)
n 공식적(보고서, 브리핑 등) 및 비공식적(메모, 대화 등)
n 수직적(상하 조직)과 수평적(동료 및 파트너 조직 간)
의사소통의 일반적인 관리 기법은(10장에서 기술) 프로젝트 의사소통 관리와 관계는 있지만, 같지는 않다. 의사소통은 더 넓은 주제(subject)이고 상당한 지식 체계에 관련되어 있지만 프로젝트 내용(context)과는 동일하지 않다. 예를 들어,
n 송신자-수신자 모델 - 피드백 루프, 의사소통 장벽 등
n 매체의 선택 – 필기(writing)를 통한 의사소통, 언어를 통한 의사소통, 비공식적인 메모를 작성할 때, 공식적인 보고서를 작성할 때 등
n 필기 스타일 – 능동적 vs. 수동적 목소리, 문장 구조, 단어 선택 등.
n 발표 기술 - 몸짓 언어, 가시적 지원(aids)의 설계 등
n 회의 관리 기술 – 의제(agenda) 준비, 논쟁의 처리 등
프로젝트 의사소통 관리는 프로젝트의 특정한 요구에 대한 이러한 넓은 개념의 응용이다 – 예를 들어, 어떻게, 언제, 어떤 형식으로, 누구에게 프로젝트 성과를 보고할 것인지를 결정
2.4.3 협상(negotiating)
협상은 상대방과 협정을 체결하거나 동의(agreement)를 얻기 위하여 협의하는 것에 관련된다. 동의는 직접적이거나 지원(assistance)에 의해서 협상될 것이다; 조정(mediation)과 중재(arbitration)는 지원된(assisted) 협상의 두 가지 유형이다.
협상은 많은 쟁점(issue)과, 많은 시간마다, 그리고 프로젝트의 많은 단계에서 일어난다. 전형적인 프로젝트의 기간 동안, 프로젝트 조직원은 다음에 기술된 모든 것들이나 어떤 것에 대해 협상을 할 경향이 있다.
n 범위, 비용, 일정 목적
n 범위, 비용, 일정의 변경
n 계약 용어(term) 및 조건
n 임무(assignment)
n 자원
2.4.4 문제 해결기법(problem solving)
문제 해결기법은 문제 정의(definition)와 의사 결정(decision-making)의 조합(combination)에 관련된다.
문제 정의는 원인(cause) 및 징후(symptoms)간의 구별을 필요로 한다. 문제는 내부적(핵심 종업원이 다른 프로젝트에 재배치 됨)이거나 외부적(시작 작업에 필요한 허락(permit)이 연기됨)일 수 있다. 문제는 기술적(제품 설계 방법에 대한 의견 차이)이거나 관리적(기능적인 그룹이 계획에 따라 생산하지 않음), 혹은 개인간(개성 및 성향의 충돌)일 수 있다.
의사 결정은 시행 가능한 해결책을 정의하기 위해 문제를 분석하고, 해결책 사이에서 선택하는 것을 포함한다. 결정들은 고객, 팀 또는 기능적인 관리자로부터 만들어지고 얻을 수 있다. 일단 만들어진 결정들은 구현되어야 한다. 결정은 또한 시간적인 요소가 있다 – “옳은(right)” 결정은 너무 빠르거나 늦게 만들어진 다면 “최상의(best)” 결정이 되지 않을 수도 있다.
2.4.5 조직에의 영향
조직에 영향을 주는 것은 "실행된 것을 얻을 수 있는(get things done)" 능력에 관련된다. 이는 관련된 모든 조직의 공식적 또는 비공식적 구조 모두를 이해하는 것을 필요로 한다 – 실행 조직, 고객, 파트너, 계약자 등. 조직에의 영향은 또한 권력(power) 구조와 정치(politics)에 대한 이해가 필요하다.
권력과 정치는 여기에서는 그들의 긍정적인 감각(sense)으로 사용된다. Pfeffer는 권력을 "행동에 영향을 주고, 사건의 경로를 바꿀 수 있고, 저항을 극복할 수 있는 잠재적 능력”으로 언급하고 있다. 이와 비슷한 방법으로, Eccles[6]은 "정치란 아주 다른 관심을 가진 사람의 집단으로부터 집단 행동(collective action)을 얻는 것에 관한 것”이라고 말하고 있다. 이것은 대립(conflict)과 무질서(disorder)를 창조적으로 기꺼이 이용하려는 것이다. 물론, 부정적인 감각으로는 권력 투쟁의 산물인 이러한 관심들을 일치시키려는 시도라는 사실로부터 얻고, 때로는 완전히 비생산적인 자신의 일생 동안의 조직적인 게임으로부터 얻는 것" 이라고 정의한다.
2.5 사회-경제적-환경적인 영향
일반적인 관리와 같이, 사회-경제적인 영향은 광범위한 내용과 주제를 포함한다. 프로젝트 관리팀은 사회-경제적인 분야에서의 현재의 조건(condition) 및 경향(trend)이 프로젝트에 중요 요인이 될 것이라는 것을 알아야 한다: 사회-경제적인 분야에서의 작은 변화는 보통 시간 지연을 수반하며, 프로젝트 자체에는 큰 영향을 미친다. 많은 잠재적인 사회-경제적인 영향 중에서 프로젝트에 자주 영향을 미치는 여러 가지 주요 분류가 아래에 개략적으로 기술되었다.
2.5.1 표준과 규정(regulation)
국제 표준 기구(ISO)는 표준과 규정을 차이를 아래와 같이 구별하였다.
n 표준(standard)은 공통적이고 반복적인 사용, 규칙, 가이드라인 또는 제품의 특성이며, 준수(compliance)는 강제적이지 않은 프로세스 또는 서비스에 대한 인증 기구로부터 승인된 문서이다. 유체의 온도 안정성부터 컴퓨터 디스켓의 크기까지 모든 것을 다루는 데 사용되는 표준은 수 없이 많다.
n 법규(regulation)는 생산품의 전반에 걸쳐 일련의 활동과 서비스를 적용할 행정규정을 포함하는 문서로, 그의 활용은 강제적이다. 빌딩 코드(code)는 규정의 한 예이다.
표준과 법규는 광범위한 부분에서 구분이 명확하지 않기 때문에 조심스럽게 논의해야 할 것이다. 예를 들어,
n 표준은 종종 선호되는 접근방법(preferred approach)을 기술한 가이드라인으로 시작하여, 차후에는 넓게 적용되며, 사실상 법규로 된다. (예, 주요 건설 프로젝트의 일정 관리를 위한 주경로 기법(Critical path method)의 사용)
n 다른 수준에서의 준수는 강제적일 수 있다. (예, 정부 부처에 의해서, 실행조직의 관리에 의해서, 또는 프로젝트 팀에 의해서)
많은 프로젝트에서 표준과 법규는(정의가 어떻든지) 잘 알려져 있고, 프로젝트 계획은 그것들을 잘 반영해야 한다. 다른 경우에, 알려지지 않고 분명하지 않은 영향은 프로젝트 위험관리(11장에서 설명)에서 고려해야 할 것이다.
2.5.2 국제화(Internationalization)
조직이 국제 무대에서 일하게 되는 경우가 많아짐에 따라, 점점 더 많은 프로젝트들이 국제 무대가 범위가 된다. 범위, 비용, 시간 및 품질에 대한 기존의 관점에 덧붙여 프로젝트 관리팀은 또한 시간대(time-zone) 차이의 영향과 국가와 지역의 휴일, 면담을 위한 여행 요구사항, 전화 회의의 세부계획(logistics), 그리고 종종 변동하는(volatile) 정치적 차이에 대하여 고려해야 할 것이다.
2.5.3 문화적 영향문화란 "사회적으로 전이된 행동 양식, 예술, 종교, 단체 그리고 인간의 작업이나 생각의 전체(totality)" 이다. 모든 프로젝트는 하나 이상의 문화적 규범(norm) 내에서 운영되어야 한다. 프로젝트에 영향을 주는 영역에는 정치, 경제, 인구통계학(demographic), 교육, 윤리, 인종, 종교 등이 있고, 다른 영역으로는 사람과 조직들에 상호 영향을 주는 실행(practice)과 신념, 그리고 사고방식(attitude) 등이 있다.
2.5.4 사회-경제-환경적 지속능력(substainability)
사실상 모든 프로젝트는 사회적, 경제적, 환경적 배경(context) 내에서 계획되고 구현되며, 의도된 또는 의도되지 않은 긍정적 및 부정적 영향을 가진다. 조직은 프로젝트로부터 나온 영향(예, 도로 건설 프로젝트에서 고고학적 위치에 대한 우연한 파괴) 뿐만 아니라 프로젝트가 완수된 후 오랜 동안 사람, 경제 및 환경에 대한 영향(예, 도로는 접근을 용이하게 할 수도 있지만 예전 환경에 대한 파괴도 가져올 수 있다)에 대해서도 책임이 있다.
댓글