프로젝트를 계획할 때 중요한 일들이 많겠지만 그 중 하나가 프로젝트의 완료 기간을 예상하는 것입니다. 특히 인력의 효율적인 운용이 중요시되는 조직일수록 프로젝트 일정을 지나치게 짧게 잡아도 안 되고 또 지나치게 길게 잡아도 안 되죠. 하지만 사람들은 보통 지난 번 글('성공의 착각에 빠져 있습니까?')에서 이야기했듯이 프로젝트 일정을 실제로 필요한 기간보다 짧게 잡는 경향이 있습니다. 1년이 필요한 데도 6개월이면 충분하다는 식으로 일정을 정하죠. 과거에 유사한 프로젝트를 수행한 경험이 있건 없건 상관없이 프로젝트의 진행을 낙관적으로 예상하고 실패 가능성을 낮게 점치는 '계획 오류(Planning Fallacy)'를 범하곤 합니다.

이런 경향이 있기 때문인지 주로 프로젝트 방식으로 일하는 조직(예 : 시스템 개발, 컨설팅, 건축 및 토목 등)에서는 프로젝트 일정 수립의 정확성을 중요한 성과지표(KPI)로 관리하곤 합니다. 계획과 실제가 얼마나 일치하느냐에 따라 개인과 조직을 평가하고 그에 따라 보상하는 조치를 취함으로써 계획 오류의 발생 가능성을 사전에 억제하려고 합니다. 이 글을 읽는 프로젝트 매니저들은 십중팔구 이러한 KPI를 부여 받았을 거라 짐작되는군요.



하지만 계획의 정확성을 강조하고 그에 따라 평가하겠다는 조치가 계획 오류를 줄이기는커녕 오히려 확대시킨다는 연구 결과가 있습니다. 잉 쯔앙(Ying Zhang)과 에일렛 피시바흐(Ayelet Fishbach)는 일련의 실험을 통해 정확성의 중요함을 강조할수록 보수적이고 '안전한' 일정을 정하는 경향이 존재하고 그로 인해 정확성이 개선되지 않는다는 사실을 규명했습니다. 

쯔앙과 피시바흐는 학생들에게 GRE 스타일의 객관식 문제 100문항을 제시하고서 문제를 다 풀면 즉시 이메일로 보내라고 요청했습니다. 문제를 제시하기 전에 학생들 중 절반은 이 문제들이 어렵다는 말("다른 학생들이 어려워 했다")을 들었고 나머지 절반의 학생들은 문제가 쉽다는 말("다른 학생들도 쉽게 풀었다")을 전달 받았습니다. 또한 학생들은 문제를 다 푸는 데 걸리는 시간을 예상하여 연구자에게 이야기해야 했죠. 쯔앙과 피시바흐는 학생들 중 절반에게는 예상 완료 시간이 그저 참고용이라고 말한 반면, 나머지 절반에게는 채점 담당자들의 스케쥴을 조정해야 하기 때문에 예상 완료 시간의 정확성이 아주 중요하다고 말했습니다. 정확성의 중요함을 서로 다르게 인식하도록 만든 것이죠.

문제가 어렵다란 말을 들은 학생들은 높은 정확성을 요구 받을 때 예상 완료 시간을 더 크게 잡는 경향을 보였습니다(29시간 대 86시간). 반대로, 문제가 쉽다는 말을 들은 학생들은 낮은 정확성을 요구 받을 때 예상 완료 시간을 더 높게 잡았죠(60시간 대 53시간). 조직에서 수행되는 대개의 프로젝트가 '어렵다'라고 간주하면, 프로젝트 매니저나 조직의 장에서 계획의 정확성을 강조하고 그것에 높은 비중을 부여할 경우 프로젝트 예상 완료 기간을 실제로 필요한 기간보다 더 길게 잡을 것이라 해석되는 결과입니다.

그렇다면 실제로 학생들은 몇 시간만에 문제 풀이를 완료했을까요? 결과는 학생들 자신들의 예상과 비슷하게 나타났습니다. 문제가 어렵다고 인식한 학생들은 높은 정확성을 요구 받을 때 실제 완료 시간이 더 길었습니다(35시간 대 86시간). 반면, 문제가 쉽다고 인식한 학생들은 낮은 정확성을 요구 받을 때 실제 완료 시간이 더 길었죠(62시간 대 52시간). 

학생들이 사전에 문제의 난이도를 어떻게 인식했건 간에 모두 동일한 문제를 풀었다는 점에서 이 결과는 상당히 의미심장합니다. 어렵고 중대한 프로젝트를 앞에 둔 사람이 계획의 정확성이 중요하다고 인식할수록 필요한 시간보다 더 길게 일정을 잡으려 할뿐더러 더 오랫동안 프로젝트를 수행한다는 점을 시사하기 때문입니다. 이 실험의 결과로 우리는 일정의 정확성을 높이려는 조치가 프로젝트가 필요 이상으로 오래 끌 가능성을 높인다는 점과, 오히려 계획의 정확성을 별로 강조하지 않는 것이 프로젝트를 빨리 끝내는 데 도움이 된다는 점을 알 수 있습니다. 정확성 때문에 프로젝트가 길어지는 것은 정확성이 지불해야 할 비용인 셈입니다.

