프로젝트 관리 표준서 | 프로젝트 관리 원칙 (12)

 

1. 스튜어드십(Stewardship): 성실하고 존중하며 배려하는 관리자가 되어야 한다.

 1) 개요: 관리자는 내부 및 외부 지침을 준수하면서 청렴성, 관심 및 신뢰성을 가지고 활동을 수행하기위해 책임감 있게 행동한다. 관리자는 자신이 지원하는 프로젝트의 재무적, 사회적, 환경적 영향에 대한 광범위한 헌신을 보여준다.

 2) 구성

  (1) 스튜어드십은 조직 내부 및 외부에 대한 책임을 포괄한다.

  (2) 스튜어드십에는 다음이 포함된다.

   - 청렴성

   - 관심

   - 신뢰성

   - 규정 준수

  (3) 스튜어드십의 전체적인 관점에서는 재무적, 사회적, 기술적 및 지속 가능한 환경 인식을 고려한다.

 

2. 팀(Team): 협업하는 프로젝트 팀 환경을 조성한다.

 1) 개요: 프로젝트 팀은 다양한 기술, 지식 및 경험을 갖춘 개인으로 구성되어 있다. 협력적으로 작업하는 프로젝트 팀은 독자적으로 작업하는 개인보다 공유 목표를 더 효과적이고 효율적으로 달성할 수 있다.

 2) 구성

  (1) 프로젝트는 프로젝트 팀에서 인도한다.

  (2) 프로젝트 팀은 조직적, 전문적 문화와 지침 내에서 업무를 수행하며, 종종 자체적인 "현지" 문화를 구축한다.

  (3) 협력적 프로젝트 팀 환경은 아래와 같은 것을 촉진한다.

   - 다른 조직 문화 및 지침과 연계

   - 개인 및 팀의 학습 및 개발

   - 원하는 성과를 인도하기 위한 최적의 기여

 

3. 이해관계자(Stakeholder): 이해관계자와 효과적으로 소통한다.

 1) 개요: 프로젝트 성공 및 고객 만족도에 기여하는 데 필요한 수준으로 선제적으로 이해관계자를 참여시킨다.

 2) 구성

  (1) 이해관계자는 프로젝트, 성과 및 결과에 영향을 미친다.

  (2) 프로젝트 팀은 참여를 통해 다른 이해관계자에게 서비스를 제공한다.

  (3) 이해관계자 참여는 가치 인도를 선제적으로 발전시킨다.

 

4. 가치(Value): 가치에 중점을 둔다.

 1) 개요: 비즈니스 목표 및 의도한 편익과 가치에 맞게 프로젝트 연계를 지속적으로 평가 및 조정한다.

 2) 구성

  (1) 가치는 프로젝트 성공의 궁극적인 지표이다.

  (2) 가치는 프로젝트 전반에 걸쳐 프로젝트 종료 시 또는 프로젝트 완료 후에 실현될 수 있다.

  (3) 가치와 가치에 기여하는 편익은 정량적 및/또는 정성적 용어로 정의될 수 있다.

  (4) 성과에 집중하면 프로젝트 팀이 가치 창출로 이어지는 의도한 편익을 지원할 수 있다.

  (5) 프로젝트 팀은 진행 상황을 평가하고 예상 가치를 극대화하도록 조정한다.

 

5. 시스템 사고(System Thinking): 시스템 상호 작용을 인식하고 평가 및 대응한다.

 1) 개요: 프로젝트 성과에 긍정적인 영향을 미치기 위해 총체적인 방법으로 프로젝트 내부 및 주변의 동적 상황을 인식하고 평가하고 대응한다.

 2) 구성

  (1) 프로젝트는 상호 의존적이고 상호 작용하는 활동 영역의 시스템이다.

  (2) 시스템 사고는 프로젝트 각 부분이 서로 간에, 그리고 외부 시스템과 어떻게 상호 작용하는지에 대한 전체적인 관점을 수반한다.

  (3) 시스템은 계속해서 변하므로 내부 및 외부 조건에 지속적으로 주의를 기울여야 한다.

  (4) 시스템 상호 작용에 반응함으로써 프로젝트 팀은 긍정적인 성과를 활용할 수 있다.

 

