5. Project Scope Management (2)

5.2 Collect Requirements
Collect Requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.

The project success directly influenced by active stakeholder involvement in the discovery and decomposition of needs into requirements and by the care taken in determining, documenting, and managing the requirements of the product, service or results of the project. Requirements include conditions or capabilities that are to be met by the project or present in the product, service or result to satisfy an agreement or other formally imposed specification. Requirements become the foundation of the WBS, cost, schedule, quality planning and sometimes procurement are all based upon these requirements. The development of requirements begins with an analysis of the information contained in the project charter, the stakeholder register and stakeholder management plan.

Inputs
1) Scope management plan: provides clarity as to how project teams will determine which type of requirements need to be collected for the project.

2)Requirements management plan: provides the processes that will be used throughout the Collect Requirement process to define and document the stakeholder needs.

3)Stakeholder management plan: used to understand stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirement activities.

4) Project charter: used to provide the high level description of the product, service, or result of the project so that detailed requirements can be developed.

Tools & Techniques
1) Interview: Talking to stakeholders directly, typically performed by asking prepared and spontaneous questions and recording the responses.

2) Focus groups: trained moderator guides the group through an interactive discussion, designed to be more conversational than a one-to-one interview.

3) Facilitated workshop: focused sessions that bring key stakeholders together to define product requirements. Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. Because of their interactive group nature, well facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition issues can be discovered earlier and resolved more quickly than in individual sessions.

Joint application development (JAD)

• used in software development industry
• focus on bringing business subject matter experts and the development team together to improve software development process

Quality function deployment (QFD)

• helps determine critical characteristics for new product development
• starts by collection customer needs, also known as Voice of the Customer (VoC)
• collected needs are then objectively sorted and prioritized

4) Group creativity techniques: group activities can be organized to identify project and product requirements.

• Brainstorming - used to generate and collect multiple ideas, not include voting or prioritization.
• Nominal group technique - enhances brainstorming with a voting process used to rank most useful ideas
• Idea/mind mapping - ideas created through brainstorming are consolidated in a single map to reflect commonality and differences
• Affinity diagram - large numbers of ideas to be classified into groups for review and analysis
• Multicriteria decision analysis - utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas

5) Group decision making techniques: can be used to generate, classify and prioritize product requirements

• Unanimity - everyone agrees on a single course of action, one way to reach unanimity is the Delphi technique.
• Majority - more than 50%
• Plurality - largest block in a group decides, even if a majority is not achieved
• Dictatorship - one individual makes the decision

** Delphi technique: 

The experts answer questionnaires in two or more rounds. After each round, a facilitator provides an anonymous summary of the experts’ forecasts from the previous round as well as the reasons they provided for their judgments. Thus, experts are encouraged to revise their earlier answers in light of the replies of other members of their panel. It is believed that during this process the range of the answers will decrease and the group will converge towards the "correct" answer. Finally, the process is stopped after a pre-defined stop criterion.

(keywords: experts, questionnaire, anonymous) 

6) Questionnaires and surveys: written set of questions designed to quickly accumulate information from large number of respondents, appropriate with varied audiences, when respondents are geographically dispersed and where statistical analysis is appropriate.

8) Prototypes: obtains early feedback on requirements by providing a working model of the expected product before actually building it. allows stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements.


Outputs
1) Requirements documentation: describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more about the requirements is known.

2) Requirements traceability matrix: a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a meas to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally it provides a structure for managing changes to the product scope.

Tracing includes Business needs, goals, objectives, project scope/WBS deliverables, etc.

5. Project Scope Management (1)

Project Scope management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project.

In the project context, the term scope can refer to:

• Product scope: the features and functions that characterize a product, service or result
• Project scope: the work performed to deliver a product, service, or result with the specified features and functions. The term project scope is sometimes viewed as including product scope.

The scope baseline for the project is the approved version of the project scope statement, work breakdown structure (WBS), and its associated WBS dictionary. A baseline can be changed only through formal change control procedures and is used as a basis for comparison while performing Validate Scope and Control Scope processes as well as other controlling processes.

Completion of the project scope is measured against the Project management plan. Completion of the product scope is measured against the product requirements. The project scope management processes need to be well integrated with the other knowledge area processes, so that the work of the project will result in delivery of the specified product scope.

5.1 Plan Scope Management