정확성이 지불해야 할 비용이 프로젝트 기간의 증가만은 아닙니다. 쯔앙과 피시바흐는 정확성을 강조하면 어떤 일을 끈질기게 수행하고자 하는 의지도 저하된다는 점도 실험을 통해 규명했습니다. 그들은 실험 참가자들에게 헤드폰으로 음악을 들으면서 8개의 문자로부터 의미 있는 영어 단어를 찾아내는 애너그램 과제를 수행하도록 했습니다. 참가자들의 절반은 배경음악이 애너그램 같은 창의적인 과제를 수행하는 데 도움이 된다('비장애 조건')는 말을 들은 반면, 나머지 참가자들은 배경음악이 오히려 해가 된다('장애 조건')는 말을 들었습니다. 

그런 다음, 쯔앙과 피시바흐는 각 그룹의 참가자들을 다시 둘로 나눠 첫 번째 서브 그룹에게는 남들보다 좋은 성적을 거둘수록 많은 수고료를 주겠다고 하고, 두 번째 서브 그룹에게는 자신이 거둘 실제 성적을 사전에 정확히 예상할수록 높은 수고료를 지불하겠다고 말했습니다. 참가자들에게 모니터 상에 나타나는 8개의 애너그램 문제를 풀도록 하니 '장애 조건'에서 정확성에 따라 보상 받기로 한 참가자들은 성적에 따라 수고료를 받기로 한 참가자들에 비해 과제를 오랫동안 지속하려는 경향이 적었습니다. 다시 말해, 자신이 수행하는 일이 어려울뿐더러 예상의 정확성이 중요한 요소라고 인식할 때 사람들은 그 일에 힘을 쏟으려는 동기가 약화된다는 것입니다.

계획의 정확성을 강조하면 실제보다 짧게 기간을 정하려는 계획의 낙관적 경향('계획 오류')이 줄어들긴 합니다. 하지만 그것은 공짜가 아닙니다. 앞서 살펴봤듯이 빨리 끝낼 수도 있는 프로젝트를 오래 수행하도록 유도하기 때문이고 어려운 일을 끈질기게 지속하려는 동기를 저하시키기 때문입니다. 이렇게 늘어난 시간과 비용을 감안하지 않고 '계획 대비 실제'를 측정하는 KPI가 양호하다고 해서 높은 평가를 내리고 보상하는 것은 눈에 잘 띄지 않는 아이러니입니다. 

위 실험을 짧게 정리하면, 쉬운 프로젝트는 정확성을 강조하고 어려운 프로젝트는 정확성을 그리 강조하지 않는 것이 좋습니다. 하지만 어떤 프로젝트가 쉽고 어려운지, 또 어느 정도의 정확성이 좋을지 판단하고 결정하는 문제는 여전히 여러분 손에 달렸습니다. 프로젝트 매니저나 조직의 책임자는 계획의 부정확성으로 인한 비용과 계획의 정확성을 강조함으로써 발생할 비용 사이에서 적절하게 균형을 잡는 지혜를 갖춰야 합니다. 한쪽으로 쏠리는 관리법은 프로젝트의 실패 확률을 높인다는 점을 늘 경계해야 합니다.

지금 여러분의 프로젝트는 얼마나 정확한 일정으로 진행되고 있습니까? 일정을 딱딱 맞춘다고 좋아할 일은 아닐지 모릅니다.


(*참고논문)
Counteracting Obstacles With Optimistic Predictions.



  
,


예전에 올린 글 '성공의 착각에 빠져 있습니까'에서 '계획 오류(Planning Fallacy)'에 대해 언급했습니다. 전문가들이 커리큘럼 설계를 최대 30개월 안에 끝내겠다고 했지만 결국 8년이나 지나서 겨우 끝나버렸다는 사례를 들며 풍부한 지식과 경험이 전략이나 프로젝트의 앞날을 예측하는 데에 별로 도움이 안 될뿐더러 헛된 망상을 키울 위험이 있음을 지적한 바 있습니다.

이번엔 이러한 계획 오류와 '권한(혹은 권력)' 사이의 관계를 실험을 통해 규명한 연구 결과를 소개하면서 그 의미를 찾아보고자 합니다. 권한을 가진 자와 권한을 가지지 못한 자들이 프로젝트의 완료 시점을 예측할 때 누가 더 큰 계획 오류에 빠질까요? 마리오 웨이크(Mario Weick)와 애나 귀노트(Ana Guinote)는 여러 개의 실험을 통해 이 질문에 답하기로 했습니다. 



