박종명의 아름다운 개발 since 2010.06

이 글은  제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=480

---

사람들끼리 모여서 일을 하다 보면 갈등은 피할 수 없는 주제이다
개개인의 성향과 기질이 다른 것은 차치하고서라도 업무의 우선순위, 맡은 역할, 일정 준수 등
프로젝트를 완료하기 위한 하나하나의 과정들에서 갈등은 발생할 수 있다

이번 시간에는 이러한 갈들을 PMI에서는 어떻게 정의하고 관리하는지에 대해 알보도록 하자

프로젝트 수행 중 발생되는 많은 갈등의 원인은 일정과 업무우선순위,자원에 있다
일정을 준수하지 못하거나 일정을 오버하거나 일정 변경 없이 범위가 변경하거나 특정 리소스의 결핍으로 인한
일정 위험을 느낄때, 또한 업무에 대한 우선순위 결정등에서 갈등이 많이 발생하게 된다

프로젝트 초기에 갈등의 원인은 다음의 순위라 할 수 있다
업무우선순위 > 일정 > ...

그리고 보편적인 경우, 그리고 프로젝트가 중반 이후로 갈 수록 갈등의 원인은 다음의 순위로 바뀐다
일정 > 업무우선순위 > 자원 > ....


프로젝트 수행 중 이러한 이슈들은 각 개인들의 견해차이를 발생시키고 결국 사람간 갈등으로 번지게 될 수 있다
PMI에서는 갈등의 당사자는 갈등해결에 1차적 책임이 있으며 갈등 해결에 반드시 참여해야 한다고 말한다
PMP에서 갈등을 해결하는 순서를 다음과 같이 제시한다

갈등 당사자간 사적으로 해결 => PM의 중재 => 공식적 절차

즉 당사자간 해결이 최선이며 이것이 힘들 경우 PM이 중재할 수 있다
만일 PM의 중재에도 갈등의 해결되지 않고 프로젝트에 악영향을 미칠 수 있다면 종국에는 징계와 같은
공식적인 절차를 사용할 필요가 있는 것이다


* 갈등을 바라보는 관점의 변화
현대에 와서 갈등의 평가는 과거와는 달라 졌다

과거의 전통적인 관점에서 갈등은,
특정 문제 유발자 때문이며 갈등 자체가 나쁜것이며, 웬만하면 피하거나 억압하여 갈등이 발생하지 않도록
하는 것이 최선이라 생각했다

그러나 현대의 관점은,
갈등은 피할 수 없는 것이며 변화에 따른 자연적 현상이며 관리할 수 있으며 관리해야 하는 것 그리고
갈등이 꼭 나쁜 것만은 아니며 가끔 이익이 된다는 관점으로 변화하고 있다

* 갈등 해결의 5가지 방법
갈등을 해결하기 위해서는 일방적으로 자기 주장만 할 수 없다
때로는 타협이 필요하며 한발 물러서거나 한발 나가거나 하는 융통성이 필요하다
갈등을 해결하는 5가지 방법에 대해 알아보자

1.철수/회피 (Withdrawal)
자기 주장도 하지 않고 타협도 하지 않고 그냥 회피하는 방법이다
낮은 주장, 낮은 협력으로 다음과 같은 상황에서 이러한 회피를 사용할 만 하다
- 이슈가 사소한 것일 때
- 추가적인 정보가 필요 할 때
- 자기의 의견이 관철될 가능성이 매우 낮을 때

이 방법은 일시적으로 상황을 진정시키는 효과는 있지만 가장 피해야 할 갈등해결 방법이라 하겠다

2. 양보/수용 (Smoothing)
자기의 주장은 낮추고 타협을 중시하는 방법이다
낮은 주장, 낮은 협력으로 다음과 같은 상황에서 이러한 양보를 사용할 만 하다
- 나중을 위하여 신용을 얻고자 할 때
- 조화와 안정이 매우 중요할 때(분위기가 우선일  때)
- 이슈가 갈등 상대방에게 보다 중요한 사안일 때

