PM Time Management

Why IT Projects Fail to Deliver on Promises ? Req. 46% The system delivered did not meet the requirements Req. The system was used as intended but did not produce expected benefits 40% Req. The system worked, but the intended users would not use it 38% The technology did not work 37% Time The system met the requirements but was late 37% Time The system met the requirements, but the requirements had changed by the time it was delivered 35% There was a failure in business change management 35% Time The benefits were obtained but no longer mattered to the business 22% Source: "The User's View of Why IT Projects Fail," February 2005: Report G00124846

요구사항 불일치 46% (개발 후) 인도된 시스템이 요구사항을 만족하지 못했다. 요구사항 불일치 시스템을 의도한 데로 사용했으나, 예상한 결과를 가져오지 않았다. 40% 요구사항 불일치 시스템은 작동했지만, 의도된 사용자가 시스템을 사용하지 않으려 한다. 38% 기술 불일치 적용한 기술이 (제대로) 기능하지 않는다. 37% 시간 불일치 시스템은 요구사항을 만족시켰으나, 너무 늦었다 (비즈니스요구가 바뀌었거나, 조직이 바뀌었다) 37% 시간 (요구사항) 시스템은 요구사항을 만족시켰으나, 시스템이 인도된 때에는 요구사항이 바뀌어 있었다. 35% 변화실패 (시스템 도입으로 인한) 업무 변화관리에 실패했다. 35% 효용/이득은 얻었지만, 더 이상 비즈니스에 중요치 않다. 22% 시간 불일치

Time Sheet Time Management와 착각하기 쉬운 사례 : 급여지급의 근거자료 및 프로젝트 투입원가 산정자료 : 원가관리를 위한 수단

6. Time Management Activity Definition Activity Sequencing Scope Definition Activity Definition Develop Project Management Plan Activity List Create WBS Activity Sequencing Requested Changes Network Diagram Select Sellers Activity Resource Estimating Resource Availability Acquire Project Team Activity Duration Estimating Cost Estimating Schedule Development Risk Management Risk Register Project Schedule Close Project Schedule Control Integrated Change Control

Project scope statement Project management plan 6. Time Management Activity Definition ITO Input Tool & Technique Output Project scope statement Decomposition(분해) Templates Rolling wave planning Expert judgment Planning component Activity list WBS Activity attributes WBS dictionary Milestone list Project management plan ■ Activity list(활동 목록) : 프로젝트 팀원이 어떤 작업을 해야 하는지 충분히 이해할 수 있도록 상세한 일정 활동 및 활동에 대한 식별자(activity identifier)와 작업기술서 범위(scope of work description) 포함 ■ Activity attributes(활동 속성) : 활동 식별자, 활동 코드, 활동 설명, 선행 활동, 활동들간의 관계, 선행 & 지연, 자원 요구사항, 지정된 날짜, 제약사항 및 가정, 활동 담당자, 승인자 등이 있음 ■ Rolling Wave Planning : 프로젝트 초기에 개발단계까지 Work Package를 상세화 하는 것은 매우 어렵다. 초기에는 분석,설계단계의 WBS 만을 상세하게 작성 하고, 개발과 이후 단계는 상위 수준으로 정의하고, 분석 이후에 점차 상세하게 정의한다. (점진적 상세화) ■ Planning component(계획 컴포넌트) - 통제 계정(control account) : 아직 정보가 부족하여 Work Package가 충분히 분할되지 못해 상세히 정의되지 못했을 때, 나중에 좀 더 상세화 하기로 하고, 관리,통제가 가능할 정도의 수준으로 선정하는 단위

Compiling the Activity List 6. Time Management Compiling the Activity List WBS Activity List    Activity List가 완성되었다면, 그 다음은, 이들의 Logical Sequence를 배열하는 일이다. < OJT > 접착 메모지(포스트-잇)를 활용하라. Activity List들을 각각 포스트-잇에 적고, 화이트보드에 배열해서 붙이고, 관련된 포스트-잇 간에 선을 긋고, 선/후 관계를 조정해 간다.(붙였다 떼었다…) <Sequencing은 무엇에 의해 좌우되나?> Mandatory Dependency(강제 종속), Discretionary Dependency(임의 종속), External Dependencies, Milestones <참고> 자주, 사업을 변화,혁신시켜야 한다. 3M은 Minnesota Mining & Manufacturing(미네소타 채광, 제조회사)의 첫머리를 따서 회사 이름이 비롯됐다.  1902년 철도원 출신인 헨리 S. 브라이언과 윌리엄 A. 맥고나글, 의사 J. 던레인 버드, 변호사 존 드완, 푸줏간 주인 허몬 케이블 등 5명의 평범한 개인들이 각각 1천 달러씩 출자를 해 사업을 시작한 이후 여러 번의 사업형태 변화를 거쳐 혁신적인 제품들을 개발, 인간의 삶의 질 향상에 기여하며 성장을 계속해 왔다. 20세기가 채 끝나기도 전에 이미 세계 80위권의 우량 기업으로 성장했으며 2002년에는 설립 100주년을 맞았다.  미국의 “포츈”지는 3M을 매년 가장 명망있는 기업의 상위권에 포함시키고 있다.