그들은 20명의 학생들을 권한을 위임 받은 그룹과 그렇지 못한 그룹에 무작위로 배정한 다음, 대학 당국이 새로 들어올 학생들을 위해 학점 체계를 새로 정비할 계획이라는 말을 전했습니다. 권한을 위임 받은 학생들은 자신들의 의견이 대학의 최종 결정에 50%의 비중으로 반영될 거라고 들은 반면, 권한을 갖지 못한 학생들은 자신들의 의견이 열람되겠지만 학점 체계에는 영향을 미치지 않을 거라고 들었습니다. 그런 다음, 웨이크와 귀노트는 두 그룹의 학생들에게 각자 학기 중에 제출할 과제의 마감일을 정하고 언제까지 그 과제를 제출할 수 있을지 예상하라고 요청했습니다.

학생들이 과제를 제출한 날짜와 예상한 날짜를 비교해 보니 계획 오류가 뚜렷하게 나타났습니다. 그룹과 상관없이 학생들은 마감일이 되기 1.88일 전에 과제를 제출했지만 그보다 2일 먼저 제출할 수 있다고 예상했습니다. 흥미롭게도 계획 오류는 권한을 가진 그룹에서 더 크게 나타났습니다. 그들은 실제로 마감일이 되기 2.47일 전에 제출을 완료했으나 당초 예상할 때에는 마감일보다 4.93일 전에 제출할 수 있다고 장담한 바 있었죠. 대략 2.5일 정도를 낙관적으로 본 겁니다. 반면, 마감일 2.7일 전에 과제 제출을 예상했던 '비권한 그룹'의 학생들은 마감일 1.3일 전에 제출을 완료함으로써 1.4일의 오차를 보였습니다. 권한을 가질수록 예측이 상대적으로 덜 정교하고 소요시간을 더 적게 산정한다는 점이 드러난 결과입니다.

이 결과는 권한을 가진 학생들이 자신도 모르게 더 어려운 과제를 선택했을지도 모른다는 생각에 웨이크와 귀노트는 후속실험을 수행했습니다. 그들은 40명의 학생들에게 과거에 남들에게 권력을 발휘한 기억과 타인의 힘에 의해 억압 받았던 기억을 각각 떠올리게 하는 '프라이밍' 기법을 써서 학생들을 두 그룹으로 나눴습니다. 그런 다음, 거칠게 작성된 파일을 문서 편집 프로그램을 써서 깔끔한 포맷으로 만들라는 과제를 학생들에게 부여했죠. 학생들은 과제를 수행하기 전에 각자 완료 시간을 예상해야 했습니다.

분석 결과, '지배자' 학생들이 '피지배자'로 프라이밍된 학생들에 비해 완료 예상 시간을 훨씬 적게 예측한다는 경향이 도출되었습니다. 지배자 학생들은 8.91분이나 걸릴 일을 3.95분만에 끝낼 수 있다고 장담했지만, 피지배자 학생들은 실제로 9.13분 걸리는 일을 6.32분 정도에 끝낼 수 있으리라 예측했던 겁니다. 추가로 분석해 보니 전체적으로 지배자 학생들이 피지배자 학생들에 비해 77% 정도 더 계획 오류를 범한다는 사실이 드러났습니다.

왜 이런 결과가 나타난 걸까요? 권한 혹은 권력이 '자기 효능감(Self Efficacy, 무언가를 성공적으로 할 수 있다는 믿음)'을 높이기 때문일까요? 학생들이 작성한 설문을 기초로 자기효능감과 계획 오류 사이의 관계를 분석하니 유의미한 연관성이 드러나지 못했습니다. 웨이크와 귀노트는 또 다른 실험을 통해 권력을 가진 사람이 예상되는 결과물에 너무나 집중한 나머지 그 예상을 벗어나게 만들 잠재 요소에 관한 정보를 미처 감안하지 못하기 때문이라고 결론 내립니다. 즉 '주의 초점(Attentional Focus)'이라는 현상이 계획 오류와 연관이 있다고 밝힌 겁니다.

두 번째 실험과 마찬가지 방식으로 지배자와 피지배자로 각각 프라이밍된 학생들은 2천자 분량의 에세이 쓰기, 저녁 외출 준비하기, 슈퍼마켓에서 쇼핑하기, 세 가지 요리 준비하기 등 4가지 상황을 전달 받았습니다. 웨이크와 귀노트는 절반의 학생들에게 과거에 이 4가지 과제를 수행하는 데 얼마나 시간이 걸렸는지 회상하게 한 다음, 과거의 경험에 감안하여 어떻게 이 과제들을 수행할지 짧게 글을 쓰도록 했습니다. 글을 다 쓴 후에 학생들은 4가지 과제를 모두 완료하는 데 걸릴 시간을 예측했습니다. 

그 결과, 과거의 경험을 회상한 지배자 그룹의 학생들이 낸 예측값은 피지배자 학생들의 것과 차이가 나지 않았습니다. 이는 그들이 과거의 일을 떠올림으로써 덜 낙관적이 됐다는 뜻입니다. 반면 피지배자 학생들의 예측값은 과거의 일을 회상하는 것에 의해 별로 영향을 받지 않았습니다. 이는 권력과 낙관적인 예측 사이에는 목표 외적인 요소를 고려하지 못하도록 만드는 주의 초점이 연관되어 있음을 말합니다. 

