SlideShare a Scribd company logo
1 of 122
Download to read offline
CRITICAL CHAIN
PROJECT MANAGEMENT
JISUNG, AHN
2015.01
PROJECT
• 어떤 특정 목적을 달성 하기 위한 일련의 행위들
• 시작, 중간, 끝이 명확하다
프로젝트에 문제가 있다
• 예산 초과
• 시간 초과
• 내용 절충
왜냐하면…
• 공식적인 이유
• 기상 조건이 좋지 않았다
• 납품업자가 예기치 못한 문제들을 일으켰다
• 정부와 고용조건을 협상하는데 시간이 예상보다 오래 걸렸다
• 프로젝트 리더가 말하길
• 회사에서 실현가능성 없는 일정을 밀어 부쳤다
• 품질문제에도 불구 하고 더 저렴한 납품업자를 선택하라는 압력
• 사건 경고에도 불구하고 직원과 작업자에 대한 훈련이 너무 늦었다
문제가 일어난 이유를 물어보면…
• 대체로 남탓이다.
• 최고 경영자들의 이유는 불확실성 탓으로 돌리는 경향이 있
다
• 하지만, 하위직/실무직에 있는 사람일수록 외부 보다는 내부
를 향해 손가락질 하는 경향이 있다.
• 내부에 원인이 있다면, 기업입장에서 무언가 할수 있는 일이
있다는 것이다.
조직이 무엇을 할수 있을까?
• 프로젝트를 더 잘 관리하기 위해 노력해야 한다.
• 프로젝트에 내제되어 있는 불확실성이야 말로 관리 잘못이라
고 불리는 현상의 가장 큰 원인
• 여기저기 커다란 불확실성이 널려 있는 상황에서 확실성을
끌어 낼수는 없다.
그럼 왜?
• 계획 수립 단계에서부터 이런 불확실성을 염두에 두지 않을
까?
• 30개월 걸리는 프로젝트를 경영자가 24개월에 완수하라고
하는등 경영적인 압박이 존재한다
• 따라서 불확실성에 대응할만한 여유시간 따위는 존재하지 않
는다….
• 그럼에도 계획 수립단계에서 불확실성을 염두에 두어야 한다.
프로젝트에서 불확실성은 어떻게 다루는
가?
• 여유 시간/자금/자원으로 다룬다.
• 프로젝트의 여유시간과 프로젝트의 각 단계의 여유 시간은 다르다.
• 어떤 프로젝트의 한 단계에 걸리는 소요 시간을 예측한다고 했을때
확률
시간
프로젝트의 여유시간?
• 중앙값은 이 시간 이전에 끝낼 확률이 50%
• 보통은 8~90%의 확률지점을 예측 소요 시간으로 잡는다.
• 머피의 법칙으로 부터 자신을 보호하기 위한 여유시간 -> 보통 중앙값의 200%. 불확실성이 클수혹 더 여유를
준다.
확률
시간
중앙값
50% 30% 20%
여유시간
보통의 예측 소요시간
정말 그럴까?
• 실제로 작업 소요시간을 측정하면
• 25%정도는 예정시간보다 조금 일찍 끝났고
• 50%는 제때 끝났으며
• 25%는 조금 늦어졌다고 한다.
• 어느 경우에도 200%의 여유 시간을 확인할수 없다.
크리티컬 패스
A.건물 신축
90일
B.설비공사
30일
C.공급업자 계약
15일
D.기계 제작
90일
E.공장에 기계 설치
30일
크리티컬 패스: 연결된 단계가 가징 긴 패스
위의 예에서는 A-B-E
크리티컬 패스
A. 90 B.30
E.30
그럼 C,D는 어떻게 계획 하면 좋을까?
크리티컬 패스
A. 90 B.30
E.30
리스크를 먼저 해결 하는 방안
C.15 D. 90
차이
이른
시작
크리티컬 패스
A. 90 B.30
E.30
정말로 필요할때까지 투자를 미루는 방안
C.15 D. 90
차이
늦은
시작
어느 방법을 선택해야 할까요?
빨리 시작할까요?
• 실제 프로젝트에서는 단순화 된 예제 보다 훨씬 더 많은 패스
가 있다. 단계가 훨씬 더 많다
• 만약 모든 패스를 가장 빨리 시작하는 방법을 선택한다면 프
로젝트 리더가 신경 써야 하는 일이 너무 많아진다.
• 너무 많을 일을 시작하면 집중력을 잃게 된다.
• 프로젝트 리더가 촛점을 잃으면 프로젝트는 아주 많이 지연
될수 밖에 없다.
늦게 시작할까요?
• 한 패스를 늦게 시작하는 방법을 택한다면,
• 그 패스에 관한한 여유 시간은 없습니다.
• 그 패스에서 조금이라도 지연되게 되면 곧장 프로젝트 지연으로 이어
진다.
• 따라서 늦게 시작하면 모든게 중요해진다. 모든 것을 집중 관리 해야
한다.
• 모든 걸 집중 관리 한다는 것은 전혀 집중 관리를 하지 않는 다는 것과
같은 말이다.
프로젝트 리더의 딜레마
• 빨리 시작하는 방법을 택하게 되면 촛점을 잃게 되고
• 늦게 시작하는 방법을 택하면 집중 관리가 불가능해지고
• 어떻게든 프로젝트 리더가 집중적으로 관리할수 있는 매커니
즘을 찾아야 한다.
• 적절한 통제 메커니즘으로 집중관리를 해야 한다.
통제 메커니즘?
• 프로젝트의 진행 상태를 측정하는 것
• 문제는 프로젝트 현황 보고서에 무언가 잘못되었다고 보고
가 될때는 이미 너무 늦었다는 것
• 프로젝트 현황 보고서에서 프로젝트의 90%를 끝내는데 1년
이 걸린후에, 나머지 10%를 끝내는데 꼬박 1년이 걸릴수도
있다.
프로젝트 현황은?
• 일반적으로 이미 정해진 작업량이나 투자액을 앞으로 진행해
야 할 작업량과 비교해 구해진다.
이렇게 측정을 한다면…
• 각 패스를 최대한 빨리 시작하려는 경향이 있다
• 한 패스가 지연 되더라도, 다른 패스가 빨리 진행 되면, 진척도를 보충할수 있기
때문
• 모든게 두리뭉실한 덩어리가 되어 버림
• 별 어려움 없는 패스들을 아무리 빨리 끝내 봐야 어쨌든 지연된 패스를 기다려
야 함
• 너무 이른 투자를 한셈이고, 더 나쁜건 좀더 집중해야 할 부분이나 신경써야 할
지연된 패스에 집중을 못하게 된다는 것
•
근시안적인 프로젝트 매니저라면..
• 문제가 생겨 지연 되는 패스를 무시할수 있다.
• 그래도 측정 결과는 여전히 프로젝트가 잘 지전되고 있는 걸로 나타난다. 프로젝
트 리더는 잘하고 있는 것처럼 보인다.
• 한동안은.
• 별 문제 없는 패스들이 다 끝나고 문제 있는 패스만 남게 되면, 비로서 오류가 드
러나기 시작한다.
• 그 많은 프로젝트들이 마지막 10%를 끝내는게 그리 오랜 시간이 걸리는 이유이
다.
• 크리티컬 패스의 중요성을 간과 한 것.
그럼 훌룡한 관리란 무엇일까?
• 비용을 20% 아꼈는데 고객 절반이 화를 내면?
• 제품을 잘 출시 했는데 비용이 200% 초과했다면?
• 좋은 관리란
• 비용을 통제하고,
• 쓰루풋(Throughput)을 지키는 것
회사를 체인으로 본다면..
구매부서 생산 마감 출하 마케팅 …
원가 세계
구매부서 생산 마감 출하 마케팅 …
원가 를 체인의 무게로 보았을때 하나 하나의 무게를 줄여서 개선 할수 있다.
마감 체인에서 200g을 줄였다면 체인 전체가 가벼워졌으므로 개선된 것
어떤 부분적인 개선도 자동적으로 조직의 개선으로 간주된다.
쓰루풋 세계
구매부서 생산 마감 출하 마케팅 …
연결중 단 한 연결 고리에서 뭔가 실수한다면?
회사 전체의 쓰루풋이 떨어진다.
고리 하나 하나가 중요 한게 아니라, 연결 그 자체가 중요하다.
체인의 강도는 가장 약한 고리가 결정한다.
만약 출하 체인을 3배 더 강화하면 쓰루풋이 개선될까?
NO
대부분의 경우 부분적인 개선은 전체적인 개선에 도움을 주지 않는다.
월말 증후군
• 원가를 관리하고자 한다면, 관리자는 원가 세상에 따라야 하고
• 쓰루풋을 지키고자 한다면 쓰루풋 세계에 따라야 한다.
• 월초에는..
• 비용을 통제한다. 야근도 통제하고, 배치 사이즈도 최적으로 유지하려고 한
다.
• 그러나 월말에는…
• 이런 것들은 모두 잊혀진다.
• 빌어 먹을 제품들을 출하 시키기 위해서 무엇이든 한다.
왜 쓰루풋세계여야 하는가?
• 과거에 받아들여졌던 절충이 오늘날 받아 들여지지 않음
• 10년전만 해도 80%만 정시에 출하해도 OK
• 오늘날엔 95%를 정시에 출하해도 클레임
• 10년전에 출하 했던 품질의 제품을 오늘날 출하하면 모두 반
품할것
• 쓰루풋을 보호하는 것이 훨씬 더 어려워 진것
집중하는 것이 중요하다.
• 우리는 집중을 파레토 법칙으로 이해한다. 중요한 문제 20%를 해결하는
데 집중하면, 80%의 이익을 거두게 된다.
• 그러나 이 법칙은 독립변수로 이루어진 시스템에만 적용된다.
• 원가 세계에만 적용된다.
• 쓰루풋의 세계에서는 20%를 개선한다고 해도, 그 대부분은 전체적은 조
직 성과를 개선하는데 도움이 되지 못한다.
• 연결이 중요하며, 변수들은 상호 의존적이다.
• 파레토 법칙은 적용되지 않는다.
무엇에 집중해야하는지 어떻게 아는가?
우선 체인에 대해서만 생각해보자
• 체인의 강도를 결정하는 것은 가장 약한 연결 고리이다.
• 체인을 튼튼하게 하고 싶다면 제일 먼저 무엇을 해야 할까?
• 제일 먼저 할 것은 가장 약한 연결 고리를 찾는 것이다.
• (시스템의 제약들을 찾는다)
제약을 찾았다면
• 제약이 어떤 종류인지 파악한다.
• 병목 자원인지
• 자원 제약이라면 두가지 개선이 가능
• 더 많은 자원을 투입하던가
• 더 효율적으로 쥐어 짜던가
• 정책 제약인지
• (시스템 제약을 어떻게 활용할지 결정한다. )
제약을 어떻게 활용할지 결정했다면
• 다른 연결 고리에 미치는 영향을 살펴 보아야 한다.
• 병목작업장에서 최대 10개를 생산할수 있을 때
• 의존관계의 비병목 작업장에서도 20개를 생산할수 있어도
10개만 생산해야 한다.
• (윗 단계에서 내린 결정에 다른 모든 것을 종속 시킨다. )
이제 쓰루풋을 개선한다
• 병목 작업장에 더 많은 기계를 사용하던가
• 사람을 더 투입하던가
• 병목지점을 개선하면, 쓰루풋이 개선된다.
• (시스템의 제약들을 향상한다. )
쓰루풋이 좋아졌는가?
• 약한 연결 고리를 계속 강화하다 체인 전체가 강해진다.
• 그런데 어느 순간 체인이 더이상 강해지지 않는다.
• 이 연결 고리는 더이상 제약이 아니다.
• 타성에서 벗어나 (다시 처음 단계로 돌아가 다른 제약을 찾아
야 한다. )
무엇을 집중 관리 해야하는가?
• 우리는 집중 관리하기 위한 절차를 찾아 냈다
• 쓰루풋 세계에서의 집중관리
• 지속적인 개선 작업, 카이젠
• 쓰루풋의 세계에서는 집중과 지속적인 개선 과정이 같은 것
이다
제약이론
• 시스템의 제약들을 찾는다
• 시스템의 제약들을 어떻게 활용할지 결정한다.
• 윗단계에서 내린 결정에 모든 것을 종속시킨다.
• 시스템의 제약들을 향상한다.
• 연결고리가 더이상 제약이 아니라면 처음으로 돌아가 다른
제약을 찾는다.
갈등
• 쓰루풋 세계에 따라 비 병목 작업장이 10개를 생산했다.
• 원가 세계에 의해 평가 된다면 이 작업장의 생산성은 50%이
다
• 모가지가 남아 날까?
문제란?
• 문제: 그것이 두가지 필요조건간에 갈등을 일으킬 때 그것을
문제라고 정의 할수 있다.
갈등 해소도
관리를
잘한다
비용을 통제
한다
쓰루풋을
보호한다
쓰루풋 세계에 따라 관
라한다.
원가 세계에 따라 관라
한다.
제약이론에서는
• 우리가 갈등에 직면하게 되면,
• 거기에는 반드시 어느 한쪽에 잘못된 가정이 존재하고,
• 잘못된 가정은 수정될수 있으며
• 잘못된 가정에 수정을 가함으로서 갈등은 제거할수 있다.
• 라는 가정을 한다.
갈등 해소도
관리를
잘한다
비용을 통제
한다
쓰루풋을
보호한다
쓰루풋 세계에 따라 관
라한다.
원가 세계에 따라 관라
한다.
비용관리를 잘 할수 있는 유일한 방법은
어디서든 부분적인 성과가 좋아야 한다.
모든 곳에서 부분적인 성과가 좋은 것으로는
좋은 쓰루풋 성과를 달성할수 없다.
위쪽 가정에 도전해보자
• 비병목 지점에서 부분 최적화를 하여 10개가 아닌 20개를 생
산하면
• 재고가 쌓인다
• 재고가 쌓이면 비용이 올라간다.
• 우리가 비병목지점의 업무 효율을 제한한 이유는 단한가지,
비용을 관리하기 위해서이다.
•
TOC(제약이론)에서는
• “전체적인 비용 관리를 잘 할수 있는 유일한 방법은 모든 곳
에서 부분적인 관리를 잘하는 것이다”.
• TOC에서는 많은 관리자와 거의 모든 시스템이 이 같은 가정
하에 관리를 하고 있다는 사실이, 현재 우리 조직들이 안고 있
는 가장 핵심적인 문제라고 본다.
철강소 예제
500 철강 업계에서는 오랫동안 “시간당 생산
량”을 주요 성과 측정 지표로 사용해 왔다.
510 대부분의 사람들은 자신이 평가받는 대로
행동한다.
515 각 부서들은 시간당 생산량에 의해 측정되
는 성과를 극대화 하려고 노력한다
530 작업 준비 시간이 길어지면 당연히 시간
당 생산량에 의한 작업량이 줄어든다
520 다른 제품보다 작업 시간이 길게 걸리는
제품이 있다
525 생산을 하지 않으면 시
간당 생산량은 제로이다
545 시간당 생산량에 의한 성과를 극대화 하
기 위해 각 부서들은 당장 시장에서 필요로 하
지 않는 제품을 제고로 쌓아두면서 까지 생산하
려는 경향이 있다.
540 일정한 기간 내에 시간당 생산량에 의한
성과를 극대화 하기 위해, 각 부서들은 작업 시
간이 긴 제품 보다는 작업시간이 짧은 제품을
먼저 작업하려는 경향이 있다.
560 V형 공정은 여러 분기점을 거치면서 제품
이 다양해진다.
550 시간당 생산량에 의한 성과를 극대화 하기
위해 각 부서는 배치 사이즈를 키우기 위해 주
문을 앞당겨 생산하는 경향이 있다.
545 시간당 생산량에 의한 성과를 극대화 하
기 위해 각 부서들은 도둑질을 초래하는 행동
을 하는 경향이 있다
TOC의 논지
• 현재 우리 조직들이 안고 있는 가장 핵심적인 문제이자 제약
은 우리의 관리시스템 대부분이 원가 세계의 가정이 올다는
믿음에 기초하고 있다는 사실
• 현실에 존재하는 시스템이라면 많아야 한개 내지 두개의 제
약
다시 프로젝트로 돌아가 보자
5+5 = 13
• 프로젝트 책임자는 각 사람들에게 각자 예측한 시간을 물어
그 시간들을 더합니다.
• 그리고 거기에다 다시 자신의 여유 시간을 추가하죠
• 여러 레벨의 관리자가 관여 하게 되면, 각 레벨마다 또 여유
시간을 두게 되죠
• 경영자가 일반적으로 20%정도 일정을 줄이라고 하기 때문
에 애초부터 25%정도 더 부풀리기도 한다.
프로젝트에서 여유시간이 더해질때
• 실패했던 경험을 토대로 여유 시간을 예측하는데, 이는 분포
곡선 오른쪽 끝쪽에 해당함
• 프로젝트 관리 레벨이 많아 질수록, 총 예측 시간도 길어진다.
• 예측 작업을 하는 사람들이 예측 기간이 전체적으로 잘릴 것
에 대비해 아예 미리 여유 시간을 추가한다.
?? 그럼 여유 시간 투성이 잖아??
• 그토록 많은 여유 시간이 포함되어 있는데 왜 그 많은 프로젝
트들이 제때에 끝나지 못하는 것일까?
만약 프로젝트에서
A 10일 B 10일
이런 연속된 두 단계가 있을때 A가 12일 만에 완료 되면 어떻게 될까?
B는 2일 지연 되어 13일째에 시작하게 될 것이다.
만약 프로젝트에서
A 10일 B 10일
이런 연속된 두 단계가 있을때 A가 8일 만에 완료 되면 어떻게 될까?
B는 9일째에 시작할까?
대부분의 경험자들은 B는 11일째에 시작할거라 답할것이다
예상 보다 일찍 끝낸 팀이 그걸 보고하지 않을 것이기 때문이다
일찍 끝낸다고 보상이 있는 것도 아니고
예측시간을 줄이라는 압력만 받게 되는 것을 안다
프로젝트에서
• 어떤 단계에서 일이 지연되면, 그건 고스란히 다음 단계로 이
전된다.
• 그렇지만, 한 단계에서 일찍 끝나 시간을 절약하게 되면, 그
시간은 대개 그냥 허비된다.
만약 프로젝트에서
A
-5일
B
-5일
C
-5일
D
+15일
이런 동시 작업이 있을때
3개의 작업은 모두 5일 일찍 끝나고
1개의 작업은 15일 지연되었다
E
동시에 진행되는 단계인 경우
그리고 그런 단계가 많은 프로젝트의 경우
가장 오래 지연된 단계가
다음 단계에 영향을 미치게 된다.
일찍 끝난 다른 모든 단계는 전혀 도움이 되지 않는다
우리가 추가한 대부분의 여유 시간은 전혀 도움이 되지 않는다.
필요한 곳에만 여유 시간을 줄수 있을까?
• 중요한 것은 단하나, 프로젝트 전체의 성과
• 그런에 우리는 각 단계의 성과를 지키는데만 신경을 쓰고 있
다
• 그렇게 시간을 벌어 봤자 다 낭비만 될뿐인데도
• 그래서 그 많은 여유 시간을 넣고도 프로젝트 전체가 위험에
노출된다.
하나의 단계에서 여유시간을 주어도..
• 어떤 단계는 늦어진다. (여러 단계가 아니고)
• 애초에 여유시간을 주었는데도?
• 학생증후군
• 처음에는 여유 시간을 가지려고 투쟁
• 그러나 일단 시간이 확보되면, 이제 시간이 충분한데 뭣때문
에 서두르겠는가?
학생증후군만으로 설명이 되는가?
• 너무 바빠서 여유 시간조차 없는 경우도 있는데?
• 멀티 태스킹!!
• 왜 멀티 태스킹이 나쁜가?
한 사람이 멀티 태스킹을 하면
• A,B,C 세단계의 일을 3개의 프로젝트를 위해 멀티 태스킹
한다고 할때
• 각 단계는 10일씩 소요된다.
• 이 일을 하는 사람은 압력을 받고 있고, 모든 사람을 만족시키
려 애를 쓴다.
• 결국 한단계의 일을 5일만 하고 다음 단계의 일로 넘어간다.
한 사람이 멀티 태스킹을 하면
A B C
10 10 10
A1 B1 C1 A2 B2 C2
20
20
20
리드 타임이 2배가 되었다
• 작업 준비 시간은 고려조차 하지 않아도 이렇게 된다.
• 더우기 멀티태스킹 단계에 여유 시간을 더 늘리면
• 모든 프로젝트의 리드 타임 역시 늘어난다.
여유 시간을 낭비하는 3가지 메커니즘
• 학생증후군
• 멀티 태스킹
• 각 단계에 존재하는 의존성
우리는…
• 전체 프로젝트 일자를 지키는 유일한 방법은 각 단계의 완료 일
자를 지키는 것이라고 믿어 왔다.
• 그결과
• 각 단계에 많은 안전 여유 시간을 두었다.
• 항상 세가지 메커니즘(a. 학생증후군, b.멀티태스킹, c. 지연된
시간은 누적되지만, 일찍 끝난 시간은 누적되지 않는 다는것)이
문제를 야기하고, 여유시간의 대부분이 헛되이 낭비되고 있다.
생산에서 처럼 프로젝트에서도 TOC가 성
립될수 있을까?
프로젝트에서…
• 제약은 무엇 일까?
• 병목은 무엇일까?
병목은…
• 한 기업이 더 많은 돈을 버는데 저해가 되는 요인
• 프로젝트라면, 개발을 끝내지 못하는 것
• 프로젝트가 시작해서 끝날때 까지의 리드 타임은 무엇에 의
해 결정되는가?
• 크리티컬 패스
제약을 찾았다.
• 제약을 최대한 활용 하기 위해서는 어떻게 해야 할까?
• 제약 자원을 낭비하지 말아야 한다.
• 프로젝트의 제약인 크리티컬패스를 낭비 하지 않는 다는 것은 무슨
뜻일까?
• 결국 시간을 낭비 하지 말아야 한다.
• 크리티컬 패스에서 할당된 시간을 낭비하지 말아야 한다.
• 크리티컬 패스에서 시간을 낭비하면 프로젝트가 지연될 것이다.
크리티컬 패스에 할당된 시간을 어떻게 낭
비하고 있는가?
• 너무나 많은 방식으로 시간이 낭비되고 있다.
• 그러나 핵심은, 우리가 프로젝트의 각 단계에 많은 안전 여유
시간을 끼워 넣고 있다는 사실이다.
• 가장 많이 낭비 되는 시간은 각 단계의 안전 여유 시간이다.
그래도…
• 약간의 여유 시간은 필요하지 않을까?
• 물론. 머피의 법칙이 있으니까
• 가장 도움이 될만한 곳에 안전 여유 시간을 끼워 넣어야 한다.
• 제약을 보호하려고 여유 시간을 둘 것이다.
• 우리의 제약은? 크리티컬 패스
• 우리는 크리티컬 패스의 완료 일자를 보호 해야 합니다.
모든 안전 여유 시간을 크리티컬 패스의 끝
쪽으로 옮겨보자
Task 1 Task 2 Task 3 Task 4
Task1 Task2 Task3 Task4 프로젝트 버퍼
이렇게 예측 시간을 줄이게 되면…
• 각 단계가 제때에 끝날 확률은 50%정도
• 당연히 실무자의 반발이 생긴다.
• 그래서 경영자의 경영지원이 필요하다.
• 제때에 못 끝난다고 해서 개인 평가에 적용되어서는 않된다.
• 그저 “팀”이 일을 최대한 빨리 빈틈없이 할수 있는지 알기 위
한 수단으로 사용해야 한다.
경영자가 버퍼를 잘라내려고 할텐데…
• 역시, 경영자의 경영지원이 필요하다.
• 프로젝트 버퍼를 자르면 프로젝트가 엉망이 된다라는 인식
이 필요함
• “최종 완료 날자만이 중요하다”라는 결단이 있어야 함
제약 자원을 최대한 활용하라
• 크리티컬 패스상에선 시간을 낭비하지 말라. 다음 단계로 넘
어가기 전까지는
• 그리고 모든 걸 제약 자원에 종속 시키기 전까지는
• 종속 시키지 않는다면 다른 곳에서 생기는 문제로 인한 시간
손실로 부터 제약 자원을 보호할수 없기 때문
크리티컬 패스에…
• 영향을 미치는 대부분의 문제가 크리티컬 패스 그 자체에서
발생하는 것이 아니다.
• 비병목 작업장에서 발생하는 문제들로부터 병목작업장을 어
떻게 지키는가?
• 병목 작업장 앞에 재고 버퍼를 둔다.
프로젝트에서는?
• 크리티컬 패스와 합류하는 공급 패스의 끝에 시간 버퍼를 끼워
넣어야한다.
• 이 시간 버퍼의 공식은?
• 각 공급 패스의 각 단계에 대한 애초의 예측 시간을 반으로 줄이
고,
• 줄어든 리드 타임의 절반을 공급 버퍼로 이용
• 쓰루풋의 세계에서 긴급은 쓰루풋에 영향을 미치는 것만이 긴급
공급 버퍼
시간만?
• 다른 모든 자원이 크리티컬 패스상의 한 단계를 위해 준비 되
어 있는데
• 다른 일을 하느라 바쁜 특정 자원때문에 지연되는 경우도 있
다
• 따라서 자원 버퍼가 필요하다.
이렇게 하면…
프로젝트 진척 상황
• 크리티컬 패스의 진척 상황만을 평가한다.
더이상 마일스톤은 없다
• 마일 스톤으로 2주가 주어 지면 그 2주일은 완전히 작업자의 것
• 1주일이 지나 재촉이라도 하면 “아직 1주일이 더 남았는데 대
체 뭘 바라는 거요?”
• 더이상 꾸물 거릴 여유가 없기에 꾸물 거리지 않는다. 학생증우
군이 사라진다.
• 프로젝트를 제때에 완료할수 있는 시간 예측 확률을 90%에서
50%로 줄여야 하는 이유임
멀티 태스킹은?
• 거짓 경고를 제거하고,
• 한 단계를 수행하는 시간을 실질적으로 줄이면
• 멀티태스킹을 줄이는데 큰 도움이 된다.
•
멀티태스킹은 자원에 대한 것인데?
• 이전에는 한단계의 작업을 하기 위해 모든 것이 준비되었지만,
• 사람들은 아직 준비가 않 된 경유가 비일비재했다.
• 크리티컬 패스에서는 그런일이 일어 나지 않게 해야 한다.
• 작업 1주일전, 3일전 크리티컬 패스가 곧 도래 함을 상기
• 작업 하루전 모든 것이 다 준비가 되었다는 것을 확인
•
모니터링은 어떻게?
• 프로젝트 버퍼를 모니터링
• 크리티컬 패스의 작업을 하는 사람은 매일 뜨거운 감자를 다
음 단계로 넘겨줄때까지 며칠이 더 필요한지 예측치를 보고
• 예측치는 매일 바뀔수 있다. 문제가 있으면 늘어 나고, 쉽게
해결되면 줄어들고
크리티컬 패스가 아닌곳은?
• 공급 버퍼에 대해서도 모니터링
• 다른 모든 버퍼에 대해서도 모니터링
• 모니터링 은 일일 보고서형태로 정리 가능
• 보고서 내용 정렬 우선 순위
• 1순위 프로젝트 버퍼를 잠식하는 작업
• 2순위 공급 버퍼를 소모하고 있는 단계
• 지속적으로 모든 버퍼를 모니터링 하고 있는한 그 버퍼들은 집중 관리가 될것
모든 프로젝트에 적용할수 있나?
프로젝트의 종류
• 납품업체나 하청 업체에 의해 수행 되는 프로젝트
• 회사 자체의 자원에 의해 행해지는 프로젝트
회사 자체의 자원 프로젝트에서의 변화
• 여러 자원을 설득해 리드 예측 타임을 줄이게 함
• 마일스톤을 없앰(각 개별 단계의 완료 예정 일자를 없앰)
• 예상 완료 작업일을 수시로 보고하게 함
납품업체나 하청업체에 의한 프로젝트는?
• 하청업체에 많은 것을 요구하지만….
• 결국 최종적으로는 가격을 요청한다
• 가격은 중요하지만, 리드타임도 그에 못지 않게 중요하다
• 변화는 거기서부터 시작된다
• 프로젝트 지연이 결국 재정적인 손실을 야기한다는 것 이해
해야 한다.
프로젝트가 지연되면
• 구축비용이 증가된다.
• 회사의 손실은 추가 매출이 늦어진다.
• 프로젝트 결과물이 매출을 영원토록 올려주지는 않는다.
• 따라서 단순히 돈이 지연 되는게 아니라, 상당부분 영원히 사라진
다.
• 한달의 지연이 얼마만한 금전적 손실을 주는지 깨닫지 못하고 있
다는 것이 프로젝트 팀원의 하청업체 관리 방식에도 영향을 준다.
왜 제때 끝내야 하는가?
• 제때 끝냐야한다.
• 그러나 왜 그러는가 정확한 이유를 모르고 있다
• 그래서 하청업체에게 가격만으로 경쟁하도록 해 놓는다.
• 리드 타임은 때론 가격보다 중요하다.
대부분의 하청업체는…
• 고객이 결과물에 OK하는데 너무 많은 시간을 허비한다는
안 좋은 경험을 가지고 있어서
• 미리 충분한 리드타임을 확보하려 하는 것이다.
일을 하고 있는 사람에게…
• 완료 날자를 말하지 않는게 얼마나 중요한가!
• 그런데 납품업체들에 대해선 어떻게 하고 있는가?
• 납기일을 지키라고 강요한다.
• 내부적인 원칙과 정반대이다.
납품업체들의 언어..
• 서로 다른 작업이 비슷한 리드타임으로 제시된다.
• 그들의 제안서를 잘 분석해보면
• 언제나 여유시간을 확인 할 수 있다.
• 가격과 리드타임을 맞바꾸는 옵션을 제시 할 수 있다.
• 더 빨리 납품하면 더 높은 비용을 지불하는 옵션
납품업체들은 보통…
• 고객의 요구사항 변경에 진절머리를 내기때문에, 리드타임
의 시작을 모든 요구사항이 전달된 시점으로 정하자고 할것
이다
• 보통 납품과정에서 가장 많은 시간을 뺏기는 과정이다.
•
납품업체와의 초기 협상은..
• 협상해야 하는 것은 리드 타임이다. 날자가 아니고.
• 업체에게 리드타임에 동의하게 하고
• 그 리드타임에 집착하게 하고,
• 그러다보면 우리 스스로 날짜를 결정하게 만드는 것이다.
• 납품업체가 아니고.
이런 협상을 할때…
• 리드 타임을 위해 돈을 더 지불하는 것은
• 일반적인 회사의 원가 비용 절감 정책에 위배된다.
• 경영자를 설득해서 경영지원을 얻어 내는 방법도 있다.
가끔은 리드타임 지연이 문제가 아닌것 같
은 프로젝트도 있다.
건설 프로젝트에서..
• 입찰은 매우 낮은 가격으로 이루어 진다.
• 그럼 어디에서 돈을 벌까?
• 변경을 통해서!
• 고객은 항상 옮다
• 고객이 변경을 원하면, 싸우지 않고 기꺼이 그에 응한다
• 그리고 그 변경에 이익을 붙인다
• 그래서 고객에게 더 많은 변경을 부추긴다.
• 일정은 그만큼 늘어난다. (부럽당 ㅠㅠ)
이런 회사에게 프록젝트가 앞당겨 끝나는
게 무슨 의미가 있을까?
• 만약 이런 회사에서 프로젝트가 3개월 늦게 끝났다고 가정하면
• 그 회사는 예상보다 3개월 후에 집을 팔수 있다.
• 현금이 3개월 후에 들어 오게 된다.
• 현금 흐름에 악영향을 준다.
• 저렇게 원가경쟁이 치열한 업계일수록 현금 흐름은 중요해진다.
• 따라서 프로젝트를 제때에 끝내는 것은 “회사 전체”로 보았을때
중요하다
이제 동일 자원이 여러 프로젝트를 진행하
는 상황으로 가보자
자원 버퍼 이야기부터 해보자.
• 실제로 “경고”만 하는 자원 버퍼는 실제 프로젝트 리드 타임
에 아무 변화도 주지 못한다.
크리티컬 패스는?
• 크리티컬 패스가 아닌 패스에서 작업이 많이 지연되어
• 공급버퍼를 이미 다 소모해 버렸고
• 프로젝트 버퍼까지 침투하기 시작했는데
• 크리티컬 패스 자체는 아직 괜찮은 상태일때
• 이런 상황이라면 크리티컬 패스가 변한것 아닐까?
크리티컬 패스는…
• 상호 종속적인 여러 단계 가운데 가장 작업 공정이 긴, 또는
작업 시간이 긴 패스를 크리티컬 패스라고 정의한다.
• 이 정의 에 따르면, 크리티컬 패스가 아니였던 N단계가 프로
젝트 버퍼까지 침투할 정도로 지연되었다면,
• N작업이 가장 긴 체인이 되고 있다는 것 아닐까?
그래서 크리티컬 패스를 프로젝트 중간에
변경할까?
• 우리는 비 크리티컬 패스가 크리티컬 패스에 만나는 곳에만 공급 버퍼를 둔
다 .
• 따라서 크리티컬 패스를 변경하면
• 불가피하게 공급버퍼의 위치도 바뀌어야 한다
• 그런데 그렇게 하면
• 프로젝트 전체가 혼란에 빠진다.
• 그렇게 할수 없다.
• 그렇게 하지 않으면 실제적인 크리티컬 패스를 보호할수 없다.
갈등!!
프로젝트를
제때에 끝낸다
모든 일정을 재조정
하지 않는다
실제로 변경되는 크
리티컬 패스를 그대
로 두지 않는다.
공식적으로 크리티컬 패스
를 바꾼다.
공식적으로 크리티컬 패스
를 바꾸지 않는다.
어떤 가정을 하고 있을까?
X
X
X FB
FB
X
X FB
FB
프로젝트버퍼
크리티컬 패스
프로젝트의 리드 타임은 작업 시간만으로
결정되는가?
• 단계들의 상호 의존성은 한 패스의 결과라고 할수 있고
• 공용 자원의 결과라고 할수도 있다.
• 일반적으로 가장 긴 체인은 패스가 상호 의존적이거나
• 자원이 상호 의존적인것에 의해 결정된다.
용어정리를 하자
• 크리티컬 패스는, 흔히 말하는 크리티컬 패스 또는 가장 긴 패
스
• 가장 중요한 것은 제약이고,
• 제약은 상호의존적인 단계들이 이어진 가장 긴 체인.
• 상호 종속성은 자원때문에 발생 할수 있기때문에
• 제약이 되는 일련의 단계는 “크리티컬 체인”으로 부르자
X
X
X FB
FB
X
X FB
FB
프로젝트버퍼
크리티컬 패스
X를 어떤식으로 작업순서를 정해야 할까?
• X를 필요로 하는 작업이 5개나 되는데
• 어떻게 순서를 정해야 할까?
8 X 8은 얼마일까?
• 우리가 프로젝트에서 다루는건 확정적인 숫자가 아니다.
• 우리가 어떤 작업이 8일 걸린다고 했을때
• 그게 정확하게 8일 걸릴 거라는 사실을 의미할까?
• 프로젝트에서 8 x 8 = 64 라는 답은 틀린 것이다.
• 자료가 정확하지 않은 상황에서 정확한 답을 찾으려 애쓰는 것은 잘못이다
• 문제에 내재된 불확실성보다 더 정확한 “척” 하는 답은 더 좋은 답이 될 수
없다.
어떤 순서로 X의 작업 일정을 잡든 별 차이
가 없다는 뜻인가?
• 차이는 있을 것이다.
• 그런데 실제적인 차이가 있을까?
• 프로젝트의 불확실성보다 큰 차이가 날까?
• 프로젝트의 불확실성을 재는 합리적인 척도는 어떤게 있을까?
• 프로젝트 버퍼
• 프로젝트 버퍼에 모든 불확실성의 누적된 결과가 담겨 있다.
자원 순서 최적화는…
• 많은 이론이 있지만,
• 어떤 경우든 프로젝트 리드 타임에 미치는 영향은
• 프로젝트 버퍼가 미치는 영향의 반도 되지 않는다.
• 각 단계의 시간 예측에 여유시간이 포함된다라는 사실을 감
안한다면,
• 프로젝트 리드타임의 1/4 정도 된다.
자원 경합을 고려하는 것과 작업 일정을 최
적화 하는 것은 다른일
• 자원 경합 요인을 제거해 버려라
• X에 의해 행해지는 어떤 두 단계도 동시에 진행되는 일이 없
게끔 작업 일정을 잡아라
• 제약을 변경했기 때문에,
• 그에따라 공급 버퍼도 변경해야 한다.
X
X
X
FB
FB
X
X
FB
FB
프로젝트버퍼
FB
크리티컬
체인
시스템을 제약에 종속시켰으니..
• 그냥 크리티컬 패스에 비교해서 완료 일자는 늦어진다.
• 하지만 이게 더 정직한 일정이다.
• 이제 제약을 향상시킨다
• X의 업무 부하를 다른 사람에게 나누어 줄수 있는지 체크한
다.
• 또는 다른 시간대로 넘길수 있는지도 체크한다.
다른 시간대?
• X가 프로젝트 내내 부하가 걸리는 것은 아니다.
• X의 작업중 일부는 좀더 일찍, 또는 늦게 끝낼수 있다.
• X의 작업중 상당 부분이 문서화일때
• 어떤 문서는 시스템 통합에 필수적이라 즉각 문서화가 이루어져야
한다.
• 하지만 대부분의 문서화는 단지 장래의 유지보수를 위한 것이다.
• 이런 일은 나중에 해도 된다.
프로젝트에서 자원 경합은 얼마나 심한가?
• 상황에 따라 다르다 .(당연히)
• 자원 경합이 벌어질 경우,
• 크리티컬 체인은 크리티컬 패스와 아주 차이가 날수 있다.
그때 체인이 아닌 패스에 따라 움직인다면
어떤 위험이 발생할까?
• 크리티컬 패스이 이리 저리 왔다 갔다 난리가 난다. 통제가 되
지 않는다.
• 자원 버퍼는 물론 공급 버퍼도 위치가 잘못 되어 있어서
• 제약이 보호 받지 못한다
자원 경합이 사라지면
• 작업 순서를 정하는 것은 그리 오래걸리지 않는다.
• 그런 다음 크리티컬 체인을 찾는다.
• 그리고 공급버퍼를 둔다
모든 문제가 해결되었나?
자원의 경합
• 자원의 경합은 동일한 자원이 동시에 서로 다른 두 단계의 작
업을 하기로 되어 있는 경우에 발생
• 두 단계 간에 자원 경합이 일어나지 않게 하려면
• 두 단계중 한 단계는 필히 지연되게 됨
• 그런데 어떤 단계를 지연해야 하는가를 결정할 명확한 방법이
없다.
• 거의 임의로 결정된다

