박종명의 아름다운 개발 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://mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=478

---

우리는 흔히 R&R 이라는 말을 많이 사용한다

R&R의 정확한 의미는 무엇인가?
R&R 은 역할(Role)과 책임(Responsibility)을 줄여 표현한 말이다
말 그대로 어떤 역할과 어떤 책임이 있느냐인데, 아래와 같이 상세히 설명할 수 있다

* R & R
역할(Role): 해당 직원이 담당하고 있는 프로젝트 영역을 설명하는 표지. 프로젝트 성공에 필수적인 요소
책임(Responsibility): 프로젝트 활동을 완료하기 위해 프로젝트 팀원에게 수행하도록 배정되는 작업

프로젝트는 결국 사람이 수행한다고 하였다
프로젝트를 수행하는 개개인의 역할과 책임이 분명해야 프로젝트는 원활히 진행되고 구성원들의 만족도
및 책임의식도 증가할 것이다

이러한 R&R은 인적자원을 기획하고 관리하는데 있어 중요한 지표가 되는데 이와 더불어
권한과 역량도 같이 설명되어야 한다

권한(Authority): 의사결정 및 승인의 권한, 프로젝트를 위해 자원을 이용할 수 있는 권한 등
역량(Competency): 프로젝트 수행을 위한 기량과 능력

이렇게 역할,책임,권한,역량이 명확히 식별되고 잘 관리될 때 각 구성원들이 호흡을 맞추며 프로젝트를 원활히
수행하게 될 것이다

그리고 이러한 R&R 을 시각적으로 표현하기 위해 책임배정매트릭스(RAM, Responsibility Assignment Matrix)가 흔히 사용된다


* RAM (Responsibility Assignment Matrix)

일과 사람을 매핑한 도표이다
WBS(Work Breakdown Specification)는 작업을 분류한 체계이며
OBS(Organization Breakdown Specification)는 조직구성을 분류한 체계이다

이 둘을 합친 형태가 바로 RAM 이라 할 수 있다
WBS + OBS = RAM

RAM은 아래 그림과 같은 형태로 일과 사람을 매핑한 표이다

* RACI 포맷
RAM 에 개개인이 정확히 어떤 역할을 하는지 의미를 부여하는 표기 기법이다
R = Responsibile, A = Accountable, C = Consult, I = Inform
즉 책임, 담당, 자문, 정보 제공으로 그 역할을 명시하도록 한다(아래 그림 참조)

그리고 마지막으로 중요한 한가지...
책임과 권한이 다음의 공식을 만족할 때 각 구성원들의 최고의 업무 효율 및 동기를 끌어 올릴 수 있다

책임 == 권한 (책임과 권한이 일치해야 함)

이 글은 제가 과거에 운영했던 사이트인 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이 해결하라고 권고하고 있다

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

---

일정 개발의 기법 중 CCM(Critical Chain Method)라는 것이 있다

이는 각 활동 사이의 여유시간을 별도로 관리하여 일정을 타이트하게 운영하는 기법이다
이전에 살펴 봤던 CPM(Critical Path Method)을 통한 네트워크 및 일정 산출 방식은 동일하지만,
각 활동 사이의 여유 시간은 별도로 떼 내어서 필요시 여유시간을 적절히 공급하겠다는 원칙이다


다음과 같이 전체 일정안에서 각 활동을 수행하는 기간에 여유시간이 포함되어 있을 경우

여유시간을 각 활동사이에서 제거하여 별도로 모아서 관리하도록 하는 기법이다
이렇게 하여 불필요하게 노는시간(?)을 없애 프로젝트를 보다 타이트하게 운영하고자 하는 기법이다

눈치챘겠지만 이 기법은 관리자들이 만든 가장 최근에 등장한 기법이다
결론적으로 쉴 팀을 주지 않고 빡빡하게 일을 시키겠다로 해석될 수 있는데
이 기법에는 다음과 같은 이론이 뒷 받침 하고 있다

1) 학생 증후군(Student syndrome)
보통 학생들은 시험기간이 코 앞에 다가와야 벼략치기를 해서 최대의 집중을 발휘 한다
이렇듯 일이 닥치기 전에는 느긋함을 피우는 비효율적인 것을 예방하기 위해 CCM 기법이 만들어 졌다
그러나 이는 잘못하다가는 프로젝트를 지연시킬 수 있는 위험도 내포하고 있다