사람들은 대개 완료 시간을 과소평가하는 계획 오류를 범하곤 하지만 권력이 가진 자들이 주의 초점에 빠져 나타내는 오류의 정도가 더 크다는 게 이 연구의 결론입니다. 이 실험은 우리에게 어떤 시사점을 줄까요? 조직 내에서 힘을 가진 사람이 프로젝트의 완료 시점을 제시하고 주도하려 할 때 스스로를 경계해야 한다는 점을 이 연구는 일깨웁니다. 권한을 가진 자는 프로젝트를 통해 이루어야 할 목표 자체에 매몰되어 생각하는 경향이 큰 탓에 과거의 경험이나 앞으로 생길지 모를 돌발변수를 별로 감안하지 않으려 한다는 것입니다. 

따라서 프로젝트나 전략의 실행계획을 수립할 때 권력을 가진 사람은 욕구를 자제하고 다른 구성원들의 생각을 충분히 받아들이려는 의도적인 노력이 필요합니다. 다시 말해 상대적으로 의사결정권을 가지지 못한 구성원들에게 실행계획 수립을 일임할 필요가 있다는 것입니다. 프로젝트를 무조건 일찍 끝내는 게 능사가 아니라 충실하게 수행하는 것이 중요하다면 말입니다.

여러분이 의사결정권을 가진 위치에 있다면 구성원들에게 요구하는 완료 시점이 지나치게 빡빡하지 않은지 되돌아 볼 필요가 있습니다. 자신도 모르게 너무 낙관적으로 생각했을지 모르니까요. 그런 예측은 의사결정권 없는 '힘 없는 자'들에게 위임하는 게 나을지 모릅니다.

(*참고논문)
How Long Will It Take? Power Biases Time Predictions



  
,



조직에서 추진하는 프로젝트(혹은 전략)들이 모두 성공으로 끝나는 것은 아닙니다. 사람들이 쉬쉬하지만 사실 실패가 다반사죠. 어떤 프로젝트가 실패로 판명되면 어떤 이유로 그런 일이 벌어질 수밖에 없었는지 뜯어보고 여기서 얻은 교훈을 다른 프로젝트를 수행할 때 거울로 삼는 일이 필요합니다. 하지만 이 당연한 과정이 제대로 진행되는 일은 별로 없어 보입니다. 실패의 책임을 떠안지 않기 위해서 성공인지 실패인지 모르도록 프로젝트를 흐지부지 끝내거나 관심을 다른 프로젝트로 돌리려고 하기 때문에 실패를 통한 진정한 배움은 이루어지지 않습니다.

실패를 쉬쉬하지 않고 실패를 반면교사로 삼으려는 기업이 건강한 문화를 지닌 조직임에는 틀림없지만, 더욱 건강한 조직이라면 '사후 부검(post-mortem)'보다는 '사전 부검(pre-mortem)'을 통해 실패를 적극적으로 끌어들일 줄 압니다. 알다시피 부검은 불분명한 이유로 죽은 사람의 사망 원인을 밝히기 위한 과정이죠. 사전 부검이란, 말 그대로 프로젝트가 '죽기 전'에 실시하는 부검으로서 프로젝트를 계획하는 단계에서 "이 프로젝트가 실패로 끝났다"라고 가상으로 선언한 다음 "왜 이 프로젝트가 실패했는가?"라는 질문을 던지면서 예상되는 실패원인을 찾는 과정입니다. 규명된 실패원인을 통해 프로젝트 계획을 수정함으로써 성공확률을 끌어올리려는 게 목적이죠.



실패를 기정사실화한 후에 실패원인을 미리 찾자는 것은 말이 쉽지 의외로 실행이 어렵습니다. '희망을 가지고 성공을 꿈꾸며 프로젝트를 실행해도 성공할까 말까인데, 뭐? 실패를 기정사실화하자고?'라는 집단사고에 밀려 사전 부검란 말은 금기시되고 맙니다. 이의를 제기하는 사람은 프로젝트에 몰입하지 않는 자로 '찍히기'도 합니다. 그러나 사전 부검이 무엇보다 중요한 이유는 그것이 프로젝트의 성공 가능성을 높인다는 데 있습니다. 데보라 미첼(Deborah Mitchell), 제이 루소(Jay Russo), 낸시 페닝턴(Nancy Pennington)이 수행한 연구에 따르면, 사전 부검이 프로젝트의 산출물을 옳게 설정할 확률을 30% 높여준다고 합니다. 