6. 리더십(Leadership): 리더십 행동을 보여준다.

 1) 개요: 개인 및 팀의 요구를 지원하기 위해 리더십 행동을 보여주고 조정한다.

 2) 구성

  (1) 효과적인 리더십은 프로젝트 성공을 촉진하고 긍정적인 프로젝트 성과에 기여한다.

  (2) 어떤 프로젝트 팀 구성원이라도 리더십 행동을 보여줄 수 있다.

  (3) 리더십은 권위와 다르다.

  (4) 효과적인 리더는 상황에 맞게 자신의 스타일을 조정한다.

  (5) 효과적인 리더는 프로젝트 팀원 간의 동기부여의 차이를 인식한다.

  (6) 리더들은 정직성, 청렴성 및 윤리적 행동 영역에서 바람직한 행동을 보인다.

 

7. 조정(Tailoring): 상황에 맞게 조정한다.

 1) 개요: 가치를 극대화하고, 비용을 관리하고 속도를 개선하는 동시에 추구하는 성과를 달성하기에 "충분한" 프로세스를 사용하여 프로젝트, 목표, 이해관계자, 거버넌스 및 환경의 맥락에 기반하여 프로젝트 개발 방식을 설계한다.

 2) 구성

  (1) 각 프로젝트는 고유하다.

  (2) 프로젝트의 성공은 프로젝트의 고유한 맥락에 적응하며, 원하는 성과를 내기에 가장 적절한 방법을 결정하는 데 달려있다.

  (3) 접근 방식 조정은 반복적이므로 프로젝트 전반에 걸쳐 지속되는 프로세스이다.

 

8. 품질(Quality): 프로세스 및 결과물에 품질을 확보한다.

 1) 개요: 프로젝트 목표를 충족하고 관련 이해관계자가 제시하는 니즈, 사용 및 인수 요구사항에 부합하는 인도물을 생산하는 품질에 계속해서 초점을 맞춘다.

 2) 구성

  (1) 프로젝트 품질에는 이해관계의 기대를 충족하고 프로젝트 및 제품 요구사항을 충족하는 것이 수반된다.

  (2) 품질은 인도물의 인수 기준을 충족하는 데 중점을 둔다.

  (3) 프로젝트 품질에는 프로젝트 프로세스가 적절하고 최대한 효과적인지 확인하는 작업이 수반된다.

 

9. 복잡성(Complexity): 복잡성을 살핀다.

 1) 개요: 접근 방식 및 계획에 따라 프로젝트 팀이 프로젝트 생애주기를 성공적으로 탐색할 수 있도록 프로젝트 복잡성을 지속적으로 평가하고 탐색한다.

 2) 구성

  (1) 복잡성은 인간의 행동, 시스템 상호작용, 불확실성 및 모호성으로 인해 발생한다.

  (2) 복잡성은 프로젝트 진행 중 어떤 지점에서든 발생할 수 있다.

  (3) 복잡성은 가치, 범위, 의사소통, 이해관계자, 리스크 및 기술 혁신에 영향을 미치는 이벤트 또는 조건에 의해 발생할 수 있다.

  (4) 프로젝트 팀은 복잡성의 요소를 파악하는 데 주의를 기울이고, 복잡성의 규모나 영향을 줄이기 위해 다양한 방법을 사용할 수 있다.

 