2) 파킨슨 법칙(Parkinson's Law)
모든 작업은 납기일을 준수한다. 역설적으로 말하자면 빨리 끝낼 수 있는 일이라도 납기일이 남았다면
천천히 수행하여 납기일만 맞춘다는 법칙이다

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

---

지금까지 프로젝트 일정을 산출하기 위한 사전 프로세스들에 대해 알아 보았다

활동정의, 활동 순서 부여, 활동 자원 산정, 활동 지속 기간 산정이 그 프로세스 들이다
이러한 사전 프로세스를 거치며 어떤 활동이 필요하며 이를 수행하기 위해 어떤 자원이 언제 필요하며
각 활동들간의 연관관계 및 개발 활동들의 소요 기간을 산정하였다

이제 이를 종합적으로 통합하여 프로젝트를 수행하기 위한 전체 일정을 산출하는 방법에 대해 알아보도록 하자

* CPM (Critical Path Method), 핵심 경로법
개별 활동들을 연결하여 '순방향 분석' 과 '역방향 분석'을 수행하여 각 활동의 시작일과 종료일 그리고 여유시간 및 전체 프로젝트 수행 기간을 산출하는 기법이다

* CP(Critical Path)
CPM에서 CP(Critical Path)는 핵심 주요 구간(경로)로써 각 활동들을 연결했을 때 수행 기간이 가장 긴 경로를 
나타내는데 이 구간은 여유시간이 0 이며 전체 프로젝트 소요 기간을 나타내므로 프로젝트 매니저가 가장
신경을 써야 하는 구간이다

다음의 그림을 보자
아래 표는 각 활동과 활동의 연관관계 그리고 개별 활동의 수행 기간까지 산정된 결과를 나타낸다

각 경로별로 수행기간을 계산 해 보면 다음과 같다
Path 1) start -> A -> C -> F -> end : 8일
Path 2) start -> B -> D -> F -> end : 6일
Path 3) start -> B -> D -> G -> end : 10일
Path 4) start -> B -> E -> G -> end : 13일

총 4가지 경로 중 가장 긴 수행 기간을 가지는 구간은 Path 4 가 된다
즉 Path 4 가 CP(Critical Path)가 되며 이는 곧 프로젝트를 수행하기 위한 총 소요시간이 되는 것이다
물론 프로젝트 매니저가 가장 신경을 써야 하는 구간이된다

참고로 위 표에서는 CP 가 1개 였지만, CP 는 경우에 따라 여러개가 될 수 도 있다
즉 최장기간이 동일한 구간이 여러개가 될 수 있다는 것이다
이렇게 CP가 많아지게 되면 프로젝트의 위험(Risk)이 올라간다

그리고 각 활동들의 수행 기간이 일부 변경되는 경우가 발생한다면 CP도 변경될 수 있으므로 주의깊에
살펴 봐야 한다
예를 들어 활동 D의 수행기간이 기존 2일에서 7일로 변경된다면
Path 3 일정이 총 15일이 되어 CP가 Path4 에서 Path3으로 바뀌게 된다

CP는 프로젝트 일정에 주의를 요하는 구간인 만틈 CP의 변경사항을 잘 파악하여 적절히 상황에 맞도록
프로젝트를 수행하여야 할 것이다


이제 순방향 분석과 역방향 분석을 통해 각 활동의 시작일과 종료일 그리고 여유시간을 산출해 보도록 하자

* 순방향 분석(Forward Scheduling)
Start 시점으로 부터 왼쪽 -> 오른쪽으로 계산하는 방식이다
ES(Early Start date): 빠른 착수라 해석하며 바로 앞 활동을 마친 후 착수 할 수 있는 가장 빠른 시점이다
EF(Early Finish date): 빠른 종료라 해석하며 ES 이후 활동이 완료되는 시점이다 

다음과 같이 활동(Activity)에 대한 기간 및 ES,EF를 표기하도록 한다

아래 그림은 각 활동들을 연결하여 ES 와 EF를 계산한 예시이다

1일 부터 시작하여 각 활동이 소요되는 기간을 더해 나가는 방식이다
활동 B의 경우를 보면, A 활동을 마친 후 빠르게 착수 할 수 있는 시점(ES)은 4일이 되겠다
그리고 4일, 시작 이후 B 활동을 마칠 수 있는 시점(EF)은 7일이 되겠다

이렇듯 '순방향 분석'을 통해 각 활동의 ES, EF를 계산할 수 있는 것이다
참고로 위 표에서 CP는 A->D->E->F->G 이며 프로젝트 총 소요시간은 18일이 된다


* 역방향 분석(Backward Scheduling)
순방향 분석과 반대로, End 시점으로 부터 오른쪽 -> 왼쪽으로 계산하는 방식이다
LF(Late Finish): 늦은 종료라 해석하며 바로 뒤 활동을 제때 시작하기 위해 본 활동이 종료되어야 하는 가장
                      늦은 시점을 말한다