More Related Content

Similar to Critical_Chain.pdf

현장에서 사용하는 Software production
현장에서 사용하는 Software production현장에서 사용하는 Software production
현장에서 사용하는 Software productionJinho Yoo
 
임태현, 프로그래머 생존 가이드
임태현, 프로그래머 생존 가이드임태현, 프로그래머 생존 가이드
임태현, 프로그래머 생존 가이드태현 임
 
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰Myeongseok Baek
 
SWDeveloperStory201501
SWDeveloperStory201501SWDeveloperStory201501
SWDeveloperStory201501Suho Kwon
 
프로젝트가 서쪽으로 간 까닭은
프로젝트가 서쪽으로 간 까닭은프로젝트가 서쪽으로 간 까닭은
프로젝트가 서쪽으로 간 까닭은종석 박
 
더 나은 팀을 위하여
더 나은 팀을 위하여더 나은 팀을 위하여
더 나은 팀을 위하여Heejong Ahn
 
멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면Byeongsu Kang
 
언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing software언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing softwareKevin Kim
 
10만 라인, 26280시간의 이야기
10만 라인, 26280시간의 이야기10만 라인, 26280시간의 이야기
10만 라인, 26280시간의 이야기Minyoung Jeong
 
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한..."행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...Myeongseok Baek
 
