1. 글을 시작하며
안녕하세요. 글 쓰는 아빠 도도한 쭌냥이입니다.
프로젝트 관리에서 일정 개발은 단순한 시간표 작성이 아닙니다. 프로젝트의 범위, 자원, 제약 조건, 리스크 등을 종합적으로 고려해 현실적이면서도 전략적인 실행계획을 수립하는 과정입니다. 잘 짜여진 일정은 프로젝트의 성공을 견인하지만, 잘못된 일정은 지연, 비용 초과, 품질 저하로 이어질 수 있습니다. 따라서 프로젝트 일정은 만드는 것도 중요하지만, 그 일정이 타당한지 평가하는 과정 또한 반드시 거쳐야 합니다.
이 글에서는 프로젝트 관리자로서 일정을 어떻게 체계적으로 개발할 수 있는지, 그리고 개발된 일정이 실제 실행 가능한지 평가하는 방법까지 전 과정을 실무적으로 안내합니다.
2. 프로젝트 일정 개발방법
프로젝트 일정 개발은 프로젝트 관리(PM)의 핵심 업무 중 하나이며, 프로젝트의 성공 여부를 좌우할 만큼 매우 중요합니다. 일정 개발은 단순히 작업 날짜를 나열하는 것이 아니라, 업무의 흐름과 논리를 정리하고, 자원과 제약 조건을 고려하여 실행 가능한 일정표를 만드는 일입니다.
요약
프로젝트 일정 개발은 단순히 “언제 시작하고 언제 끝나는가?”를 정하는 것이 아니라,
- 작업을 식별하고
- 그 순서를 정하며
- 자원과 기간을 추정한 후
- 일정 상의 논리적 흐름을 고려해 현실적인 일정표를 개발하고
- 그 일정에 대한 근거와 가정을 명확히 하고 팀과 공유하는 과정입니다.
1단계: 작업 정의 (Define Activities)
목표: WBS(Work Breakdown Structure)를 바탕으로 실제 수행할 작업(Activity) 들을 정의합니다.
- 방법
- WBS에서 도출된 작업 패키지를 기준으로 세부 작업으로 분해
- 작업은 측정 가능하고 명확해야 함
- PM, 팀원, 기술 전문가들과 협의하여 작업 목록을 도출
- 도구: 작업 목록(Activity List), Activity Attributes (작업 속성), 마일스톤 리스트
2단계: 작업 순서 정하기 (Sequence Activities)
목표: 각 작업들의 선후 관계(논리적 관계) 를 설정합니다.
- 논리적 종속관계 유형
- FS (Finish to Start): A가 끝나야 B가 시작 가능 (가장 일반적)
- SS (Start to Start): A와 B가 동시에 시작 가능
- FF (Finish to Finish): A와 B가 동시에 끝나야 함
- SF (Start to Finish): 드물게 사용
- 도구
- Precedence Diagramming Method (PDM)
- 네트워크 다이어그램
3단계: 작업 자원 추정 (Estimate Activity Resources)
목표: 각 작업을 수행하는 데 필요한 자원(사람, 장비, 재료 등) 을 추정합니다.
- 고려 사항
- 리소스 가용성 (팀원 일정, 장비 대여 가능 시간 등)
- 숙련도, 속도, 단가
- 조직 내 외부 자원 활용 여부
- 결과물: Resource Requirements, Resource Breakdown Structure(RBS)
4단계: 작업 기간 추정 (Estimate Activity Durations)
목표: 각 작업을 완료하는 데 소요되는 시간(일/시간) 을 추정합니다.
- 방법
- 전문가 판단
- 과거 유사 프로젝트 참고 (Analogous Estimating)
- 세부 분석(PERT 등)
- 팀원들과 협의
- PERT 기법 예시
- 낙관치(O), 가장 가능성 있는 값(M), 비관치(P)로 추정
- 예상 기간 = (O + 4M + P) / 6
5단계: 일정 개발 (Develop Schedule)
이제 위에서 수집한 정보를 바탕으로 실제 일정표를 구성합니다.
핵심 활동
- Critical Path Method (CPM) 적용
- 전체 프로젝트의 최소 기간 계산
- 여유 시간 없는 작업(크리티컬 경로)을 확인하여 일정 위험 요소 파악
- Resource Leveling / Smoothing:
- 자원 제약으로 작업을 재배열하여 과부하 방지
- Lead / Lag 시간 조정:
- 작업 간 여유 시간 설정 또는 겹치는 기간 조정
- 일정 시뮬레이션
- "무엇이 만약?" 분석(What-if Analysis)으로 일정 리스크 검토
- 일정 최적화 기법
- Crashing: 자원 투입으로 일정 단축 (비용 증가)
- Fast tracking: 병렬 작업 수행 (리스크 증가 가능)
- 도구
- Gantt 차트
- MS Project, Primavera, Jira, Notion 등
- Critical Path 분석표, 네트워크 다이어그램
6단계: 일정 베이스라인 수립 (Set Schedule Baseline)
일정 베이스라인은 공식적인 기준 일정입니다. 이 일정과 실제 수행 일정 간 차이를 추적하며 프로젝트를 관리합니다.
- 일정 승인: 주요 이해관계자(PMO, 고객, 스폰서)와 협의하여 승인받음
- 일정 공유: 팀원, 이해관계자들에게 명확히 전달
실무 팁 및 유의사항
| 항목 | 설명 |
| 초기 일정은 가정 기반 | 모든 정보가 완전하지 않으므로, 일정은 가정을 기반으로 유연하게 관리할 것 |
| 주간/일간 업데이트 | 주기적으로 진행률 체크 및 일정 변경 필요 여부 확인 |
| Slack(여유 시간) 관리 | Slack이 있는 작업은 일정 지연이 전체 프로젝트에 미치는 영향을 줄여줌 |
| 위험(Risk) 고려 | 일정에 영향을 줄 수 있는 리스크 식별 및 완충 시간(Buffer) 확보 |
| 의사소통 계획과 연동 | 일정 변경은 커뮤니케이션 계획에 따라 적절히 공유되어야 함 |
3. 개발된 일정 평가 방법
개발된 일정이 적절한지 평가하는 방법은 프로젝트의 성공 가능성을 높이기 위해 반드시 필요한 단계입니다. 단순히 일정이 만들어졌다고 끝나는 게 아니라, 현실적인지, 논리적인지, 리스크에 대비했는지 등 다양한 관점에서 평가해야 합니다.
논리적 일관성 평가 (Logical Consistency)
- 작업 간 종속 관계(Dependency)가 타당한가?
- 예: 설계가 끝나기 전에 개발이 시작되는 등의 논리 오류가 있는지 확인
- 모든 작업이 연결되어 있는가?
- 단절된(Orphaned) 작업이 없어야 함
- 순환 종속 관계(Circular Dependency)가 없는가?
- A → B → C → A 같은 구조는 일정 오류의 원인
- 도구 활용: MS Project의 "일정 점검 기능", Network Diagram, Precedence Diagram
자원 적정성 평가 (Resource Feasibility)
- 자원 과부하 여부 확인
- 한 팀원이 동시에 3개의 작업에 할당되어 있지는 않은지?
- 자원 가용성 현실 반영 여부
- 휴가 기간, 공휴일, 장비 수급 일정 등 고려했는가?
- 자원 평준화(Resource Leveling)가 적절히 이루어졌는가?
- 도구 활용: 자원 할당 테이블(Resource Usage Chart), Resource Histogram
기간 추정의 신뢰성 평가
- 기간 추정 근거가 있는가?
- 경험 기반, 유사 프로젝트, PERT 등 객관적 근거가 있어야 함
- 낙관/비관/보통 기간이 고려되었는가?
- 한 가지 값만으로 일정이 계산되면 리스크에 취약함
- 도구 활용: Three-Point Estimating, Monte Carlo Simulation (리스크 기반 시뮬레이션)
크리티컬 경로(Critical Path) 검토
- 크리티컬 경로가 현실적인가?
- 과도하게 많은 작업이 크리티컬로 되어 있다면 일정 조정 필요
- 여유 시간(Slack/Float) 관리가 되어 있는가?
- 비크리티컬 작업의 여유 시간을 활용한 효율적 일정인지 확인
- 도구 활용: CPM 분석표, Float 확인 도구
마일스톤과 목표 일정 일치 여부
- 주요 마일스톤(중간 목표)이 적절히 설정되어 있는가?
- 스폰서나 고객과 합의된 주요 일정과 일치하는가?
- 규제/계약 상의 데드라인이 반영되었는가?
- 확인 항목 예시:
- ○월 ○일까지 MVP 제출
- 베타 테스트 시작일: 고객 계약 조항 반영 여부
리스크 반영 여부
- 일정에 완충 시간(Buffer)가 포함되어 있는가?
- 중요 작업 직후 일정한 버퍼가 있는가?
- 고위험 작업이 크리티컬 경로에 있을 경우 대응 전략이 있는가?
- 도구 활용: Risk Register, Schedule Risk Analysis (예: Monte Carlo)
이해관계자 검토 및 승인
- 팀원, 관리자, 고객 등 주요 이해관계자가 검토했는가?
- 실제 작업을 수행할 사람들의 동의를 얻었는가?
- 현장에서는 이 부분이 매우 중요함
- 커뮤니케이션 계획에 맞게 일정이 공유되었는가?
- 실무 팁: 워크숍 형태로 일정 리뷰 세션 진행 시 효과적
일정 변경 시 대응 계획 확인
- 일정 변경 절차(Change Control Process)가 정의되어 있는가?
- 무엇을 기준으로 일정 변경이 필요한지를 명확히 했는가?
- 기준 일정(Baseline)과의 비교 수단이 있는가?
- 도구 활용: Schedule Performance Index(SPI), Earned Value Management(EVM)
최종 체크리스트 (Yes/No)
| 평가 항목 | 체크(O/X) |
| 모든 작업이 WBS 기반으로 정의되었는가? | |
| 작업 간 종속 관계가 논리적인가? | |
| 자원 과부하가 없는가? | |
| 기간 추정에 대한 객관적 근거가 있는가? | |
| 크리티컬 경로가 과도하거나 너무 짧지 않은가? | |
| 마일스톤이 명확하게 정의되었는가? | |
| 일정 리스크가 반영되어 있는가? | |
| 이해관계자와 공유 및 승인이 이루어졌는가? |
4. 글을 마치며
프로젝트 일정은 단순한 업무 리스트가 아니라, 프로젝트를 성공으로 이끄는 전략적 로드맵입니다. 이를 효과적으로 개발하려면 작업 정의, 순서 결정, 자원 및 기간 추정, 크리티컬 경로 분석 등 논리적이고 구조적인 접근이 필요합니다. 그러나 일정이 완성되었다고 끝나는 것이 아니라, 그 일정이 현실적인지, 자원과 리스크를 충분히 반영했는지, 이해관계자의 요구에 부합하는지 평가하는 과정이 반드시 뒤따라야 합니다.
PM은 일정 개발과 평가를 통해 계획과 실행 사이의 간극을 줄이고, 리스크를 사전에 통제할 수 있는 주도적인 위치에 서게 됩니다. 이는 프로젝트의 품질, 일정, 비용 모두에 긍정적인 영향을 주는 핵심적인 PM 역량입니다. 제대로 된 일정은 단지 시작일과 종료일을 나열한 표가 아닌, 프로젝트 전체를 이끄는 핵심 전략이자 약속임을 잊지 말아야 합니다.
이상으로 글을 마치도록 하겠습니다.
모두 힘내세요!
