해법을 깔끔하게 정리하는 기술   

2010. 5. 25. 09:00
반응형


개인의 문제든 조직의 문제든, 문제를 일으킨 핵심원인이 규명되면 그것을 제거하거나 약화시키기 위해 해법을 찾아야 합니다. 규명된 핵심원인을 뒤집어 생각하면 곧바로 해법이 되기도 하지만, 늘 그렇지는 않습니다.

가령 "직원들의 근무태도가 상당히 나태하다"란 문제의 핵심원인으로 "해당 팀장의 취약한 리더십"이 규명됐다고 가정해보죠. 그렇다면 이 핵심원인을 뒤집어서 "해당 팀장의 리더십을 강화한다"라는 해법을 뽑을 수 있습니다. 


물론 의뢰인에 이 정도 수준의 해법도 의미가 있는 경우도 있지만, 어떤 의뢰인에게는 "리더십을 강화하라는 말은 알겠는데 도대체 그걸 어떻게 해야 하나?"란 반문을 받을지도 모릅니다. 좀더 구체적인 해법을 요구하는 것이죠.

해법이 의뢰인에게 구현 가능하게 느껴지려면 해법을 찾는 단계에서부터 가능한 한 구체적인 내용을 해법 안에 담을 수 있게 해야 합니다. 이를 도와주는 기법이 바로 'Duncker 도표(Duncker Diagram)'입니다.

Duncker 도표는 다음과 같은 절차에 따라 작성합니다.

(1) 핵심원인을 맨 위에 둔다
(2) 핵심원인의 좌하단에 '희망하는 상태'를 기술한다
(3) 핵심원인의 우하단에는 희망하는 상태가 아니어도 '수용 가능한 상태'를 기술한다
(4) 각 상태를 이루기 위해서 '무엇을 해야 하는가?'에 대한 해법을 기술한다
(5) '무엇을 해야 하는가?'에 대하여 '어떻게 해야 하는가?'에 대한 해법을 기술한다

이렇게 설명하면 딱딱하기도 하거니와 이해도 쉽지 않으니, 예를 들어 설명하겠습니다. "직원들의 근무태도가 나태하다"란 문제의 핵심원인이 "팀장의 취약한 리더십"이라고 한다면, 다음과 같은 모양으로 Duncker 도표가 그려집니다.


'희망하는 상태'에 대한 해법
핵심원인이 "팀장의 리더십이 취약하다"이므로 문제해결사가 희망하는 상태는 "팀장의 리더십을 강화해서 문제를 해결한다"가 됩니다. 그런 상태에 도달하려면 무엇을 해야 할까요? 이 질문에 대한 답을 그 아래에 적습니다. 위 그림에서 "리더십을 교육한다"와 "리더십 문제를 자각하게 한다"와 같은 해법이 바로 그것입니다.

헌데 이 해법들은 '어떻게 해야 하는가?'란 질문을 통과하면서 좀더 현실감 있게 구체화되어야 합니다. 예를 들어 "리더십의 문제를 자각하게 한다"는 해법은 "리더십에 대한 주변의 평가를 피드백해 준다"라는 해법으로 구체화됩니다. 만약 그 자체로 '어떻게 해야 하는가?'에 대한 답이라면 전개하지 않아도 됩니다.


'수용 가능한 상태'에 대한 해법
핵심원인을 기준으로 오른편에 위치한 '수용 가능한 상태'란 핵심원인이 제거되지 않으면서 문제를 해결할 수 있는 방법을 논의하기 위한 틀입니다. 즉, 팀장의 리더십을 강화하지 않더라도 문제를 해결할 방법은 없는지 살펴보자는 것이죠. 핵심원인을 제거하거나 약화시키는 것만이 옳은 해법은 아니기 때문에 '수용 가능한 상태'를 꼭 살펴야 합니다. 해법을 기술하는 방법은 '희망하는 상태'의 기술 방법과 동일합니다.

일상적인 예
보다 쉽게 이해하기 위해서 일상적인 예를 들어보겠습니다. 사각형 모양으로 드넓은 잔디밭이 있는데 사람들이 잔디밭을 우회하지 않고 가로질러 간다고 해보겠습니다. 그렇게 되면 사람들이 자주 다니는 경로의 잔디들이 밟혀 죽어서 보기 흉한 흙길이 잔디밭 한가운데 만들어집니다. 여기서 핵심원인은 "사람들이 잔디밭을 가로질러 횡단한다"가 되겠죠.