소프트웨어 개발 프로세스 배경 설명
소프트웨어 개발 프로세스 배경 설명소프트웨어 개발 프로세스 배경 설명
소프트웨어 개발 프로세스 배경 설명Andrew Sungjin Kim
 
[로컬챌린지프로젝트 교육자료] 기업역량강화교육 Lcp3기 2코스_프로젝트관리
[로컬챌린지프로젝트 교육자료] 기업역량강화교육 Lcp3기 2코스_프로젝트관리[로컬챌린지프로젝트 교육자료] 기업역량강화교육 Lcp3기 2코스_프로젝트관리
[로컬챌린지프로젝트 교육자료] 기업역량강화교육 Lcp3기 2코스_프로젝트관리thecirclefoundation
 
내 일의 주도권을 찾기 위한 습관, GTD 사용설명서
내 일의 주도권을 찾기 위한 습관, GTD 사용설명서내 일의 주도권을 찾기 위한 습관, GTD 사용설명서
내 일의 주도권을 찾기 위한 습관, GTD 사용설명서i4uworks
 
An inconvenient truth
An inconvenient truthAn inconvenient truth
An inconvenient truthSeokmoon Ryoo
 
나 혼자 한다: 개발자가 창업을 하면 벌어지는 일
나 혼자 한다: 개발자가 창업을 하면 벌어지는 일나 혼자 한다: 개발자가 창업을 하면 벌어지는 일
나 혼자 한다: 개발자가 창업을 하면 벌어지는 일Hyeonjong Gim
 
