Part 12. 언제까지 만들어야 하는가 - Project Schedule

“견적은 나왔습니다. 그런데… 언제까지 만들 수 있습니까?”

 

프로젝트 견적을 제출하고 며칠이 지났습니다. 앞선 검토를 통해 우리는 대략적인 프로젝트 비용을 계산했습니다.

 

Equipment Cost가 얼마인지, Engineering Cost가 얼마인지, Construction Cost가 얼마인지, 그리고 예상되는 예비비까지 반영했습니다.

 

이제 고객에게 가격을 제시할 준비가 되었습니다. 그런데 고객이 마지막으로 묻습니다.

“그래서 이 공장은 언제까지 만들어 줄 수 있습니까?”

 

여기서 또 하나의 문제가 생깁니다. 가격을 계산하는 것과 기간을 계산하는 것은 전혀 다른 문제이기 때문입니다.

 

1억 원짜리 프로젝트라고 해서 한 달 만에 끝낼 수 있는 것도 아니고, 100억 원짜리 프로젝트라고 해서 무조건 1년이 걸리는 것도 아닙니다.

 

프로젝트의 기간은 무엇을 만들어야 하는지(Scope), 어떤 순서로 만들어야 하는지(Sequence), 어떤 장비가 필요한지(Procurement), 현장에서 얼마나 빨리 시공할 수 있는지(Construction)에 따라 결정됩니다.

 

결국 프로젝트에는 돈뿐만 아니라 시간이라는 또 하나의 자원이 필요합니다.

 

그리고 그 시간을 설계하는 것이 바로 Project Schedule입니다.

 

 

1. Project Schedule은 단순한 달력이 아니다

 

Project Schedule이라고 하면 가장 먼저 떠오르는 것이 아마 이런 형태의 Gantt Chart일 것입니다.

Monday.com

 

 

Activity	기간
Basic Design	1~2개월
Detail Engineering	2~5개월
Procurement	3~8개월
Construction	6~10개월
Commissioning	10~12개월

 

하지만 이것만 가지고는 좋은 Schedule이라고 하기 어렵습니다.

 

Project Schedule의 핵심은 단순히 “무엇을 언제 한다”를 적는 것이 아닙니다.

 

진짜 중요한 것은

“어떤 일이 끝나야 다음 일이 시작될 수 있는가?”

 

를 정의하는 것입니다.

 

예를 들어 Pump를 설치하려면 먼저 Pump가 제작되어 현장에 도착해야 합니다.

 

Pump를 제작하려면 Vendor에게 구매주문을 해야 합니다.

 

구매주문을 하려면 먼저 Pump Specification이 확정되어야 합니다.

 

Pump Specification을 확정하려면 Process Design과 Hydraulic Calculation이 끝나야 할 수도 있습니다.

 

즉, Process Design → Specification → Vendor 선정 → Purchase Order → 제작 → 납품 → 설치 → Commissioning이라는 연결고리가 만들어집니다. 이 연결고리를 Logic이라고 합니다.

 

PMI 역시 프로젝트 일정을 만들 때 WBS를 바탕으로 Activity를 정의하고, Activity 간의 Dependency와 Duration을 설정한 뒤 Critical Path를 분석하는 방식을 설명하고 있습니다.

 

따라서 좋은 Project Schedule은 단순한 달력이 아니라,

프로젝트를 실제로 실행하기 위한 시간 기반의 논리 모델

 

이라고 보는 것이 더 정확합니다.

 

AACE 역시 Project Schedule을 프로젝트 계획을 시간축에 따라 논리적으로 표현한 것으로 설명하고 있으며, Schedule Basis에는 일정 작성에 사용한 가정, 제외사항, 리스크와 같은 근거가 포함되어야 한다고 제시합니다.

 

 

2. 가장 먼저 해야 할 일은 WBS를 만드는 것이다

 

Schedule을 만들기 전에 먼저 해야 할 일이 있습니다. 바로 WBS(Work Breakdown Structure)입니다.

 

프로젝트를 한 덩어리로 놓고

“공장 하나를 만드는 데 12개월!”

 

이라고 하는 것은 Schedule이라고 보기 어렵습니다.

 

프로젝트를 실제 수행 가능한 작업 단위로 쪼개야 합니다.

 

Beer to Zero Project를 예로 들어보겠습니다.

 

Level 1

Beer to Zero Project

 

Level 2

• Engineering
• Procurement
• Construction
• Commissioning

 

Level 3

Engineering