여러분이 잔디밭 관리자라면 '희망하는 상태'는 "사람들이 잔디밭을 횡단하지 못하게 한다"입니다. 이에 대해서 '무엇을 해야 하는가?'란 질문에 해당하는 해법 중 하나는 "잔디밭에 들어오려는 사람들에게 벌을 준다"일 겁니다. 그리고 다시 '어떻게 해야 하는가?'란 질문을 던지면 다음과 같이 수많은 해법이 추출되겠죠.

'희망하는 상태'에 대한 해법 기술

무엇을 해야 하는가? : "잔디밭에 들어오려는 사람들에게 벌을 준다"
어떻게 해야 하는가?
   (1) 잔디밭에 들어간 사람에게 벌금을 물린다
   (2) 잔디밭 안에 고압 전류를 흐르게 한다
   (3) 잔디밭에 들어가면 나오지 못하게 막는다, 등등

이 해법들은 모두 '희망하는 상태'에 해당하는 해법입니다.

반면 '수용 가능한 상태'는 "사람들이 잔디밭을 횡단하게 놔두면서 문제를 해결한다"입니다. 이 상태에 이르려면 무엇을 해야 할까요? 여러 가지가 있겠지만 "잔디밭을 횡단하도록 장려한다"란 해법이 있습니다. 좀 이상한 해법이라고요?

잔디밭에 보기 흉한 길이 난 이유는 동선(動線)을 줄이려는 경향 때문입니다. 그래서 그 흙길에 자갈이나 보도블럭을 깔고 길 가장자리에 꽃을 심어 놓아 사람들의 통행을 장려하면, 사람들의 칭찬도 듣거니와 다른 부분의 잔디를 보호하는 1석 2조의 효과를 얻기 때문에 오히려 훌륭한 해법일지도 모릅니다. 따라서 '수용 가능한 상태'에 대해서는 다음과 같이 해법이 기술될 수 있습니다.

'수용 가능한 상태'에 대한 해법 기술

무엇을 해야 하는가? : "진디밭을 횡단하도록 장려한다"
어떻게 해야 하는가?
  (1) 흙길에 자갈이나 보도블럭을 깔고 가장자리에 꽃을 심는다
  (2) 사람들이 밟아도 끄떡없는 품종의 잔디를 심는다
  (3) 잔디밭 위로 지나가는 육교를 설치한다, 등등

이런 방법으로 해법들을 전개해 나가는 과정이 바로 Duncker 도표의 작성입니다. Duncker 도표에서 가장 밑단에 위치한 박스들이 해법의 후보가 되는데, 검증 과정을 통해 어떤 해법이 가장 효과적이고 효율적이며 '윤리적'인지를 따짐으로서 최적의 해법을 선정하면 됩니다.

그런데 보다시피 Duncker 도표는 몇 번의 조작으로 쉽게 해법을 '톡' 뱉어내는 자판기가 아닙니다. Duncker 도표는 적용 가능한 해법의 후보들을 기술하기 위해서 '사고의 프로세스'를 도와주는 틀로서 의미가 있음을 염두에 두기 바랍니다.

해법을 궁리 중이라면 종이 위에 Duncker 도표를 그려보세요. 어지럽게 머리를 돌아다니는 생각들이 정리되면서 해법의 '스펙트럼'이 어디에서 어디까지인지 가늠하는 효과를 얻을 겁니다.

오늘도 즐겁게 문제해결 하세요~!


인퓨처컨설팅 & 유정식의 포스트는 아이폰 App으로도 언제든지 볼 수 있습니다.  여러분의 아이폰에 inFuture App(무료)을 설치해 보세요. (아래 그림 클릭!)
                   
inFuture 앱 다운로드 받기
 
반응형

  
,

챌린저호는 왜 폭발했나?   

2010. 5. 24. 09:00
반응형

우주왕복선 챌린저호 폭발 사고를 기억하십니까? 1986년 1월 28일, 챌린저호는 발사된지 73초만에 공중에서 폭발하고 맙니다. 교사 신분으로 우주인으로 선정된 민간인 여성을 포함한 7명의 승무원들은 안타깝게 사망하고 말았습니다.

