Transcript Program Management

Program Management
- Program and Project Definition 2011. 10. 13
건설사업관리특론 3
201121089 정 지 성
Program Management
◈ 설계관리와 변경의 최소화
PgMr은 프로젝트 요구사항을 결정하고, 프로젝트 일정을 작성해야 함
PM
input
Definition
For owner
Design
Definition
For builder
Translation
Construction
Definition for entitlement agencies
프로젝트의 지속적인 개선과 정의를 규명하는 과정은 PgMr의 가치를 증대시
킴
높은 효율은 프로젝트 정의를 기반으로한 프로그램의 정의를 활용함으로써 나
타낼 수 있음
 PgMr은 프로젝트의 반복적인 사항들로부터 주요한 결정을 할 수 있는데, 이는 반복적인 사업이
라는 점에서 10배의 능률향상이 가능함
2
Program Management
◈ 설계관리와 변경의 최소화
요구사항을 규정함으로써, 여러 복잡한 팀의 업무를 설명하고, 이를 변경사항
없이 효율적으로 수행할 수 있음
프로그램의 요구사항 정의 과정은 변경을 최소화하기 위한 최선의 방법임
한 시공 컨설턴트에 따르면 미숙한 프로젝트 정의는 약 50%의 비용이 증가되
는 경향이 있다고 통계적으로 분석함.
이러한 중요성으로 프로젝트 정의를 돕는 PDRI가 개발됨
◈ PDRI (Project Definition Rating Index, 프로젝트 정의 평가지수)
- 설계 진행에 따른 자료의 등급을 평가하는 방법
- 64개의 항목으로 이루어진 체크리스트
- 1) 올바른 사업인지?(why?), 2) 올바른 범위인지?(what?), 올바른 사업발주전
략인지?(how?)의 3부분으로 구성됨
PgMr은 PDRI와 같은 도구를 활용할 수 있어야 함
3
Program Management
1. 정의
프로그램 정의와 프로젝트 정의는 다음과 같은 과정인 동시에 성과임
 정보를 수집하고 해결방안을 도출하는 과정에서 합의를 이끌어 냄
 성과란 당사자 간 합의를 기술한 것이며, 상호간 이해와 동의 사항을 이해하기 위하
여 세부내용이 필요함
협의내용을 포함한 문서는 발주자를 위해 3D 디자인으로 표현될 수 있고, 미환
경보호청을 위한 환경영향평가, 또는 시공자를 위한 계약서에도 포함될 수 있음
4
Program Management
2. 변경에 대한 비용증가
PgMr은 설계변경이 용이한 요소들을 증명한 체크리스트를 보유해야 함
설계변경은 요구사항을 확정한 후, 적절한 시기에 수행해야 함
사업초기에 대안들은 다양하게 나타날 수 있으며, 이를 분석하는데 소요되는 비
용은 낮음
변경에 따른 비용은 프로젝트의 변경범위가 클 수록 증가함
1. 프로젝트를 정의하는 방법을 변경하는데 점차 많은 비용이 투입됨
2. 다수의 프로그램, 프로세스 및 참여자가 변경에 관계됨
변경에 따른 비용은 프로젝트의 변경범위가 클 수록, 사업의 진행률이 높을수록
증가함
일정 단축의 목표를 위해 사업을 충분히 정의하지 않을 경우, 비용초과와 공기
지연 등의 문제가 발생할 확률이 높아짐
5
Program Management
2. 변경에 대한 비용증가
요구사항을 정확하게 정의하고 발주자∙관련 기관 및 시공자와 최선책을 도출하
면 신속하게 결과를 획득할 수 있음
예측 가능한 결과가 발생하도록 유도하는 방법은 다음과 같음
1. 가장 종합적인 체크리스트를 통해 프로젝트 팀에서 제시할 수 있는 모든 지
적 에너지를 발산
2. 빠른 시일 내에 많은 정보를 수집
3. 변경이 용이하고 대안이 많은 단계에서 여러 대안을 고려
4. 사업을 진행하기에 앞서 가능한 모든 것을 정의
5. 프로그램 내, 후속 프로젝트를 위하여 의사결정 사항을 문서화하고 체크리스
트를 갱신
6
Program Management
3. Fast-track project
Fast-Track에 대하여 다수의 사람들은 “일정을 맞추기 위하여 모든 것을 정의
하기 전에 사업을 시작해야 한다”라고 비평함
Fast-Track은 정의를 줄이는 것이 아니라 더 많은 정의를 필요로 함
각 공종에 대해 제대로 정의를 하지 않으면 초과된 비용이 발생할 것임
Fast-Track 방식은 선행작업을 최종설계와 일치시키기 위하여 충분하게 정의
해야 함
설계변경은 종종 발생하므로, PgMr은 이에 대한 계획수립을 추진해야 함
7
Program Management
4. 관계자
프로그램과 프로젝트 정의의 목적은 사업발주에 참여하는 모든 주체 간의 협약
체결임
프로젝트 정의와 증빙자료는 발주자, 인허가기관, 시공자의 합의에 의해 작성되
어야 함
관계자들 중 한 명이라도 정의에 동의하지 않는다면, 변경이 발생함
 예방법은 발주자와 인허가기관의 요구를 수렴하여 시공자가 요구에 따라 신속하게 사