6. Time Management Precedence Diagramming Method (PDM) Activity Sequencing Precedence Diagramming Method (PDM) : Box나 Node를 사용해서 Activity들을 표시, 화살표로 연관(의존,선후)관계를 연결(most common method) Network Diagram 예 : Activity-on-Node (AON)라고도 함. A B ES=10/14 EF=10/22 C D E Task(Activity) name 시작 H F G 종료 LS=10/19 LF=10/22 I J Duration, TF or FF K L 4가지 유형의 연관 관계 Finish-to-Start (Most Common) : 선행 활동이 완료되면 후속 활동 시작 Finish-to-Finish : 선행 활동이 완료되면 후속 활동 완료 Start-to-Start : 선행 활동이 시작되면 후속 활동 시작 Start-to-Finish (사용빈도 낮음) : 선행 활동이 시작되면 후속 활동 완료

Schedule network templates Dependency determination 6. Time Management Tool & Technique PDM or ADM Schedule network templates Dependency determination Applying leads & lags Activity name 10/20 ■ ADM (Arrow Diagramming Method) 화살표 위에 Activity를 표시하는 기법(Activity On Arrow) 거의 잘 잘 사용치 않음 Dummy Activity ■ Schedule Network Templates : 미리 작성해 놓은 Standard Schedule (Subnet) 10/6 Dummy Activity 10/20 ■ Dependency Determination : 활동 순서를 배열하는 방법 3가지 Mandatory dependencies : 반드시 지켜야 하는 연관 관계 Discretionary dependencies : 임의로 선택할 수 있는 연관 관계 (성공적이었던 프로젝트 경험에 기반해서 일정 순서를 만듦) External dependencies : 프로젝트 활동이 아닌 것과 연관 관계 ■ Lead & Lag Lag란 두 개의 공정이 서로 링크되었을 경우, 두 링크 사이의 간격을 뜻하며, 두 공정 사이 에 이 간격보다 더 가까워 질 수 없음을 의미 래그와 리드는 원칙적으로 같은 의미이며, 부호의 차이에 의해 이름의 차이가 있습니다. (+) (-) 래그가 2일이면, 후속공정이 2일보다 더 늦게 시작해도 되나, 2일보다 간격을 더 좁힐 수는 없음.

제안단계에서 주로 사용하는 FP(Function Point)방식의 공수 6. Time Management “자원을 추정”하는 것으로서, “원가 추정”과 더불어 프로젝트 계획 수립에 핵심이 되는 2개 프로세스. (WBS는 계획 수립의 가장 근간) 따라서, 이러한 기본체계가 부실하면, 사업현황관리는 형식적이 됨. Activity Resource Estimating 프로젝트 활동을 수행하기 위해 어떤 자원(인력,장비,자재)이 언제, 얼마나 사용될지 결정 Input Tool & Technique Output EEF / OPA Activity List / Attribute Resource Availability Expert judgment Alternative analysis Bottom-up estimating Activity Resource Requirement Resource Breakdown Structure (RBS) Resource Calendar 과거 유사 프로젝트 사례와 현재 업무범위 및 인당 생산성을 검토 하여 상세 Activity별로 실제 공수를 산정코자 함. 제안단계에서 주로 사용하는 FP(Function Point)방식의 공수 추정은 과히 적합치 않으며, 오히려 Bottom-up 방식의 상세 추정 필요 ■ Bottom-up estimating : Activity가 어느 정도 확신이 서지 않으면, 좀 더 자세히 분해하여 보아서, 각 분해된 작업에 대해 자원을 산정해서 산정된 자원들을 모아서 전체 수량이 나오게 됨, 자원별로 특수한 조건들이 있을 수 있으나, 일단 작성해 놓음. Bottom-up에 비해, Top-Down 방식은 Function Point 방식이라고 말할 수 있다. 어느 것이 더 좋은 방식이냐는??  초기 제안단계는 FP, 내부적으로 상세 자원,원가,일정 산정에는 Bottom-up

Parametric estimating Three-point estimating 6. Time Management Activity Duration Estimating 각 Activity를 완료하기 위해 필요한 기간을 산정 ■ Analogous Estimating : 이전에 유사한 일정 활동을 기준으로 산정 ■ Parametric Estimating : 수행할 작업 양을 생산율(productivity rate)로 곱해서 활동 기간 기준을 산정 ■ 3점 추정 : 전에 수행 경험이 전혀 없을 경우 : Mostly likely, Optimistic(best), Pessimistic(worst) 평균 = (P + 4M + O) / 6 Tool & Technique Expert judgment Analogous estimating Parametric estimating Three-point estimating Reserve analysis Parametric Estimating Three-Point Estimate Average     Most likely                      소규모 프로젝트 또는 단위작업 Optimistic Pessimistic