직접적인 원인은 로켓 부스터 내에서 누출을 막아주는 고무 오링(O-ring)이 추운 날씨로 인해 갈라져서 제대로 기능하지 못했기 때문으로 밝혀졌습니다. 유명한 물리학자인 리처드 파인만이 진상규명위원회의 위원으로 참여해서 얼음물 속에 클림프로 꽉 조여진 고무 오링의 샘플을 넣으면 어떻게 되는지 생생하게 보여주기도 했지요.

(챌린저호 폭발 모습)


사고가 터지면 왜 그것이 발생했는지를 따지는 일련의 진상규명 작업이 뒤따르기 마련이지만, 챌린저호 사건은 미국의 우주개발 노력에 치명타를 가한 중대한 사건이었기에 각계의 전문가가 NASA의 잘못을 집중적으로 캤습니다.

그들 대부분은 NASA가 방만하게 조직을 운영한다느니, 느슨하게 직원들을 관리한다느니, 추운 날씨라서 오링이 갈라질 것을 알면서도 묵인했다느니, 모두다 비난 일색의 보고서를 썼습니다.

그런데 사회학자인 다이앤 본(Diane Vaughan)은 색다른 주장을 폈습니다. 그녀는 챌린저호 폭발을 일으킨 원인을 명확하게 꼬집어 말할 수 없다고 말했습니다. NASA라는 거대한 조직의 시스템 내에 사고의 원인이 잠재되어 있다는 의미였죠. 그녀는 더 나아가 NASA가 규칙을 준수하면서 일했기 때문에 사고가 발생했다는, 알듯 모를듯한 주장을 했습니다.

그녀의 주장을 풀어서 말하면 이렇습니다. 우주 왕복선은 수많은 모듈과 부품으로 이루어져 있습니다. 그런데 각 부품이 100% 완벽하게 동작하리란 보장은 없습니다. 자동차는 양산에 들어가기 전에 여러 번 테스트를 거치면서 오류를 수정해 갑니다. 하지만 우주 왕복선은 특성상 시험 비행이 제한적이기 때문에 각 부품에 오류가 발생할 가능성을 어느 정도 수용하는 문화가 있었습니다. 

그렇지 않으면, 오류를 없애기 위해 치러야 할 비용이 막대해지기 때문이었죠. 그래서 일정한 크기의 오류 가능성을 인정하고 수용하는 규칙으로 NASA 내부에 자리잡았습니다. 폭발을 일으킨 오링의 문제도 사전에 여러 차례 지적되긴 했으나 '수용 가능한 위험'의 목록에 있었기에 넘어가고 말았죠. 

하나의 부품으로 이뤄진 기계는 그 부품의 신뢰도를 0.5%P 향상하면 시스템 전체의 신뢰도도 그만큼 향상됩니다. 반면, 100개의 부품으로 이뤄진 기계는 한 부품의 신뢰도를 0.5%P 향상했다고 해서 시스템의 신뢰도가 동일한 크기만큼 상승하지는 않습니다. 

다음의 풀이를 보면 어떤 의미인지 알 겁니다.

모든 부품의 신뢰도는 각각 99.0%
100 개의 부품으로 이뤄진 시스템의 신뢰도 =  (99.0%)의 100제곱 = 36.60%

특정 부품 A의 향상된 신뢰도 = 99.5%
나머지 부품의 신뢰되는 각각 99.0%
100 개의 부품으로 이뤄진 시스템의 신뢰도 = 99.5% * (99.0%)의 99제곱 = 36.79%

특정 부품 A의 0.5%P 신뢰도 향상으로 인한 기여도 = 36.79 - 36.60 = 0.19%P

수만 수십만 개의 부품으로 이뤄진 우주 왕복선 시스템 전체의 신뢰도를 끌어올리려면, 해야할 일이 엄청나게 늘어납니다. 따라서 NASA가 '수용 가능한 위험'을 허용했다는 것은 당연히 그럴 수밖에 없었고 어떻게 보면 현명한 행동규칙이었습니다. 