10. 리스크(Risk): 위험 대응을 최적화한다.

 1) 개요: 프로젝트와 그 성과에 대한 긍정적인 영향을 극대화하고 부정적인 영향을 최소화하기 위해 리스크에 대한 노출, 즉 기회 및 위협을 지속적으로 평가한다.

 2) 구성

  (1) 개별적인 리스크와 전반적인 리스크가 프로젝트에 영향을 줄 수 있다.

  (2) 리스크는 긍정적(기회) 또는 부정적(위협)일 수 있다.

  (3) 리스크는 프로젝트 전반에 걸쳐 지속적으로 처리된다.

  (4) 리스크를 대하는 조직의 태도, 리스크 선호도 및 한계선은 리스크 처리 방식에 영향을 미친다.

  (5) 리스크 대응은 다음과 같아야 한다.

   - 리스크 심각성에 적합해야 한다.

   - 비용 대비 효과적이어야 한다.

   - 프로젝트 맥락 내에서 현실적이어야 한다.

   - 관련 이해관계자가 동의해야 한다.

   - 담당자가 결정되어야 한다.

 

11. 적응성과 복원력(Adaptability and Resiliency): 적응력과 유연성을 받아들인다.

 1) 개요: 조직 및 프로젝트 팀의 접근 방식에 적응성과 복원력을 구축하여 프로젝트가 변경을 수용하고, 좌절에서 회복하며, 프로젝트 작업을 발전시킬 수 있도록 지원할 수 있다.

 2) 구성

  (1) 적응성은 변화하는 조건에 대응할 수 있는 능력이다.

  (2) 복원력은 충격을 흡수하고 좌절 또는 실패로부터 신속하게 회복하는 능력이다.

  (3) 산출물보다는 성과에 중점을 두면 적응성을 촉진할 수 있다.

 

12. 변화(Change): 계획한 앞날을 달성할 수 있도록 변화할 수 있다.

 1) 개요: 현재 상태에서 프로젝트 성과에 의해 생성되는 의도된 미래 상태로 전환하는 데 필요한 새롭고 다른 행동과 프로세스의 채택 및 지속에 대비해 영향을 받는 사람들을 준비시킨다.

 2) 구성

  (1) 변화에 대한 구조적인 접근 방식은 개인, 그룹 및 조직이 현재 상태에서 미래지향적 상태로 전환하는 데 도움이 된다.

  (2) 변화는 내부 영향 또는 외부 요인에서 비롯될 수 있다.

  (3) 모든 이해관계자가 변화를 수용하는 것은 아니므로 변화를 가능하게 하는 것은 어려울 수 있다.

  (4) 짧은 시간 내에 너무 많은 변화를 시도하면 변화에 대한 피로감 및/또는 저항으로 이어질 수 있다.

  (5) 이해관계자 참여와 동기부여식 접근 방식은 변화를 채택하는 데 도움이 된다.

 

 

출처: PMP Certification ECO 문제집, ATP 주식회사 PCCA, (주)도서출판 성안

프로젝트 관리 표준서 | 가치 인도 시스템

 

* 개념 : 프로젝트 < 프로그램 < 포트폴리오

* 주요 용어

 - 인도물(Deliverable): 프로세스, 단계 또는 프로젝트를 완료하기 위해 산출해야 하는 고유하고 검증 가능한 제품, 결과.

 - 결과물(Artifact): 템플릿, 문서, 산출물 또는 프로젝트 인도물.

 - 산출물(Output): 측정 가능한 유/무형의 결과.

 - 성과(Outcome): 프로세스나 프로젝트의 최종 결과물. 성과에는 산출물과 결과물이 포함될 수 있지만 프로젝트를 통해 인도하려는 편익과 가치에 초점을 맞추면 의미가 더 넓어질 수 있다.

 - 편익(Benefit): 편익이란 재화나 서비스를 소비함으로써 얻을 수 있는 주관적 만족감을 객관적 척도인 화폐가치로 표현한 것.

 - 가치(Value): 어떤 것의 가치, 중요성 또는 유용성. 이해관계자마다 가치를 인식하는 방식이 다르다. 고객은 제품의 특정 기능 및 특징을 사용할 수 있는 능력으로 가치를 정의할 수 있다. 조직은 재무 지표(어떤 편익을 얻는 데 드는 비용보다 그 편익이 적음)에 따라 결정된 비즈니스 가치에 중점을 둘 수 있다. 사회적 가치에는 사람, 지역사회 또는 환경 그룹에 대한 기여도가 포함될 수 있다.

 