Plan Scope Management is the process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled.

The scope management plan is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and verified. The development of the scope management plan and the detailing of the project scope begin with the analysis of information contained in the project charter, the latest approved subsidiary plans of the project management plan, historical information contained in the organizational process assets, and any other relevant enterprise environment factors. This plan helps reduce the risk of project scope creep.

Inputs

1) Project management plan

Approved subsidiary plans of the project management plan are used to create the scope management plan and influence the approach taken for planning scope and managing project scope.

2) Project charter

Project charter is used to provide the project context needed to plan the scope management processes. It provides the high level project description and product characteristics from the project statement of work.

Outputs

1) Scope management plan

Scope management plan describes how the scope will be defined, developed, monitored, controlled and verified. Major input into the Develop Project Management Plan process, and the other scope management processes.

2) Requirements management plan

Requirement management plan is a component of the project management plan that describes how requirements will be analyzed, documented, and managed. 

4. Project Integration Management (6)

4.6 Close Project or Phase
Close Project or Phase is the process of finalizing all activities across all of the Project management process groups to formally complete the project or phase.

When closing the project, Project Manager reviews all prior information from the previous phase closures to ensure that all project work is completed and that the project has met its objectives. Since project scope is measured against the project management plan, the project manager reviews the scope baseline to ensure completion before considering the project closed. Close Project or Phase process also establishes the procedures to investigate and document the reason for actions taken if a project is terminated before completion. In order to successfully achieve this, the project manager needs to engage all the proper stakeholders in the process.

Inputs
1) Project management plan: agreement between the project manager and project sponsor, defining what constitutes project completion

2) Accepted deliverables: include approved product specifications, delivery receipts and work performance documents, Partial or interim deliverables may also be included for phased or cancelled projects.

3) Organizational process assets: OPA that can influence the Close Project or Phase process incl.
- Project or phase closure guidelines or requirements (e.g. admin procedures, project audits etc.)
- Historical information and lessons learned knowledge base (e.g. project records and documents etc.)

Tools & Techniques
1) Expert judgement: applied when performing administrative closure activities, these exports ensure that project or phase closure is performed to the appropriate standards.

2) Analytical technique:examples of analytical techniques used in project closeout are
- Regression analysis
- Trend analysis

3) Meetings: may be face-to-face, virtual, formal or informal. Types of meetings include lessons learned, closeout, user group and review meetings.

Outputs
1) Final product, service or result transition: this output refers to the transition of the final product, service or result that the project was authorized to produce.

2) OPA updates: OPA that are updated as a result of the Close Project or Phase process include project files, closure documents and historical information

4. Project Integration Management (5)

4.5 Perform Integrated Change Control
Perform Integrated Change Control is the process of reviewing all change requests; approving changes and managing changes to deliverables, organizational process assets, project documents, and the project management plan, and communicating their disposition.

This reviews all requests for changes or modifications to project documents, deliverables, baselines or project management plan and approves or rejects the changes.

Changes may be requested by any stakeholder involved with the project. Although changes may be initiated verbally , they should be recorded in written form and entered into the change management and/or configuration management system. Change requests are subject to the process specified in the change control and configuration control system. Those change request processes may require information on estimated time impacts and estimated cost impacts.

Every documented change request needs to be either approved or rejected by a responsible individual, usually the project sponsor or project manager or change control board (CCB)

Approved change requests can require new or revised cost estimates, activity sequences, schedule dates, resource requirements, and analysis of risk response alternatives. These changes can require adjustments to the project management plan and other project documents.

Inputs
1) Project management plan: elements of the project management plan that may be used include
- Scope management plan: contains the procedures for scope changes
- Scope baseline: provides product definition
- Change management plan: provides the direction for managing the change control process

Changes are documented and updated within the project management plan as part of the change and configuration management processes.

2) Work performance reports: include resource availability, schedule and cost data, earned value management (EVM) reports, and burn up or burn down charts.

3) Change requests: all of the Monitoring and controlling processes and many of the Executing processes produce change requests as an output. May include corrective action, preventive action or defect repairs.
However corrective and preventive actions do not normally affect the project baselines.

Tools & Techniques
1) Export judgement: in addition to the project management team's expert judgement, stakeholders may be asked to provide their expertise and may be asked to sit on the change control board (CCB).

