"제안서 한번 내 주시죠"   

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 앱 다운로드 받기

반응형

  
,

조직이 깔끔해야 BSC가 잘된다   

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

어떤 고객을 만나 BSC에 관한 이야기를 나눈 적이 있습니다. 그 회사는 부서 단위로 BSC를 운영하고 있는데, 그것 때문에 일부 직원들이 평가에 대해 불만을 가지고 있다는 것이 이야기의 요지였죠. 부서 BSC의 평가 결과가 개인의 평가결과에 반영되어 최종적으로 개인별 평가등급이 산정되는 방식이었습니다.


풀어서 이야기 하면, 부서의 목표 달성 여부가 20% 내외, 개인의 역량평가 결과와 업적평가 결과가 80% 내외로 가중 평균하여 100점 만점 기준으로 총점을 계산한 다음, 평가군별로 S-A-B-C-D 등급을 결정하는 로직으로 구성되었습니다.

당초 부서(조직) BSC를 개인의 평가등급 산정에 반영한 이유는, 직원들이 오로지 자신에게 해당되는 개인 목표 달성에만 관심을 두는 폐해를 막고 팀 플레이적인 마인드를 공고히 하기 위해서였다고 합니다.

문제는 이랬습니다. 부서 내에 성격이 다른 두 개 이상의 비공식적인 조직이 숨어 있는 경우가 있을 경우, 부서 BSC 결과 반영에 따라 피해를 보는 직원들이 생길 수 있다는 점이었죠. 자금부를 예로 들어 설명하면, 그 부서 내에 자금 담당 직원들과 회계 담당 직원들이 한 조직으로 묶여 있었습니다. 물론 어느 정도 관련이 있는 기능이긴 하지만, 수행하는 업무를 놓고 볼 때 상이한 기능임에 틀림 없습니다.

그런데 회사에서는 자금부의 BSC를 결정할 때, 자금 기능에 해당하는 목표를 회계 기능에 해당하는 목표보다 더 많이 잡도록 했습니다. 목표가 8개 라면 7개가 자금 기능, 1개가 회계 기능이 달성하도록 한 것이죠. 전사적인 관점에서 회계 기능보다는 자금 기능의 전략적 중요도가 컸기 때문입니다.

이런 경우, 회계 기능에 속한 직원들은 자신들이 전혀 컨트롤 할 수 없는 7개의 목표 달성여부에 의해 본인들의 평가결과가 좌우되어야 하는 모순적인 상황에 처하게 됩니다. 그리고, 회계 기능에서 추진해야 할 여러 목표는 무시되고 오직 1개의 목표로 회계 기능 전체를 평가 받는 경우에 빠지게 되어, 자칫 그 목표와 관련 없는 업무를 소홀히 할 우려가 있지요.

단위조직의 BSC는 독립적인 조직 단위를 기초로 수립되어야 합니다. 현재의 조직도 상에 그려져 있는 부서 단위가 아니라, 실질적으로 별도의 특성을 지닌 조직 단위별로 BSC가 수립되어야 한다는 말이죠. 자금부의 경우, 현재의 조직도가 자금부로 되어 있다고 해서 ‘자금부 BSC’만 고려할 것이 아니라, 자금 기능의 BSC, 회계 기능의 BSC를 별도로 세워야 합니다.

이렇게 되려면 독립적인 조직 단위, 즉 팀(Team)으로 조직을 개편할 필요도 있습니다. 자금부를 자금팀과 회계팀으로 분할시켜 각각 BSC를 수립하게 하는 것입니다. 그래야 위에서 언급한 평가의 불공정한 측면을 최소화할 수 있지요.

BSC와 개인평가의 납득성을 위해 조직을 개편하는 것이 ‘주객이 전도’된 것처럼 보일지도 모릅니다. 물론 쉬운 일은 아닙니다. 그러나 BSC란 기본적으로 팀제를 밑바탕에 두고 생겨난 경영기법임을 생각해 볼 때, 회사가 목표 지향의 조직이 되기 위해서는 과거의 조직구조에 억지로 BSC를 끼워 맞출 것이 아니라, 이 참에 조직의 그림을 새로 그려 보는 시도가 필요하지 않을까 생각합니다. 

조직이 깔끔하게 구성되어야 BSC가 잘 됩니다. 옛말에 새 술은 새 부대에 담으라고 하지 않았던가요? 즐거운 하루 되세요. ^^


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

반응형

  
,

대박 투자는 쪽박의 지름길   

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

이길 확률이 "10분의 1" 인 게임이 있습니다. 누군가가 여러분에게 이 게임을 이렇게 제안합니다. 


이 게임을 하려면 100 만원을 내야 합니다. 하지만, 한 번 이기기만 하면 1000 만원을 딸 수 있습니다. 어때요, 한번 해 보시지요?



구미가 당기는 제안인가요? 이 게임에서 이길 확률은 10분의 1이니 10 번에 한 번 꼴로 이기는 게임이겠지요. 그래서 여러분은 머리 속으로 다음과 같이 계산할지도 모릅니다.


10 번 게임을 하는 데 드는 비용 = 100 만원 * 10번 = 1000 만원
한 번 이기면 딸 수 있는 금액 = 1000 만원

∴ 잃어봤자 본전이니, 게임을 해보자!


그러나 수치로 나오는 확률과 실제가 항상 일치하지는 않습니다. 이길 확률이 10분의 1 이라고 해서 10 번 게임을 하면 적어도 한 번은 이긴다고 장담하지는 못합니다. 왜냐하면, 10번 게임을 해서 모두 질 확률이 35%나 되기 때문입니다.


10번 게임을 모두 질 확률 = (9/10)의 10제곱 = 약 35%


35% 라는 수치는 꽤 높은 확률이어서, 쉽게 1000 만원을 몽땅 털릴 위험이 크다는 걸 의미합니다.

물론 10번 게임해서 적어도 한 번 이상 이길 확률이 65%이고, 운이 좋아서 2번 이상 이길 수도 있기 때문에 여러분은 꽤 많은 돈을 벌 수도 있습니다. 그러나 그러기에는 위험 부담이 너무 큽니다.

성공할 확률이 작고 비용 부담도 크지만 성공하게 되면 '대박'이 터지는 사업이나 투자가 있습니다. 그런 사업이나 투자를 여러 번 한다고 해서 '한 번은 성공할 거니까 몇 번 실패해도 괜찮아'라고 생각하는 습성을 경계해야 합니다. 여러분의 기대와는 달리 모든 시도가 실패로 돌아가서 '쪽박'을 찰지 모르는 일입니다.

현명하지 못한 사람은 성공확률이 작은 '대박 투자'를 여러 번 하려고 하지만(과거의 벤처 캐피탈리스트들), 현명한 사람은 성공확률이 높은 투자만을 엄선할 줄 압니다. 투자와 사업의 성공은 '성공확률에 있는 것'이지 성공했을 때에 주머니에 들어올 돈의 규모에 있지 않습니다. 이 점이 매우 중요합니다.

머리 속으로는 잘 알아도 주식 투자나 전략을 실행할 때 이 교훈을 잊는 경우가 생각보다 많습니다. 성공확률이 작고 비용부담이 크지만 일단 성공하면 대박이 터지는,일명 '모 아니면 도' 방식의 투자나 사업을 진행 중이거나 준비 중이라면 자신의 선택이 과연 올바른지 재검토할 필요가 있지 않을까요? 

대박 투자는 쪽박의 지름길일지 모릅니다. 여러분의 생각은 어떠십니까?



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

반응형

  
,