LS(Late Start): 늦은 착수라 해석하며 LF 시점에 활동이 완료되기 위해 시작되어야 하는 시점을 말한다

다음과 같이 활동(Activity)에 대한 기간 및 LF,LS를 표기하도록 한다

아래 그림은 각 활동들을 연결하여 LF와 LS를 계산한 예시이다

End 일인 18일 부터 시작하여 활동이 소요되는 기간을 빼 나가는 방식이다
활동 F의 경우를 보면 G활동을 제때 시작하도록 하기 위해 종료되어야 하는 시점(LF)가 13일이 되겠다
그리고 13일에 활동이 종료되기 위해 이 활동이 시작되어야 하는 시점(LS)은 12일이 되겠다

이렇듯 '역방향 분석'을 통해 각 활동의 LF, LS를 계산할 수 있는 것이다

* 여유 시간
여유 시간은 말 그대로 프로젝트 수행 기간 동안 여유를 부릴 수 있는 시간을 말한다
CP 구간은 여유 시간이 0, 즉 여유가 하나도 없는 구간이라 했다
그러나 CP 구간을 제외한 경로에서는 여유 시간이 나올 수 있다

여유 시간은 다음과 같이 두 가지가 존재한다

1) Total Float (TF)
Slack Time 이라고도 하며, 프로젝트 납기일을 지연시키지 않으면서 각 활동이 가질수 있는 여유시간을 말한다
공식: TF = Min {LS-ES , LF - EF}. 즉 LS-EF 와 LF-EF 값 중 작은 값이 TF가 된다
CP(Critical Path) 구간은 은 TF가 0인 구간이다

TF > 0 경우에는 일정에 여유가 있는 것이며 TF = 0 은 일정 여유가 없는 CP 구간임을 의미한다

2) Free Float (FF)
후행(직후) 활동의 착수일(ES)를 지연시키지 않으면서 선행(직전) 활동이 가잘수 있는 여유시간을 말한다
공식: FF = EF - 직후 ES


TF와 FF는 다음과 같이 표기한다

TF와 FF 의 계산 공식을 도식화 해 보면 다음과 같다

아래 그림은 위에서 계산해 왔던 일정을 토대로 TF와 FF를 계산한 결과이다

지금까지 CPM(핵심경로법)을 통해 프로젝트 전체 일정은 물론이고 각 활동의 시작일/종료일을 산출할 수 있었으며
CP구간을 파악하고 프로젝트 수행 중 여유시간(TF,FF)를 도출하는 방법에 대해 알아 보았다

이렇게 산출된 일정이라 할 지라도, 일정을 단축해야 하는 이슈가 발생할 수 있다
PMI 에서는 프로젝트의 스펙(범위)를 변경하지 않고 프로젝트 일정을 단축하기 위한 방법으로 다음과 같은 기법이
제시된다

* 일정 단축 기법
1) Crashing
크래싱이라 발음하며 자원과 비용을 더 투입하여 일정을 단축시키는 기법이다
Crashing 는 프로젝트 전체 구간 중 CP(Critical Path) 구간에 자원을 먼저 할당하여 프로젝트 전체 일정을 줄이는
기법이다. 단 이 기법은 프로젝트 원가가 상승한다는 단점이 존재한다

2) Fast tracking
순차적으로 진행되는 활동들의 연관관계를 병렬로 작업함으로써 일정을 단축시키는 기법이다
통산 소프트웨어 프로젝트에 많이 사용되는 기법(밤샘?)이며 이는 프로젝트위 리스크가 증가할 수 있으며
재 작업 해야 하는 가능성이 있다는 단점이 있다

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

---

이전 글에서 일정관리를 위한 두 가지 프로세스를 정리 했었다

간략히 요약하자면,
범위관리에서 범위기술서를 분할한 WBS(WBS Package)를 다시 분할하여 활동(Activity)을 정의하고
이렇게 정의된 활동들의 연관관계 및 의존성을 식별하여 Project Schedule Network Diagram을 도출하였다

이 다이어그램의 표기방식으로는 PDM(Precedence Diagramming Method), ADM(Arrow Diagramming Method),
CDM(Conditional Diagramming Method)의 3가지 종류가 있었다. 이 중 많이 사용되는 기법이 PDM이다

이제 이 글에서는 하나의 활동(Activity)를 수행하기 위해 소요되는 기간(일정)을 산출하는 방법에 대해 알아 보자