• Process Engineering
• Mechanical Engineering
• Piping Engineering
• Electrical Engineering
• Instrument Engineering
• Civil/Structural Engineering

Procurement

• Major Equipment
• Pumps
• Tanks
• Piping Materials
• Instruments
• Electrical Equipment

Construction

• Civil Work
• Equipment Installation
• Piping Installation
• Electrical Work
• Instrument Work

Commissioning

• Pre-commissioning
• Utility Start-up
• Equipment Test
• Water Trial
• Product Trial
• Performance Test

이렇게 프로젝트를 Work Package와 Activity 단위로 분해해야 비로소 일정 계산이 가능해집니다.

 

PMI에서도 WBS를 Schedule 개발의 중요한 기반으로 보고 있으며, WBS → Activity → Dependency → Duration이라는 흐름을 통해 Critical Path를 만들어가는 접근을 설명합니다.

 

 

3. 모든 일을 순서대로 할 필요는 없다

 

여기서 엔지니어링 프로젝트의 재미있는 부분이 하나 나옵니다. 프로젝트의 모든 작업을 순서대로 하면 너무 오래 걸립니다.

 

예를 들어,

Engineering 완료
↓
Procurement 시작
↓
Procurement 완료
↓
Construction 시작

 

이렇게 하면 프로젝트 기간이 지나치게 길어집니다. 실제 EPC 프로젝트에서는 여러 업무가 동시에 진행됩니다.

 

예를 들어 Pump 하나를 생각해 보겠습니다.

 

Process Engineer가 Pump Capacity를 계산하고 있습니다. 이 계산이 끝나면 Pump Datasheet를 작성할 수 있습니다. Datasheet가 확정되면 Vendor Inquiry를 시작할 수 있습니다. Vendor가 선정되고 Purchase Order가 발행되면 제작이 시작됩니다. 그런데 Pump를 제작하는 동안 다른 Engineer들은 Piping Layout을 계속 진행할 수 있습니다. 또한 Civil Engineer는 Equipment Foundation 설계를 진행할 수 있습니다.

 

즉, Engineering → Procurement → Construction은 단순히 직렬로 연결되는 것이 아니라 상당 부분 Overlap 됩니다.

이것이 프로젝트 Schedule을 어렵게 만드는 이유입니다.

 

프로젝트를 빨리 끝내기 위해서는 단순히 사람을 많이 투입하는 것이 아니라,

어떤 업무를 어디까지 겹쳐서 수행할 수 있는가

 

를 찾아야 합니다.

 

 

4. Schedule에서 가장 중요한 것은 Critical Path

 

그렇다면 프로젝트에서 어떤 일이 가장 중요할까요? 모든 Activity가 똑같이 중요한 것은 아닙니다.

 

예를 들어 어떤 Equipment의 구매가 하루 늦어져도 전체 프로젝트에는 아무 영향이 없을 수 있습니다.

 

반면 특정 Reactor의 납품이 한 달 늦어지면 Construction이 시작되지 못하고, 결국 Commissioning까지 한 달씩 밀릴 수도 있습니다.

 

이처럼 프로젝트 전체 완료일을 결정하는 가장 중요한 작업의 연결고리가 있습니다.

 

이를 Critical Path라고 합니다. 쉽게 표현하면,

“이 길에 있는 작업이 늦어지면 프로젝트 전체가 늦어지는 경로”

 

입니다.

 

PMI는 Critical Path를 일반적으로 프로젝트 전체 기간을 결정하는 가장 긴 Activity 경로로 정의하며, CPM(Critical Path Method)은 각 Activity의 Float를 계산해 프로젝트의 최소 기간과 일정 유연성을 분석하는 방법으로 설명합니다.

 

예를 들어 다음과 같은 일정이 있다고 해보겠습니다.

 

• A. Process Design
• B. Equipment Specification
• C. Equipment Procurement
• D. Equipment Delivery
• E. Installation
• F. Commissioning

총 10개월이 걸린다고 해보겠습니다. 그런데 별도의 다른 작업은 6개월이면 끝납니다.

 

이 경우 프로젝트 완료를 결정하는 것은 10개월짜리 경로입니다.

 

따라서 Project Manager는 모든 Activity를 똑같이 관리하는 것이 아니라,

 

Critical Path에 있는 Activity를 특히 집중적으로 관리해야 합니다.

 

 

5. Float가 있다는 것은 아직 시간이 있다는 뜻이다

 

여기서 Float라는 개념이 등장합니다.

 