NASA의 구성원들이 특별하게 태만하게 근무했거나 뻔한 실수나 비리를 저지르지 않아도 사고가 발생할 수밖에 없었던 이유가 여기에 있습니다. "규칙을 준수한 탓에 사고가 초래됐다?" 언뜻 생각하면 이상한 말이지만, 다이앤 본의 주장은 충분히 설득력이 있습니다. 

(챌린저호 승무원들)


챌린저호 폭발 사건으로부터 조직의 운영이나 전략을 실행하는 데에 어떤 시사점을 얻을 수 있을까요? 

첫째, 고의성이 없고 무해한(효율을 높이기 위한) 개별적인 의사결정이 조직 전체를 와해시키는 파국으로 치닫게 만들 가능성이 충분하다는 것입니다. 조직 내 시스템이 복잡하게 얽혀있을 때 더욱 그러합니다.

둘째, 개별 부품이나 프로세스를 미시적으로 개선한다고 해서 시스템 전체의 안정을 기하는 데엔 한계가 있다는 점입니다. 역시 시스템이 복잡하게 얽혀있을 때 더 그렇지요. 시스템 전체의 신뢰도가 떨어질 때엔 시스템의 아키텍쳐 전체를 뒤집어 엎는 혁신이 필요할지도 모릅니다.

셋째, 문제가 터지고나서 그 발생원인을 따지는 과정은 책임 소재를 찾아 '응징'하는 데에는 의미가 있을지 몰라도, 문제의 근본원인을 제거하는 데엔 그다지 소용이 없을지 모른다는 것입니다. 시스템과 제도를 아무리 정교하게 수정한다 해도 언제나 그 안에 시스템을 붕괴시킬 위험요소가새롭게 창출되기 마련입니다. 완벽을 기하기 어려워 조금씩은 허용 가능한 오류를 인정할 수밖에 없기 때문입니다.

이 세 번째 시사점이 가장 중요하고 가장 '우울한' 일면입니다. 시스템 안에는 스스로를 붕괴시킬 위험요소가 상존한다는 사실은 인간이라는 시스템이 서서히 '스러져 가는' 현상인 노화와 죽음에 비유할 수 있지 않을까요? 그만큼 피하기 어렵다는 뜻입니다.

그렇다면 이러한 위험으로부터 시스템을 보호하려면 어떻게 해야 할까요? 살펴봤듯이 개별 요소의 신뢰도를 끌어올려서 시스템 안정도의 완벽을 기하겠다는 생각은 무모하고 그 이익도 노력에 비해 미미합니다. 그렇다고 시스템 전체를 뒤집어 엎는 일도 꽤나 지난하고 매몰비용(sunk cost) 때문에 섣불리 결정을 못 내리는 심리적 장벽이 존재합니다.

그러므로, 개별 요소의 오류 가능성을 인정하되 하나의 요소에서 발생한 오류가 시스템 전체로 연쇄되지 않도록 해서 피해를 최소화하는 것이 현명한 조치입니다. 오류가 전염되지 못하도록 이중 삼중의 방어벽을 설치하는 것입니다. 인간의 면역계가 생명이라는 시스템을 그런 방식으로 수호하듯 말입니다.

여러분의 시스템, 여러분의 조직, 여러분의 전략은 얼마나 안정적입니까? 어떤 상태이든 너무 신뢰하진 마십시오.

(언뜻 든 생각 : 천안함 사건을 챌런저호 폭발과 대비해 보면 어떨까요? 잘 모르겠으나, 사건을 바라보는 시각을 넗힐 필요는 있지 않을까요?)

* 참고도서 : '그 개는 무엇을 보았나'(말콤 글래드웰). '호모 파베르의 불행한 진화'(킴 비센티)



inFuture 아이폰 앱 다운로드       inFuture 안드로이드 앱 다운로드 

반응형

  
,

"제안서 한번 내 주시죠"   

2010. 5. 20. 09:00
반응형

모두 그런 것은 아니지만, 몇몇 고객들은 컨설팅을 무엇 때문에 받아야 하는지 목적을 명확히 정하지 않는 상태에서 컨설팅을 의뢰하곤 합니다. 그 어떤 프로젝트보다 이런 고객사의 컨설팅이 제일 어렵습니다.