2) Meetings: in this case these meetings are usually referred to as change control meetings. When needed for the project, a change control board (CCB) is responsible for meeting and reviewing the change requests and approving, rejecting, or other disposition of those changes. The R&R of these boards are clearly defined and agreed upon by appropriate stakeholders and documented in the change management plan.

3) Chang control tools: in order to facilitate configuration and change management, manual or automated tools may be used. Tool selection should based on the needs of the project stakeholders incl. organizational and environmental considerations and constraints.

Outputs
1) Approved change requests: change requests are processed according to the change control system by the project manager, CCB or by an assigned team member. Approved change requests will be implemented through the 4.3 Direct and Manage Project Work process. The disposition of all change requests, approved or not, will be updated in the change log as part of updates to the project documents.

2) Change log: a change log is used to document changes that occur during a project. These changes and their impact to the project in terms of time, cost, and risk, are communicated to the appropriate stakeholders. Rejected change requests are also captured in the change log.

3) Project management plan updates: any subsidiary plan and baselines that are subject to the formal change control process may be updated.

4) Project documents updates: may be updated as a result of the Perform Integrated Change Control process include all documents specified as being subject to the project's formal change control process.

4. Project Integration Management (4)

4.4 Monitor and Control Project Work
Monitor and Control Project Work is the process of tracking, reviewing, and reporting the process to meet the performance objectives defined in the project management plan.

Monitor and Control Project Work process is concerned with

• comparing actual project performance against the project management plan
• assessing performance to determine whether any corrective or preventive actions are indicated, and then recommending those actions as necessary
• identifying new risks and analyzing, tracking, and monitoring existing project risks to make sure the risks are identified, their status is reported, and that appropriate risk response plans are being executed
• maintaining an accurate, timely information base concerning the project's products and their associated document through project completion
• providing information to support status reporting, progress measurement, and forecasting
• providing forecasts to update current cost and current schedule information
• monitoring implementation of approved changes as they occur
• providing appropriate reporting on project progress and status to program management when the project is part of an overall program

Inputs
1) Project management plan: monitoring and controlling project work involves looking at all aspects of the project, subsidiary plans (Scope, requirements, schedule, cost, quality, etc.) within the project management plan form the basis for controlling the project

2) Schedule forecasts: forecasts are derived from progress against the schedule baseline and computed time estimate to complete (ETC). Forecasts are typically expressed in terms of schedule variance (SV) and schedule performance index (SPI).

3) Cost forecasts: forecasts are derived from progress against the cost baseline and computed cost estimates to complete (ETC). Expressed in terms of cost variance (CV) and cost performance index (CPI). An estimate at completion (EAC) can be compared to the budget at completion (BAC) to see if the project is still within tolerance ranges or if a change request is required.

4) Validated changes: approved changes that results from the Perform Integrated Change Control process require validation to ensure that the change was appropriately implemented. A validated change provides the necessary data to confirm that the change was appropriately executed.

5) Work Performance Information: performance data collected from various controlling processes, analyzed in context, and integrated based on relationships across areas. Work performance information (e.g. status of deliverables, implementation status for change requests, forecasts) is circulated through communication processes.

Tools and Techniques
2) Analytical techniques: applied in project management to forecast potential outcomes based on possible variations of project or environmental variables and their relationships with other variables.
- Regression analysis
- Grouping methods
- Causal/Root cause analysis
- Forecasting methods (e.g. time series, scenario building, simulation)
- Failure mode and effect analysis (FMEA)
- Fault tree analysis (FTA)
- Reserve/Trend/Variance analysis
- Earned value management (EVM)

Outputs
1) Change requests: as a result of comparing planned results to actual results, change requests may be issued to expand, adjust, or reduce project scope, product scope, or quality requirements and schedule or cost baselines. Change requests may necessitate the collection and documentation of new requirements. Changes can impact the project management plan, project documents or product deliverables. Changes that meet the project's change control criteria should go through the integrated change control process established for the project. Changes may include corrective, preventive actions and defect repair.

2) Work performance reports: physical or electronic representation of work performance information compiled in project documents, intended to generate decisions, actions, or awareness.

3) Project management plan updates: changes identified during the Monitor and control project work process may affect the overall project management plan. These changes, after being processed through the appropriate change control process can lead to project management plan updates.