그에 앞서 어떤 작업을 수행하기 위해 어떤 사람이 몇 명이나 필요할까? 또는 어떤 자원이 투입되어야 하는가?
에 대한 정의를 해야 할 것이다. 이러한 자원에 대해 정의하는 프로세스가 '활동 자원 산정' 이다

활동 자원 산정(Activity Resource Estimating)
각 활동 수행에 필요한 자원의 유형과 양(어떤 자원을 언제, 얼만큼 사용 할 것인지)을 산정한다

이 과정에서는 어떤 자원이 언제 필요하다라고 명시한 '활동 자원 요구사항'을 도출하고 '자원 달력'을 수정,
갱신하게 된다. 자원 달력은 근무일/휴일, 각 일자별 특정 인적/물적 자원의 가용현황을 결정 및 표시하는 수단이다

활동이 정의되고 활동에 필요한 자원이 산정되면 이제 본격적으로 개별 활동에 대한 소요 기간을 산정하게 된다

활동 지속 기간 산정(Activity Duration Estimating)
개별 활동들의 작업기간을 산정한다. 이 과정에서 정량적인 기간 값이 결정된다
기간을 산정, 추정하기 위해 여러 기법이 도입될 수 있는데, 통상 모든 추정의 기법이 되는
전문가 판단, 하향식 추정, 상향식  추정, 유추 추정, 모수 추정 기법이 사용될 수 있다

이러한 추정 기법에 대한 내용은 다음에 차근차근 알아 보도록 하고,
여기서는 일정 관리 분야에서 널리 알려진 PERT에 대해 알아 보자 

* PERT (Program Evaluation Review Technique)
'퍼트'라고 발음한다
3가지 추정치를 이용해 일정을 산정한다고 하여 3점 추정치(Three-point Estimating)라고도 한다
3가지 추정치란 비관치(p),최빈치(m),낙관치(o) 를 말한다

p (Pessimistic) : 비관치, 비관적 추정치, 최악의 일정(일정을 최악으로 길게 잡는다)
m (Most likely) : 최빈치, 가장 가능성이 높은 일정
o (Optimistic)  : 낙관치, 가장 좋은 일정, 가장 짧은 일정

이 세가지 값이 추정되면 다음의 공식으로 Mean(평균) 값과 Sigma(표준편차)를 계산한다
Mean(평균)        = (p + 4m + o) / 6
Sigma(표준편차) = (p - o) / 6

이렇게 계산된 Mean(평균)값으로 활동의 소요기간을 도출할 수 있으며,
이렇게 도출 된 평균과 Sigma(표준편차)를 이용하면 달성 확률을 계산 할 수 있게 된다

Sigma(표준편차)는 평균값으로부터 벗어난 정도를 보여주는데,
다음과 같이 신뢰도를 평가하게 된다. 신뢰도란 정규분포에서 표준편차에 따른 확률값을 말한다
Mean +- 1sigma = 68%
Mean +- 2sigma = 95%
Mean +- 3sigma = 99%


공식만 봐서는 이게 무신 말인고 싶다. 간단한 예를 보도록 하자

문) 어떤 작업의 수행기간을 PERT 기법을 이용해 기간을 산정하고 있다.
이 작업에 대한 3가지 추정치는 다음과 같다
p: 36일
m: 21일
o: 6일
이때 이 작업의 수행기간은?

답) 공식에 대입해 보면,
Mean = (36 + 4*21 + 6) / 6 = 21 , 즉 수행기간은 21일이 되겠다

문) 위 작업이 11일에서 31일 내에 끝마칠 수 있는 확률은 얼마나 되는가?

답) 달성확률을 알기 위해서는 Sigma(표준편차)를 계산해야 한다
Sigma = (36 - 6) / 6 = 5, 표준편차는 5일이 된다

이제 신되로 공식에 의거하여, 평균과 표준편차를 이용해 11일에서 31일 내에 마칠 수 있는 확률을 계산해 보자
Mean : 21일
Sigma: 5일

11일 에서 31일은 Mean += X*sigma 공식에 Mean 값과 Sigma 값을 대입해 보면 
11일 = 21 - X * 5 => X는 2가 된다
31일 = 21 + X * 5 => 역시 X는 2가 된다

결과적으로 Mean +- 2sigma 영역에 있으므로 95% 라는 확률 값을 얻을 수 있다
작업을 즉 11일에서 31일 사이에 달성할 수 있는 확률은 95%가 된다

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

---

프로젝트 수행에 있어 아주 중요한 부분이 시간 즉 일정관리 일 것이다