컨설팅 프로젝트가 성공하기 위한 요소 중 첫째는 뭐니뭐니해도 ‘왜 우리가 컨설팅을 받아야 하는지’, ‘그 결과로 무엇을 얻고자 하는지’를 초기에 분명히 하는 것입니다. 제아무리 뛰어난 컨설턴트가 와서 자문하더라도 고객담당자가 갈피를 못 잡고 헤맨다면, 컨설팅 목적만을 잡는데 프로젝트 기간의 절반 이상을 하릴없이 보낼 수밖에 없지요.

(지난 주말에 청계산에 올랐습니다. 공기가 상쾌했지요)


컨설팅 목적 수립은 제안요청서(RFP, Request for Proposal)를 제대로 작성하는 것에서 시작됩니다. 제안요청서란, 컨설팅을 받고자 하는 목적과 기대효과, 예상산출물, 일정, 예산범위, 기타 컨설팅 수행조건 등을 명시한 문서로서, 컨설팅사에 의뢰를 하기 전에 필수적으로 작성돼야 합니다.

컨설팅 의뢰 경험이 많은 기업은 제안요청서를 잘 활용하지만 아직까지 상당수의 고객들이 제안요청서를 통해 의뢰를 해 오지 않습니다. 한 장이지만 대략적이나마 제안 요청 내용을 작성해 보내오는 경우는 그나마 낫습니다. 단 한번의 전화 통화나 이메일로 제안서를 요청해 오는 고객들이 의외로 많죠. 심지어는 직접 컨택하지 않고 제3삼자의 입을 통해 제안을 요청하는 경우도 있습니다.

솔직히 말해, 그런 회사들에게서는 뭔가 감추고 있는 듯한 인상을 받습니다. 기안문서를 작성하기가 어려워서 컨설팅업체의 제안서를 받아만 보는 경우도 제법 많기 때문입니다.

짧든 길든 제안요청서는 반드시 컨설팅 의뢰 전에 작성해야 합니다. 제안요청서가 준비되지 않거나 부실하다면 엉뚱한 방향의 제안서가 제출될지 모르며, 이를 시정하기 위해 귀중한 시간이 소모된다든지, 고객과 컨설팅사가 컨설팅 목적과 방향에 대해 서로 다른 생각을 가지게 돼 나중에 갈등의 원인이 될 수 있습니다.

제안요청서는 여러 가지 포맷이 있지만, 포함되어야 할 기본적인 사항은 다음과 같습니다. 

간단한 제안요청서의 목차
 
1.  컨설팅 추진 배경
    (컨설팅을 의뢰한 근거, 과정 등을 기술)

2.  컨설팅 목적 및 기대효과
     (컨설팅에 기대하는 금전적/비금전적 효과를 서술)

3.  컨설팅 산출물
     (최종보고서에 들어갈 구체적인 결과물을 명기)

4.  컨설팅 수행기간 및 일정
    (중간보고, 최종보고 등 이벤트에 대한 실시시점도 명기)

5.  컨설팅 예산 
    (대략적인 범위로 제시. 부가가치세 포함인지 불포함인지 명기)

6.  제안서 요청사항
    (제안서에 포함돼야 할 내용, 제출 기일/방법/형태 등)
    (제안서 제출 이후의 제안발표(Presentation) 일정도 기술)

7.  기타 요구조건
    (참여 컨설턴트의 조건, 프로젝트 수행시 주의사항 등)

제안요청서를 작성하는 일은 컨설팅 프로젝트의 첫 단추를 꿰는 일입니다. 구두로 "제안서 한번 내주시죠."라고 간단히 말해서는 안 될 일입니다. 이 점을 필히 염두에 두기 바랍니다. ^^ 

혹시 제안요청서 없이 제안을 요청한 적이 있던가요? 그 프로젝트는 성공적이었나요?


인퓨처컨설팅 & 유정식의 포스트는 아이폰 App으로도 언제든지 볼 수 있습니다.  여러분의 아이폰에 inFuture App(무료)을 설치해 보세요. (아래 그림 클릭!)
                  
inFuture 앱 다운로드 받기
 
반응형

  
,

아는게 많다고 똑똑한건 아닙니다   

2010. 5. 19. 09:00
반응형