4) Project documents updates: documents such as schedule and cost forecasts, work performance report, issue log, may be updated.

4. Project Integration Management (3)

4.3 Direct and Manage Project Work
Direct and Manage Project Work is the process of leading and performing the work defined in the project management plan and implementing approved changes to achieve the project's objectives.

Direct and Manage Project Work activities:

• perform activities to accomplish project objectives
• create project deliverables to meet the planned project work
• obtain, manage, and use resources incl. materials, tools, equipment, and facilities
• implement the planned methods and standards
• generate work performance data, such as cost, schedule, technical and quality progress, and status to facilitate forecasting
• issue change requests and implement approved changes into the project's scope, plans, and environment
• manage risks and implement risk response activities
• manage sellers & suppliers and stakeholders & their engagement
• collect and document lessons learned and implement approved process improvement activities

Direct and Manage Project Work process also requires review of the impact of all project changes and the implementation of approved changes:

• corrective action: realigns the performance of the project work with the project management plan
• preventive action: ensures the future performance of the project work is aligned with plan 
• defect repair: modify a nonconforming product or product component

Inputs
1) Project management plan: contains subsidiary plans,
- Scope management plan
- Requirements management plan
- Schedule management plan
- Cost management plan
- Stakeholder management plan

2) Approved change requests: outputs of the 4.5 Perform Integrated Change Control Process incl. those requests reviewed & approved by CCB (Change Control Board)
The approved change may be a corrective/preventive/defect repair, it can also modify project management plan or project documents.

Tools & Techniques
2) Project management Information System: part of EEF and provides tools such as a scheduling tools, configuration management system or information collection and distribution system.

Outputs
1) Deliverables: any unique and verifiable product, result. Typically tangible components completed to meet the project objectives and can include elements of the project management plan.

**Flow of deliverable
Defined Deliverable >> Approved Deliverable >> Verified Deliverable >> Accepted Deliverable
(4.2 Project management plan) >> (4.3 Direct and Manage Project Work) >> (8.3 Quality Control) >> (5.5 Verify Scope) >> (4.6 Close Project or Phase)

2) Work Performance Data: raw observation and measurements identified during activities.
data is gathered through work execution and passed to the controlling processes for further analysis
e.g. work completed, key performance indicators, performance measures, start/finish dates of activities etc.

3) Change Requests: formal proposal to modify any document, deliverable or baseline
- corrective action
- preventive action
- defect repair
- updates: changes to formally controlled project documents, plans etc., to reflect modified or additional ideas or content

4. 프로젝트 통합 관리 (2)

4.2 프로젝트 관리 계획서 개발 
Develop Project Management Plan is the process of defining, preparing, and coordinating all subsidiary plans and integrating them into a comprehensive project management plan.

프로젝트 관리 계획서 개발은 모든 보조 계획서들을 정의, 준비, 조정하고 관리 계획서에 통합하는 프로세스로써, 프로젝트가 종료될 때까지 점진적이고 구체적으로 개발되며 4.5 통합 변경 통제 수행을 통해서 승인된 내용도 지속적으로 업데이트 됨.

주요 Inputs
1) 프로젝트 헌장 - 4.1 에서 작성된 헌장에는 프로젝트 목적을 포함한 상위 수준의 정보가 포함되어 있어서 관리 계획서를 개발할 때 반드시 참조해야 함.

2) 다른 프로세스의 산출물 - 5. 범위 ~ 13. 이해관계자 관리의 기획 프로세스 산출물인 기준선 및 보조 관리 계획서들을 통합하여 관리 계획서를 작성함.
4.5 통합 변경 통제를 통해서 승인된 변경 사항을 업데이트하기도 함.

Outputs 
1) Project Management Plan
요약 또는 상세 수준으로 작성되며, 프로젝트의 실행, 감시 및 통제, 종료의 기준 문서로 활용
- 선정된 프로젝트 life cycle 및 각 단계 별 프로세스 포함
- 프로젝트 관리 프로세스, 도구 및 기법 등
- 변경 감시 및 통제를 위한 변경 관리 계획서
- 형상 관리 수행을 위한 형상 관리 계획서
- 이해 관계자들의 의사소통 요구 및 방법 등


프로젝트 수행의 기준 문서는 프로젝트 관리 계획서이고, 기타 다른 문서들은 프로젝트 문서라고 하며, 각각의 문서 예시는 아래와 같음.