사전 부검의 단계는 이렇습니다. 먼저 프로젝트 매니저가 '프로젝트의 사망'을 선언합니다. 그런 다음 팀원들에게 왜 프로젝트가 사망했는지를 묻습니다. 팀원들은 처음에 프로젝트의 사망원인을 끄집어내는 일을 꺼려합니다. 불충한 사람으로 비춰질까봐 나서지 못합니다. 그렇기 때문에 발언을 종용하기보다는 각자 독립적으로 실패원인을 종이에 적게 함으로써 의견이 집단사고에 의해 공격 받거나 폐기될 가능성을 최소화해야 합니다. 이때 프로젝트 매니저는 분위기를 잘 조성해야 합니다. 재미삼아 거치는 과정이 아니라, 진짜로 프로젝트가 사망했다는 상황으로 팀원들을 몰입시켜야 합니다. 그렇지 않으면, 프로젝트 계획서의 말미에 양념처럼 들어가는, 아무도 참조하지 않는 리스크 계획에 그치고 맙니다.

프로젝트 매니저부터 시작해 모든 팀원들이 각자의 의견을 발표한 다음, 각각의 실패원인을 사전에 막으려면 프로젝트 계획을 어떻게 수정 보완해야 하는지 논의하는 단계를 거치면서 사전 부검을 마무리합니다. 사전 부검을 거치면 현실적이지 않은 희망(특히 프로젝트에 공을 많이 들인 사람들)에 부풀어 오르는 일을 줄일 수 있습니다. 프로젝트의 완료기간을 지나치게 짧게 잡거나 예산을 필요 수준보다 적게 설정하려는 오류를 피하고 실질적인 계획을 세울 수 있죠. 또한 프로젝트를 수행하다가 중간에 CEO가 교체되면 프로젝트에 대한 관심과 지원이 끊길 수도 있다는, 입에 올리기 힘든 '진짜 실패원인'을 제기하도록 유도할 수 있습니다. 그리고 프로젝트를 진행하다가 발생하는 위험신호를 재빨리 감지해서 대응하도록 마음의 준비를 시키는 효과도 있죠.

지금 프로젝트를 착수 중이라면 사전 부검의 과정을 꼭 진행하기 바랍니다. 부검이라는 말 자체가 꺼림칙하다고요? 약간의 충격적인 용어가 프로젝트의 실패를 직시하도록 만듭니다. 바로 실행에 옮기세요!


(*참고논문 : Performing a Project Premortem )



  
,

"제안서 한번 내 주시죠"   

2010. 5. 20. 09:00

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

  
,

여러분이 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 앱 다운로드 받기


  
,

엉터리 컨설턴트 감별법   

2010. 5. 7. 09:00

컨설팅 결과가 잘 나오느냐 그렇지 않냐를 결정하는 가장 큰 요소는 바로 컨설턴트의 역량임은 두말할 필요가 없습니다. 그래서 오늘은 엉터리 컨설턴트를 가려내는 방법에 대해 말해 볼까 합니다. 척 보고 저 사람이 엉터리 컨설턴트라는 것을 어떻게 알 수 있을까요?


첫째, 엉터리 컨설턴트는 말만 번지르르합니다. 그들이 온갖 수사법과 사례를 들어가면서 하는 말을 듣고 있자면 자신도 모르게 그의 말에 빠져들어가는 걸 느낄 겁니다. 물론 말 잘하는 컨설턴트가 모두 엉터리라고는 단정지을 수 없습니다. 하지만 그가 내뱉는 번지르르한 말이 행동과 일치가 되지 않는 경우라면 100% 엉터리라고 봐야 합니다.

제가 예전에 알던 모 컨설턴트는 이른바 ‘입만 산’ 컨설턴트의 전형이었습니다. 그는 고객과 회의를 할 때마다 꼭 앞에 나서더군요. 누구나 인정하는 달변인 그는 현실적으로 가능한 것인지 따지지 않고 지극히 이상향적인 내용으로 고객들을 현혹시키는 게 특기라면 특기였습니다. 그래서 전문적인 지식이 없는 고객들은 그의 언변에 속아 컨설팅 결과에 대해 굉장한 기대를 가지게 될 수밖에 없었습니다.

하지만 옆의 다른 컨설턴트들은 그야말로 고역이었죠. 고객 앞에서 그가 틀렸다고 나서서 제지하기도 뭐하고, 그렇다고 그가 제 맘대로 지껄이게 놔둘 수도 없는 노릇이었으니까요. 잔뜩 기대를 갖게 된 고객들을 나중에 만나 ‘그것은 지나치게 이상적인 내용이다, 현실적으로는 이 단계까지가 한계다’ 라고 시정시키기 바빴습니다. 당연히 고객들이 기분 좋을 리 없었겠죠.

한편 이런 사태를 만든 장본인인 그는 한 발 물러나 사태를 즐기는 듯 보였습니다. 자신은 말만 했을 뿐 아무런 잘못도 없다는 태도이더군요. 그래서 그를 괘씸하게 생각한 프로젝트매니저가 ‘그렇게 좋은 방안을 고객에게 이야기했으니 한번 보고서로 꾸며봐라.’고 지시하면, 몇 날 며칠을 끙끙대기 일쑤였고 그나마 가져 온 보고서 내용은 그가 말한 ‘이상적인 내용’과 거리가 먼 그저 누구나 말할 수 있는 평범한 내용 일색이었습니다.