이 방법은 분위기를 중시하고 좋은 인상을 줄 수는 있지만 갈등의 근본적인 해결 방법은 아니라 하겠다

3. 타협 (Compromising)
자기의 주장도 적당히 하고 타협점도 찾는 방법이다
중간 주장, 중간 협력으로 다음과 같은 상황에서 이러한 타협을 사용할 만 하다
- 목표는 중요하나 더 이상 설득이 힘들 때
- 비슷한 파워를 가진 집단들 끼리의 갈등일 때
- 양측이 어느정도 만족할 수 있는 합의점을 도출할 때

이 방법은 양 당사자간 타협점을 찾는 좋은 방법이긴 하지만 만족도는 다소 떨어질 수 있다 하겠다

4. 강요 (Forcing)
자기의 주장을 강하게 고집하고 타협은 하지 않는 방법이다
높은 주장, 낮은 협력으로 다음과 같은 상황에서 이러한 강요를 사용할 만 하다
- 인기 없는 정책이지만 꼭 필요한 정책을 집행할 때
- 긴급한 사안을 결정해야 할 때
- 갈등 상대방보다 경쟁우위에 있을 때

이 방법은 자신의 주장을 관철시킬 수는 있지만 부작용이 따를 수 있다 하겠다

5. 문제해결/대면 (Problem Solving/Confrontation)
자신의 주장도 강하게 어필하면서 타협점도 적극적으로 찾는 방법이다
높은 주장, 높은 협력으로 다음과 같은 상황에서 이러한 문제해결을 사용할 만 하다
- 매우 중요한 통합된 의견을 도출하고자 할 때
- 공감대를 형성해 지속적인 관계유지가 필요할 때

이 방법은 시간이 오래 걸리는 단점이 있지만 갈등해결을 위한 가장 효과적인 방법이며 근본적인 갈등해결
방법이라 하겠다

이 글은  제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=479

---

프로젝트를 수행하기 위한 인적자원을 획득하고 관리하는 것에 대해 알아보자

* 팀 획득
팀 획득이란 말 그대로 팀원을 모집하는 것이다. 아래와 같은 방법으로 팀원을 셋팅하게 된다

1. 사전 배정
프로젝트 수행하기 전에 이미 일부 인원이 사전에 배정된 경우가 있다
예를 들어 경쟁 입찰 과정에서 특정 인원 투입이 약속되어 있는 경우, 프로젝트가 특정 개인의 전문성에 달려 있는
경우, 조직에서 사전에 배치 하기를 원하는 경우 등이다

2. 협상
다른 부서 혹은 다른 프로젝트 팀의 인원을 팀원으로 영입할 수 있다
이럴 경우 각 부서장 및 PM과의 협상을 통해 인원을 공급받도록 한다

3. 획득(조달)
조직 내부에 가용할 수 있는 인력이 없거나 부족한 경우, 외부에서 조달할 수 있다
보통의 직원 채용을 예로 들 수 있겠다

* 가상팀(Virtual Team)
보통의 팀은 같은 사무실에 같은 시간에 상주하며 일을 하게 된다
그러나 경우에 따라서는 원격에서 그것도 서로 다른 시간대에 일을 하게 될수 있다
원격으로 떨어져 전자우편이나 화상회의 등을 통해 프로젝트를 수행하는 팀을 가상팀(Virtual Team)이라 한다

다음과 같은 상황일 경우 가상팀으로 팀을 셋팅하게 된다
- 지역적으로 사람들이 프로젝트를 수행할 때
- 재택근무를 하는 사람들이 프로젝트를 수행할 때
- 근무시간이 다른 사람들이 프로젝트를 수행할 때