요즘같이 불확실한 시대에 의사결정을 내리려 할 때 "정보가 부족하고 구하기도 어렵다"란 소리를 많이 합니다. 정보가 많으면 불확실한 의사결정을 하지 않을 텐데, 그렇지 못해서 안타깝고 답답하다고들 합니다. 이렇듯 많은 사람들이 정보의 양이 클수록 불확실성은 작아지리라는 생각을 가집니다.

그러나 과연 그럴까요? 정보가 많을수록 불확실성이 작아져서 예측의 정확도가 높아질까요?

(말 달려 봅시다)


경마(競馬) 결과의 예측을 본업으로 하는 기자들이 있습니다. 그들은 경주마별로 축적된 과거 성적 데이터를 근거로 누가 우승할지를 점치는 일을 합니다. 

연구자들은 그들 중 8명을 대상으로 실험을 진행했습니다. 각 경주마에 대해 5개의 정보만을 가지고 우승마를 예측하도록 했습니다. 그리고 각 말에 대해 10개, 20개, 40개의 정보를 사용하게 해서 우승할 말을 맞추도록 하는 실험을 추가로 실시했습니다.

연구자들의 가설은 이것이었습니다.

"많은 정보를 사용할수록 우승마를 더 잘 예측할 수 있다"

기자들의 생각도 동일했습니다. 40개의 정보를 사용하면 5개를 사용할 때보다 예측의 정확도가 약 20%에서 30%로 증가하리라 생각했으니까요. 

그러나 연구자들의 가설과 기자들의 확신은 실험을 해본 결과 '근거 없음'으로 드러났습니다. 예상과 달리, 적은 정보를 사용했을 때나 많은 정보를 사용했을 때나 예측의 정확도는 비슷했으니 말입니다. 오히려 40개의 정보를 사용했을 때 예측 정확도가 조금 감소하기까지 했습니다.

5개의 정보를 사용할 때 :  예측정확도 15%
10개의 정보를 사용할 때 : 예측정확도 15.5%
20개의 정보를 사용할 때 : 예측정확도 16%
40개의 정보를 사용할 때 : 예측정확도 14%

이 실험에서 우리가 알아야 할 시사점은 "불확실성은 정보의 양에 의해 줄어드는 성질의 것이 절대 아니다"라는 점입니다. 오히려 많은 정보가 제공되면 의사결정자가 자신의 예측능력을 실제보다 과잉확신하기 때문에 의사결정을 혼란스럽게 만들 수도 있습니다.

불확실성이 별로 개입되지 않는 상황이라면 정보의 양은 예측의 정확도를 분명히 높입니다. 예를 들어 밀폐된 방안에 여러 전자제품을 설치했을 때 방안의 온도가 어떻게 될 것인지 예측하는 문제라면, 전자제품 각각에서 내뿜는 열기(熱氣)의 정보들을 가능한 한 많이 확보할 수록 방안의 기온을 더 잘 예측할 수 있습니다.

그러나 환경의 복잡성에 대처해 의사결정을 내리는 기업들처럼 불확실성이 강력하게 개입된 상황이라면 정보의 양은 그리 도움이 되지 못합니다. 의사결정의 '맹점'을 확대시키고 방대한 데이터를 처리하느라 자원을 소모시키는 경우가 비일비재합니다.

정보가 많을수록 예측의 정확도가 올라갈 거라는 생각은 주사위 던지기 게임의 과거 데이터를 많이 끌어 모을수록 다음에 어떤 숫자가 나올지 예측 가능하다는 생각과 다를 바 없습니다. 주사위가 과거에 어떤 숫자들이 나왔는지 살펴봤자 예측의 정확도는 6분의 1 수준에서 향상되지 못합니다.

여러분 중에 혹자는 "양이 중요한 게 아니라, 질이 높은 정보를 사용하면 불확실성을 줄일 수 있다"고 주장할지도 모릅니다. 맞는 말씀입니다. 그러나, 의사결정 이전에 과연 그 정보가 '질이 높은 정보'인지의 여부를 어떻게 알아차릴 수 있을까요? 

사전적으로 질 높은 정보를 가리는 데에 인간의 능력은 매우 보잘것없습니다. 특히 불확실성이 큰 상황에서는 더욱 그러합니다.  어떤 정보가 질 높은 정보라면 그렇게(질이 높다고) 판단 내린 이유는 '내 그럴 줄 예전부터 알았지'식의 '사후가정'에서 나온 것이라고 해도 과언이 아닙니다.