이렇듯 말만 번지르르하고 그것을 보고서나 자료로 제대로 옮기지 못한다면, 그는 100% 엉터리 컨설턴트입니다. 이런 사람은 컨설턴트를 그만 두고 다른 일을 찾는 게 본인을 위해 나을 겁니다.

둘째, 엉터리 컨설턴트가 작성한 보고서는 굉장히 화려합니다. 보고서 페이지 마다 총천연색의 갖가지 도형들이 가득하죠. 그리고 프리젠테이션을 하면 여기 저기 날아다니는 애니메이션 효과가 마치 영화를 보는 듯합니다. 모르는 사람이 보면 굉장히 그럴 듯하게 여기겠지만, 사실 화려하게 치장된 보고서와 프리젠테이션의 내용을 보면 별 볼 일 없는 경우가 상당히 많습니다. 

물론 보고서의 가독성(可讀性)과 프리젠테이션의 흡입력을 높이려면 도표나 도형, 그리고 적절한 색깔의 사용은 필수적입니다. 그러나 눈이 어지러울 정도로 화려하게 꾸며 내용보다는 화면에만 도취하도록 만든다면 문제가 있습니다. 인터넷에 올려진 어느 글을 보니, 미국의 육군에서는 화려한 파워포인트 프리젠테이션을 금지했다고 합니다. 화려함 때문에 내용이 축소되거나 왜곡될 수 있기 때문이라고 합니다. 

만일 컨설턴트의 보고서나 프리젠테이션 자료가 지나치게 화려할 경우 멋지다고 생각하지 말고 반드시 그들에게 시정을 요구해야 합니다. 컨설팅 보고서와 관련자료는 고객들이 그것을 읽고 충분하게 이해하여 실행에 옮길 수 있도록 명료하고 구체적이어야 합니다. 갖가지 도형과 총천연색으로 내용의 부실함을 감추고자 하는 속셈이 다분하다고 느껴질 때, 우리는 그를 역시 100% 엉터리 컨설턴트라고 여겨도 무방합니다.

셋째, 엉터리 컨설턴트는 유행어나 전문용어를 사랑(?)합니다. 소위 3글자로 된 경영전문용어는 ERP, CRM, ABC, ABM, SCM, BPM, BPR 등 셀 수 없이 많습니다. 3글자로 되어있지 않으면 최신경영기법이 아닌 것처럼 보일 정도죠.

고객이 그걸 알아듣든 말든 자신만 아는 전문용어를 남발하며 한껏 현학적인 발언을 즐기는 컨설턴트는 속 빈 강정과 같은 엉터리인 경우가 많습니다. 반면, 진정으로 능력 있는 컨설턴트는 고객과 눈높이를 맞출 줄 압니다. 경영기법에 대해 고객의 지식이 높으면 보다 전문적인 용어를 사용하여 니즈를 만족시키고, 그렇지 못하면 쉬운 일상적인 용어로 설명할 줄 아는 거죠. 

상대하는 고객의 지적 수준을 무시하고 화려한 미사여구와 전문용어를 구사하는 자의 마음에는 본인이 잘났다는 은근한 과시는 물론, 고객을 깔보는 시선 또한 내재돼 있음을 알아야 합니다. 

끝으로 '엉터리 컨설턴트 감별법'을 올려 봅니다. 만일 ‘예’가 7개 이상이면, 그를 멀리하십시오. 4개에서 6개 사이면, 그가 엉뚱한 방향으로 컨설팅을 끌고 가는지 면밀히 감시하십시오.

평가문항 중 재미있는 것은, ‘보고서에 엉뚱하게 다른 회사 이름이 나온다’는 항목입니다. 타사 사례라면 몰라도 앞뒤 정황에 맞지 않게 타사명이 주어(主語)나 목적어로 등장했다면, 100% 베낀 것임에 틀림없습니다. Copy & Paste 해 놓고 실수로 회사명을 고치지 않은 것이죠. 이 역시 엉터리들이 자주 범하는 실수이니 눈 여겨 보기 바랍니다.
 

엉터리 컨설턴트 감별법

말하지 못해 죽은 귀신이 붙었다
말과 보고서가 불일치하다
말은 잘하는 데 글 쓴 걸 보면 이해하기 어렵다
고객의 답변을 자기 멋대로 해석한다
다른 컨설턴트의 말을 대놓고 무시한다
보고서에 텍스트보다 도형이 더 많다
총천연색을 사랑한다
프리젠테이션 치장에 시간을 많이 보낸다
보고서에 ‘효율/효과적으로’, ‘체계적인’, ‘합리적인’ 등 쓸데없는 수식어가 많이 등장한다
보고서에 엉뚱하게 다른 회사 이름이 나온다
볼 때마다 인터넷에 접속해 있다
지나치게 전문용어를 구사한다
문제해결을 상품(경영기법)으로만 접근하려 한다
전문용어 설명을 얼버무린다
자꾸만 회의, 인터뷰, 워크샵을 하자고 한다
공은 자신에게, 책임은 다른 사람에게 돌린다