4. 프로젝트 통합 관리 (1)

프로젝트 통합 관리는 관리 프로세스 그룹에 속하는 다양한 프로세스와 관리 활동들을 식별, 정의, 결합, 통합 및 조정하는데 필요한 프로세스와 활동들을 포함한다.

4.1 프로젝트 헌장 수립

• 프로젝트를 공식적으로 승인하고 PM에게 권한을 부여함.
• 요구 사항 수집, 상위 수준의 이해관계자/리스크 식별, 일정 및 원가 관리 계획서 등을 개발하기 위한 기준 문서로 활용됨.
• 프로젝트 헌장은 스폰서 조직이 작성하고 승인
• PM은 프로젝트 초기에 선임되어야 하며, 헌장을 개발하는 동안, 반드시 기획 프로세스를 시작하기 전에 선임되어야 함.

주요 투입물 (Inputs):

1) 작업 기술서 (Project Statement of Work ) - 프로젝트의 겨과로 제공해야 할 제품이나 서비스를 상세하게 기술한 문서, 승인된 프로젝트에서 할일에 대한 상위 수준의 요구 사항을 기록

- 비즈니스 요구 사항, 제품 범위 명세서, 조직 전략적 계획을 포함.

- 내부 프로젝트의 경우: 착수자나 스폰서가 비즈니스 요구, 제품 또는 서비스 요청 사항을 토대로 작업 기술서를 제공.

- 외부 프로젝트의 경우: 고객이 RFP, RFI, RFB와 같은 입찰/계약 서류의 일부로 작업 기술서 제출

2) 비즈니스 케이스 (Business Case)

조직의 비즈니스 관점에서 투자할 가치가 있는지 검토한 판단 근거를 기록한 문서 

- Cost-Benefit Analysis 를 통해서 제공

3) 협약서 (Agreements)

외부 고객을 위한 프로젝트를 수행할 때, 구매자/공급자 사이 자율적으로 협약한 내용이 포함된 광범위한 문서

4) 기업 환경 요인 (Enterprise Environmental Factors: EEF)

- 조직 외부 환경: 정부/산업 표준, 시장 여건

- 조직 내부 환경: 조직 문화/구조

5) 조직 프로세스 자산 (Organizational Process Assets: OPA)

- 프로세스와 절차: 조직의 표준 프로세스/정책, 프로젝트 헌장 개발 템플릿

- 조직 지식 기반: 선례 정보 및 습득한 교훈 지식 기반

도구 및 기법 (Tools & Techniques : T&T)

1) 전문가 판단 (Export Judgement: EJ)

해당 업무나 유사 업무에 대한 지식을 보유한 인적자원/전문가 시스템 활용

2) 촉진 기법 (Facilitation Techniques)

Facilitator (촉진자)가 주체가 되어 프로젝트 팀과 팀원이 활동을 수행하는 것을 돕는 기법

- Brainstorming

- 갈등/분쟁 해결 (Conflict Resolution)

- 문제 해결 (Problem Solving)

- 미팅/회의 관리 (Meeting management)

**산출물 (Outputs)

1) 프로젝트 헌장 (Project Charter) 

- 프로젝트의 시작을 알리는 공식적인 문서

- 시작 승인 및 재정을 지원할 수 있는 프로젝트 착수자 (Initiator)/스폰서 (Sponsor) 가 작성

- PM을 선임하고 조직의 자원을 투입할 수 있는 권한 부여

- 주요 이해 관계자들의 서명을 마지막에 받음

- 상위 수준의 프로젝트 목적, 요구사항, 제약 사항, 가정 사항 등 포함

3. 프로젝트 관리 프로세스

프로세스란 사전에 정의되어 있는 제품이나 서비스, 결과를 생성하고자 수행하는 관련 조치나 활동들로서 투입물, 적용할 수 있는 도구나 기법, 그리고 결과로 생성되는 산출물로 구성됨.

프로젝트 관리 프로세스 그룹 (또는 프로세스 그룹)은 아래와 같이 5개 그룹으로 구성됨.