업을 수행하는 것임
지속적인 건설 프로그램에서 개별 프로젝트들은 정의와 승인이 유사함
 PgMr은 당해 문서를 기안하고, 엄격한 의사결정과 원칙에 따라 관리해야 함
PgMr은 주요 프로젝트 발주를 원활하게 진행하기 위한 기준공정과 체크리스트
를 구축하고, 후속 프로젝트에서 공사기간과 사업비를 절감해야 함
요구사항과 승인의 일정 패키지를 관리하는 업무는 프로그램 관리와 개별 프로
젝트 관리의 근본적인 차이점임
8
Program Management
5. 발주자
발주자측 조직은 계약도서와 시공 불일치로 인해 설계를 변경해야 함
PgMr의 실수이지만, 엄격한 정의를 통해 예방할 수 있음
발주자는 관계자들 사이에서 발생하는 다양한 이슈에 대해 의사결정을 신속하
게 수행해야 함
 조기에 문제점을 발견하는 것이 가장 해결책을 제시하기 쉬움
발주자를 위한 프로젝트 정의 마일스톤은 불분명함
 계약도서는 설계자가 시공자를 위한 프로젝트 정의를 표시한 법적인 마일스톤 임
발주자를 위한 프로젝트 정의가 계약도서를 완성하기 위한 성과물로 혼동되는
문제점이 있음
프로젝트의 정의가 명확하지 않으면, 모든 사항을 검토하고 변경해야 함
현명한 PgMr은 시공자와 동일하게 계약문서 승인 시점을 기다리기보다는 발주
자의 최종승인 승인 시점을 예측해야 함
9
Program Management
5. 발주자
발주자의 프로젝트 정의는 발주자가 프로젝트에 대해 이해하고 동의하였을 때,
결정해야 함
 발주자와 설계자가 설계안에 요구사항과 결정사항이 충분히 반영되었다고 동의한 때임
프로젝트 정의는 계약문서 작성 전에 이루어져야 함
PgMr의 업무는 발주자의 결정을 정밀히 표현하여 설계자가 의사결정 과정에
집중하게 하고, 수행한 것을 표시할 수 있도록 함
PgMr은 발주자의 이익이 되는 곳을 정밀하게 표현하는 것에 집중해야 함
또한 PgMr은 프로젝트 정의 패키지를 구성하기 위해 사업부지, 공간계획 등을
고려해야 함
 다양한 발주자 그룹을 구별해야 하며 각각의 요구사항을 부합해야 함
10
Program Management
5. 발주자
발주자를 위한 프로젝트 정의는 관계자들이 이해 할 수 있는 언어로 기술되어야 함
 시공자의 오해로 인한 설계변경이나 공기지연을 예방하기 위함
 사용자의 클레임을 사전에 예방하기 위함
발주자와 의사소통 한 결과를 시방서로 작성하기 보다는 명료한 도면으로 제시
할 필요가 있음
11
Program Management
6. 인허가기관
다양한 인허가기관으로부터 시공 전 요구되는 인가사항은 계속적으로 증가함
인허가기관의 동의는 발주자의 요구사항 만큼 중요함
인허가사항은 프로젝트 정의에 결정적인 영향을 주며, 발주자의 요구사항에 따
라 일정이 계획됨
PgMr은 개별적인 설계라도 인허가기관의 기준적용 여부를 확인해야 함
12
Program Management
7. 시공자
완전한 정의를 통해 시공자와 합의를 하면 변경사항이 복잡해지지 않음
건설분야에서는 설계협업 과정과 경쟁을 유지하면서 전문지식을 유도하는 사업
발주방식을 고안하기 위해 노력하고 있음
프로젝트 정의를 조기에 규정하기 위해 최선의 노력을 하고 있음에도 불구하고,
일부는 지속적으로 정의를 해야 할 필요가 있음
설계자와 시공자는 시공초기에 워크샵을 통해 결정사항들을 협의함으로써 진행
을 가속화시킬 수 있음
하지만 시공초기에 내린 모든 결정이 모두 좋은 결정으로 볼 수는 없으므로, 관
계자들의 필요시점까지 의사결정 사항들 중 일부는 연기하는 것이 타당함
PgMr은 공기를 지연 사항을 충분히 인지해야 향후 프로젝트에서 의사결정 사
항을 계획하고, 그 의사결정 사항들에 대한 체크리스트를 조정할 수 있음
13
Program Management
8. BIM
BIM은 전체 사업에 대한 데이터베이스로 특정 그룹에게 제공될 보고서 작성을
용이하게 함
BIM의 간단한 개념은 2세대 CAD로써 정보화된 객체를 포함하는 도구이며, 다
른 부가적인 소프트웨어와 호환되는 장점을 가짐
BIM의 그래픽 이미지를 통해 발주자와 의사소통의 문제를 해결할 수 있음
BIM의 가장 큰 장점은 협업을 가능하게 하는 것이고, 이는 계약방식의 근본적
인 변경을 요구하고 있음
 효과를 상승시키기 위해서는 시공자는 설계 시작 시 설계자와 협력해야 함