PMI에서도 프로젝트의 3대 제약사항으로 범위,시간(일정),원가(비용)을 꼽고 있다
이 세가지가 만족했을때 프로젝트 결과물에 대한 품질이 보장된다고 하였다

그럼 지금부터 PMI에서 정의한 시간관리의 프로세스를 살펴보도록 하자

활동(Activity) 정의
프로젝트를 착수할 때 '예비프로젝트 범위 기술서'를 정의해야 한다
이 말은 구체적인 프로젝트 스펙을 처음부터 다 정의할 수는 없지만 무슨 일을 해야 한다는 정도의
추상적인 스펙이 나와야 하는데 이를 정의하는 것이 '예비프로젝트 범위 기술서'라 한다

그리고 난 후, 실질적인 프로젝트 범위에 대한 기획단계에서 스펙을 기획,정의하여 범위기술서를 정의하며
이를 더욱 분할,구체화시킨 것이 WBS명세서이다.
또한 WBS를 다시 한번 세세하게 분할한 것이 WBS Package 라 한다

당연하겠지만, 시간관리 즉 일정을 산출할때 가장 중요한 근간이 되는 것이 바로 프로젝트 범위이기 때문에
범위관리에서 산출된 범위기술서,WBS,WBS Package 가 일정산출에 중요 근간 자료가 된다

범위를 구체적으로 정의하고 세부적으로 분할한 WBS(WBS Package)를 더욱 분할하여 '활동(Activity)'을 정의한다
WBS에서 정의된 각각의 세부 범위를 수행하기 위한 활동을 파악하고 정의하는 것이다

지금까지 이야기한 내용을 그림으로 나타내면 다음과 같다

활동 순서 부여
이렇게 하여 활동이 정의되면, 각 활동들 간의 연관관계를 파악해야 한다
이를 '활동순서부여'라 하는데 정의된 활동들간의 관계를 파악하고 각 활동의 순서를 부여하는 것이다

이때 사용되는 기법이 Project Schedule Network Diagram 인데 이는 다음과 같이 나우어 진다
각 활동을 표현하고 활동들간의 연관관계(의존성)을 표현한 다이어그램 표기 기법이라 할 수 있다

1) PDM(선후행 도형법, Precedence Diagramming Method)
각 활동을 노드(node) 위에 표시하고 화살표로 각 활동의 의존관계를 표현한다
노드에 표현된다고 하여  AON(Activity-on-node)라고도 한다
PDM을 이용하면 각 활동들간의 연관관계를 4가지 형태로 표현할 수 있다
- FS(Finish-to-start)
  말그대로, 앞의 작업이 끝나야 뒤 작업을 시작할 수 있는 개념
- FF(Finish-to-finish)
  앞으 작업을 마쳐야 뒤 작업도 마칠 수 있는 개념
- SF(Start-to-finish)
  앞의 작업을 착수해야 뒤 작업을 마칠 수 있는 개념
- SS(Start-to-start)
  앞의 작업을 착수해야 뒤 작업을 시작 할 수 있는 개념

2) ADM(연결선 도형법, Arrow Diagramming Method)
각 활동을 노드가 아닌 화살표(arrow)위에 표현한다
화살표에 표현된다고 하여 AOA(Activity-on-arrow)라고도 한다
ADM으로는 각 활동들의 연관관계 중 FS(Finish-to-start)만 표현 가능하다
기타 연관관계가 필요하면 Dummy Activity(점선)으로 표현할 수 있다

3) CDM(조건부 도형법,Conditional Diagramming Method)
이는 마치 각 활동의 관계를 프로그래밍 처럼 조건에 의해 순환(loop),분기(if)되는 구조를 표현한다


아래 그림은 소프트웨어 프로젝트에서 Project Schedule Network Diagram를 표현한 예시인데,
PDM으로 표현한 것이다.

중요한 것은 Project Schedule Netowrk Diagram 에서는 활동과 활동들간의 연관관계만 표시하지,
소요되는 시간 및 기간정보는 표현하지 않는다는 점이다.

프로젝트의 일정개발은 각 활동을 수행하기 위해 소요되는 자원(리소스)를 산정하고 개별 활동의 기간을 개개별로
산정하여 일을 통합함으로써 완성된다

경우에 따라서는 각 활동들의 연관관계를 보다 세밀하게 정의하기 위해서 선도 및 지연을 정의할 수 있다

Lead(선도)는 FS(Finish-to-start)관계, 즉 앞의 활동이 완료되어야 뒤의 활동을 시작할 수 있는 관계를
조정하여 앞의 활동이 진행 중일때 뒤의 활동을 시작하여 일정을 단축시키는 개념이다