1. 착수 (Initiating): 기존 프로젝트의 새로운 단계 또는 새 프로젝트 정의/승인 받아 시작
2. 기획 (Planning): 프로젝트의 범위 설정, 목표 구체화, 목표 달성을 위한 활동 계획/관리
3. 실행 (Executing): 프로젝트 명세서/관리 계획서에 정의된 작업 수행
4. 감시 및 통제 (Monitoring & Controlling): 진행 성과 추적/검토/조정/변경 등
5. 종료 (Closing): 모든 활동을 종료하는 과정에서 수행되며 프로젝트/단계 공식적으로 종료

프로세스 그룹의 특징:

1. 하나의 프로세스에서 수행된 조치는 해당 프로세스 및 다른 프로세스에도 영향을 미침
2. 프로세스 그룹은 각각의 산출물을 통해 서로 연결됨
3. 프로세스 산출물은 다른 프로세스의 Input/Output이 됨
4. 프로세스 그룹은 산업 전반에 적용되며 What만 정의해주고 How 등 가이드 제공은 하지 않음.

감시 및 통제 프로세스 그룹은 전체 실행 영역과 지속해서 상호 작용 함.

각 프로세스 그룹 및 지식 영역 별 프로세스의 관계는 아래 표에서 확인 가능.

* 착수 프로세스 그룹에서는 4.1 프로젝트 헌장 개발, 그리고 13.1 이해관계자 식별 프로세스가 중요.

* 종료 프로세스 그룹에서는 4.6 프로젝트 또는 단계 종료, 그리고 12.4 조달 종료 프로세스가 중요.

각 지식 영역 별 프로세스는 PMBOK 4장부터 설명이 되어 있으며, 위표에 표시되어 있는 각 프로세스 번호가 PMBOK의 장임.

2. 조직의 영향력과 프로젝트 생애 주기

2. Organizational Influences and Project Life cycle

프로젝트를 진행할 때, 조직 문화/스타일/의사 소통 방법/조직 구조/조직 프로세스 자산 (Organizational Process Assets: OPA)/기업환경요인 (Enterprise Environmental Factor: EEF) 같은 항목들이 부정적 또는 긍정적으로  프로젝트에 영향을 준다..

1. 조직 구조
 조직의 유형은 기능, 매트릭스, 프로젝트 조직으로 나누어 볼 수 있다


기능 조직은 전통적인 조직 구조로 각 부서별로  장이 있는 것과 비슷하며,
프로젝트 조직은 프로젝트 특징과 분야 별로 조직을 구성하는 형태이며, SI 업체와 비슷하다
매트릭스는 기능과 프로젝트 중간 단계임..

*여기서 중요한 것은 균형 매트릭스 조직으로, 예산 관리 담당의 주체, PM/PMO의 전임/시간제 등을 눈여겨 봐야 한다...

2. 조직 프로세스 자산 (OPA)
프로젝트를 수행하는 조직에 지정되어 사용되는 계획, 프로세스, 정책, 절차, 지식 기반
- 각종 템플릿 (e.g. WBS)
- 조직 표준, 절차 등(e.g. 품질 정책)
- 프로젝트 종료 지침 및 요구 사항
- 형상 관리 지식 기반
- 선례 정보와 교훈 지식 기반
- 과거 프로젝트의 프로젝트 파일 등등

3. 기업 환경 요인 (EEF)
프로젝트 팀의 통제관 범위 밖에 있으며 프로젝트에 영향을 주고, 제약을 주며, 방향을 제시하는 조건...
- 조직 문화/구조, 인사 행정
- 정치 풍토, 정부/산업 표준
- 인프라/시스템 등등

4. 이해관계자
프로젝트 전반에 걸쳐서 긍정적/부정적으로 영향을 미칠 수 있는 개인/조직

* 스폰서: 주로 경영층이 담당자, 프로젝트 재정적 자원을 제공하는 개인/그룹으로 프로젝트를 공식적으로 승인하며, 중요 의사 결정에 참여할 수 있음.

5. 프로젝트 생애 주기
- 예측형 (Predictive): 요구 사항 명확하며, 프로젝트 시작 시점에 모든 계획 확정 (e.g. Waterfall)
- 적응형 (Adaptive): 초기 요구 사항 불분명하나 갈수록 명확해지며, 시작 시점에는 대략적인 계획만 수림하며 단계별로 세부 계획 수립 (e.g. Agile)

* 이해관계자의 영향력,리스크, 불확실성은 프로젝트 초기에 높으며 갈수록 낮아짐..
* 변경 및 오류 정정 비용은 반대로 프로젝트 초기에 낮으나 갈수록 높아짐..