예를 들어 어떤 작업이 원래 3개월 차에 시작해서 4개월 차에 끝나야 한다고 해보겠습니다.

 

그런데 실제로는 3개월 차가 아니라 3.5개월 차에 시작해도 다음 작업에 아무런 문제가 없다면, 그 작업에는 일정상의 여유가 있는 것입니다. 이것이 Float입니다.

 

쉽게 말하면,

“조금 늦어져도 프로젝트 전체 일정에는 영향을 주지 않는 시간”

 

입니다.

 

반대로 Float가 0인 Activity라면 이야기가 달라집니다.

 

하루가 늦어지는 순간 프로젝트 완료일에도 영향을 줄 수 있습니다.

 

그래서 Project Schedule을 관리할 때는 단순히 “몇 월 며칠에 끝나는가?”만 보는 것이 아니라, “얼마나 늦어도 괜찮은가?”까지 봐야 합니다. 이것이 Critical Path와 Float를 분석하는 이유입니다.

 

 

6. 그런데 실제 Plant Project에서는 Equipment 하나가 Schedule을 결정하기도 한다

 

Beer to Zero Project를 다시 생각해 보겠습니다.

 

무알콜 맥주 생산공장에 여러 Equipment가 필요합니다. Tank도 필요하고, Pump도 필요하고, Heat Exchanger도 필요합니다.

 

그리고 일부 Equipment는 국내에서 바로 구매할 수 있지만, 일부는 제작기간이 상당히 긴 Long Lead Item일 수 있습니다.

 

예를 들어 특정 장비의 제작 및 납품에 6개월이 필요하다고 가정해 보겠습니다.

 

그런데 Construction은 4개월 후부터 시작할 예정입니다. 그렇다면 문제가 생깁니다. Equipment가 없는데 현장에서 설치할 수 없기 때문입니다.

 

결국 Schedule을 보면 다음과 같은 구조가 됩니다.

 

• Process Design
• Equipment Specification
• Vendor Selection
• Purchase Order
• Manufacturing
• Delivery
• Installation
• Commissioning

이 중 하나라도 Critical Path에 걸려 있다면, 그 Equipment의 Procurement Schedule이 곧 Project Schedule이 됩니다.

 

그래서 EPC 프로젝트에서는 Engineering만 잘한다고 되는 것이 아닙니다. Engineering, Procurement, Construction, Commissioning을 하나의 일정으로 통합해서 봐야 합니다.

 

실제로 PMI의 프로젝트 관리 사례에서도 Engineering, Procurement, Construction, Commissioning을 통합한 Project Schedule을 핵심적인 Schedule Control 체계로 다루고 있습니다.

 

 

7. “12개월이면 됩니다”라는 말에는 조건이 붙어야 한다

 

여기서 고객이 다시 질문합니다.

“그래서 이 공장, 몇 개월이면 완공됩니까?”

 

여기에

“12개월입니다.”

 

라고 단정해서는 안 됩니다. 정확한 답변은 오히려 다음과 같아야 합니다.

“현재 정의된 Scope와 주요 Equipment의 Procurement 조건을 기준으로 약 12개월을 예상하고 있습니다.”

 

왜냐하면 Schedule에는 수많은 Assumption과 Constraint가 들어가기 때문입니다.

 

예를 들어,

 

• 고객의 Engineering Document 승인이 예정대로 이루어지는가?
• Site가 예정일에 인계되는가?
• Long Lead Equipment의 납기가 지켜지는가?
• Construction Permit은 언제 나오는가?
• Utility가 언제 공급되는가?
• 고객이 지정한 Vendor가 있는가?
• Shutdown 기간은 언제인가?
• 현장 작업시간에 제한이 있는가?
• 기존 Plant와 Interface가 있는가?

이런 조건 하나가 바뀌면 Schedule도 바뀝니다.

 

따라서 Schedule은 단순한 날짜표가 아니라 특정한 조건을 전제로 한 실행 계획입니다.

 

 

8. 그래서 Schedule에는 'Basis'가 필요하다

 

여기서 앞서 언급한 Schedule Basis가 중요해집니다.

 

예를 들어 우리가 다음과 같은 일정을 만들었다고 해보겠습니다.

Mechanical Completion: 2027년 8월

 

그렇다면 질문이 나옵니다.

“왜 2027년 8월입니까?”

 

여기에 답할 수 있어야 합니다.

 

예를 들어,

 