Lag(지연)은 반대로 FS관계에서 앞의 활동이 끝난 후에 일정기간이 지난 뒤 뒤의 활동을 시작하는 개념이다

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

---

프로젝트 관리에서,
주어진 일정과 오픈 예정일은 아주 민감한 부분이죠.

'인간사'에서도 약속을 잘 지켜야 하듯이,
프로젝트도 약속을 잘 지켜 적시 완료를 보장해야 기본을 한 것 이겠죠 

PMBOK 의 프로젝트 관리 9대 지식영역 중, '6.1 시간관리'에 대해 정리합니다.
내용이 방대하지만 나름 핵심만 정리해 봅니다

6.0 시간관리 

* 프로세스 매핑표

 * 일정기획(계획)은 ‘4.0통합영역’ 기획 프로세스그룹의 ‘4.3 프로젝트관리계획개발’ 프로세스에 선행됨

* 시간관리 도식화

아마... 아래 그림은 한번쯤은 본 적이 있을 겁니다.
개개인의 서로 다른 재능을 무시한채, 획일적인 기준으로 평가하는 문제를 풍자하는 그림인데요..

이 카툰은 획일적인 교육과 평가에만 의존하는 교육분야의 문제 인식으로 자주 인용되지만, 기업의 경영 전략에도 대입해 볼 수 있다는 생각이 듭니다.

기업의 존재 목적은 수익 창출입니다. 모든 기업은 수익을 창출하기 위해 다른 기업과는 차별화된 재화나 서비스를 시장에 공급합니다. 이러한 수익 창출 과정에서 주어진 자원을 최대한 효율적으로 사용해서 수익을 극대화 시키고 리스크(risk)를 경감하는 것이 중요합니다.

따라서 기업은 자신이 제공하는 핵심 서비스 전개를 위한 업무 역량은 자체적으로 내재화 시켜서 경쟁력을 확보하고 다른 기업과의 차별화를 꾀해야 합니다. 

반면, 핵심 서비스에 직접적이지 않은 비 핵심업무는 다른 기업이나 다른 사람에게 위임하여 그들의 전문성을 활용하는 것이 좋습니다. 그렇게 해야 생산성이 향상하고 리스크를 경감할 수 있습니다. 

기업의 외주(아웃소싱) 전략에 좋은 참조 모델이 있어 소개하고자 합니다.

---

'캐즘(Chasm) 이론'으로 유명한 제프리 A.무어의 '코어/컨텍스트(Core/Context) 모델'은 기업이 주어진 자원을 어떻게 운용하는 것이 좋을지에 대한 참조 모델을 제시하며 '클라우드 충격'이라는 책에서 자세히 설명하고 있습니다.

코어(Core)란 의미 그대로 기업의 핵심 업무를 말합니다. 코어 업무는 기업의 경쟁우위를 높여주는 중요한 것이므로 최대한 자원을 집중해야 하고 자체 개발을 해야 한다는 것입니다.

반면 컨텍스트(Context)는 코어 이외의 모든 활동이라고 말합니다. 컨텍스트 업무는 차별성을 추구하는 것이 아니라 가능한 표준적인 방식으로 효율을 최우선으로 수행하는 것'이 좋다고 말합니다.

또한 이러한 컨텍스트 업무는 어느 누군가에게는 코어 업무이기 때문에 그쪽에 아웃소싱을 맡길 수 있다고 시사합니다.

게임을 개발하는 기업에서 인사관리 프로그램이 필요한 사례를 예로 들어 보겠습니다.
게임 개발은 회사의 중요한 코어 업무이기 때문에 자체 개발을 해야 하며, 인사관리 프로그램은 컨텍스트 업무이기에 그 업무를 코어로 하는 외부 업체에게 아웃소싱 하는 식입니다.

그러나 코어/컨텍스트만으로는 기업내 모든 활동을 양분하기에는 한계가 있어 보입니다.

무어는 코어/컨텍스트 구분과 더불어, '미션크리티컬/'비미션크리티컬' 이라는 또 하나의 축을 또 다른 기준으로 내세웠습니다. 미션 크리티컬은 만일 중지되었을 때 즉시 심각한 리스크로 이어지는 기업 활동을 말하며 그 외의 모든 업무는 비 미션크리티컬이 됩니다. 즉 리스크의 정도를 기준으로 삼고 있습니다.

이에 대한 도식은 아래와 같습니다.

[출처: 클라우드의 충격]

---

제가 속해 있는 IT 분야에서도 아웃소싱 전략에 큰 영향을 주는 두가조 요소가 있습니다.