'내 그럴 줄 예전부터 알았다'면 의사결정할 때 일러 줄 일이지 왜 다 지난 다음에야 확신에 찬 주장을 하는지 모르는 경우가 얼마나 많습니까? 사건이 발생한 후에야 왜 그 사건이 발생할 수밖에 없었는지를 왈가왈부하는 전문가는 왜 또 그렇게 많을까요? 예측의 정확도를 높이는 데에 정보의 질을 운운하는 것도 어찌보면 환상이고 '신화(myth)'입니다.

의사결정의 불확실성을 줄이려는 목적으로 정보의 양을 추구하는 방식으로 경영한다면 하루 빨리 그런 관행을 버리는 게 좋습니다. 또한, 질 높은 정보를 미리 알아내겠다는 식의 자세는 의사결정의 속도를 한없이 늦추기 때문에 속도와 타이밍이 중요한 기업환경에서 역시 폐기해야 할 습관입니다. 

'아는 게 많다고 똑똑한 것은 아닙니다.' 기업도 마찬가지입니다. 불확실성을 이기는 똑똑한 의사결정은 정보의 양과 질을 통해 예측을 잘하는 것에서 비롯되지 않습니다. 불확실성에 의해 발생될 몇 갈래의 상황(시나리오)을 미리 그려보고 대비전략을 세우는 것이 보다 현명한 대처법입니다.

 여러분의 조직은 혹시 '정보의 환상'에 빠져있지는 않습니까?


인퓨처컨설팅 & 유정식의 포스트는 아이폰 App으로도 언제든지 볼 수 있습니다.  여러분의 아이폰에 inFuture App(무료)을 설치해 보세요. (아래 그림 클릭!)
                 
inFuture 앱 다운로드 받기

반응형

  
,

"팀장님이 프로젝트의 걸림돌이에요"   

2010. 5. 18. 09:00
반응형

여러분이 30일 짜리 프로젝트를 수행하게 됐다고 생각해 보세요. 그렇다면 여러분이 '순수하게' 프로젝트를 수행할 수 있는 기간은 얼마나 될까요?

"30일 짜리라고 했으니 당연히 30일이 답이잖아. 이거 너무 쉽잖아?" 라고 생각했을지 모르겠군요. 그러나 애석하게도 30일 짜리 프로젝트에서 여러분이 순수하게 프로젝트 수행(문제 해결)을 위해 쓸 수 있는 시간은 30일보다 훨씬 작을 수 있습니다.

그 이유는 바로 '보고와 리뷰' 때문입니다.

(프로젝트가 힘들 때 시원한 약수 한잔을 쭉~)


만일 여러분의 직속상사가 위로 4명이 있다면(예를 들어, 팀장, 담당임원, 사업부장, 사장), 30일 짜리 프로젝트에서 여러분이 문제 해결에 쓸 수 있는 시간은 얼마일까요? 반드시 30일 안에 끝내야 하는 프로젝트라면, 아마도 17일 밖에 안 될 겁니다. 프로젝트의 거의 1/2이 되는 기간이죠.

1~17일차 : 문제 해결
18일차 : 팀장 보고
21일차 : 담당임원 보고
24일차 : 사업부장 보고
27일차 : 사장 보고
30일차 : 최종 보고


프로젝트를 수행할 때 이런 식의 말들이 오고가지 않습니까?

팀장 : 프로젝트 결과물이 언제 나오나?
프로젝트 책임자 :  26일차 정도에 프로젝트 결과가 나옵니다.
팀장 :  안돼, 임원님과 사업부장님이 충분히 검토할 시간이 없잖아.
           그리고 나도 검토를 해야 하니까, 17일차 까지 끝내도록 해.
           그게 어려우면 초안이라도 17일차까지 보고해.

위로 4명의 상사가 있다면, 각각에게 보고를 하고 '리뷰 결과'를 반영해서 보고서를 고치는 일을 4번이나 반복해야 합니다. 문제는 상사들에게 각각 리뷰(혹은 결재)를 받는 시간이 3~4일씩 걸리기 일쑤라는 겁니다. 바쁜 탓인지, 게으른 탓인지 보고서를 올리면 즉각 검토해주는 경우는 별로 없습니다. 마음 먹고 앉아서 리뷰하면 1시간도 안 걸릴 일이 그렇게 함흥차사처럼 늘어집니다.