BIM을 효율적으로 활용하기 위해서는 방대한 양의 정보와 프로그램을 운용할
수 있는 BIM 책임자가 필요함
14
Program Management
8. BIM
BIM은 단계적으로 발전해가고 있음




초기단계 : 종전의 CAD를 대체하는 간단한 3D 도면 제작도구
현재단계 : MEP, 구조 등의 설계자로부터 작성된 도면들을 통합
개선단계 : 하수급자와 제조업자들로부터 시공상세도와 시방서를 통합
최종 요구단계 : 다른 사업발주전략과 계약구조의 재조정
BIM은 발전단계이므로 장기 문제를 해결할 방안을 지속적으로 모색해야 함
15
Program Management
9. 계획과 공기의 정의
업무흐름을 명확하게 보여주는 결과물은 모든 관계자들의 올바른 수행에 도움
이됨
능숙한 PgMr은 다음과 업무를 수행함
1)
2)
3)
4)
5)
사업 시작시기에 가능한 많은 정보 확보
신속한 의사결정
상세도면의 변경이 어려워지기 전에 엄격한 검토
사업참여자들로부터 동의를 확보
설계변경 요청 전에 공사를 완료
우수한 PgMr 그룹은 광범위한 체크리스트를 통해 신속하게 쟁점사항을 해결
하는데 집중하여 프로젝트 정의를 완료함
16
Program Management
10. 설계착수 지시
PgMr은 각 프로젝트의 설계자와 업무를 함께 수행함으로써 업무지시사항을
지속적으로 보완할 수 있음
명확한 프로젝트 정의 패키지는 2개의 부가효과를 제공함
1) 업무 효율 향상
- 관계자들이 프로젝트에 대해 명확하고 종합한 전망을 가질 때 더욱 효율적으로 일함
- 모든 의사결정 사항들을 정확하게 알고 있을 때 사업을 진행함에 있어 부담을 줄일
수 있음
2) 품질 향상
- 품질에 대한 정의는 “요구사항과의 일치”임
- 품질은 요구사항에 순응하므로, 반드시 프로젝트 정의에 따름
17
Program Management
11. 성공을 측정하는 기준
프로젝트 정의의 역할은 목표와 성공을 측정할 수 있는 기준을 수립하는 것임
하지만 목표에 많은 변화가 발생하므로 논쟁이 됨
설계자에게 작업을 지시하는데 성공을 측정하기 위한 기준을 설정하는 것은 불
가피한 설계변경에 따른 혼란을 완화시킬 수 있음
18
Program Management
12. 설계변경의 종류
설계변경의 원인은 다양함
1)
2)
3)
4)
발주자의 요구사항으로 인한 설계변경
오류, 누락 및 불완전한 문서
날씨, 기술, 경제, 정치 등의 예측 불가능한 외부요인
etc.
높은 수준의 프로젝트 정의도 설계변경을 완벽하게 제거할 수는 없음
PgMr의 업무 중 하나는 설계변경의 원인을 고려하여, 잠재된 설계변경에 맞게
계획과 예산을 설정하는 것임
19
Program Management
13. 설계변경 최소화 전략
1) 유연한 설계
• 환경변화에 따라 변경이 용이한 설계는 설계와 시공 중에 발생하는 설계변경에 보다
적절히 대응할 수 있음
• 예측 불가능한 미래를 위해 유연하게 설계해야 함
2) 철저한 요구사항 정의
• PgMr은 시공하고자 하는 시설물에 대한 지식을 축적함으로써 프로젝트 정의에 대한
논리적∙효과적인 의사결정 프로세스를 개발할 수 있음
• 의사결정 프로세스는 제안사항 및 요구사항을 달성하기 위한 모든 것을 목적으로 함
- PgMr이 시공하려는 시설물에 대한 지식의 축적과정을 거쳐 프로젝트 정의에 대한
프로세스를 개발할 수 있음
• 이러한 과정을 통해 축적된 지식은 공기 단축 및 비용 절감에 효과를 나타낼 수 있음
• 프로젝트의 지속적인 개선을 위하여 PgMr의 통찰력이 요구됨
20
Program Management
13. 설계변경 최소화 전략
3) 승인시점 설정
• 대부분의 설계팀은 계약도서 작성을 위한 일정을 프로젝트의 진행에 따라 마일스톤으
로 계획하여 관리함
• 요구사항을 정의하고, 승인을 받기 위한 필수과정임
• 보다 나은 방법은 관계자들의 요구사항 및 착수시점에서 제공된 정보가 포함된 여러 개
별 승인 사항을 규정하는 것임
• 설계변경이 발생하였을 때 PgMr은 발주자를 위해 비용과 일정을 신속하게 정의해야
함
21
감사합니다!
Program Management
PDRI
PDRI는 건물 프로젝트에 대하여 개발 수준을 측정하기 위한 단순하고 쉬운 도
구임(NASA 2000)
PDRI는 학교, 은행, 사무실 등의 다양한 용도의 건물을 측정할 수 있음
PDRI는 3개 범주, 11개 카테고리와 64개 요인으로 리스트됨
<PDRI Hierarchy>
Program Management
PDRI
PDRI 구성의 세부사항은 다음과 같음
SECTION 1. BASIS OF PROJECT DECISION
A. Business Strategy
A1.
A2.
A3.
A4.
A5.
A6.
A7.
A8.
Building Use Requirements
Business Justification
Business Plan
Economic Analysis
Facility Requirement
Future Expansion/Alteration
Site Selection considerations
Project Objective Statement
B. Owner
B1.
B2.
B3.
B4.
Reliability Philosophy
Maintenance Philosophy
Operation Philosophy
Design Philosophy
C. Project Requirements
C1.
C2.
C3.
C4.
C5.
C6.
Value-Analysis Process
Project Design Criteria
Evaluation of Existing Facilities
Scope of Overview
Project Schedule
Project Cost Estimate
Program Management
PDRI SECTION 2. BASIS OF DESIGN
E7. Functional Relationship
Diagrams/Room by Rome
E8. Loading/Unloading/Storage
D. Site Information
Facilities Requirements
D1. Site Layout
E9. Transportation Requirements
D2. Site Survey
E10. Building Finishes
D3. Civil/Geotechnical Information
E11. Room Data Sheets
D4. Governing Regulatory Requirement
E12. Furnishings, Equipment &
D5. Utility Sources with Supply Condition
Built-Ins
D6. Site Life Safety Considerations
E13. Window Treatment
D7. Special Water and Waste Treatment
Considerations
Requirements
D8. Project Objective Statement
E. Building Programming
E1.
E2.
E3.
E4.
E5.
E6.
Program Statement
Building Summary Space List
Overall Adjacency Diagrams
Stacking Diagrams
Growth and Phased Development
Circulation and Open Space
Requirements
F. Building/Project Design
Parameters
F1. Civil/Site Design
F2. Architectural Design
F3. Structural Design
F4. Mechanical Design
F5. Electrical Design
F6. Building Life Safety
Requirements
G. Equipment
Program Management
PDRI
SECTION 3. EXCUTION APPROACH
H. Procurement Strategy
L. Project Execution Plan
L1. Project Organization
H1. Indentify Long Lead/Critical
L2. Owner Approval Requirements
Equipment and Materials
H2. Procurement Procedures and Plans L3. Project Delivery Method
L4. Design/Construction Plan &
Approach
J. Deliverables
L5. Substantial Completion
J1. Economic Analysis
Requirements
J2. Documentation/Deliverables
K. Project Control
K1. Project Quality Assurance and Control
K2. Project Cost Control
K3. Project Schedule Control Requirements
K4. Risk Management
K5. Safety Procedures
Program Management
PDRI
체크리스트는 다음 예시와 같이 설계됨
Program Management
PDRI
체크리스트 기반 다이어그램 작성함
Program Management
PDRI
종합점수를 산출하고 다음 표를 통해 프로젝트의 정의를 측정할 수 있음
PDRI Score
Performance
Cost
Schedule
Change Order
< 200
> 200
Difference
1% above budget
6% above budget
5%
2% behind schedule
11% behind schedule
9%
7% of budget
11% of budget
4%