바로 클라우드(Cloud)와 오픈소스(Opensource)입니다.

오픈소스의 경우 외주(아웃소싱)라는 카테고리와는 성격이 조금 다를 수 있지만, 특정한 업무를 외부 자원으로 해결한다는 위임이라는 측면에서는 맥을 같이 하기에 연결지어 봤습니다.

클라우드의 경우 종전의 자체 전산실에 직접 렉과 장비를 구비하고 운영했던 온프레미스(On-Premise) 환경과는 달리 클라우드 환경에서는 이러한 물리적인 장비와 운영체제, 소프트웨어까지 빌려 쓸 수 있게 되었습니다. 또한 기업은 자신들이 어디 까지를 직접 운영할지 결정하여 Iaas, Paas, Saas 형태의 클라우드 서비스 모델을 선택할 수 있습니다. 

갈수록 IT 환경의 판이 많이 달라지고 있습니다. 자원을 최적화 시키는 것은 기업의 생산성을 향상시키는 것 뿐만 아니라, 서로 다른 재능을 가진 기업간 위임이 활성화 되어 산업의 발전에도 기여하게 된다고 봅니다. 과거 분업화가 많은 발전을 야기한 것 처럼요.

현재 자신의 회사나 수행하는 프로젝트에서, 코어와 컨텍스트, 미션크리티컬과 비미션크리티컬의 4사분면에 해당하는 업무가 무엇인지 파악하여 전략을 재정비 해 보는 것도 좋을 것입니다.

지금까지 IT업계에 20년 가까이 일을 하면서, 많은 팀을 겪어 왔습니다.
역할로는 팀원에서부터 파트장, 팀장까지 다양하게 경험을 해왔으며 현재도 진행중이지요.

팀과 프로젝트를 리딩한 경험도 다양한데, 팀의 규모로는 3명에서부터 20명이 넘는 팀을 리딩해 본 경험이 있습니다.

또한 경험해 온 조직 환경도 무지 다양한데, 여러 회사의 다양한 팀 구조와 문화를 체험했습니다.
 
인터넷 컨텐츠 회사에서 부터, 게임회사, 대기업 SI 등의 서로 다른 조직 문화에서 팀 작업을 수행해 왔으며, 팀의 조직화 특성으로는 보통의 기능조직 성격의 팀에서부터 프로젝트에 특화된 TFT(Task Force Team) 형태의 팀구조를 겪어 봤습니다.

지금까지 제가 경험해 온 팀들은 제각각 다른 특성이 있었지만, 결국 사람이 모여서 일을 하는 것이라는 점에서 팀의 근원적 특성은 크게 다르지 않았습니다. 즉 팀이 결성되고 협업하고 때론 갈등에 직면하고 목표를 달성해 나가는 근본적인 원칙과 과정은 크게 다르지 않았다고 생각합니다.

오래전 팀리딩을 시작하게 되면서, 프로젝트 관리와 동기부여에 관련된 다양한 이론과 지식을 찾아서 학습해 왔습니다. 그전(팀원일때)에는 관심 없었던 다양한 경영이론과, 심리학 이론 등이 존재하더군요.

이 글에서는 그 중 하나인, Tuckmana의 팀 발달 모델을 소개하고 제 개인의 경험과 접목하여 글을 정리해 볼까 합니다.

Tuckman's Team Development Model

1965년, 심리학 교수인 Bruce Tuckman은 'Developmental Sequence in Small Groups'이라는 논문을 통해 Team Development Model이라는 경영이론을 발표했습니다.

팀이 형성되고 발달해 나가는 과정을 4단계로 나눈 이 모델은, 각 단계별로 팀이 겪게 되는 특징을 잘 설명합니다. 첫 논문 발표시 4단계였던 것이 1977년에 Adjourning 단계가 추가되면서 현재는 총 5단계 모델로 알려져 있습니다.

국제적인 프로젝트관리 협회인 PMI에서 발행하는 PMBOK에서도 '인적자원관리'라는 챕터에 '프로젝트 팀 개발' 이라는 지식영역에서 이 모델을 팀 관리의 참조 모델로 안내하고 있습니다.

팀 리더는 팀 운영과 프로젝트의 성공을 위해 이 모델을 활용할 수 있습니다. 팀이 발달하는 과정을 이해하고 각 단계별로 당면하는 팀의 상황과 각 상황별로 필요한 리더십 스타일을 이 모델의 이론에 근거하여 결정할 수 있습니다.

개인적으로도 이 모델은, 그간 제가 맡아온 팀을 이해하고 문제를 해결하고 리딩 스타일을 결정하는데 많은 도움이 되었습니다.