* '컨설팅 절대 받지 마라'(유정식 저)에서 수정 발췌


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


  
,


내가 컨설턴트 A군을 데리고 컨설팅을 진행하던 어느 날이었다. 재무제표를 바탕으로 인건비 지출의 적정성을 분석하는 작업을 A에게 지시했다. A는 그 작업을 언제까지 마쳐야 하나며 나에게 물었다. “그 작업은 하루면 충분해. 다른 일로 바빠질 것 같으니 지금 시작해 줘.”, 라고 답해줬다. 그랬더니 그 친구는 너무하다는 표정을 짓고는 시간을 더 달라고 아우성이었다. 마음 약한 내가 어쩌겠는가? 결국 3일의 시간을 A에게 주면서 “납기는 반드시 지켜라.”는 다짐을 받아두었다.

그런데 요놈 봐라! 처음 이틀은 빈둥빈둥 놀며 인터넷과 메신저에 빠져 키득거리고 있는 것이 아닌가? 당장에 호통 칠까 하다가 약속한 기일까지 어쨌든 기다려보기로 했다. 그때 가서 혼내줄 요량이었다. 약속한 날이 되자 A는 슬금슬금 관련 자료를 챙기고 하는 척하기 시작했다. 하루 종일 꼼지락대더니 저녁때가 되자 쓱 하고 뭔가를 내놓았다. 내가 지시했던 작업 결과였다.

내가 제일 싫어하는 알록달록 총천연색으로 장식된 문서였다. 그 문서의 모양새는 차치하고서라도, 도대체 숫자들이 서로 맞지 않았다. 급하게 한 티가 팍팍 났다. 화가 난 나는 A에게 그동안 지켜 본 바를 이야기하며 왜 빨리 분석을 시작하지 않았는지 이유를 물었다.

A가 대답했다. “작업을 하기 전에 생각할 시간이 필요했다.” 어이쿠! 속으로 불덩이가 솟는 것을 억지로 참았다. 세상에, 간단한 숫자계산에 길고긴 사색의 시간이 요구된다니 어이가 없어서 나중엔 웃음만 나왔다. 그 이후에도 그런 식의 태도를 강력히(?) 견지하는 A를 결국 떠나보내지 않을 수 없었다!

사용자 삽입 이미지
학생증후군?
여러분은 학창시절에 교수가 과제를 내주면 거의 습관적으로 “너무 시간이 촉박해요. 조금 더 시간을 주세요.” 라는 앓는 소리를 누구나 해봤을 것이다. 그런데, 교수가 10일의 시간을 줬다면 처음 5일 정도는 아예 신경 끄고 다른 일을 하다가, 3일 정도는 고민 좀 해보고, 막판이 돼서야 부랴부랴 해내지 않았었나?

이것을 ‘학생 증후군’ 이라고 한다. 즉 어떤 작업을 수행하는 데 소요되는 시간을 예측할 때마다 습관적으로 실제 소요될 시간에다 여유시간(Slack Time)을 덧붙여 부풀리는 증상을 말한다. 이 학생 증후군을 ‘직장인 증후군’이라고 불러도 될 만큼, 회사 여기저기에 이런 증상을 보이는 직원들이 많다는 사실을 부인하긴 어려울 것이다. 혹시 여러분이 그 중 하나가 아닌가?

그러면 분명 하루 밖에 안 걸리는 일에 3일이나 5일의 시간을 요구하는 이유는 무엇일까? 누가 당신에게 차를 가지고 주어진 시간 안에 잠실에서 종로까지 와달라고 지시했다고 가정해보자. 그리고 그 일이 여러분에게 매우 중요한 일이라고 해보자. 시간이 얼마나 걸릴 것 같은가? 교통체증이라는 변수 때문에 어쩔 때는 30분밖에 안 걸리지만 최악의 경우 2시간이 걸릴 수도 있을 것이다.

당신은 그에게 얼마의 시간을 달라고 요구할 것 같은가? 백이면 백 2시간 정도는 줘야 한다고 말할 것이다. 왜냐하면, 작업에 소요되는 최대시간을 그 작업의 실질적인 수행시간으로 삼는 경향이 있기 때문이다. 실제로 2시간이 소요될 확률은 매우 적은데도 말이다.

프로젝트가 질질 늘어지는 이유
어떤 프로젝트가 있는데, 여러분이 A, B, C 3명의 프로젝트 멤버를 거느린 프로젝트 매니저라고 가정해보자. 프로젝트가 시작되기 전에 여러분이 멤버들에게 각자가 맡은 작업이 얼마나 걸릴 것 같은지 물어봤더니 A가 5일, B가 6일, C가 7일이라고 답했다. 그러면 여러분은 모두 더해서 총 18일을 프로젝트 소요시간으로 간주할 것이다.