프로젝트 생애 주기와 프로세스 그룹은 다름
프로젝트 생애 주기는 개시, 구성/준비, 작업 수행, 종료로 구분되지만
프로세스 그룹 (착수, 기획, 실행, 감시/통제, 종료)은 전체 프로젝트에서 한번만 실행될 수도 있고, 프로젝트 단계별로 수행될 수도 있음...

1. PMP Intro

첫 번째 장인 서론은 아래와 같은 항목들을 소개하는 것으로 내용을 이해하는 데는 큰 문제가 없어 보인다...

• 프로젝트 정의 및 특징
• 프로젝트 관리
• 포트폴리오 관리, 프로그램 관리, 프로젝트 관리 등 연관 관계
• 프로젝트 관리자(PM)의 역할
• 프로젝트 관리와 운영 관리의 차이점 등등

1. 프로젝트란 무엇인가?

고유한 제품, 서비스 또는 결과물을 창출하기 위해 한시적으로 투입하는 노력이다..

- 한시성/일시성 (Temporary): 프로젝트의 시작과 끝이 정해져 있음

- 유일성 (Unique): 고유한 제품, 서비스 또는 결과물을 산출한다.

- 점진적 구체화 (Progressively elaboration): 프로젝트에서 산출되는 제품이나 결과물들은 반복적이며 점진적인 방법으로 갱신되면서 구체화된다는 의미이다..

2. 포트폴리오 & 포트폴리오 관리

포트폴리오는 전략적 목표를 달성하기 위해 하나의 그룹으로 관리되는 프로젝트, 프로그램, 하위 포트폴리오 및 운영업무의 집합체이며, 포트폴리오 관리란 조직의 전략적 목표를 달성하고자 포트폴리오를 중앙 집중 방식으로 관리하는 것을 말한다...

- 프로젝트나 프로그램들이 서로 의존 관계에 있지 않아도 됨.

- 조직의 전략과 우선순위를 기반으로 생성

3. 프로그램 & 프로그램 관리

개별적으로 관리해서는 실현할 수 없는 혜택을 얻기 위해 통합으로 관리하는 관련 (하위) 프로젝트, 프로그램 등으로 구성된 그룹

프로그램 관리는 프로그램 요구 사항을 충족하고 개별적인 관리로는 달성되지 않는 혜택과 통제를 실현하고자 지식, 기량, 도구 및 기법을 프로그램에 적용하고 관리하는 방식이다..

4. 프로젝트 관리?

프로젝트 요구 사항을 충족시키기 위해 지식, 기술, 도구, 기법 등을 프로젝트 활동에 적용하는 것을 프로젝트 관리라고 한다...

- 5개 프로세스 그룹 (착수, 기획, 실행, 감시 및 통제, 종료)

- 47개 프로젝트 관리 프로세스

프로젝트/프로그램/포트폴리 관리 비교

5. 프로젝트 관리 오피스 (PMO)

프로젝트 관련 거버넌스 프로세스를 표준화하고, 자원, 방법론, 도구, 기법 등의 공유를 촉진하는 관리 조직

- 지원형 (Weather station): 다른 프로젝트에서 얻은 교훈/정보 등을 제공, 통제력 낮음

- 통제형 (Coach): 다양한 수단을 통해 지원하고 준수 사항 요구, 통제력은 보통

- 지시형 (Control tower): 프로젝트를 직접 관리, 통제 지휘, 높음

6. 프로젝트 관리자 (PM)

조직에서 프로젝트 목표 달성 책임을 갖는 팀의 리더/책임자

조직의 구조에 따라 기능 관리자에게 보고할 수도 있음. 

- 기능 관리자: 기능 또는 사업 부분의 관리 감독에 집중

- 운영 관리자: 비즈니스 운영의 효율을 유지하는 책임

PM은 작업/팀 요구 사항, 개인별 요구 사항을 충족시켜야 할 책임이 있으며, 프로젝트에 필요한 해당 분야의 기술 역량, 관리 능력도 요구됨.

PM은 프로젝트의 책임을 지는 사람으로, 대인 관계 기술도 필요함...

- 리더십, 팀 빌딩, 코칭, 의사소통, 동기 부여, 협상, 갈등 관리 등등등