Tuckman에 의하면 팀은 (아래 도식에서와 같이)  5단계의 과정을 거치게 됩니다. 처음에 혼돈과 불확실성으로 가득찬 상태에서 긴장과 대립, 갈등이 촉발되는 시기가 옵니다. 이후 각 시행착오를 거치면서 팀은 성장하고 프로젝트를 성공적으로 완수할 수 있게 됩니다. 물론 잘 운영되는 경우에 말이지요.

출처: https://www.lfhe.ac.uk/download.cfm/docid/3C6230CF-61E8-4C5E-9A0C1C81DCDEDCA2

Tuckman의 이론을 하나의 표로 요약해 봅니다.

처음 이 모델을 봤을 때, 참으로 공감되는 내용이 많았습니다.

제가 맡은 여러 형태의 팀들 중에서도 특히, 프로젝트에 특화된 팀(TFT)이나 SI 프로젝트를 수행하는 팀 구조에서 이 모델의 적합성이 더 높았습니다.

각 단계별 리더십 스타일

이 글에서 하고자 하는 얘기의 핵심입니다. 팀리더가 어떻게 해야 팀을 원만하게 운영하고 프로젝트를 성공시키느냐 하는 것입니다.

팀리더는 프로젝트를 성공시키고 팀을 성장시키는데 책임이 있습니다. 그 책임을 다하기 위해서는 팀과 팀 구성원들을 정확히 이해하고 자신의 리더십 스타일을 적절히 변경할 수 있어야 합니다.

즉 팀 리더는 Tuckman의 모델에 참조하여 팀을 이해하고 자신의 리더십 스타일을 결정하거나 조정할 수 있습니다.

여기에 좋은 안내서가 있습니다.

https://kristalaace2014.wordpress.com/2014/02/26/w1_al_tuckman-analysis-assignment/comment-page-1/

위의 표는 각 단계별로 팀리더의 스타일을 안내하고 있습니다. 저도 이 표를 보면서 간과했던 부분을 다시금 깨닫는 계기가 되었습니다.

형성기(Forming)

모든것이 불명확하고 불확실한 상태입니다. 프로젝트의 목표와 과제에 대해 공감과 이해가 부족한 상태이며, 구성원들은 서로 어색하고 신뢰가 형성되지 않은 시기입니다.  

'우리가 여기에 왜 모였는가?'' 를 분명히 해야 합니다.

팀 리더는 팀 구성원들이 길을 잃지 않고 프로젝트를 수행할 수 있는 초석을 마련해야 합니다. 프로젝트의 목표와 방향성을 명확히 수립하고 전달해야 합니다. 또한 R&R을 설정하는 동시에 구성원 개개인과 프로젝트 과제(What) 자체에 집중해야 할 시기입니다.

다시 말하자면, 우리가 왜 모였으며 무엇을 언제까지 누가 어떤 일을 해야 하는지를 명확히 해야 할 시기입니다. 그러므로 이 시기에는 보다 직접적인 리더십 스타일이 필요한데 이를 지시형 리더십 스타일이라 하겠습니다.

격동기(Storming)

앞서 형성기의 단계를 거쳐, 팀 구성원들은 프로젝트의 목표와 개인의 역할을 인지하게 되었습니다. 이제 본격적으로 각 구성원들이 프로젝트를 위해 일을 시작하는 시기입니다. 그러나 이제 막 모인 사람들은 각자의 업무 스타일과 개성이 표출됩니다. 이로 인해 잦은 의견충돌과 대립이 발생하면서 긴장상태로 접어들기도 합니다. 말 그대로 격동기 입니다.

팀 리더로써 가장 중요한 시기입니다. 다름과 틀림을 구분할 수 있도록 해야 합니다. 구성원들의 서로 다른 업무 스타일로 갈등이 고조되지 않도록 하는 조치가 필요합니다. 팀이 일을 하는 방식에 대한 표준(기술표준, 프로세스 표준, 의사결정 방식 등)이 반드시 필요합니다. 각자의 스타일을 존중하되, 협업을 위한 표준으로 각자의 업무 스타일을 조화시켜야 합니다.

이 시기의 팀 리더는 구성원들의 개인적인 상호작용에 많은 관심을 가져야 합니다. 구성원들의 의견 불일치, 갈등을 적극적으로 중재해야 합니다. 이때 팀의 표준과 프로세스가 많은 도움이 됩니다.

코치형 리더십 스타일이 필요하다 하겠습니다. 특히 개인적인 관계를 촉진하는 역할이 중요합니다.