그런데 이때 각자가 답한 소요시간에는 이미 여유시간이 포함되어 있을 가능성이 높다. 그 비율이 개인별로 차이가 나겠지만 말이다. A, B, C가 각각 1일, 2일, 3일의 여유시간을 나름대로 계산에 넣어뒀다면, 실제 프로젝트 소요시간은 4일, 4일, 4일로 총 12일이다. 18일과 비교할 때 6일의 차이가 난다.

그러나 이것만으로 끝나는 것은 아니다. 프로젝트 매니저인 여러분은 A, B, C가 답한 결과인 18일에다 5일 정도를 덧붙여서 모두 23일 걸린다고 상사에게 보고하기 때문이다. 그래야 18일을 경과하더라도 비난을 피할 수 있겠다 생각한 탓이다. 결국 12일에 끝날 일이 11일이 더 보태져서 23일이 지나야 끝나는 불합리한 현상이 발생한다.

이 프로젝트에 관여된 의사결정자들이 겹겹이 존재하면 사태는 더욱 심각해진다. 흔히들 그러지 않는가? 부장 보고를 위해 2일 정도 여유시간을 붙이고, 부사장 보고를 위해서는 3일, 사장 보고를 위해서는 5일 정도를 늘이는 따위의 행위 말이다.

이렇게 되면 11일에 끝날 일이 33일이나 걸려 겨우 끝난다! 단계 단계를 지날 때마다 하루하루씩 늘어나는 게 뭐가 대수냐고? 조직 전체로 생각해보면 그 양은 엄청나다. 남들이 1년에 할 것을 3년이 지나야 겨우 해낸다면, 우리 회사는 그만큼 경쟁에서 뒤처지는 것이다.

무조건 빨리 빨리?
H사 회장이 연구개발센터 건설 현장을 찾아가 금일봉을 전달하면서 예정된 공기보다 앞당겨 달라는 말을 수차례 내렸다는 말이 있었다. 무슨 이유로 공기 단축을 지시했는지 모르겠지만, 연구개발센터에 남다른 애정을 쏟고 있는 것으로 보아 아마도 하루 바삐 건립된 모습을 보고 싶어 하는 이유 때문일 것이다. 안 좋게 이야기하면 그의 조급증 때문일지도 모른다.

대부분의 관리자들은 프로젝트 완료 시점에 대한 예측을 일단 믿으려 하지 않는다. 직원들이 알게 모르게 여유시간을 끼워 넣고 있다는 사실을 간파한 까닭인지도 모르겠지만, 어쨌든 결과를 빨리 보고 싶어 한다. 그래서 100일 걸릴 예정이라고 보고하면, 앞뒤 안 가리고 20일 정도를 줄이라고 하는 것이 보통이다. 프로젝트 실무자들은 관리자의 한마디에 일률적으로 프로젝트 일정을 압축(?)하는 과정을 거치는 게 상례이다.

보통 할 일이 별로 없는 관리자일수록 결과를 재촉하길 좋아한다. 그 일 이외에는 별로 하는 일이 없기 때문이기도 하지만, 일단 다그쳐 줘야 권위가 선다는 유치한 생각 때문이기도 하다. 그런데, 정작 결과를 제출하여 검토를 요청하면 차일피일 미루기 일쑤다. 자기 자신에게는 한없이 너그러운 것이 무능한 관리자의 단면이다.

이러한 관리자의 습관 때문에, 아예 애초부터 125일 정도 걸릴 거라 부풀리는 악순환이 이어진다. 아이러니하게도, 일을 빨리 끝내려는 관리자의 시도가 일을 늦게 끝마치도록 유도하는 꼴이 된다. 결국 관리자나 프로젝트 실무자나 Lose-Lose 게임이 되는 것이다.

조직의 민첩성을 위해
실행력을 저해하는 요소의 첫째는 마지막에 가서야 일을 시작하는‘직장인 증후군’이고, 둘째는 겹겹이 쌓인 의사결정단계이며, 셋째는 관리자의 대책 없는 조급증 때문이다. 따라서 이 세 가지 요소를 격파한다면 실행력을 높일 수 있다.

나이 먹은 직장인들이 학생들처럼 징징거리며 해야 할 일을 미루지 않고 당장 실행하게 하는 것이 무엇보다 중요하다. 이를 위해 관리자가 역시 중요하다. 본인의 경험을 충분히 떠올리며 작업에 소요되는 실제 시간과 작업품질의 목표를 명료하게 전달해야 한다. 그렇다고 빨리 끝내는 것이 좋다고 생각하여 지나치게 빠듯한 시간을 강요하지는 말라. 부하직원들이 알아서 요리조리 피할 궁리만 하게 될 테니까 말이다.

복잡한 의사결정 단계가 있다면 이를 과감히 줄여야 한다. 모회사 이야기를 들어보니, CEO가 중간관리자를 거치지 않고 바로 실무자의 보고만 받는다고 한다. 조직도를 펼쳐 놓고 한번 살펴 보는 것이 어떨까? 자리를 주기를 위해 만들어 놓은 ‘장(長)’이 얼마나 많은지 볼 수 있을 것이다.실행력을 높이려면 답은 하나다. 조직을 혁신하라!


  
,