• Engineering 시작일: 2026년 10월
• Major Equipment PO: 2026년 12월
• Major Equipment 제작기간: 5개월
• Equipment Delivery: 2027년 5월
• Construction Start: 2027년 2월
• Mechanical Completion: 2027년 8월
• Commissioning: 2027년 9~10월
• Performance Test: 2027년 11월

이라는 근거가 있어야 합니다. 즉,

Schedule은 날짜를 만드는 작업이 아니라 날짜를 설명할 수 있는 근거를 만드는 작업입니다.

 

AACE의 Schedule Basis 개념 역시 일정의 기반이 되는 가정, 리스크, 제약사항, 특별 고려사항 등을 문서화하는 데 목적이 있습니다.

 

 

9. 계약 단계에서는 Schedule이 곧 약속이 된다

 

여기서 PART 2의 핵심이 등장합니다. 우리는 지금 프로젝트를 설계하는 단계가 아니라,

프로젝트를 수주하기 위해 계약조건을 검토하는 단계

 

에 있습니다.

 

따라서 Schedule은 단순한 내부 관리자료가 아닙니다. 고객에게 제출한 Schedule이 계약서에 들어가는 순간, Project Schedule은 Contractual Commitment가 될 수 있습니다.

 

예를 들어 계약서에

Contract Award → Mechanical Completion : 12개월

 

이라고 명시되어 있다면,

 

그 12개월은 단순한 목표가 아니라 계약상 중요한 일정 기준이 됩니다. 따라서 계약 전에 반드시 확인해야 합니다.

 

Schedule을 만들기 전에 확인해야 할 것

 

① Contract Start Date

• 계약 체결일인가?
• NTP(Notice to Proceed) 발행일인가?
• 선급금 수령일인가?

 

② 주요 Milestone

• Engineering Complete
• PO Issued
• Equipment Delivery
• Construction Start
• Mechanical Completion
• Pre-commissioning
• Commissioning
• Performance Test
• Final Acceptance

 

③ Client Responsibility

고객이 제공해야 하는 자료와 승인이 일정에 포함되어 있는가?

 

④ Long Lead Item

납기가 긴 Equipment가 Critical Path에 있는가?

 

⑤ Site Condition

현장 인도가 실제로 가능한 시점은 언제인가?

 

⑥ Permit & Approval

인허가 및 고객 승인에 필요한 기간이 반영되어 있는가?

 

이런 조건을 확인하지 않고 무조건 짧은 Schedule을 제시하면, 수주 당시에는 경쟁력이 있어 보일 수 있습니다. 하지만 프로젝트가 시작된 후에는 이야기가 달라집니다.

 

 

10. 가장 위험한 Schedule은 “만들 수 있는 일정”이 아니라 “수주하기 좋은 일정”이다

 

프로젝트를 수주하려고 하면 누구나 일정을 짧게 만들고 싶어 집니다.

 

12개월이면 되는 프로젝트를 10개월이라고 하면 경쟁력이 있어 보입니다.

 

문제는 그다음입니다. 10개월이라는 일정이 실제로 가능한지 확인하지 않았다면, 그 순간부터 프로젝트는 Schedule Risk를 안고 시작하게 됩니다.

 

예를 들어,

Engineering 4개월
Procurement 5개월
Construction 4개월
Commissioning 2개월

 

이 필요하다고 해보겠습니다. 단순히 더해서 15개월입니다.

 

그런데 Engineering과 Procurement를 일부 Overlap 하고 Construction과 Procurement도 일부 병행하면 12개월로 줄일 수 있을 수도 있습니다.

 

그러나 이것이 실제로 가능한지는 별도의 검토가 필요합니다.

 

• Resource가 충분한가?
• Vendor가 그 기간 안에 제작할 수 있는가?
• Construction Area가 준비되는가?
• 고객 승인이 제때 이루어지는가?

이런 질문에 답하지 않고 단순히 Gantt Chart의 막대를 겹쳐놓는 것은 Schedule Engineering이 아닙니다.

 

PMI에서도 좋은 Schedule의 핵심을 단순한 일정표가 아니라 실제 실행 가능한(Executable) 계획으로 보는 접근을 강조합니다.

 

 

11. Project Schedule은 Cost Estimation과 연결되어 있다

 

앞선 Part 11. Project Cost Estimation에서 우리는 프로젝트에 필요한 비용을 계산했습니다.

 

그런데 Cost와 Schedule은 사실 서로 떨어져 있지 않습니다.

 