Productivity Hacks
Productivity HacksProductivity Hacks
Productivity HacksJahee Lee
 
git + Pull Request + Code Review and Project Management with Agile
git + Pull Request + Code Review and Project Management with Agilegit + Pull Request + Code Review and Project Management with Agile
git + Pull Request + Code Review and Project Management with AgileWooseong Kim
 
Pivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - CoinonePivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - CoinoneVMware Tanzu Korea
 
세상과 통하는 서비스 개발하기 자료 [스타트업 A to Z 세미나]
세상과 통하는 서비스 개발하기 자료 [스타트업 A to Z 세미나]세상과 통하는 서비스 개발하기 자료 [스타트업 A to Z 세미나]
세상과 통하는 서비스 개발하기 자료 [스타트업 A to Z 세미나]미선 윤
 

Similar to Critical_Chain.pdf (20)

현장에서 사용하는 Software production
현장에서 사용하는 Software production현장에서 사용하는 Software production
현장에서 사용하는 Software production
 
임태현, 프로그래머 생존 가이드
임태현, 프로그래머 생존 가이드임태현, 프로그래머 생존 가이드
임태현, 프로그래머 생존 가이드
 
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
 
SWDeveloperStory201501
SWDeveloperStory201501SWDeveloperStory201501
SWDeveloperStory201501
 