1. 가치 창출

 - 조직과 이해관계자를 위한 가치를 창출하기 위해 시스템 내에서 프로젝트가 어떻게 작동하는지 설명한다.

 - Portfolios, programs, projects, products 등 다양한 요소를 통해 가치를 창출할 수 있다.

 - 가치 전달 시스템은 정보와 피즈백이 모든 구성 요소 간에 일관되게 공유될 때 가장 효과적으로 작동한다.

2. 조직 거버넌스 시스템

 - 거버넌스가 가치 전달 시스템을 지원하는 방법을 설명한다.

 - 거버넌스 시스템은 가치 전달 시스템과 함께 작동하여 원활한 워크플로를 지원하고 문제를 관리하며 의사 결정을 지원한다.

3. 프로젝트 관련 기능

 - 프로젝트를 지원하는 기능을 식별한다.

 - 프로젝트와 관련된 기능은 한 사람 혹은 여러 사람이 수행하거나 정의한 역할로 결합한다.

4. 프로젝트 환경

 - 프로젝트와 가치 전달에 영향을 미치는 내부 및 외부 요인을 식별한다.

 - 프로젝트는 가치 전달에 다양한 영향을 주는 내부 및 외부 환경에서 수행한다.

 - 내부 및 외부 환경은 계획 및 기타 프로젝트 활동에 영향을 줄 수 있으며, 이러한 영향은 프로젝트 특성, 이해관계자 또는 프로젝트 팀에 유리하거나 불리하거나 중립적인 영향을 미친다.

5. 제품 관리 고려 사항

 - 포트폴리오, 프로그램, 프로젝트 및 제품이 관련되는 방식을 식별한다.

 

 

 

출처: PMP Certification ECO 문제집, ATP 주식회사 PCCA, (주)도서출판 성안당

프로젝트 - 정해진 기간 안에서 정교한 작업을 통해 결과와 서비스를 만들어 내는 일련의 과정
* 프로젝트 정의(TPO)
1. Temporary(일시적인)
 - 일정 상 시작과 끝이 반드시 존재한다는 의미
2. Progressivley elaborated(점진적 정교화)
 - 지속적으로 수정, 향상, 갱신, 추가되는 요소를 점진적으로 정교화하는 작업에 대한 의미
 ex) Rolling wave planning(high-level), prototype(working model, mock-up)
3. Output(산출물)
 - 서비스를 운영(Operation)하는 소프트웨어 제품(Product)을 의미

 

Tech PM - 비지니스 가치가 있는 소프트웨어를 발의하고 기획/설계/일정관리/오픈/운영까지 A-Z를 관리

소프트웨어를 통해 서비스를 제공하는 프로젝트를 발의하고 시스템을 기획/설계하는 Tech PM은 아래와 같은 일을 해야 합니다.

1. 개발자가 이해할 수 있는 수준의 요구사항 정의
2. 비지니스 상황에 맞춘 구축 우선순위 선정 판단
3. 간결하지만 명료한 문서작성 기술

비지니스 측면 가치에 대한 기획을 통해 구축된 시스템이 Product(제품)로서 안정적인 서비스를 제공하고, 고정적인 수익을 창출할 수 있는 도구가 될 수 있도록 설계해야 합니다.

 

Tech PM은 소프트웨어 기반의 회사에서 개발자와 현업이 서로 원하는 바를 얻게끔 만들어주는 역할을
책임을 가지고 헌신적으로 실천할 수 있어야 합니다.

 

PM은 이 모든 고민을 문서로 남겨 관리할 수 있어야 합니다.

* Why?

 - 상시 보고할 수 있는 준비

 - 혼재된 요구사항과 모호한 협의안, 방향을 정하는 의사결정 점검

* 문서 히스토리
* 메뉴구조도
* 요구사항 정의서 2부 (현업, 개발사)
* 플로우차트(task, user, I.A)
* 와이어프레임
* 화면정의서
* 기능명세서
* ERD(다이어그램)

+ Recent posts