예를 들어 Schedule을 12개월에서 10개월로 줄이려고 한다면, Engineering 인력을 추가로 투입해야 할 수도 있습니다. Vendor에게 긴급 제작을 요청해야 할 수도 있습니다. Construction Manpower를 늘려야 할 수도 있습니다. 야간작업이나 추가 Shift가 필요할 수도 있습니다.

 

결국,

Schedule을 줄이면 Cost가 증가할 수 있습니다.

 

반대로 비용을 줄이기 위해 인력을 줄이면 Schedule이 늘어날 수도 있습니다.

 

즉, Scope – Cost – Schedule은 서로 연결되어 있습니다.

 

프로젝트에서 흔히 말하는 Triple Constraint를 실제 현장에서 경험하게 되는 순간입니다.

 

AACE 역시 Cost Engineering의 범위에 Cost Estimating뿐 아니라 Project Management, Planning & Scheduling, Cost/Schedule Performance Measurement, Change Control 등을 함께 포함하고 있습니다.

 

 

12. 그래서 프로젝트 초기에는 Master Schedule이 필요하다

 

계약을 준비하는 단계에서는 모든 Activity를 세세하게 쪼갤 필요는 없습니다.

 

오히려 너무 세부적으로 만드는 것이 좋지 않을 수도 있습니다.

 

이 단계에서는 프로젝트 전체를 볼 수 있는 Master Schedule이 필요합니다.

 

예를 들어 Beer to Zero Project의 Master Schedule을 다음과 같이 구성할 수 있습니다.

 

Phase	주요 내용
Project Start	Contract / NTP
Engineering	Basic & Detail Engineering
Procurement	RFQ / PO / Manufacturing / Delivery
Construction	Civil / Equipment / Piping / E&I
Pre-commissioning	Cleaning / Flushing / Inspection
Commissioning	Utility / Equipment / Process
Performance Test	Production Test
Final Acceptance	Handover

 

그리고 그 아래 단계에서 각 분야의 Detailed Schedule이 만들어집니다. 즉,

Master Schedule
↓
Engineering Schedule
Procurement Schedule
Construction Schedule
Commissioning Schedule

 

이라는 구조입니다. 이러한 계층형 Schedule은 대규모 프로젝트에서 전체 일정과 세부 실행 일정을 연결하는 데 활용됩니다.

 

 

13. 그리고 계약이 체결되면 Schedule은 Baseline이 된다

 

이제 프로젝트가 수주되었다고 가정해 보겠습니다.

 

고객과 일정에 합의했습니다. 그렇다면 그 일정은 더 이상 단순한 계획이 아닙니다.

 

Baseline Schedule로 관리할 수 있습니다.

 

Baseline은 쉽게 말해,

“우리가 프로젝트를 이렇게 수행하기로 처음 합의한 기준 일정”

 

입니다. 이후 실제 프로젝트가 진행되면서

Planned Date
vs.
Actual Date

 

를 비교합니다. 예를 들어,

Activity	Planned	Actual
Equipment PO	1/15	1/20
Fabrication Start	2/1	2/10
Delivery	5/1	5/15
Installation	5/15	5/25

 

이렇게 실제 진행 상황을 계속 비교하면, “우리가 계획보다 얼마나 늦어지고 있는가?”를 확인할 수 있습니다.

 

PMI 역시 승인된 Baseline을 기준으로 실제 프로젝트의 진행을 비교·관리하는 Schedule Control의 중요성을 강조합니다.

 

 

14. 일정이 늦어진다는 것은 단순히 날짜가 늦어진다는 뜻이 아니다

 

Project Schedule에서 가장 무서운 말 중 하나가 있습니다.

“2주 Delay입니다.”

 

2주 늦었다는 사실 자체보다 더 중요한 것은,

“그래서 Critical Path에 영향을 주는가?”

 

입니다.

 

예를 들어 Non-critical Activity가 2주 늦었다면 프로젝트 전체에는 아무런 영향이 없을 수도 있습니다.

 

반대로 Critical Path에 있는 Activity가 2주 늦었다면,

 

Project Completion도 2주 늦어질 수 있습니다.

 

그래서 Project Manager는 단순히 Delay를 집계하는 것이 아니라, Delay → Logic → Float → Critical Path → Project Completion의 관계를 봐야 합니다.

 

이것이 Project Schedule Control의 핵심입니다.

 

 

15. Beer to Zero Project의 일정은 어떻게 만들어질까?

 

이제 우리가 실제로 Beer to Zero Project를 수주한다고 생각해 보겠습니다.

 

고객은 우리에게 말합니다.

