프로젝트 홍반장, ‘Tiger Team’ 🐯

보기만 해도 늠름한 호랑이(무료이미지)

우선 프로젝트에 대한 개념을 살펴보자. 일상에서 ‘프로젝트’라는 단어를 자주 접할 수 있을 것이다. 특정 작업이나 작업이 모여 있는 묶음, 특정 목표를 위한 행위에 ‘프로젝트’라는 단어로 표현한다.

그렇다면, ‘프로젝트(Project)’는 ‘운영(Operation)’은 무엇이 다른가?🧐
이 둘의 관계는 연장의 형태를 띌 수 있지만, 개념 자체는 대조된다.

‘프로젝트’는 정해진 기간(한시적)에 점진적인 구체화 활동으로 불확실성을 제거하고 유일한 산출물(Deliverable or Outcomes)을 만드는 작업의 모음이다. 그런 이유로 PMBOK(Project Management Body Of Knowledge)에서는 각 지식 영역과 프로세스를 제시하고 ‘통합, 범위, 시간’을 주요 관리 영역으로 꼽고 있다.
‘운영’은 시스템이나 조직의 서비스 운영에 있어 서비스 운영 수준 관리를 통해 운영수준 진단 지표를 통해 시스템의 생산성 개선이나 안정적 관리를 주요 목표로 수립한다. 해당 부분은 ITIL에서 Best Practice를 관리하여 계속 업데이트되고 있다.

프로젝트에서 유한한 자원과 제한된 일정으로 목표 산출물을 생성하기가 항상 쉽지는 않다. 내부나 외부 요인으로 프로젝트의 근간이 흔들리거나 통합, 범위, 시간 측면에 치명적인 상황이 발생할 수 있다. 이럴 경우 Tiger Team이 투입되어 이른 Spot 성으로 처리해주는 역할을 진행한다.
그래서 제목에서도 언급한 것과 같이 ‘프로젝트 홍반장’ 역할을 도맡아 진행한다.

어디선가 누군가에 무슨일이 생기면 틀림없이 나타난다. | 홍반장

홍반장의 역량

 

역사와 함께하는 Tiger Team의 유래를 살펴보도록 하자.
우선 1970년대 아폴로 13호 달 착륙 임무에서 Tiger Team은 결정적인 역할을 진행했다. 임무 중 서비스 모듈 일부가 오작동으로 폭발하였고 전문가팀이 투입되어 이를 해결하여 그 공로를 인정받으면서 그 역사가 시작된다.

QA나 Testing을 業(업)으로 활동하시는 분은 자격 공부 진행할 때 보통 1장에 있는 Testing이 필요한 이유에 소프트웨어 사건 사고를 많이 접해봤을 것이다.

그런 사건 사고를 적시에 투입하여 해결하는 일을 위해 조직된 팀이라고 보면 된다. 이후에는 보안이라든지 환경, 안정, 보건, 우주 등의 다양한 프로젝트에서 무슨 일이 생기면 Tiger Team이 투입되어 처리되었고, 아마 지금도 그럴 것으로 생각한다.

Tiger Team은 조직의 규모와 상관없이 운영된다. 다만, 조직을 어떻게 운영할 것인지에 대한 정책이나 전략에 따라 개인 내지는 팀으로 구성되어 관리될 것이고 아직 몰랐다면, 지금이라도 심각하게 고민하길 바란다. Tiger Team 구성에 앞에 선발 대상군의 모든 경험이나 지식수준은 먼저 관리되어야겟죠?🙄

구성된 Tiger Team은 크리티컬 프로젝트에 중점을 두며 어떤 방식으로든 실패에서 구해내는 역할을 수행한다. 구성원은 일반적으로 각 부분의 전문가로 선발하며 특정 영역에 있어 Specialist나 광역적 지식이 필요한 Generalist를 요구할 수도 있다. 어찌 보면 이 팀은 마치 Marvel의 어벤져스(Avengers)가 아닐까 생각이 든다.

각 부분 전문가로 구성된 Avengers, 물론 역량은 조금씩 차이가 있지만…(원본)

Tiger Team은 다음과 같이 활동합니다.
(다르게 생각하면 모든 일은 아마도 이렇게 하지 않나요? 😁)

1. 증상과 그 영향을 관찰하고 문서화한다.
2. 발생할 수 있는 원인을 식별하고 검증한다.
3. 조직의 우선순위에 따라 수준을 정의한다.
4. 근본의 원인이 해결될 때까지 활동한다.
5. 적용할 수 있는 솔루션을 제시하고 협의/확정을 진행한다.
6. 솔루션은 구현하고 그 결과를 모니터링한다.

다소 간단한 단계 내지는 절차로 보일 수 있겠으나 기울어져가는 프로젝트 어떤 단계에서 이와 같은 작업은 그리 녹록지 않을 것으로 생각된다. Tiger Team은 프로젝트 진도 및 진척을 모두 정상 궤도로 올려놓고 문제 사항이나 특정 목적을 해결하고 프로젝트에서 철수한다.
해당 결과가 너무 흡족하여 프로젝트에 해당 인원을 포함하고 싶을지 모르겠다. 하지만, 프로젝트 내 이슈가 이곳에서만 발생할 것이라는 생각은 더 이상 하지 않는 것이 좋겠다. 갖은 방법을 다 써서 Tiger Team 구성원 하나를 프로젝트에 투입한 경우를 보았는데 그 결과는 좋지 않았다. 선순환을 위해 놓아주자.

복귀한 Tiger Team 구성원은 기본적으로 작업 일지나 Practice를 자산화한다. 자산화 내용 중 일부는 PAL(Project Asset Library)에 포함하여 관리하고 본 소속으로 복귀하거나 팀으로 유지하여 다음 작업을 계획한다.

 

지금까지 Tiger Team에 대한 내용을 살펴보았다.
필자는 QA(Quality Assurance)로 활동하는 사람이다. 그런데 왜 Tiger Team에 대해서 글을 쓰냐면 투입되었던 경험이 있기도 했고 그 경험이 짜릿해서 아직 기억나기 때문이다. 프로젝트 이슈 및 리스크를 늘어놓고 현실적인 대안을 찾아 제안하고 이를 빠르게 처리하여 힘들게만 보였던 프로젝트 종료로 마무리할 수 있었다. 어쩌면 QA나 PMO, PM역할을 하는 인원 처럼 프로젝트 Generalist와 기획이나 설계/구현의 Specialist가 Tiger Team 구성원의 적격이라고 생각한다. 다른 것이 Agile이 아니라 이런 것이 Agile 아닌가 싶다.

대부분의 프로젝트에 있어 Human Resource는 제한적인 것은 자명한 사실이지만, 지연되는 일정을 Human Resource로 대체하는 것이 현실이다. 그리고 이런 방식의 해결은 궁극의 해결로 볼 수 없다.

프로젝트 성공으로 가자!!(무료 이미지 링크)

Tiger Team 운영은 브룩스의 맨먼스 미신을 이겨낼 수 있는 근본적인 해결 방안이라고 필자는 생각한다. 아울러, 프로젝트 관리자의 빠른 판단 유도와 119 긴급 출동과 같은 체계를 마련해두는 것은 프로젝트 성공으로 가는 지름길이라고 생각한다.