프로젝트가 서쪽으로 간 까닭은
프로젝트가 서쪽으로 간 까닭은프로젝트가 서쪽으로 간 까닭은
프로젝트가 서쪽으로 간 까닭은
 
첫 번째 모임
첫 번째 모임첫 번째 모임
첫 번째 모임
 
더 나은 팀을 위하여
더 나은 팀을 위하여더 나은 팀을 위하여
더 나은 팀을 위하여
 
멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면
 
언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing software언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing software
 
10만 라인, 26280시간의 이야기
10만 라인, 26280시간의 이야기10만 라인, 26280시간의 이야기
10만 라인, 26280시간의 이야기
 
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한..."행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
 
소프트웨어 개발 프로세스 배경 설명
소프트웨어 개발 프로세스 배경 설명소프트웨어 개발 프로세스 배경 설명
소프트웨어 개발 프로세스 배경 설명
 
[로컬챌린지프로젝트 교육자료] 기업역량강화교육 Lcp3기 2코스_프로젝트관리
[로컬챌린지프로젝트 교육자료] 기업역량강화교육 Lcp3기 2코스_프로젝트관리[로컬챌린지프로젝트 교육자료] 기업역량강화교육 Lcp3기 2코스_프로젝트관리
[로컬챌린지프로젝트 교육자료] 기업역량강화교육 Lcp3기 2코스_프로젝트관리
 
내 일의 주도권을 찾기 위한 습관, GTD 사용설명서
내 일의 주도권을 찾기 위한 습관, GTD 사용설명서내 일의 주도권을 찾기 위한 습관, GTD 사용설명서
내 일의 주도권을 찾기 위한 습관, GTD 사용설명서
 
An inconvenient truth
An inconvenient truthAn inconvenient truth
An inconvenient truth
 
나 혼자 한다: 개발자가 창업을 하면 벌어지는 일
나 혼자 한다: 개발자가 창업을 하면 벌어지는 일나 혼자 한다: 개발자가 창업을 하면 벌어지는 일
나 혼자 한다: 개발자가 창업을 하면 벌어지는 일
 
Productivity Hacks
Productivity HacksProductivity Hacks
Productivity Hacks
 
git + Pull Request + Code Review and Project Management with Agile
git + Pull Request + Code Review and Project Management with Agilegit + Pull Request + Code Review and Project Management with Agile
git + Pull Request + Code Review and Project Management with Agile
 
Pivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - CoinonePivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - Coinone
 
세상과 통하는 서비스 개발하기 자료 [스타트업 A to Z 세미나]
세상과 통하는 서비스 개발하기 자료 [스타트업 A to Z 세미나]세상과 통하는 서비스 개발하기 자료 [스타트업 A to Z 세미나]
세상과 통하는 서비스 개발하기 자료 [스타트업 A to Z 세미나]
 