이러한 가상팀에서는 중요한 것은 의사소통이다
같은 장소에 같은 시간에 얼굴을 마주보며 일을 하지 않기 때문에 의사소통에 더욱 많은 신경을 써야 한다
또한 팀원들 간의 신뢰가 바탕이 되어야 원할한 프로젝트 수행이 가능하다
그리고 지역적으로 나아가 국가적으로 떨어진 사람들끼리 일을 하기 때문에 각 지역,국가의 문화(culture)를
알고 이해하고 배려하는 것이 필요하다

이러한 가상팀은 출장비 및 시,공에 제약을 받지 않는 장점이 있지만
PM이 팀의 통제가 어렵다는 점과 팀원 사이에 분쟁이 발생할 가능성이 높다는 점, 의사소통이 쉽지 않다는 점이
단점으로 작용할 수 있다

이러한 가상팀과 반대되는 개념이 공동 배치(Co-location) 이다
팀의 업무 수행능력을 향상하기 위해 물리적으로 동일한 장소에 배치하도록 한다
나아가 War room 과 같이 마치 전쟁터에서 중앙 상황실과 같은 개념을 도입해 프로젝트 진행 상황을
보다 적극이지고 직접적으로 팀원들과 공유할 수 도 있다


* 킥 오프 미팅(Kick-off meeting)
프로젝트를 본격적으로 수행하기 전에 하는 일종의 착수 회의이다
킥 오프 미팅은 프로젝트 초반에 수행하는 중요한 팀 형성 활동이며
프로젝트의 목표, 팀원의 역할과 책임을 정의하고 공유하는 자리이다
다만 킥 오프 미팅에서는 예산 및 비용, 계약과 관련된 내용은 토의하지 않는 것이 원칙이다

* 팀원들의 동기 부여
팀원들의 동기를 자극하기 위해서는 포상과 같은 직접적인 방법이 있을 수 있으며
기획과정에 팀원을 참여 시키는 방법 등과 같이 간접적으로 동기부여를 할 수 있다

포상 및 보상
- 반드시 성과에 근거해야 한다
- 분명하고 명확하고 실현가능해야 한다
- 상대 평가, 우수 사원 포상과 같은 개념은 제로섬(zero sum) 혹은 윈-로즈(Win-lose) 보상이라 하며
  팀 결속력을 해칠 가능성이 있으므로 주의해야 한다
- 팀원들이 각기 다른 문화권일 경우 보상 방식에 문화를 고려해야 한다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=477

---

프로젝트의 3대 제약사항인 범위,시간,원가가 충족되었을 때 비로써 프로젝트의 품질이 보장된다고 하였다

이러한 제약사항 속에 프로젝트를 원활히 수행하는 것은 다름아닌 사람이다
결국 어떤 사람이 어떤 역할과 책임으로 무엇을 어떤 방식으로 수행할지를 관리하는 것이 바로
인적자원관리(Human Resource Management)이다

그리고 인적자원관리 측면에서 인적 자원이란 범위는 프로젝트를 직접 수행하는 구성원 이외에도
고객, 오너, 스폰서, 외부 관계자, 프로젝트 연관자 등 모든 이해관계자가 포함된다

* 인적자원관리 프로세스
인적자원관리는 다음의 과정으로 이루어 진다
인적자원 기획 -> 프로젝트 팀 획득 -> 프로젝트 팀 개발 -> 프로젝트 팀 관리

1) 인적자원 기획
인적자원과 관련해 제일 처음 수행하게 된다
어떤 사람이 필요할지를 계획하고 이에 대한 인력 조달 계획을 수립하며
프로젝트의 R&R(역할 및 책임)을 정의하고 의사소통 관계 및 보고관계를 식별하는 과정이다

2) 프로젝트 팀 획득
말 그대로 사람을 뽑는 것이다. 프로젝트 수행을 위한 적절한 인적 자원을 효과적으로 획득하도록 한다

