딘 캐리슨 저
이진원 역
2003년 10월
소프트웨어 개발프로젝트가 수행된 이래 프로젝트 데드라인, 일명 납기(^^)를 잘 지키기위한 방안에 관한 많은 책들이 씌어져 왔습니다.
죽음의 행진(Death March:Edward Yourdon), 데드라인:소설로 읽는 프로젝트 관리(The Deadline: A Novel About Project Management,Tom DeMarco),프로젝트 데드라인(Under Pressure and On Time,Ed Sullivan) 등등..
도서관에서 우연하게 만난 책 '데드라인'은 좀 다릅니다.원제는 'Deadline! : how premier organizations win the race against time' 입니다.
책에서 소개하는 내용에는 IT 프로젝트는 하나도 없습니다.
대신 세계 최고의 조직들이 불가능해보이는 프로젝트를 어떻게 성공적으로 마무리했는지 프로젝트 관리 및 리스크 관리방안을 사례를 통해 설명하고 있습니다.
세계의 유명 조직들이 어떻게 시간과의 싸움을 이겨냈는지를 저자인 댄 캐리슨이 오랜 기간의 인터뷰를 통해 수집한 자료를 정리한 글이라 이론뿐만아니라 현장의 목소리도 많이 들어있습니다.
또한 각각의 사례마다 우리들이 배워야할 실천적 과제를 제시하고 있어 우리의 현실에 어떻게 적용해야 할지 고민해보는것도 큰 의미가 있을 것 같습니다.
프로젝트 데드라인에 관한 책들이 말하는 공통주제는 관리기술에 관한것도 있겠지만 '사람','팀'에 관한 내용입니다.
이 책 '데드라인'에도 시간과 공간의 제약을 받고 있는 프로젝트를 성공시키기 위해 어떻게 훌륭한 팀을 만들고 고객을 설득하고 사람들을 움직이게 할것인가.. 이 질문에 대답이 될 만한 여러 교훈들이 녹아있습니다.
각 사례의 소제목들을 요약하면서 깨달은건데 중복되는 교훈이 많이 있습니다. 서로 다른 분야라 하더라도 조직을 운영하는데는 공통적인 면이 많다는 의미겠지요.
책 씌여진지는 좀 오래되었지만(원서는 2002년, 번역서는 2003년) 여전히 유효한 교훈들이니 일독해보는것도 좋을듯 싶습니다.
(주의) 아래 정리한 내용은 개인적으로 책내용을 요약한거라 사례를 읽지 않으면 이해가 잘 안되는 문구들도 있습니다.
==================================================
Chapter 1. 터너건설의 덴버 브롱코스 스타디움 건설기
많은 장애때문에 기일안에 공사를 완공하는것이 어렵다고 알려진 미국 덴버의 브롱코스 스타디움을 더 적은 비용으로 더 빨리 건설해낸 터너건설의 이야기입니다.
1) 적과의 협력을 통해 시간을 단축하라
건설회사와 적대적인 관계인 설계회사와의 협력을 통해 절대적으로 부족한 시간을 단축 (설계와 동시에 건설)
2) 출발신호를 기다리지 말라
투표결과에 따라 스타디움 건설이 백지화 될 수도 있었으나 미리 준비하여 리스크를 줄임
=> 최악의 상황이 되어 일이 취소되더라도 다음 데드라인을 좀 더 쉽게 다룰 수 있는 경험을 쌓을수 있다
3) 예상되는 상황을 기다리지 말라
부지가 확보되지 않은 상황에서도 현실적으로 공사가 가능한 부분부터 공사를 시작
=> 제대로 준비될때까지 기다리다가는 위험에 직면하고 만다.
4) 모든 의사결정자를 한곳에
빠른 의사결정을 위해 모든 이해당사자를 한 곳에 위치시킴
-본문중 "결정에는 좋은 결정, 나쁜 결정이 있지만 가장 나쁜것은 결정을 못내리는것이다. 적절한 시기에 내린 잘못된 결정은 고칠 시간이라도 있지만 지체하다 내린 결정이 잘못된 것이면 고칠 시간도 없다"
5) 아무것도 없이 스케줄을 짜서는 안된다
현실적인 스케줄을 작성하고 계획을 세울때마다 당사자를 참여시켜 스케줄을 납득할 수 있게 한다.
중요 deadline마다 중간기록을 점검하고 스케줄을 당길 기회가 있으면 그때마다 당겨놓는다.
6) 방해세력을 일의 초기단계에 참여시켜라
절차(소방서), 환경문제(멸종위기의 쥐보호)등으로 프로젝트에 개입하는 세력에게 우호적으로 대함으로써 불필요한 지연을 막는다.
=>중요결정이 끝난상태에서의 외부의 개입에 의해 변경이 가해지면 엄청난 비용과 시간이 필요하다. 사전에 막아라.
7) 밀어붙여라. 그러나 때로는 풀어주라
인간은 본능적으로 스스로에게 관대하기 때문에 모든 직원들에게 끊임없이 동기부여가 필요하다고 많은 관리자들이 생각한다.
하지만 너무 많은 오버헤드는 역효과를 가져온다. 데드라인에 몰린 직원들을 가끔 풀어주는 일이 필요하다.
8) 되돌아갈 배를 불태우라 (시저가 잉글랜드 침공할때를 비유함)
직원들이 '데드라인을 맞추지 못할 경우'라는 만약의 상황을 생각하지 않도록 한다. 물론 백업플랜이나 만약의 사태를 준비할 필요는 있으나 모든 직원이 그런 생각을 갖고 있다면 데드라인을 지킬 수 없다.
9) 데드라인을 유명한 프로젝트로 만들어라
직원들이 자긍심을 갖고 일할 수 있게하라.
10) 분쟁은 당장 해결하라
분쟁은 즉각, 그리고 개인적으로 해결하라. 프로젝트 멤버과의 분쟁이 지속되면 분쟁이 지속되면 데드라인은 지켜질 수 없고 공개적으로 비난하면 역효과가 발생할 가능성이 높다.
11) 모아놓은것을 공유하라
터너사는 공사기간 단축으로 얻은 이익을 참여한 사람들과 공유했다.
경영진이 실패의 결과는 책임지지 않으면서 아래사람들의 노력으로 얻은 성과에 대해서는 가장 먼저 이익과 칭찬을 챙기는 집단으로 인식되면 안된다.
12) 불가능한 임무는 절대 맡지 말라 - Mission impossible is impossible.
정말 불가능하면 받아들이지 말라. 좀더 현실적인 스케줄을 제시하던지 아니면 포기하라.
13) 데드라인을 기꺼이 받아들여라
데드라인이 무서우면 보험이나 파는게 낫다. ^^
Chapter 2. 미국 영화배급산업의 스타, 에어본 익스프레스(Airborne Express)
과거에는 NFS(National Film Service)가 미국내 영화배급을 독점했다고 합니다. 1990년대 초반 Technicolor사가 배급사업에 변화를 일으키기 위해서 UPS, Fedex 등에 영화배급을 제안했으나 양사는 제안을 거절합니다.
Airborne Experss가 그 제안을 받아들이는 모험을 감행했고 결국 7년간 점유율을 70%까지 끌어올리게 됩니다. 이것을 가능하게했던 Airborne Express의 이야기입니다.
1) 상대방을 옹호하라
아군앞에서 고객의 요청을 옹호해야 할 경우 용기를 내야한다.
단기적으로는 조직내에서 미움을 받겠지만 고객을 최우선시함으로써 회사와 고객 모두에게 승리를 안겨줄 것이다.
제일 중요한것은 상호이익이 되는 해법을 제시하는것이다.
2) 위험을 받아들이는 문화를 만들자
실패를 허용하지 않는 조직, 위험을 감수하지 않는 조직은 발전할 수 없다.
3) 베타테스트에 고객을 참여시켜라
베타테스트에 고객을 참여시킴으로서 얻는 이득은 생각보다 많다.
예를들면 초기에 고객으로부터 피드백을 받을 수 있어 저비용으로도 수정이 가능하다는 장점같은것 말이다.
4) 데드라인 중심의 기업문화를 만들자
5) '한개의 실수도 허용되지 않는다'는 생각을 갖게하라
'한번에 성공하지 못하더라도 대담하고 창의적인 생각은 용인'
'완벽히 이해하고 있는 임무를 부주의하게 처리하는것에 대해서는 당연히 용인하지 않는다.'
6) 사전에 문제를 찾아내라
7) 결정권한을 한곳에 몰아라
여러 다양한 고객의 요구로부터 직원을 보호하라. 이는 결정을 내려서는 안되는 사람들이 결정을 내리지 못하도록 막는 장점도 갖고있다.
8) 고객이 쉽게 데드라인을 맞추도록 만든다
고객을 무시하거나 현실을 이해하게 만들기보다는 고객이 일을 쉽게 할수 있도록 해줌으로써 데드라인을 맞출 수 있게하라.
9) 상대방에게 집착하라
자신의 팀의 범위에 고객등 핵심파트너를 포함시키고 그들이 같은 팀이라는 자긍심을 갖도록 노력하라.
10) 어려운 선택의 순간으로부터 직원을 보호하라
11) 중요한 일 가운데 더 중요한 일을 가려내서는 안된다
모든 고객이 동일한 서비스를 받고 있다고 인식시켜야 한다
12) 큰 성공뒤에 오는 무기력감을 주의하라
13) 병행계획을 수립하라
원래 계획이 달성될 수 없을 때 함께 할 수 있는 병행계획을 수립하라
Chapter 3. NASA의 2001 화성탐사 오디세이 : 자연과의 데드라인
1) 스케줄에 여유를 둬라
스케줄 관리방법 첫번째. 스케줄에 여유를 둬라. 하지만 그 여유 스케줄을 팀원이 알면 안된다.
스케줄 관리방법 두번째. 여유시간을 팀원이 관리하게하라. 대신 더 이상의 여유시간이 없음을 알려줘라.
여유를 조금씩 주거나 한꺼번에 주거나 결국 관리가 가장 중요하다.
2) 포상 인센티브를 제공하라
3) 파트너와 유사한 팀제를 만들어라
JPL는 록히드사와 동일한 편제로 조직을 바꾸었다. JPL이 고객이었음에도 불구하고 말이다.
4) 팀에 '자유정신'을 불어넣어라
5) 책임감은 헌신적 태도에서 나온다
팀원들을 보호함으로써 헌신적 태도들 끌어내라. 업무이외의 것에 대한 불안을 줄여줘라.
6) 팀이 결정하도록 하라
팀내부토론을 통해 결정할 수 있게하고 리더는 최종결정만을 한다. 물론 책임은 리더의 몫이다.
7) 패거리문화를 만들지 말라
팀과 팀이 시너지 효과를 발휘할 수 있도록 조치를 취해야한다. 록히드마틴은 팀을 구성할 때 서로 다른 팀의 멤버를 한 팀으로 만들었다.
8) 사전에 실패를 예측해 대비하라
1-10-100 규칙. 구상단계의 오류를 해결하는데는 1명,설계단계에는 10명, 조립단계에는 100명이 필요하다.
9) 객관적인 검토 실시하기
결정을 객관적으로 검토할 수 있는 조직이 필요하다. 하지만 그 조직의 결정을 무조건 따를 필요는 없다. 현명한 결정을 위한 안전장치일 뿐이다.
10) 가끔은 느린것이 더 빠를 수 있다
급하게 하다 다시 하는것 보다는 천천히 그러나 착실히 하는것이 시간을 줄여준다.
Chapter 4. 생사의 벽을 넘은 FBI의 납치범 검거작전
1) 주도적인 입장을 고수하라
예상치 못한 데드라인에서는 리드하기보다는 끌려다니게 되고 그들의 기대치에 맞추려고 하다보면 페이스를 잃게 마련이다.
2) 팀원들에게 데드라인 관리도구들을 제공하라
3) 데드라인 일정을 기록하고 유지하라
프로젝트 이력을 문서화하라. 이렇게 작성된 일정은 보호망의 역할도 한다.
4) 사후검토과정을 가져라
성공을 가능게 한 요소를 찾고 향후 활용하라. 실패한 프로젝트는 실패요인을 찾아 반복하지 않는다.
5) 데드라인의 유형별 행동사례를 준비하라
일반적인 대응계획만으로도 미리 작성되어있으면 시간을 줄일 수 있다.
Chapter 5. 777여객기 인도를 위한 보잉의 질주 : Working Together
1) 고객의 일에 귀를 기울여라
단순히 듣는것에 그치는것이 아니라 서로가 서로의 요구사항을 이해해야한다.
2) 혼자 비밀을 짊어지지 말라
문제를 공개할 수 있는 분위기,용기. 이것들이 시간과 비용을 단축시킨다.
공개하면 '능력있고 똑똑한 누군가'가 문제를 해결해 줄것이다.
777모델에서 보잉은 바닥빔 재료를 금속에서 다른 재료로 변경했다. 그런데 제작 당시에는 곧았던 빔이 얼마 지나지 않아 3인치가량 휘어진다는것을 제작업체가 밝히게 된다.
스스로 해결하려다가 시간을 보내기보다는 문제를 공개하기로 한것이다. 누군가 '처음부터 휘어놓으면 스스로 다시 곧아지지 않겠는가'라고 농담처럼 제안했는데 결국 그 제안이 채택되었다.
그는 아무 상관없는 다른 팀 소속이었다.
3) 일찍 그리고 자주 공유하라
4) 처음부터 긴장하라
5) 하나의 큰 그림을 그려라
전체 팀이 모이는 미팀에서 '큰그림'에 대한 이미지를 심어주고 업데이트하라. 공동의 목적과 집단적 책임감이 직원들에게 가시화되는 효과를 얻을 수 있다.
6) 미니 데드라인 달성을 축하하라
프로젝트 중반에 직원들을 격려하고 자극하는 좋은 계기가 될 것이다.
7) 거절할 수 없는 제안을 하라
프로젝트를 규제하고 저지하려는 상대가 나타날 경우 상대방이 받아들일 수 밖에 없는 매력적인 제안을 내놓아 우리편으로 만들어라.
승인등 시간이 걸리는 일을 단축시킬 수 있다.
8) 데드라인 이후를 생각하라
새로운 변화(Working Together)는 데드라인을 잘 지키기 위해 도입되었지만 데드라인을 위협할 수도 있다.
실제로 777은 767의 제작기간보다 3~4개월 더 걸렸지만 이후를 생각해보면 그건 아무것도 아니다.
9) 고객이 데드라인을 지킬 수 있도록 도와줘라
자신의 데드라인이 끝났다고 고객의 문제를 모른척해서는 안된다. 고객의 문제는 우리의 문제이다.
Chapter 6. 단 이틀이 걸린 CONOCO의 재해 복구활동
'책을통해세상보기' 카테고리의 다른 글
달인 : 천 가지 성공에 이르는 단 하나의 길 (0) | 2008.05.11 |
---|---|
사랑하지 않으면 떠나라! (0) | 2008.03.15 |
뉴욕의 프로그래머 : 프로그래머의 일상 (0) | 2008.02.03 |
프로그래밍과 글쓰기 (0) | 2008.02.01 |
실패로부터 배우기 - 초난감 기업의 조건 (0) | 2008.01.02 |
댓글