더욱 허무한 경우는 기껏 3~4일이나 기다렸더니 "별로 고칠 것 없이 이대로 됐다. 윗선에 보고하자"란 말을 들을 때입니다. 또 어떨 때는 휴가나 출장을 이유로 "그때는 시간이 안 되니까 미리 한번 보여 달라"고 말하는 통에 밤을 새워서 보고서를 작성해야 합니다.

직속상사가 한 명이 생길 때마다 '검토'라는 이유로 문제 해결에 쓰일 프로젝트 기간을 갉아 먹는 현상은 일종의 '채찍 효과(Bullwhip Effect)'에 해당됩니다. 각 상사는 안정장치라는 이유로 3~4일 정도의 리뷰 시간을 확보하는 게 아무렇지도 않겠지만, 보고 단계가 많아지면 그것이 쌓이고 쌓여서 프로젝트의 후반부를 '보고하고 검토하는 데'에 시간을 소모하도록 만듭니다. 배보다 배꼽이 더 크게 되죠.

요즘 회사 내에서 자체적으로 여러 프로젝트를 할 텐데, 위와 같은 현상 때문에 문제 해결에 많은 공을 들이기보다는, 보고를 잘하고 결재를 잘 받는 일에 힘을 소모하는 모습을 자주 듣습니다. 30일 짜리로 계획됐다가 결재자들의 검토가 늦어지는 바람에 일정을 훌쩍 넘겨버리는 일도 흔합니다.

특히 전통적으로 위계질서가 강조되는 기업일수록 그러한데, 속도가 중요시되는 기업환경에서 이러한 '늘어짐 현상'은 조직을 정체시키는 끈적끈적한 병폐로 자리잡고 맙니다.

프로젝트는 단기간 내에게 힘을 집중시켜 문제를 해결하는 과정입니다. 따라서 윗선에 보고하고 검토를 받는 기간을 최소화함으로써 문제 해결에 매진하게 해야 합니다. 프로젝트의 보고 단계는 다음과 2단계면 충분합니다.

1~26일차 : 문제 해결
27일차 : 프로젝트 매니저 검토
28일차 : 프로젝트 오너 보고
30일차 : 최종 보고

프로젝트가 실행되면 반드시 프로젝트 매니저와 프로젝트 오너(프로젝트 결과물을 최종적으로 의사결정하고 실행의 책임을 지는 사람)를 선정하고, 중간에 다른 의사결정자들이 끼지 못하게 해야 합니다. 모든 의사결정은 프로젝트 매니저와 프로젝트 오너가 책임지고 내리도록 프로젝트 추진조직을 구조화해야 불필요한 '보고와 리뷰' 때문에 역량이 흐트러지는 일을 방지할 수 있습니다.

제 경험상, 중간에 '검토자' 혹은 '결재자'가 많아질수록 프로젝트가 늘어질뿐더러 애초에 시도했던 '예리하고 과감한' 해결책이 초점을 잃고 뭉뚝하게 변하는 일이 많습니다. 중간 결재자들이 위험을 최소화하려는 시도가 더해지는 바람에 그렇게 돼 버리죠. 프로젝트 수행자들이 미처 생각하지 못한 뛰어난 아이디어를 던져주는 경우는 거의 없습니다.

그들이 위험을 최소화하려는 의도는 해결책의 위험을 헷지하려 한다기보다는, 자신들에게 튈지 모를 불똥을 사전에 없애기 위해서인 경우가 아주 많습니다. 소위, '윗선에게 깨지지 않으려는' 시도에 불과합니다.

프로젝트의 성공요인은 여러 가지가 있지만, 의사결정(보고와 결재) 단계를 최대한 단축시키는 것도 문제 해결의 질과 속도를 높이는 데 매우 중요한 방법임을 기억하기 바랍니다.

여러분의 프로젝트는 어떻습니까?


인퓨처컨설팅 & 유정식의 포스트는 아이폰 App으로도 언제든지 볼 수 있습니다.  여러분의 아이폰에 inFuture App(무료)을 설치해 보세요. (아래 그림 클릭!)
                
inFuture 앱 다운로드 받기

반응형

  
,