“무알콜 맥주 생산설비를 12개월 안에 만들어 주세요.”

 

우리는 먼저 질문해야 합니다.

“12개월이 가능한가?”

 

그리고 그 답을 찾기 위해 프로젝트를 쪼갭니다.

 

Engineering

Process Design
→ PFD
→ P&ID
→ Equipment Specification
→ Datasheet
→ Vendor Document Review

 

Procurement

RFQ
→ Technical Evaluation
→ Commercial Evaluation
→ PO
→ Manufacturing
→ FAT
→ Delivery

 

Construction

Civil
→ Equipment Setting
→ Piping
→ Electrical
→ Instrumentation

 

Commissioning

Pre-commissioning
→ Utility Start-up
→ Equipment Test
→ Water Trial
→ Product Trial
→ Performance Test

 

이제 각각의 기간을 넣습니다. 그리고 Activity 사이의 관계를 연결합니다.

 

그 결과 우리가 처음에는 보지 못했던 하나의 길이 나타납니다.

 

Critical Path

 

그리고 그 순간 비로소 알게 됩니다.

“아, 이 프로젝트는 단순히 12개월짜리 프로젝트가 아니라, 이 Equipment의 납기 때문에 12개월이라는 기간이 결정되는구나.”

 

이것이 Project Schedule을 만드는 진짜 이유입니다.

 

 

16. 결국 Schedule은 “언제 끝나는가”보다 “왜 그때 끝나는가”가 중요하다

 

프로젝트 일정에서 중요한 것은 최종 날짜 하나가 아닙니다.

 

왜 그 날짜가 나왔는지를 설명할 수 있어야 합니다.

 

• 왜 12개월인가?
• 어떤 Equipment가 Critical한가?
• 어떤 Engineering Deliverable이 Procurement를 결정하는가?
• 어떤 Procurement Item이 Construction을 결정하는가?
• 어떤 Construction Activity가 Commissioning을 결정하는가?
• 그리고 어디에 Float가 있는가?

이 질문에 답할 수 있어야 합니다.

 

그래야 고객에게도 설명할 수 있고, Project Manager도 프로젝트를 관리할 수 있고, 문제가 발생했을 때 Schedule Recovery를 위한 판단도 할 수 있습니다.

 

 

마무리 — 프로젝트의 미래를 미리 그려보는 것

 

프로젝트를 시작하기 전에는 아무것도 만들어지지 않았습니다.

 

공장도 없고, Equipment도 없고, Piping도 없습니다. 그런데 우리는 아직 존재하지 않는 공장이 언제 완성될 것인지를 이야기해야 합니다.

 

그것이 Project Schedule입니다. Project Schedule은 단순히

“1월에 시작해서 12월에 끝난다.”

 

라는 달력이 아닙니다.

 

• Scope를 시간으로 바꾸고,
• Engineering을 Procurement와 연결하고,
• Procurement를 Construction과 연결하고,
• Construction을 Commissioning과 연결해서

마침내 하나의 완성된 프로젝트로 만들어내는 시간의 설계도입니다.

 

그리고 프로젝트를 수주하는 순간부터 이 일정은 단순한 계획이 아니라 고객과의 약속이 됩니다.

 

그래서 계약하기 전에 반드시 확인해야 합니다.

“우리가 이 프로젝트를 할 수 있는가?”

“우리가 어디까지 해야 하는가?”

“프로젝트에 얼마가 필요한가?”

 

그리고 이제 하나의 질문이 더 추가됩니다.

“그래서 우리는 언제까지 완성할 수 있는가?”

 

그 답을 찾아가는 과정이 바로 Project Schedule입니다.

 

 

Beer to Zero Project 연재 순서

 

PART 2. 프로젝트를 수주하다 — 설계하기 전에 계약부터

 

• Part 9. 우리가 이 프로젝트를 할 수 있는가 - Technical Feasibility
• Part 10. 어디까지 우리가 해야 하는가 - Project Scope 설정
• Part 11. 프로젝트에는 얼마가 필요한가 - Project Cost Estimation
• Part 12. 언제까지 만들어야 하는가 - Project Schedule
• Part 13. 무엇이 프로젝트를 망칠 수 있는가 - Project Risk Review
• Part 14. 엔지니어가 견적을 만드는 방법 - Engineering Man-hour
• Part 15. 기술제안서에는 무엇을 담는가 - Technical Proposal
• Part 16. 결국 계약이 필요하다 - Commercial & Contract
• Part 17. 프로젝트 수주 - 이제 진짜 시작이다