6. Time Management ITO Input Tool & Technique Output Schedule baseline Development : Forward Scheduling 과 Backward Scheduling의 반복적인 프로세스로서 프로젝트 활동에 대해 시작 및 종료일을 결정 ITO Input Tool & Technique Output Project scope statement Schedule network analysis (일정 네트워크 분석) Critical Path Method Schedule compression (일정 단축) What-if scenario analysis Resource leveling Critical chain method Adjusting leads & lags (선행 & 지연 조정) Schedule model Project schedule Schedule model data Activity list & attributes Schedule baseline Project schedule network diagram Resource requirements (updates) Activity resource requirements Activity attributes (updates) Activity duration estimates Project calendar (updates)

6. Time Management Critical path method Schedule compression Schedule network analysis 프로젝트 일정을 작성하기 위해 여러 가지 분석 기법들을 적용한다. Critical path method 주공정법 (CPM) 자원의 제약은 배제 주공정 경로의 총 여유는 ‘0’ , TF(Total Float) = LF – EF , FF(Free Float) = EF – 후행ES Schedule compression Crashing : 추가 인원 투입하여 일정을 단축하는 것 Fast Tracking : 순차적으로 수행해야 할 단계나 활동을 일정 단축을 목적으로 병행하여 수행 재작업과 위험의 발생 가능성이 있다 What-if scenario analysis 가상 시나리오 분석 : 만약 시나리오 X 대로 가면, 어떤 상황이 나타날 것인가?(ex. 특정일정이 지연되거나 한다면?) 시뮬레이션 (몬테카를로 분석) : 확률적 분포를 이용 Resource leveling 특정 기간에 과부하 된 자원 제약을 해결한다. 프로젝트 기간 연장의 원인이 될 수 있다 과부하 자원을 다른 기간으로 옮긴다 개발 일정이 변경되지 않도록 하기 위해서 이동 대상은 non critical activity 이어야 한다. Critical chain method “제약이론” : 저자 : 앨리 골드렛 , 제목 : The Goal, It’s not Luck(더 골 II), Critical Chain(한계를 넘어서) 자원의 제약을 고려하여 버퍼를 관리하는 일정 네트워크 분석 기법 중 하나 Buffer 관리 Project Buffer: Critical Chain의 끝에 버퍼를 두고 관리 Feeder Buffer: Non-Critical Chain의 끝에 버퍼를 두고 관리 (Critical Chain의 지연 방지) Resource Buffer: Activity가 Critical Resource (희소 자원)을 필요로 할 때 버퍼를 설정하여 관리 Project management software Adjusting leads and lags Schedule model 기존 일정 모델을 활용하여 적합한 프로젝트의 일정을 개발한다.

6. Time Management Schedule Control 일정에 대한 변경 통제 활동을 한다. 일정 변경에 영향을 주는 요소를 지속적으로 모니터링 한다. (초기 계획들, 가정들, 제약사항들 등…) 필요할 경우 이해 당사자들 간 변경을 합의한 후 변경하고 그 정보를 공유하며, 변경 이력을 관리한다.

Higher Levels of Capability Maturity Pay Off (높은 수준의 CMM이 성과를 낳는다.) 성공하는 프로젝트와 실패하는 프로젝트에는 일하는 방식의 차이가 있다는 것이 소프트웨어 프로세스 성숙도(CMMI)의 이론이다. 처음 한방에 끝내는 경우가 많다는 것이다. 숙련된 전문가들이 많을수록, 고객사 업무분석,설계단계를 단축할 수 있어 신속한 수행 이 가능하며, 구축회사의 관리체계가 성숙 되어 있을수록 프로젝트 전반 적인 성과가 우수하다. 수준이 낮은 조직에서는, 개발 스케줄을 줄이면, 임원들 이 기뻐하는데, 결과적으로는 예정 일정보다 delay 된다. (실제 작업에 필요한 일정보다는 빡빡한 스케줄이 직원들 을 열심히 일하게 할 것이라는 착각.) 아직도 CMM Level 1에 있는 회사들은, 야근과 철야를 하고서도, 결국 죽음의 행진 끝에 회사를 떠나게 되며, 최소한 CMM Level 2 정도만 되어도, 프로젝트는 현실성 있고, 달성 가능한 일정을 잡는다. Level 2에서는 PM이 예정스케줄 대비 진행스케줄을 점검 하여, 조치가 가능한 Timing에 일정지연을 알 수 있다.