0-0. What's PMP? Why PMP?

학교 졸업 후 단독으로 개발 업무도 해 보고 다른 사람들과 같이 협업도 많이 해 보았다..
그런데 가끔은 협업하는 게 너무나도 힘들 때가 있다.. 나만 그런건가?
특히 커뮤니케이션 ㅠ 그리고 같은 눈높이에서 정상을 바라보기도 너무 힘들더라...

암튼 그러던 중 PMP (Project Management Professional)이라는 자격증이 있다는 것을 알았다..
궁금해서 이것 저것 찾아보았고.. 자기 개발 차원에서 한번 도전해 보기로 했는데..공부해야 하는 범위가 장난이 아니네.. 허허..


PMP는 무엇? 도움이 되나?
PMP는 앞에 언급했듯이 Project Management Professional 이란 용어를 그대로 해석하자면 프로젝트 관리 전문가? 정도 되겠다..

PMI (http://www.pmi.org/) 협회에서 주관하는 자격 시험으로 전세계적으로 그 공신력을 인정 받는 자격임에는 틀림이 없는 듯하다.. LG CNS나 삼성 SDS 같은 프로젝트를 주업무로 하는 회사들에서는 PM이 되기 위해서 필수로 따는 자격증인가 보다..

PMP의 목적은 단순하다 프로젝트 업무에 종사하는 사람들이 프로젝트 관리의 전문성을 배양하면서 체계적인 PM 기법을 갖추도록 하는 것이다..

PMP는 일종의 프로젝트 관리 프레임워크를 제공하는 것으로 IT를 비롯해, 조선, 건설, 제조 등 거의 모든 산업 분야에서 사용될 수 있다.. 일부 회사에서는 PMP 교육 과정 및 취득 비용을 모두 지원하기도 하고, 승진 등에 많은 도움이 된다고 하니..

그럼 누구나 시험 신청이 가능한 건가?
공신력 있는 자격증이니 만큼.. 기본 요구 사항을 만족해야 하지 않을까 싶다..
학사 학위 이상인 경우에는 최소 4,500 시간 (36개월) 이상의 프로젝트 실무 경험이 필요하고
전문대나 고졸 이하 인경우에는 최소 7,500 시간 (60개월) 이상의 경험이 필요하다..
그리고 공통으로 35시간 이상의 PM 교육이수가 필요하다..

비용은?
PMI 비회원인 경우 $555
PMI 유료 회원인 경우 $405불 (회원비: $129) 이니, 유료회원이 싸네..

PMP 취득 이후에도 자격 유지를 위해서는 3년 주기로 60 교육 학점 (PDU)를 채워야 한다네..
한번 자격증 따면 그만이 아니었네...


참고 사이트: PMI (http://www.pmi.org/)

0-1 PMBOK 5th edition + 책?

PMP 공부를 위한 수험 가이드를 한번 살펴 보았다..시중에 나와 있는 책들이 좀 됨...

• PMP Pride (원지호 저)
• PMP Pass (한동환 저)
• Headfirst PMP (제니퍼 그린, 앤드류 스텔만 저) 등등

그럼 어떤 책을 봐야하나? 음...
이 수험서들은 PMI에서 publish하는 PMOBOK Guide 를 기반으로 만들어졌기 때문에 사실 내용면에서는 큰 차이가 없지 않을 까 싶고,, 아마도 기출 문제와 해설이 약간씩 다르지 않나 싶다..

암튼 PMBOK 5th edition을 먼저 보고 가장 최근에 출판된 PMP Pride를 한번 참고해 보기로..


PMBOK 5th edition의 기본 구성은 아래와 같으며, 참고 교재인 PMP Pride도 동일하게 구성되어 있다... 이제 본격적으로 각 챕터별로 공부를 시작해 봐야 겠다.

1. 서론
2. 조직의 영향력과 프로젝트 생애주기
3. 프로젝트 관리 프로세스
4. 프로젝트 통합 관리
5. 프로젝트 범위 관리
6. 프로젝트 일정 관리
7. 프로젝트 원가 관리
8. 프로젝트 품질 관리
9. 프로젝트 인적 자원 관리
10. 프로젝트 의사 소통 관리
11. 프로젝트 리스크 관리 
12. 프로젝트 조달 관리
13. 프로젝트 이해관계자 관리