3) 프로젝트 팀 개발
사람만 뽑아 놓고 일만 시켜 놓았다고 해서 다 되는 것이 아니다
팀원들의 의지를 고취 시키고 역량을 꾸준히 개발 시킨다

4) 프로젝트 팀 관리
개개인의 성과를 파악하고 개선시킨다
사람대 사람간 발생한 갈등을 파악하고 해소시키며 인력의 변경 사항에 대해 관리하는 과정이다

* 조직 구조
조직이 어떠한 보고체계를 가지고 있으며 어떤 구성으로 조직되어 있는지 PM의 권한은 얼마정도 인지,
의사결정의 핵은 누가 쥐고 있는지 등의 조직의 고유 특성 및 구조가 인적자원에 있어 고려사항, 즉 제약사항이
될 수 있다

PMI에서는 조직구조를 다음과 같이 3가지로 구분하고 있다

1. 기능(Functional) 조직
기능조직은 한국 사회에서 가장 많이 볼 수 있는 조직 구조이다
특히 자체 솔루션을 개발하는 조직에서 가장 많이 보이는 구조인데 각각의 고유한 부서가 이미 존재하며
(이러한 부서를 기능부서라 한다) 프로젝트 수행을 위해 각 부서의 특정 인력이 배정되어 프로젝트가 수행되는
조직구조이다.
이러한 조직 구조에서의 PM의 권한은 아주 미미할 수 있다
즉 각 (기능)부서의 부서장이 이미 존재하기 때문에 PM의 의사결정권이 약하며 팀원들 역시 기능 부서장과
PM에 각각 보고해야 하며 프로젝트 수행을 위한 조직구조보다 기존 기능구조의 인식이 더 강해 기능 부서에
소속감이 더욱 강하다

2. 프로젝트화된(Projectized) 조직
기능 조직과 정 반대되는 개념이다
프로젝트 수행을 위해 똘똘 뭉친(?) 조직이며 이 조직의 목표 자체가 프로젝트 성공이 된다
즉 프로젝트를 위해서 조직이 존재하며 프로젝트를 위한 결속력 역시 강하다
이러한 조직 구조에서는 PM의 권한이 막강하다
팀 목표 자체가 프로젝트 성공이기 때문에 PM의 모든 의사결정권을 가지고 있으며 전사적 지원이 이루어 진다
기능 부서 처럼 각 부서의 이해관계에 얽매일 필요가 없어 프로젝트 수행에 효과적인 특성을 보인다
보통 외주를 받아 프로젝트를 수행하는 SI 조직에서 많이 찾아 볼 수 있는 구조이다

3. 매트릭스(Matrix) 조직
기능조직과 프로젝트조직의 중간정도의 특징을 가지고 있다
이러한 조직 구조에서의 PM의 권한은 역시 중간정도라 할 수 있다
PMI에서는 보다 매트릭스 조직을 보다 세분화 하고 있는데,
약한(Weak) 매트릭스, 균형(Balanced) 매트릭스, 강한(Strong) 매트릭스가 그것이다

약한 매트릭스 조직에서의 PM은 촉진자(expeditor) 역할을 하며 기능조직 부서장의 권한보다 적다고 할 수 있다
균형 매트릭스 조직에서의 PM은 기능조직 부서장과 유사한 권한을 행사할 수 있다
강한 매트릭스 조직에서의 PM은 매트릭즈 조직 상 가장 강한 권한을 가지며 기능조직 부서장보다 우위의
결정권을 가질 수 있는 구조이다

그러나 이러한 매트릭스 조직 구조에서도 대표적인 갈등의 주 요인이 권한 관계라 할 수 있다
완전히 프로젝트화 된 조직이 아니면 각 부서의 이해관계가 얽혀 있으며 이에 따른 관계가 갈등이 될 수 있다
PMI 에서는 이중 보고 및 애매한 권한 관계로 갈등이 발생하게 되면 PM이 해결하라고 권고하고 있다