Critical_Chain.pdf

  • 2. PROJECT • 어떤 특정 목적을 달성 하기 위한 일련의 행위들 • 시작, 중간, 끝이 명확하다
  • 3. 프로젝트에 문제가 있다 • 예산 초과 • 시간 초과 • 내용 절충
  • 4. 왜냐하면… • 공식적인 이유 • 기상 조건이 좋지 않았다 • 납품업자가 예기치 못한 문제들을 일으켰다 • 정부와 고용조건을 협상하는데 시간이 예상보다 오래 걸렸다 • 프로젝트 리더가 말하길 • 회사에서 실현가능성 없는 일정을 밀어 부쳤다 • 품질문제에도 불구 하고 더 저렴한 납품업자를 선택하라는 압력 • 사건 경고에도 불구하고 직원과 작업자에 대한 훈련이 너무 늦었다
  • 5. 문제가 일어난 이유를 물어보면… • 대체로 남탓이다. • 최고 경영자들의 이유는 불확실성 탓으로 돌리는 경향이 있 다 • 하지만, 하위직/실무직에 있는 사람일수록 외부 보다는 내부 를 향해 손가락질 하는 경향이 있다. • 내부에 원인이 있다면, 기업입장에서 무언가 할수 있는 일이 있다는 것이다.
  • 6. 조직이 무엇을 할수 있을까? • 프로젝트를 더 잘 관리하기 위해 노력해야 한다. • 프로젝트에 내제되어 있는 불확실성이야 말로 관리 잘못이라 고 불리는 현상의 가장 큰 원인 • 여기저기 커다란 불확실성이 널려 있는 상황에서 확실성을 끌어 낼수는 없다.
  • 7. 그럼 왜? • 계획 수립 단계에서부터 이런 불확실성을 염두에 두지 않을 까? • 30개월 걸리는 프로젝트를 경영자가 24개월에 완수하라고 하는등 경영적인 압박이 존재한다 • 따라서 불확실성에 대응할만한 여유시간 따위는 존재하지 않 는다…. • 그럼에도 계획 수립단계에서 불확실성을 염두에 두어야 한다.
  • 8. 프로젝트에서 불확실성은 어떻게 다루는 가? • 여유 시간/자금/자원으로 다룬다. • 프로젝트의 여유시간과 프로젝트의 각 단계의 여유 시간은 다르다. • 어떤 프로젝트의 한 단계에 걸리는 소요 시간을 예측한다고 했을때 확률 시간
  • 9. 프로젝트의 여유시간? • 중앙값은 이 시간 이전에 끝낼 확률이 50% • 보통은 8~90%의 확률지점을 예측 소요 시간으로 잡는다. • 머피의 법칙으로 부터 자신을 보호하기 위한 여유시간 -> 보통 중앙값의 200%. 불확실성이 클수혹 더 여유를 준다. 확률 시간 중앙값 50% 30% 20% 여유시간 보통의 예측 소요시간
  • 10. 정말 그럴까? • 실제로 작업 소요시간을 측정하면 • 25%정도는 예정시간보다 조금 일찍 끝났고 • 50%는 제때 끝났으며 • 25%는 조금 늦어졌다고 한다. • 어느 경우에도 200%의 여유 시간을 확인할수 없다.
  • 11. 크리티컬 패스 A.건물 신축 90일 B.설비공사 30일 C.공급업자 계약 15일 D.기계 제작 90일 E.공장에 기계 설치 30일 크리티컬 패스: 연결된 단계가 가징 긴 패스 위의 예에서는 A-B-E
  • 12. 크리티컬 패스 A. 90 B.30 E.30 그럼 C,D는 어떻게 계획 하면 좋을까?
  • 13. 크리티컬 패스 A. 90 B.30 E.30 리스크를 먼저 해결 하는 방안 C.15 D. 90 차이 이른 시작
  • 14. 크리티컬 패스 A. 90 B.30 E.30 정말로 필요할때까지 투자를 미루는 방안 C.15 D. 90 차이 늦은 시작
  • 16. 빨리 시작할까요? • 실제 프로젝트에서는 단순화 된 예제 보다 훨씬 더 많은 패스 가 있다. 단계가 훨씬 더 많다 • 만약 모든 패스를 가장 빨리 시작하는 방법을 선택한다면 프 로젝트 리더가 신경 써야 하는 일이 너무 많아진다. • 너무 많을 일을 시작하면 집중력을 잃게 된다. • 프로젝트 리더가 촛점을 잃으면 프로젝트는 아주 많이 지연 될수 밖에 없다.
  • 17. 늦게 시작할까요? • 한 패스를 늦게 시작하는 방법을 택한다면, • 그 패스에 관한한 여유 시간은 없습니다. • 그 패스에서 조금이라도 지연되게 되면 곧장 프로젝트 지연으로 이어 진다. • 따라서 늦게 시작하면 모든게 중요해진다. 모든 것을 집중 관리 해야 한다. • 모든 걸 집중 관리 한다는 것은 전혀 집중 관리를 하지 않는 다는 것과 같은 말이다.
  • 18. 프로젝트 리더의 딜레마 • 빨리 시작하는 방법을 택하게 되면 촛점을 잃게 되고 • 늦게 시작하는 방법을 택하면 집중 관리가 불가능해지고 • 어떻게든 프로젝트 리더가 집중적으로 관리할수 있는 매커니 즘을 찾아야 한다. • 적절한 통제 메커니즘으로 집중관리를 해야 한다.
  • 19. 통제 메커니즘? • 프로젝트의 진행 상태를 측정하는 것 • 문제는 프로젝트 현황 보고서에 무언가 잘못되었다고 보고 가 될때는 이미 너무 늦었다는 것 • 프로젝트 현황 보고서에서 프로젝트의 90%를 끝내는데 1년 이 걸린후에, 나머지 10%를 끝내는데 꼬박 1년이 걸릴수도 있다.
  • 20. 프로젝트 현황은? • 일반적으로 이미 정해진 작업량이나 투자액을 앞으로 진행해 야 할 작업량과 비교해 구해진다.
  • 21. 이렇게 측정을 한다면… • 각 패스를 최대한 빨리 시작하려는 경향이 있다 • 한 패스가 지연 되더라도, 다른 패스가 빨리 진행 되면, 진척도를 보충할수 있기 때문 • 모든게 두리뭉실한 덩어리가 되어 버림 • 별 어려움 없는 패스들을 아무리 빨리 끝내 봐야 어쨌든 지연된 패스를 기다려 야 함 • 너무 이른 투자를 한셈이고, 더 나쁜건 좀더 집중해야 할 부분이나 신경써야 할 지연된 패스에 집중을 못하게 된다는 것 •
  • 22. 근시안적인 프로젝트 매니저라면.. • 문제가 생겨 지연 되는 패스를 무시할수 있다. • 그래도 측정 결과는 여전히 프로젝트가 잘 지전되고 있는 걸로 나타난다. 프로젝 트 리더는 잘하고 있는 것처럼 보인다. • 한동안은. • 별 문제 없는 패스들이 다 끝나고 문제 있는 패스만 남게 되면, 비로서 오류가 드 러나기 시작한다. • 그 많은 프로젝트들이 마지막 10%를 끝내는게 그리 오랜 시간이 걸리는 이유이 다. • 크리티컬 패스의 중요성을 간과 한 것.
  • 23. 그럼 훌룡한 관리란 무엇일까? • 비용을 20% 아꼈는데 고객 절반이 화를 내면? • 제품을 잘 출시 했는데 비용이 200% 초과했다면? • 좋은 관리란 • 비용을 통제하고, • 쓰루풋(Throughput)을 지키는 것
  • 24. 회사를 체인으로 본다면.. 구매부서 생산 마감 출하 마케팅 …
  • 25. 원가 세계 구매부서 생산 마감 출하 마케팅 … 원가 를 체인의 무게로 보았을때 하나 하나의 무게를 줄여서 개선 할수 있다. 마감 체인에서 200g을 줄였다면 체인 전체가 가벼워졌으므로 개선된 것 어떤 부분적인 개선도 자동적으로 조직의 개선으로 간주된다.
  • 26. 쓰루풋 세계 구매부서 생산 마감 출하 마케팅 … 연결중 단 한 연결 고리에서 뭔가 실수한다면? 회사 전체의 쓰루풋이 떨어진다. 고리 하나 하나가 중요 한게 아니라, 연결 그 자체가 중요하다. 체인의 강도는 가장 약한 고리가 결정한다. 만약 출하 체인을 3배 더 강화하면 쓰루풋이 개선될까? NO 대부분의 경우 부분적인 개선은 전체적인 개선에 도움을 주지 않는다.
  • 27. 월말 증후군 • 원가를 관리하고자 한다면, 관리자는 원가 세상에 따라야 하고 • 쓰루풋을 지키고자 한다면 쓰루풋 세계에 따라야 한다. • 월초에는.. • 비용을 통제한다. 야근도 통제하고, 배치 사이즈도 최적으로 유지하려고 한 다. • 그러나 월말에는… • 이런 것들은 모두 잊혀진다. • 빌어 먹을 제품들을 출하 시키기 위해서 무엇이든 한다.
  • 28. 왜 쓰루풋세계여야 하는가? • 과거에 받아들여졌던 절충이 오늘날 받아 들여지지 않음 • 10년전만 해도 80%만 정시에 출하해도 OK • 오늘날엔 95%를 정시에 출하해도 클레임 • 10년전에 출하 했던 품질의 제품을 오늘날 출하하면 모두 반 품할것 • 쓰루풋을 보호하는 것이 훨씬 더 어려워 진것
  • 29. 집중하는 것이 중요하다. • 우리는 집중을 파레토 법칙으로 이해한다. 중요한 문제 20%를 해결하는 데 집중하면, 80%의 이익을 거두게 된다. • 그러나 이 법칙은 독립변수로 이루어진 시스템에만 적용된다. • 원가 세계에만 적용된다. • 쓰루풋의 세계에서는 20%를 개선한다고 해도, 그 대부분은 전체적은 조 직 성과를 개선하는데 도움이 되지 못한다. • 연결이 중요하며, 변수들은 상호 의존적이다. • 파레토 법칙은 적용되지 않는다.
  • 31. 우선 체인에 대해서만 생각해보자 • 체인의 강도를 결정하는 것은 가장 약한 연결 고리이다. • 체인을 튼튼하게 하고 싶다면 제일 먼저 무엇을 해야 할까? • 제일 먼저 할 것은 가장 약한 연결 고리를 찾는 것이다. • (시스템의 제약들을 찾는다)
  • 32. 제약을 찾았다면 • 제약이 어떤 종류인지 파악한다. • 병목 자원인지 • 자원 제약이라면 두가지 개선이 가능 • 더 많은 자원을 투입하던가 • 더 효율적으로 쥐어 짜던가 • 정책 제약인지 • (시스템 제약을 어떻게 활용할지 결정한다. )
  • 33. 제약을 어떻게 활용할지 결정했다면 • 다른 연결 고리에 미치는 영향을 살펴 보아야 한다. • 병목작업장에서 최대 10개를 생산할수 있을 때 • 의존관계의 비병목 작업장에서도 20개를 생산할수 있어도 10개만 생산해야 한다. • (윗 단계에서 내린 결정에 다른 모든 것을 종속 시킨다. )
  • 34. 이제 쓰루풋을 개선한다 • 병목 작업장에 더 많은 기계를 사용하던가 • 사람을 더 투입하던가 • 병목지점을 개선하면, 쓰루풋이 개선된다. • (시스템의 제약들을 향상한다. )
  • 35. 쓰루풋이 좋아졌는가? • 약한 연결 고리를 계속 강화하다 체인 전체가 강해진다. • 그런데 어느 순간 체인이 더이상 강해지지 않는다. • 이 연결 고리는 더이상 제약이 아니다. • 타성에서 벗어나 (다시 처음 단계로 돌아가 다른 제약을 찾아 야 한다. )
  • 36. 무엇을 집중 관리 해야하는가? • 우리는 집중 관리하기 위한 절차를 찾아 냈다 • 쓰루풋 세계에서의 집중관리 • 지속적인 개선 작업, 카이젠 • 쓰루풋의 세계에서는 집중과 지속적인 개선 과정이 같은 것 이다
  • 37. 제약이론 • 시스템의 제약들을 찾는다 • 시스템의 제약들을 어떻게 활용할지 결정한다. • 윗단계에서 내린 결정에 모든 것을 종속시킨다. • 시스템의 제약들을 향상한다. • 연결고리가 더이상 제약이 아니라면 처음으로 돌아가 다른 제약을 찾는다.
  • 38. 갈등 • 쓰루풋 세계에 따라 비 병목 작업장이 10개를 생산했다. • 원가 세계에 의해 평가 된다면 이 작업장의 생산성은 50%이 다 • 모가지가 남아 날까?
  • 39. 문제란? • 문제: 그것이 두가지 필요조건간에 갈등을 일으킬 때 그것을 문제라고 정의 할수 있다.
  • 40. 갈등 해소도 관리를 잘한다 비용을 통제 한다 쓰루풋을 보호한다 쓰루풋 세계에 따라 관 라한다. 원가 세계에 따라 관라 한다.
  • 41. 제약이론에서는 • 우리가 갈등에 직면하게 되면, • 거기에는 반드시 어느 한쪽에 잘못된 가정이 존재하고, • 잘못된 가정은 수정될수 있으며 • 잘못된 가정에 수정을 가함으로서 갈등은 제거할수 있다. • 라는 가정을 한다.
  • 42. 갈등 해소도 관리를 잘한다 비용을 통제 한다 쓰루풋을 보호한다 쓰루풋 세계에 따라 관 라한다. 원가 세계에 따라 관라 한다. 비용관리를 잘 할수 있는 유일한 방법은 어디서든 부분적인 성과가 좋아야 한다. 모든 곳에서 부분적인 성과가 좋은 것으로는 좋은 쓰루풋 성과를 달성할수 없다.
  • 43. 위쪽 가정에 도전해보자 • 비병목 지점에서 부분 최적화를 하여 10개가 아닌 20개를 생 산하면 • 재고가 쌓인다 • 재고가 쌓이면 비용이 올라간다. • 우리가 비병목지점의 업무 효율을 제한한 이유는 단한가지, 비용을 관리하기 위해서이다. •
  • 44. TOC(제약이론)에서는 • “전체적인 비용 관리를 잘 할수 있는 유일한 방법은 모든 곳 에서 부분적인 관리를 잘하는 것이다”. • TOC에서는 많은 관리자와 거의 모든 시스템이 이 같은 가정 하에 관리를 하고 있다는 사실이, 현재 우리 조직들이 안고 있 는 가장 핵심적인 문제라고 본다.
  • 45. 철강소 예제 500 철강 업계에서는 오랫동안 “시간당 생산 량”을 주요 성과 측정 지표로 사용해 왔다. 510 대부분의 사람들은 자신이 평가받는 대로 행동한다. 515 각 부서들은 시간당 생산량에 의해 측정되 는 성과를 극대화 하려고 노력한다 530 작업 준비 시간이 길어지면 당연히 시간 당 생산량에 의한 작업량이 줄어든다 520 다른 제품보다 작업 시간이 길게 걸리는 제품이 있다 525 생산을 하지 않으면 시 간당 생산량은 제로이다 545 시간당 생산량에 의한 성과를 극대화 하 기 위해 각 부서들은 당장 시장에서 필요로 하 지 않는 제품을 제고로 쌓아두면서 까지 생산하 려는 경향이 있다. 540 일정한 기간 내에 시간당 생산량에 의한 성과를 극대화 하기 위해, 각 부서들은 작업 시 간이 긴 제품 보다는 작업시간이 짧은 제품을 먼저 작업하려는 경향이 있다. 560 V형 공정은 여러 분기점을 거치면서 제품 이 다양해진다. 550 시간당 생산량에 의한 성과를 극대화 하기 위해 각 부서는 배치 사이즈를 키우기 위해 주 문을 앞당겨 생산하는 경향이 있다. 545 시간당 생산량에 의한 성과를 극대화 하 기 위해 각 부서들은 도둑질을 초래하는 행동 을 하는 경향이 있다
  • 46. TOC의 논지 • 현재 우리 조직들이 안고 있는 가장 핵심적인 문제이자 제약 은 우리의 관리시스템 대부분이 원가 세계의 가정이 올다는 믿음에 기초하고 있다는 사실 • 현실에 존재하는 시스템이라면 많아야 한개 내지 두개의 제 약
  • 48. 5+5 = 13 • 프로젝트 책임자는 각 사람들에게 각자 예측한 시간을 물어 그 시간들을 더합니다. • 그리고 거기에다 다시 자신의 여유 시간을 추가하죠 • 여러 레벨의 관리자가 관여 하게 되면, 각 레벨마다 또 여유 시간을 두게 되죠 • 경영자가 일반적으로 20%정도 일정을 줄이라고 하기 때문 에 애초부터 25%정도 더 부풀리기도 한다.
  • 49. 프로젝트에서 여유시간이 더해질때 • 실패했던 경험을 토대로 여유 시간을 예측하는데, 이는 분포 곡선 오른쪽 끝쪽에 해당함 • 프로젝트 관리 레벨이 많아 질수록, 총 예측 시간도 길어진다. • 예측 작업을 하는 사람들이 예측 기간이 전체적으로 잘릴 것 에 대비해 아예 미리 여유 시간을 추가한다.
  • 50. ?? 그럼 여유 시간 투성이 잖아?? • 그토록 많은 여유 시간이 포함되어 있는데 왜 그 많은 프로젝 트들이 제때에 끝나지 못하는 것일까?
  • 51. 만약 프로젝트에서 A 10일 B 10일 이런 연속된 두 단계가 있을때 A가 12일 만에 완료 되면 어떻게 될까? B는 2일 지연 되어 13일째에 시작하게 될 것이다.
  • 52. 만약 프로젝트에서 A 10일 B 10일 이런 연속된 두 단계가 있을때 A가 8일 만에 완료 되면 어떻게 될까? B는 9일째에 시작할까? 대부분의 경험자들은 B는 11일째에 시작할거라 답할것이다 예상 보다 일찍 끝낸 팀이 그걸 보고하지 않을 것이기 때문이다 일찍 끝낸다고 보상이 있는 것도 아니고 예측시간을 줄이라는 압력만 받게 되는 것을 안다
  • 53. 프로젝트에서 • 어떤 단계에서 일이 지연되면, 그건 고스란히 다음 단계로 이 전된다. • 그렇지만, 한 단계에서 일찍 끝나 시간을 절약하게 되면, 그 시간은 대개 그냥 허비된다.
  • 54. 만약 프로젝트에서 A -5일 B -5일 C -5일 D +15일 이런 동시 작업이 있을때 3개의 작업은 모두 5일 일찍 끝나고 1개의 작업은 15일 지연되었다 E 동시에 진행되는 단계인 경우 그리고 그런 단계가 많은 프로젝트의 경우 가장 오래 지연된 단계가 다음 단계에 영향을 미치게 된다. 일찍 끝난 다른 모든 단계는 전혀 도움이 되지 않는다 우리가 추가한 대부분의 여유 시간은 전혀 도움이 되지 않는다.
  • 55. 필요한 곳에만 여유 시간을 줄수 있을까? • 중요한 것은 단하나, 프로젝트 전체의 성과 • 그런에 우리는 각 단계의 성과를 지키는데만 신경을 쓰고 있 다 • 그렇게 시간을 벌어 봤자 다 낭비만 될뿐인데도 • 그래서 그 많은 여유 시간을 넣고도 프로젝트 전체가 위험에 노출된다.
  • 56. 하나의 단계에서 여유시간을 주어도.. • 어떤 단계는 늦어진다. (여러 단계가 아니고) • 애초에 여유시간을 주었는데도? • 학생증후군 • 처음에는 여유 시간을 가지려고 투쟁 • 그러나 일단 시간이 확보되면, 이제 시간이 충분한데 뭣때문 에 서두르겠는가?
  • 57. 학생증후군만으로 설명이 되는가? • 너무 바빠서 여유 시간조차 없는 경우도 있는데? • 멀티 태스킹!! • 왜 멀티 태스킹이 나쁜가?
  • 58. 한 사람이 멀티 태스킹을 하면 • A,B,C 세단계의 일을 3개의 프로젝트를 위해 멀티 태스킹 한다고 할때 • 각 단계는 10일씩 소요된다. • 이 일을 하는 사람은 압력을 받고 있고, 모든 사람을 만족시키 려 애를 쓴다. • 결국 한단계의 일을 5일만 하고 다음 단계의 일로 넘어간다.
  • 59. 한 사람이 멀티 태스킹을 하면 A B C 10 10 10 A1 B1 C1 A2 B2 C2 20 20 20
  • 60. 리드 타임이 2배가 되었다 • 작업 준비 시간은 고려조차 하지 않아도 이렇게 된다. • 더우기 멀티태스킹 단계에 여유 시간을 더 늘리면 • 모든 프로젝트의 리드 타임 역시 늘어난다.
  • 61. 여유 시간을 낭비하는 3가지 메커니즘 • 학생증후군 • 멀티 태스킹 • 각 단계에 존재하는 의존성
  • 62. 우리는… • 전체 프로젝트 일자를 지키는 유일한 방법은 각 단계의 완료 일 자를 지키는 것이라고 믿어 왔다. • 그결과 • 각 단계에 많은 안전 여유 시간을 두었다. • 항상 세가지 메커니즘(a. 학생증후군, b.멀티태스킹, c. 지연된 시간은 누적되지만, 일찍 끝난 시간은 누적되지 않는 다는것)이 문제를 야기하고, 여유시간의 대부분이 헛되이 낭비되고 있다.
  • 63. 생산에서 처럼 프로젝트에서도 TOC가 성 립될수 있을까?
  • 64. 프로젝트에서… • 제약은 무엇 일까? • 병목은 무엇일까?
  • 65. 병목은… • 한 기업이 더 많은 돈을 버는데 저해가 되는 요인 • 프로젝트라면, 개발을 끝내지 못하는 것 • 프로젝트가 시작해서 끝날때 까지의 리드 타임은 무엇에 의 해 결정되는가? • 크리티컬 패스
  • 66. 제약을 찾았다. • 제약을 최대한 활용 하기 위해서는 어떻게 해야 할까? • 제약 자원을 낭비하지 말아야 한다. • 프로젝트의 제약인 크리티컬패스를 낭비 하지 않는 다는 것은 무슨 뜻일까? • 결국 시간을 낭비 하지 말아야 한다. • 크리티컬 패스에서 할당된 시간을 낭비하지 말아야 한다. • 크리티컬 패스에서 시간을 낭비하면 프로젝트가 지연될 것이다.
  • 67. 크리티컬 패스에 할당된 시간을 어떻게 낭 비하고 있는가? • 너무나 많은 방식으로 시간이 낭비되고 있다. • 그러나 핵심은, 우리가 프로젝트의 각 단계에 많은 안전 여유 시간을 끼워 넣고 있다는 사실이다. • 가장 많이 낭비 되는 시간은 각 단계의 안전 여유 시간이다.
  • 68. 그래도… • 약간의 여유 시간은 필요하지 않을까? • 물론. 머피의 법칙이 있으니까 • 가장 도움이 될만한 곳에 안전 여유 시간을 끼워 넣어야 한다. • 제약을 보호하려고 여유 시간을 둘 것이다. • 우리의 제약은? 크리티컬 패스 • 우리는 크리티컬 패스의 완료 일자를 보호 해야 합니다.
  • 69. 모든 안전 여유 시간을 크리티컬 패스의 끝 쪽으로 옮겨보자 Task 1 Task 2 Task 3 Task 4 Task1 Task2 Task3 Task4 프로젝트 버퍼
  • 70. 이렇게 예측 시간을 줄이게 되면… • 각 단계가 제때에 끝날 확률은 50%정도 • 당연히 실무자의 반발이 생긴다. • 그래서 경영자의 경영지원이 필요하다. • 제때에 못 끝난다고 해서 개인 평가에 적용되어서는 않된다. • 그저 “팀”이 일을 최대한 빨리 빈틈없이 할수 있는지 알기 위 한 수단으로 사용해야 한다.
  • 71. 경영자가 버퍼를 잘라내려고 할텐데… • 역시, 경영자의 경영지원이 필요하다. • 프로젝트 버퍼를 자르면 프로젝트가 엉망이 된다라는 인식 이 필요함 • “최종 완료 날자만이 중요하다”라는 결단이 있어야 함
  • 72. 제약 자원을 최대한 활용하라 • 크리티컬 패스상에선 시간을 낭비하지 말라. 다음 단계로 넘 어가기 전까지는 • 그리고 모든 걸 제약 자원에 종속 시키기 전까지는 • 종속 시키지 않는다면 다른 곳에서 생기는 문제로 인한 시간 손실로 부터 제약 자원을 보호할수 없기 때문
  • 73. 크리티컬 패스에… • 영향을 미치는 대부분의 문제가 크리티컬 패스 그 자체에서 발생하는 것이 아니다. • 비병목 작업장에서 발생하는 문제들로부터 병목작업장을 어 떻게 지키는가? • 병목 작업장 앞에 재고 버퍼를 둔다.
  • 74. 프로젝트에서는? • 크리티컬 패스와 합류하는 공급 패스의 끝에 시간 버퍼를 끼워 넣어야한다. • 이 시간 버퍼의 공식은? • 각 공급 패스의 각 단계에 대한 애초의 예측 시간을 반으로 줄이 고, • 줄어든 리드 타임의 절반을 공급 버퍼로 이용 • 쓰루풋의 세계에서 긴급은 쓰루풋에 영향을 미치는 것만이 긴급
  • 76. 시간만? • 다른 모든 자원이 크리티컬 패스상의 한 단계를 위해 준비 되 어 있는데 • 다른 일을 하느라 바쁜 특정 자원때문에 지연되는 경우도 있 다 • 따라서 자원 버퍼가 필요하다.
  • 78. 프로젝트 진척 상황 • 크리티컬 패스의 진척 상황만을 평가한다.
  • 79. 더이상 마일스톤은 없다 • 마일 스톤으로 2주가 주어 지면 그 2주일은 완전히 작업자의 것 • 1주일이 지나 재촉이라도 하면 “아직 1주일이 더 남았는데 대 체 뭘 바라는 거요?” • 더이상 꾸물 거릴 여유가 없기에 꾸물 거리지 않는다. 학생증우 군이 사라진다. • 프로젝트를 제때에 완료할수 있는 시간 예측 확률을 90%에서 50%로 줄여야 하는 이유임
  • 80. 멀티 태스킹은? • 거짓 경고를 제거하고, • 한 단계를 수행하는 시간을 실질적으로 줄이면 • 멀티태스킹을 줄이는데 큰 도움이 된다. •
  • 81. 멀티태스킹은 자원에 대한 것인데? • 이전에는 한단계의 작업을 하기 위해 모든 것이 준비되었지만, • 사람들은 아직 준비가 않 된 경유가 비일비재했다. • 크리티컬 패스에서는 그런일이 일어 나지 않게 해야 한다. • 작업 1주일전, 3일전 크리티컬 패스가 곧 도래 함을 상기 • 작업 하루전 모든 것이 다 준비가 되었다는 것을 확인 •
  • 82. 모니터링은 어떻게? • 프로젝트 버퍼를 모니터링 • 크리티컬 패스의 작업을 하는 사람은 매일 뜨거운 감자를 다 음 단계로 넘겨줄때까지 며칠이 더 필요한지 예측치를 보고 • 예측치는 매일 바뀔수 있다. 문제가 있으면 늘어 나고, 쉽게 해결되면 줄어들고
  • 83. 크리티컬 패스가 아닌곳은? • 공급 버퍼에 대해서도 모니터링 • 다른 모든 버퍼에 대해서도 모니터링 • 모니터링 은 일일 보고서형태로 정리 가능 • 보고서 내용 정렬 우선 순위 • 1순위 프로젝트 버퍼를 잠식하는 작업 • 2순위 공급 버퍼를 소모하고 있는 단계 • 지속적으로 모든 버퍼를 모니터링 하고 있는한 그 버퍼들은 집중 관리가 될것
  • 85. 프로젝트의 종류 • 납품업체나 하청 업체에 의해 수행 되는 프로젝트 • 회사 자체의 자원에 의해 행해지는 프로젝트
  • 86. 회사 자체의 자원 프로젝트에서의 변화 • 여러 자원을 설득해 리드 예측 타임을 줄이게 함 • 마일스톤을 없앰(각 개별 단계의 완료 예정 일자를 없앰) • 예상 완료 작업일을 수시로 보고하게 함
  • 87. 납품업체나 하청업체에 의한 프로젝트는? • 하청업체에 많은 것을 요구하지만…. • 결국 최종적으로는 가격을 요청한다 • 가격은 중요하지만, 리드타임도 그에 못지 않게 중요하다 • 변화는 거기서부터 시작된다 • 프로젝트 지연이 결국 재정적인 손실을 야기한다는 것 이해 해야 한다.
  • 88. 프로젝트가 지연되면 • 구축비용이 증가된다. • 회사의 손실은 추가 매출이 늦어진다. • 프로젝트 결과물이 매출을 영원토록 올려주지는 않는다. • 따라서 단순히 돈이 지연 되는게 아니라, 상당부분 영원히 사라진 다. • 한달의 지연이 얼마만한 금전적 손실을 주는지 깨닫지 못하고 있 다는 것이 프로젝트 팀원의 하청업체 관리 방식에도 영향을 준다.
  • 89. 왜 제때 끝내야 하는가? • 제때 끝냐야한다. • 그러나 왜 그러는가 정확한 이유를 모르고 있다 • 그래서 하청업체에게 가격만으로 경쟁하도록 해 놓는다. • 리드 타임은 때론 가격보다 중요하다.
  • 90. 대부분의 하청업체는… • 고객이 결과물에 OK하는데 너무 많은 시간을 허비한다는 안 좋은 경험을 가지고 있어서 • 미리 충분한 리드타임을 확보하려 하는 것이다.
  • 91. 일을 하고 있는 사람에게… • 완료 날자를 말하지 않는게 얼마나 중요한가! • 그런데 납품업체들에 대해선 어떻게 하고 있는가? • 납기일을 지키라고 강요한다. • 내부적인 원칙과 정반대이다.
  • 92. 납품업체들의 언어.. • 서로 다른 작업이 비슷한 리드타임으로 제시된다. • 그들의 제안서를 잘 분석해보면 • 언제나 여유시간을 확인 할 수 있다. • 가격과 리드타임을 맞바꾸는 옵션을 제시 할 수 있다. • 더 빨리 납품하면 더 높은 비용을 지불하는 옵션
  • 93. 납품업체들은 보통… • 고객의 요구사항 변경에 진절머리를 내기때문에, 리드타임 의 시작을 모든 요구사항이 전달된 시점으로 정하자고 할것 이다 • 보통 납품과정에서 가장 많은 시간을 뺏기는 과정이다. •
  • 94. 납품업체와의 초기 협상은.. • 협상해야 하는 것은 리드 타임이다. 날자가 아니고. • 업체에게 리드타임에 동의하게 하고 • 그 리드타임에 집착하게 하고, • 그러다보면 우리 스스로 날짜를 결정하게 만드는 것이다. • 납품업체가 아니고.
  • 95. 이런 협상을 할때… • 리드 타임을 위해 돈을 더 지불하는 것은 • 일반적인 회사의 원가 비용 절감 정책에 위배된다. • 경영자를 설득해서 경영지원을 얻어 내는 방법도 있다.
  • 96. 가끔은 리드타임 지연이 문제가 아닌것 같 은 프로젝트도 있다.
  • 97. 건설 프로젝트에서.. • 입찰은 매우 낮은 가격으로 이루어 진다. • 그럼 어디에서 돈을 벌까? • 변경을 통해서! • 고객은 항상 옮다 • 고객이 변경을 원하면, 싸우지 않고 기꺼이 그에 응한다 • 그리고 그 변경에 이익을 붙인다 • 그래서 고객에게 더 많은 변경을 부추긴다. • 일정은 그만큼 늘어난다. (부럽당 ㅠㅠ)
  • 98. 이런 회사에게 프록젝트가 앞당겨 끝나는 게 무슨 의미가 있을까? • 만약 이런 회사에서 프로젝트가 3개월 늦게 끝났다고 가정하면 • 그 회사는 예상보다 3개월 후에 집을 팔수 있다. • 현금이 3개월 후에 들어 오게 된다. • 현금 흐름에 악영향을 준다. • 저렇게 원가경쟁이 치열한 업계일수록 현금 흐름은 중요해진다. • 따라서 프로젝트를 제때에 끝내는 것은 “회사 전체”로 보았을때 중요하다
  • 99. 이제 동일 자원이 여러 프로젝트를 진행하 는 상황으로 가보자
  • 100. 자원 버퍼 이야기부터 해보자. • 실제로 “경고”만 하는 자원 버퍼는 실제 프로젝트 리드 타임 에 아무 변화도 주지 못한다.
  • 101. 크리티컬 패스는? • 크리티컬 패스가 아닌 패스에서 작업이 많이 지연되어 • 공급버퍼를 이미 다 소모해 버렸고 • 프로젝트 버퍼까지 침투하기 시작했는데 • 크리티컬 패스 자체는 아직 괜찮은 상태일때 • 이런 상황이라면 크리티컬 패스가 변한것 아닐까?
  • 102. 크리티컬 패스는… • 상호 종속적인 여러 단계 가운데 가장 작업 공정이 긴, 또는 작업 시간이 긴 패스를 크리티컬 패스라고 정의한다. • 이 정의 에 따르면, 크리티컬 패스가 아니였던 N단계가 프로 젝트 버퍼까지 침투할 정도로 지연되었다면, • N작업이 가장 긴 체인이 되고 있다는 것 아닐까?
  • 103. 그래서 크리티컬 패스를 프로젝트 중간에 변경할까? • 우리는 비 크리티컬 패스가 크리티컬 패스에 만나는 곳에만 공급 버퍼를 둔 다 . • 따라서 크리티컬 패스를 변경하면 • 불가피하게 공급버퍼의 위치도 바뀌어야 한다 • 그런데 그렇게 하면 • 프로젝트 전체가 혼란에 빠진다. • 그렇게 할수 없다. • 그렇게 하지 않으면 실제적인 크리티컬 패스를 보호할수 없다.
  • 104. 갈등!! 프로젝트를 제때에 끝낸다 모든 일정을 재조정 하지 않는다 실제로 변경되는 크 리티컬 패스를 그대 로 두지 않는다. 공식적으로 크리티컬 패스 를 바꾼다. 공식적으로 크리티컬 패스 를 바꾸지 않는다.
  • 105. 어떤 가정을 하고 있을까?
  • 107. 프로젝트의 리드 타임은 작업 시간만으로 결정되는가? • 단계들의 상호 의존성은 한 패스의 결과라고 할수 있고 • 공용 자원의 결과라고 할수도 있다. • 일반적으로 가장 긴 체인은 패스가 상호 의존적이거나 • 자원이 상호 의존적인것에 의해 결정된다.
  • 108. 용어정리를 하자 • 크리티컬 패스는, 흔히 말하는 크리티컬 패스 또는 가장 긴 패 스 • 가장 중요한 것은 제약이고, • 제약은 상호의존적인 단계들이 이어진 가장 긴 체인. • 상호 종속성은 자원때문에 발생 할수 있기때문에 • 제약이 되는 일련의 단계는 “크리티컬 체인”으로 부르자
  • 110. X를 어떤식으로 작업순서를 정해야 할까? • X를 필요로 하는 작업이 5개나 되는데 • 어떻게 순서를 정해야 할까?
  • 111. 8 X 8은 얼마일까? • 우리가 프로젝트에서 다루는건 확정적인 숫자가 아니다. • 우리가 어떤 작업이 8일 걸린다고 했을때 • 그게 정확하게 8일 걸릴 거라는 사실을 의미할까? • 프로젝트에서 8 x 8 = 64 라는 답은 틀린 것이다. • 자료가 정확하지 않은 상황에서 정확한 답을 찾으려 애쓰는 것은 잘못이다 • 문제에 내재된 불확실성보다 더 정확한 “척” 하는 답은 더 좋은 답이 될 수 없다.
  • 112. 어떤 순서로 X의 작업 일정을 잡든 별 차이 가 없다는 뜻인가? • 차이는 있을 것이다. • 그런데 실제적인 차이가 있을까? • 프로젝트의 불확실성보다 큰 차이가 날까? • 프로젝트의 불확실성을 재는 합리적인 척도는 어떤게 있을까? • 프로젝트 버퍼 • 프로젝트 버퍼에 모든 불확실성의 누적된 결과가 담겨 있다.
  • 113. 자원 순서 최적화는… • 많은 이론이 있지만, • 어떤 경우든 프로젝트 리드 타임에 미치는 영향은 • 프로젝트 버퍼가 미치는 영향의 반도 되지 않는다. • 각 단계의 시간 예측에 여유시간이 포함된다라는 사실을 감 안한다면, • 프로젝트 리드타임의 1/4 정도 된다.
  • 114. 자원 경합을 고려하는 것과 작업 일정을 최 적화 하는 것은 다른일 • 자원 경합 요인을 제거해 버려라 • X에 의해 행해지는 어떤 두 단계도 동시에 진행되는 일이 없 게끔 작업 일정을 잡아라 • 제약을 변경했기 때문에, • 그에따라 공급 버퍼도 변경해야 한다.
  • 116. 시스템을 제약에 종속시켰으니.. • 그냥 크리티컬 패스에 비교해서 완료 일자는 늦어진다. • 하지만 이게 더 정직한 일정이다. • 이제 제약을 향상시킨다 • X의 업무 부하를 다른 사람에게 나누어 줄수 있는지 체크한 다. • 또는 다른 시간대로 넘길수 있는지도 체크한다.
  • 117. 다른 시간대? • X가 프로젝트 내내 부하가 걸리는 것은 아니다. • X의 작업중 일부는 좀더 일찍, 또는 늦게 끝낼수 있다. • X의 작업중 상당 부분이 문서화일때 • 어떤 문서는 시스템 통합에 필수적이라 즉각 문서화가 이루어져야 한다. • 하지만 대부분의 문서화는 단지 장래의 유지보수를 위한 것이다. • 이런 일은 나중에 해도 된다.
  • 118. 프로젝트에서 자원 경합은 얼마나 심한가? • 상황에 따라 다르다 .(당연히) • 자원 경합이 벌어질 경우, • 크리티컬 체인은 크리티컬 패스와 아주 차이가 날수 있다.
  • 119. 그때 체인이 아닌 패스에 따라 움직인다면 어떤 위험이 발생할까? • 크리티컬 패스이 이리 저리 왔다 갔다 난리가 난다. 통제가 되 지 않는다. • 자원 버퍼는 물론 공급 버퍼도 위치가 잘못 되어 있어서 • 제약이 보호 받지 못한다
  • 120. 자원 경합이 사라지면 • 작업 순서를 정하는 것은 그리 오래걸리지 않는다. • 그런 다음 크리티컬 체인을 찾는다. • 그리고 공급버퍼를 둔다
  • 122. 자원의 경합 • 자원의 경합은 동일한 자원이 동시에 서로 다른 두 단계의 작 업을 하기로 되어 있는 경우에 발생 • 두 단계 간에 자원 경합이 일어나지 않게 하려면 • 두 단계중 한 단계는 필히 지연되게 됨 • 그런데 어떤 단계를 지연해야 하는가를 결정할 명확한 방법이 없다. • 거의 임의로 결정된다