지난 여름 프로젝트리서치와 연세대학교 인턴십 2014 프로젝트로 진행했던 “스타트업을 위한 프로젝트 관리 가이드” 및 Visual PMO for Startup 공개합니다. 연세대학교 경영학 전정빈 군이 미국 프로젝트 관리 자격증인 PMBOK 기반의 CAPM 자격증을 취득하고 및 삼성전자에서 수행하는 ISO21500 기반의 Visual PM 워크샵의 내용을 바탕으로 작성되었으며, 다음과 같은 특징이 있습니다

목적

스타트업/벤처기업의 제품/서비스 개발시 필요한 기법을 글로벌 PM 표준 프로세스 기반의 가이드와 오픈소스를 활용한 프로젝트관리시스템 (Visual PMO for Startup)에 대한 노하우를 제공하여, 올바른 프로젝트 관리 문화의 정착 및 진정한 글로벌 경쟁력을 갖추도록 함

특징

1. 글로벌 표준 PM 체계인 ISO21500과 PMBOK을 흐름도 기준으로 쉽게 도식화
2. 각각의 프로세스 설명과 더불어 한글 템플릿/양식을 함께 제공하여 쉽게 업무 적용 가능
3. GitHub를 프로젝트 관리 도구로 활용하여 Visual PMO for Startup 킷 활용 가이드 제공
4. 삼성전자 Visual PM  및 KT IPCC 프로젝트 PMO 도구로 사용했던 Visual PMO 노하우 제공

열람 및 다운로드 

Visual PMO for Startup : http://www.visualpmo.com

 

국내 스타트업 멘토링 프로그램이 초기 기획에 초점이 맞추어져 있다면, 본 가이드는 실제 제품개발/서비스개발시에 어떻게 해야하는지에 대한 가이드를 제공하는 것에 중점이 맞추어져 있습니다. 본 가이드는 http://www.visualpmo.com 에서 열람 및 다운로드 받으실 수 있습니다.

본 가이드 및 노하우를 적용하여 성공한 스타트업이 많이 생겼으면 하는 바램입니다. 4년 전부터 생각하고 있던 것을 이제서야 공개 하네요.  열정과 더불어 글로벌 프로세스로 글로벌 경쟁력을 갖춘 스타트업이 많이 나왔으면 좋겠습니다

PMI 에서 아주 좋은 공공/정부기관의 프로젝트관리 혹은 사업관리에 필요한 Best Practice 가이드인 “Challenges and Best Practices of Managing Government Projects and Programs”  이 출간되어서 요약 내용을 공유하고자 합니다. 조지워싱턴대학에 계신 한국인 곽영훈 교수님께서 발표하신 연구결과인데요, PMI 로부터 우수 사례로 선정되어 출간이 되었습니다.  정부/공공기관 PM/PMO 께서는 참고하시면 좋은 자료 같습니다.

많은 정부 프로젝트나 프로그램들이 프로젝트의 목적을 충족하지 못하고, 납세자의 세금을 낭비하면서 연장되고 있거나 혹은 계획이나 구현 중간에 종료됩니다. 정부의 프로그램과 프로그램은 국가 성장을 목표로 하는 것이나 시님의 복지 수준을 높이기 위해 투자되고 있습니다. 매우 큰 규모의 정부 프로젝트는 기간 및 교통분야, 정보통신와 국방분야와 같은 3개의 주요 부문에 대해서 기획/조정되고 있으며, 본 연구는 정부 프로젝트가 실패하는 이유와 어떻게하면 프로젝트 성공율을 높일 수 있는 방법을 제시하고 있습니다. 

미국, 영국 및 호주에서 수행된 정부 프로젝트를 분석하여, 비영리 목적, 정지적 상황 변화에 민감, PM표준프로세스 준수, 대규모 메가 프로젝트,  긴 생애주기 및 다계층 이해관계자 프로젝트 의 유형으로 구분하였으며, 이러한 정부 프로젝트의 유형별 성격이 갖는 꾸준한 문제 발생 원인과 대응 특성을 살펴보고자 합니다.

이 연구는 기술적, 법률적, 정치적, 그리고 사회적 요인이 복잡하게 얽히고 설켜있는 아래 유형의 프로젝트에 직면한 분들에게 추천합니다.

• 제품의 내구성, 기능성 및 유연성이 필요로한 현재와 미래에 직면한 상황
• 민간협력사업 (PPP, Public-private partnerships)이 고려되있는 상황
• 프로그램을 보다 관리 가능한 프로젝트 들로 쪼개야 하는 상황
• 사업 커뮤니티를 컨설팅 해야하는 상황

“정부 프로젝트, 프로그램을 위한 도전과 모범 사례 (Challenges and Best Practices of Managing Government Projects and Programs )” 는 실무자, 연구자 및 정책 입안자에게 기초적인 가이드를 제시할 뿐만 아니라 정부가 국민들에게 가져다 줄 혜택을 현실화하기 위한 중요한 기반을 제공합니다.

총 39개 정부기관을 조사한 결과인데요. 미국 18개, 호주 15개 및 영국 6개 정부 프로젝트를 조사하였고, 단일 프로젝트 평균 13조원, 기간 평균 약 9년 정도의 프로젝트 유형을 분류하여, 유형별로 중점 점검하여야할 사항을 정리해 놓은 모범사례집이라 좋은 참고가 될 것 입니다. 정부 발주 프로젝트/프로그램은 위와 같은 ▲ 비영리 목적 ▲ 정지적 상황 변화에 민감 ▲ PM표준프로세스 준수, ▲ 대규모 메가 프로젝트, ▲ 긴 생애주기 및 ▲ 다계층 이해관계자 프로젝트 로 총 6개의 유형으로 구분될 수 있으며, 각각의 프로젝트/프로그램 속성별로 중점적으로 관리해야하는 항목이 다릅니다.

1. 비영리 목적 

1. 사업 계획에 비영리 명확화
2. 현실 가능한 목표 제시
3. 프로젝트 효과에 대한 측정방법 상호 동의
4. 전략적 목표 도달시 프로젝트 영향력 평가

2. 정치적 상황 변화에 민감

1. 기획 의도가 현재의 법 준수 여부 협의
2. 프로젝트의 경제적 이해관계 협의
3. 기관의 전략에 부합하는지 확인
4. 적정한 민간협력사업(PPP) 고려
5. 민간협력사업(PPP)의 타당성 명확화
6. 권위있는 프로젝트 관리자

3. PM 프로세스 표준 이수 

1. 정부 PM 프레임워크/프로세스 구축 및 준수
2. 민간기업의 교훈 기반의 기획과 예측 실행
3. 공식적인 리스크 관리 프로세스 준수
4. 공식적인 감시 및 변경 통제 프로세스 준수
5. 프로젝트 통합 관제 프레임워크 구축 및 준수

4. 대규모 메가 프로젝트 

1. 통합 마스터 일정과 예산 기준선 개발
2. 연간 단위 기반 예산 계획 구분 수립
3. 위험도 높은 신규 개발시 기존 입증된 솔루션 적용
4. 철저한 프로젝트 관리를 위한 프로그램을 관리 가능한 프로젝트 단위로 분할
5. 비상 계획 수립 및 리스크 상시 감시
6. 롱텀 프로젝트의 교육 훈련 식별

5. 긴 생애주기 제품 

1. 완벽한 설계/디자인과 품질 관리 프로세스 명확화
2. 비승인(최첨단) 기술 이용성 최소화

6. 다계층의 이해관계자 프로젝트 유형

1. 프로젝트 팀에 조달 책임 위임
2. 연관시 사업 의사소통 조언 받음
3. 프로젝트의 운영 시스템과 협조
4. 여러 기관의 프로젝트를 위한 중계협의체 구축
5. 조달책임자와 효과적인 협업 및 조달 절차 수행

회사의 경쟁력을 높이기 위해서는 올바른 역량관리 프로그램이 필요한 PMI의 “The competitive advantage of effective talent management” 보고서를 요약 번역 해 보았습니다.

이제 기업 환경은 글로벌 경쟁 시대로 도입하고 있습니다. 적은 자원으로 보다 많은 업무 처리를 요하는 환경과, 급변하는 글로벌 시장에서 산업간의 포트폴리오와 프로그램이 조정되는 상황에서, 각 기업은 현실적인 실현가능한 혁신이 필요로 되고 있습니다. 과거 습관적 방식으로의 성장에서는 한계를 느낀거죠.

이에 따라 회사의 비전에 맞는 전략/전술을 재정비 하고, 이에 따른 프로젝트, 프로그램, 포트폴리오를 재 구성하여, 이에 맞는 조직체계와 아울러 프로젝트 팀과 구성원들의 역량관리 모델을 개발하여 꾸준히 측정하고 개선해야함을 전파하고 있습니다. 이랬을 경우 일반적인 기업보다 약 2배에 달하는 성과를 내기 때문입니다.

향후 5년 동안 6천6백조 규모의 프로젝트 (프로그램과 포트폴리오 포함) 사업이 글로벌하게 이뤄지고, 이것을 위해 약 1천6백만명의 신규 역량있는 PM 자원들이 필요합니다. CEO가 인식하는 기업의 당면과제 1순위기 이러한 급변하는 기업환경에서 조직이 높은 성과를 내는데 필요한 인적자원이라는 것을 인지하고 있고, 이미 80%에 육박하는 글로벌 기업은 이러한 변화관리를 점차적으로 시행하고 있고, 이미 23%는 효과를 보고 있습니다.

기업의 전략에 따른 포트폴리오, 프로그램 및 프로젝트를 재정비하고, 이에 필요한 역량강화 프로그램을 돌리는 이유는 제품이나 서비스의 품질을 고도화시키면서, 혁신과 효율화의 성공을 위해서 입니다. 단위 업무들이 기업의 Benefit 및 Value를 높일 수 있도록 구성되어야하며, 이것들을 모두 성공 시켜야한다는 이야기죠.

이러한 프로젝트 역량 관리를 체계적으로 이행하였을 경우 프로젝트 성공율이 14% 향상 및 프로젝트리스크 약 24% 감소 효과 때문에 그렇습니다.  회사 매출 규모가 1천억원 대라면 140억 개선효과 혹은 240억 절감효과 때문에, 체계적인 프로젝트 역량 관리 프로그램의 도입이 필요한거죠.

아울러 회사의 가치를 높임과 더불어 임직원들에게도 효과가 있습니다.  회사의 목표에 따른 조직 목표가 부합되면서, 이에 맞는 높은 성과를 객관적으로 요구합니다. 따라서 도전의식이 고취되는 분위기가 생기죠.  아울러 신규PM > 전문PM > 고급PM > C-Level 에 맞는 경력 관리 프로그램을 통해 성공적인 자원관리와 성과 효과를 개선시킬 수 있습니다. 이를 통해 우수한 역량을 가진 직원을 중요도가 높은 프로젝트의 자발적으로 참여시킬 수 있죠.  아울러 원칙중심의 투명한 의사소통으로 상하를 뛰어넘는 수평적인 커뮤니케이션이 가능하게 됩니다.

결과적으로 “기업이 꾸준히 성장해야 함”은 영원한 과제이고, 이를 위해서는 프로젝트 기반의 역량 및 성과 모델을 가져가야하며, 이는 성공율 14% 향상, 아울러 회사의 가치 증진은 물론 참여한 임직원의 만족도는 높이는 WIN-WIN 필수불가결한 정책입니다.

프로젝트를 하다보면 “프로젝트가 산으로 간다”는 표현을 쓰는 경우가 있습니다. 최초에 가야할 목적지를 정해놓지않고, 출발먼저 하다가 중감 점검을 하지 않은체 최종 위치만 확인하는 거죠. 이를 좀 더 표준 프로세스에 가깝게 분석을 해보면 크게 핵심이해관계자의 요구사항을 WBS로 매핑하여 관리하고, 주기적으로 소통해야하는데 그것을 못하는 거죠. 이때 소통은 대외용과 대내용이 있을텐데, 대외용은 철저하게 비즈니스용어, 즉 요구사항을 바탕으로 이야기가 되어야하고, 대내용은 철저하게 WBS를 기준으로만 이야기 되어야 합니다. 그래야지 혼돈이 없어지죠.

저희 프로젝트리서치가 제안하는 방법은 1) Global Standard를 바탕으로 올바르게 일해야 한다. 2) Visualization을 바탕으로 투명하게 일해야 한다. 3) Focus 철저히 업무에만 집중해서 최대의 효과를 도출해야 한다입니다. 어찌보면 이번에 500억 규모의 13개 수행사 갑을병정이 모여서 20개의 프로젝트/프로덕트로 구성되어 1년간 추진된  KT 차세대 IPCC 프로젝트가 일정지연 없이 성공적으로 끝낸 것도 근간 PMIS인 Visual PMO가 여기에 철학을 두었기 때문입니다.

프로젝트 관리는 글로벌 표준에 입각하여 PMBOK 혹은 ISO21500 기법으로 회사에 맞게 테일러링하면 문제가 없을 것이고, Visualization은 저희가 제공하는 Hybrid Agile 방식의 Visual PM/PMO 기법을 이용하면 될텐데, 문제는 앞단입니다. 즉 비즈니스의 요구사항을 프로젝트의 스펙(WBS포함)으로 명확히 레벨다운 하는 기법이 필요한데, 이러한 비즈니스 분석 역량에 대한 검증을 PMI에서 PMI-PBA (Professional Business Analysis)라는 자격으로 인증체계를 출시하였습니다.

PMI에서는 프로젝트를 투명하게 관리하도록하는 글로벌표준 체계를 개발하였습니다. 프로젝트 > 프로그램 > 포트폴리오 및 조직관리에 이르는 수직체계와 리스크, 일정, EVM기성(원가), 역량, WBS 등 많은 표준가이드를 개발하였습니다. 어찌보면 담당자는 이들 가이드 표준만 마스터링하고, 자신의 조직에 맞게 테일러링하면 되죠. 아주 합리적이고 투명하게요.

이의 접근 방식은 조직적으로 개인적으로 쌍끌이로 접근해야 합니다. 예전에 6Sigma 가 6시그마 회사 인증에 대해 그린벨트, 블랙벨트제도를 개인역량에 맞추어 확산 것과 같이요. 그래야 개인적으로도 동기부여가 되니까요. PMI 의 대표적인 PMP 자격증 (Project Management Professional) 자격증도 이런 맥락입니다. 전세계적으로 PMP 자격증 보유자가 그렇지 않은 동료보다 평균 15% 임금이 높다는 통계가 이를 보완해주고 있죠. (아쉽게도 국내엔 자격증 수당이라는 제도가 있는데, 여러이유로 바람직하지 않은 모습 같습니다.)

좀 특화된 자격증 체계가 일정 관리 전문가 PMI-SP (Schedule Professional), 리스크 관리에 특화된 RMI-RMP (Risk Management Professional), 스크럼/애자일에 특화된 PMI-ACP (Agile Certified Professioal)외에 이번에 PMI에서 비즈니스 분석/설계 기법에 특화된 PMI-PBA (Professional Business Analysis) 자격증을 내 놓으면서, 가이드서를 낸 것이 있는데, 여기에는 비즈니스 분석가가 갖춰야할 단계별 역량에 대한 정의가 잘 되어있어 이를 소개하고자 합니다.

1단계 : 필요 정의  >  2단계: 기획  >  3단계 : 분석 > 4단계 : 추적 및 모니터링 > 5단계 : 평가의 순으로 이뤄지는데, 각 단계별 체크리스트/필요지식 가이드는 아래와 같습니다.

단계#1. 필요 정의 

1. 솔루션 범위 정의 혹은 비즈니스 케이스 작성을 위한 입력물을 제공하기 위한 문제와 기회 분석 기법을 사용한 비즈니스 문제 혹은 기회 정의
2. 가치 부여에 기여하기 위한 평가 도구 및 기법을 사용하여 다양한 소스로부터 정보의 수집 및 분석
3. 조직의 목표와 목적에 맞는 제품을 배치하기 위해, 비즈니스 니즈 및 솔루션 범위를 명확하게 정의는 프로젝트의 목표과 목적 개발을 위한 협업
4. 대표화된 정보화 도출을 위해 적합한 단체 참여 선정을 하기위한 목표와 목적, 요구사항을 리뷰를 위한 이해관계자 식별
5. 요구사항의 우선순위에 기반한 베이스라인을 수립하여, 이해관계자의 가치를 제품에 적용하기 위한 절차

단계#2. 기획 

1. 비즈니스 분석 활동 정의를 위한 비즈니스 정의, 프로젝트 목표, 목적에 대한 리뷰 이행
2. 요구사항의 모니터 및 검증 추적을 위한 도구와 기법이 포함된 요구추적 전략 수립
3. 인도물 기대치가 포함된 로드맵 수립을 위해 이해관계자 식별, 역할과 책임, 소통절차, 도출기법, 분석, 문서화, 관리 및 요구승인 절차가 포함된 요구사항 관리 계획서 수립
4. 부적절한 사항의 변경을 위한 표준 절차 수립을 위해 소통요청 채널 식별에 의한 요구 변경 관리 기법 선정 및 변경 처리  프로세스
5. 요구추적 및 형상관리 표준 수립을 위해 문서화 관리 도구 및 기법을 이용한 문서 관리 기법 선정
6. 요구사항을 만족하는 솔루션인지, 이해관계자와 협업하여 사업매트릭스와 인수조건을 정의

단계#3. 분석 

1. 자세한 요구사항 도출을 위해 개인/그룹 선출기법을 이용하여 요구사항 도출/식별
2. 제품의 옵션과 성능을 식별하고 명확하게 기술하기 위해 의존분석, 인터페이스 분석 및 데이터/프로세스 모델링을 포함한 요구사항 분석, 분할과 도출
3. 요구사항 수용, 연기 및 거절을 결정하기 위해 의사결정 및 측정 기법을 사용한 제품의 옵션과 성능을 평가
4. 요구사항 베이스라인 수립을 위한 우선순위, 의존분석, 의사결정 도구와 기법을 이용하여 범위, 일정, 원가와 자원제약간의 밸런스를 맞추어 요구사항의 수용/전가를 조정
5. 이해관계자 협조와 승인 촉진하기 위해 의사결정 기법을 활용하여 요구사항 베이스라인을 공식 인가 받음
6. 적절한 개발 실행과 측정을 위한 요구사항을 소통하기 위해 Use Case, User Story 등과 같은 데이터, 인터페이스 상세 내용을 요구사항 스펙으로 작성
7. 요구사항의 완결성, 목표, 목적 그리고 가치를 제공하는지 확신을 주기위해 문서 리뷰, 프로토타입, 데모와 같이 요구사항 검증 도구 및 기법 사용
8. 솔루션이 요구사항을 만족하는지 평가하기 위한 스펙 상세 매트릭스 및 인수조건을 명확시키며 구체화함

단계#4. 추적 및 모니터링 

1. 요구사항이 제대로 인도되었는지 확신하기 위한 요구사항의 상태, 소스와 의존관계를 요구사항추적매트릭스 도구와 기법으로 추적
2. 요구사항의 구체화, 문서화 및 시험절차와 같은 구체화가 각 라이프사이클 과정마다 수행되고, 리뷰되고, 승인되는 절차가 전체 라이프사이클 동안 모니터링 되어야 함
3. 요구사항이 종료되는 과정을 추적하기 위해 라이프사이클 전체기간 동안 적정한 이해관계자와 의사소통되고 변경 사항의 추적 과정이 제대로 갱신
4. 요구사항에 관련된 이슈와 충돌, 리스크와 일반적 상황이 제대로 관리되기 위해 PM과 요구사항을 의사소통하고, 다른 이해관계자와 의사소통을 올바로 이행
5. 요구사항과 적용이 통합적으로 관리하기 위한 요구사항 베이스라인에 기반하여 변경 관리진행을 영향분석, 독립성, 영향력 변경을 올바로 추적

단계#5. 평가 

1. 솔루션이 요구사항을 만족하는지 결정하기 위한 요인수조건에 대한 검수 결과, 보고서 작성
2. 솔루션 범위, 요구사항 및 개발된 솔루션의 갭이 없다는 확신을 주기위해 차이분석 및 품즐보증의 검증 수행
3. 적용절차 수립을 위해 의사결정 기법에 기반한 이해관계자 승인 획득
4. 비즈니스 케이스와 가치 평가에 대해 측정 및 적용 방안 실행

비즈니스 분석가가 Master 해야하는 가이드서가 11권이 있는데. 저도 이중 몇 권을 가지고 있는데요. Software Req 부분이 있어서 ICT 특화된 거라 보실 수 있는데, 그것 보다는 보이지않는영역 (소프트웨어,프로세스)를 구조화하고 명세화하는 가시적인 도구와 기법이라고 이해하시면 될 것 같습니다.

기존의 IIBA와의 차이점은 IIBA 및 BABOK에서 제시하는 기법은 오로지 Business 분석에만 Focus를 둔다면, PMI에서 요구하는 방식은 비즈니스 요구를 명세화한 후 어떻게 이를 프로젝트와 연계하여 추적하고 관리할 것인지까지 확대된 보다 실용적인 방법을 요구하지 않나 싶습니다.

한국 프로젝트 환경은 여지껏 프로젝트 관리에 Focus화 된 경우가 없지 않고,  1만여 PMP 자격증 보유자가 있는 작지 않은 국가 규모로 올라가있음을 상기할때,  이러한 Business와 Project 사이의 일종의 매개/통역/꿀벌과 같은 역할의 중요성과 이해관계자 관리의 특화 버번으로 생각하고, 대비하여 실행하시면 좋을 것 같습니다.

프로젝트리서치(주)의 대표 훈련 프로그램인 Hybrid Agile 기법인 Visual PM 워크샵 프로그램을 소개하고자 합니다.

기업 환경은 날이 갈수록 제품 혹은 서비스의 기획 > 생산 > 운영까지 책임지는 라이프 사이클까지 책임져야 하고, 보다 작은 자원으로 최대의 효과와 효율을 이끌어내기 위해 다각적인 노력을 기울이고 있습니다. PMI 표준 용어로는 Project, Program 및 Portfolio에 이르는 영역까지 조직의 역량 관리를 포함한 조직관리체계 OPM3까지 어울러진 PMO 체계를 갖추도록 노력하는 것이죠.

이러한 Business hierarchy를 유지하면서 조직의 Agility를  “지속적으로 개선” 시켰을 때 가업가치는 33% 향상을 가져오죠. 부가적으로 사업 리스크 14% 감소 및 직접비 7% 절감 효과를 볼 수 있습니다. 그렇지 못한 조직에 대비하여 거의 2배나 성과 차이를 낼 수 있는 거죠.

15년간의 ICT 기반의 프로젝트 경험과, 4년여의 삼성전자 및 삼성SDS 에서의 코칭 훈련 프로그램 (Agile & Visual PM), 아울러 500억 규모 KT 프로젝트를  성공적으로 이끌어낸 PMO 솔루션 (Visual PMO) 으로, 실무 + 이론 + 컨설팅에 기반을 두어 (1) 글로벌 표준 기반, (2) 이론이 아닌 실제 시뮬레이션 게임 기법에 의한 실습형 체화 프로그램, (3) 명쾌하게 업무를 Visualization 시키면서 커뮤니케이션할 수 있는 코칭 훈련 이 융합된 Visual PM 워크숍 프로그램을 대중화 확대하고자 합니다.

급변하는 시대에  빠르고 효율적이면서 탄력적으로 프로젝트 업무를 추진하기 위해서는 Waterfall 기반의 안정성과, Agile 기반의 민첩성으로 중무장해야 합니다. 순수한 Waterfall 방식으로는 급변하는 프로젝트 환경에 대응할 수 없고, 반대로 순수한 Agile 방식으로는 체계적이고 절차적이어야 하는 숲을 바라보면서 나무를 재단해야하는 단계별 리뷰를 체계적으로 할 수 없기 때문에, 이의 장점만 취하면서 산업에서 Best Practice로 검증된 Hybrid Agile 기반으로 프로젝트를 리드할 환경이 구성되어야 합니다.  이렇게 되어야지만 HW와 SW 아울러 Infra까지의 융복합 시대를 발 빠르게 대처할 수 있습니다. 아울러 표준 모델로 접근해야 하는데 이를 위해서 SAFe (Scaled Agile Framework) 모델과 ISO 21500 ( PMBOK )을 유기적으로 연계시켜 Global Process compliant까지 확보해야 향후 글로벌 진출하더라도 혼돈 없이 일관성 있는 업무 추진이 가능하게 됩니다.

사업전략 (포트폴리오), 사업 관리 (프로그램 및 프로젝트 관리), 아울러 사업 운영 (오퍼레이션 및 ITSM) , 그리고 이를 아우르는 인문학 기반의 소통 훈련 프로그램이 종합적으로 단절되지 않고 일관성 있게 Hierarchy 를 구성하고, 프로젝트 리더 및 매니저, 팀장은 이 틀 안에서 프로젝트를 기획하고 추진하고 운영해야 “올바른” 업무 체계, 일에만 집중할 수 있는 업무 체계를 가꾸면서 “지속적인 성장”을 유도할 수 있는 것입니다. 이를 위하여 프로젝트리서치(주)에서는 종합적인 코칭 훈련 프로램을 제공합니다.

이미 저희는 4년간의 훈련 프로그램 테일러링으로 프로그램이 단단해졌고, 2013년도에는 삼성전자에서 3연속 강의 평가 100점을 받기도 하였습니다. 이는 기존의 이론/자격증 위조의 교육훈련이 아닌 실무 업무에 바로 적용하여 사용할 수 있도록 갖춰진 시뮬레이션 게임 체험 기반 워크숍 프로그램으로 스스로 부족한 부분을 깨닫고, 올바르게 보완/개선할 수 있는 역량을 스스로 강화하게끔 구성이 되어있지 않나 싶습니다. 장기적으로 In-House 사내 전문 컨설턴트를 양성하여 조직의 지속적 성장의 Seed가 되도록 하는 목적으로 본 커리큘럼이 구성된 거죠.

저희의 훈련 프로그램은 숲을 조망하면서 나무를 다듬는 방법을 제시하고 있으며, 글로벌 표준 기반으로 이론이 아닌 시뮬레이션 게임 기법으로 직접 체화하면서 체감할 수 있게 끔 구성되어 있습니다. 워크숍 이수 후 이분들이 직접 프로젝트를 리드할 수 있도록 전파교육자료, 템플릿, 체크리스트를 제공하여 직접 인하우스 컨설턴트 혹은 리더로서 프로젝트를 리드할 수 있도록 구성이 되어 있습니다.

프로젝트를 하면서 가장 혼돈이 많은 커뮤니케이션을 Visulization 하여 가시적으로 누락 없이, 일에만 집중할 수 있는 소통하는 Visual Communication을 유도하여 단일 프로젝트 관리 체계인 Hybrid Agile 방식의 Visual PM 프로그램뿐만 아니라, 수백억 규모의 수백 명 수행사와 팀원들이 하나의 일관성 있는 Project Dashboard를 보면서 멀티 프로젝트를 수행할 수 있도록 하는  Jira & Confluence 엔진 기반 혹은 Codebeamer 엔진 기반의 Visual PMO 솔루션/컨설팅의 경험으로 Best Practice 최적화된 기법을 제공하여, 팀원을 포함하여 임직원, 다양한 이해관계자까지 두루두루 만족시킬 수 있는 실사구시 기법을 제공합니다. 글로벌 표준 기법이다 보니 다국어 환경에서 원활하게 제공해야 하고, 훈련 프로그램 역시 한글과 영어 기반 프로그램을 모두 제공하고 있습니다.

SME 전문가로 똘똘 뭉쳐있는 작지만 강한 회사로, 지속적인 성장을 위해 “한국의 글로벌 수준 이상으로 올바르게 일하는 문화”를 만들고 확산하기 위해 노력하고 있습니다. 자매회사인 아키텍트그룹과 파트너사인 세임페이지, 올빛, PMPcafe/PMInside, TalkIT.tv,위키북스 출판사 모두 뜻을 함께 하며 서로 돕는 작은 물결이지만 큰 파도를 만들고자 합니다.

지금까지는 특정 기업을 대상으로만 활동하였으나, 2015년부터는 Hybrid Agile 대중화를 위해 Visual PM, PMO 훈련 프로그램을 널리 전파하고자 합니다.

“올바르게 일하는 문화” 초석을 다지고 “지속적으로 개선하고 성장하는 환경”을 국내의 모든 기업들이 도입하고 글로벌 수준의 경쟁력을 가지고 지속 성장할 수 있도록 많은 도움과 지원을 부탁드립니다.

Hybrid Agile 기법을 적용한 Visual PM 및  PMO 솔루션을 주축으로 프로젝트리서치(주) 법인 설립 후 2년이 지났습니다. 

Waterfall 과 Agile을 결합시킨 Hybrid Agile이 접목된 Visual PM 워크숍은 삼성전자 리더분들을 대상으로, Visual PMO 솔루션은 KT 차세대 프로젝트에서 성공적으로 런칭을 검증 받았습니다. Visual PM은 삼성전자내 3연속 강의평가 100점을, Visual PMO는 KT 차세대 IPCC 프로젝트에 적용되어 가시적 소통 기준선 역할을 해주어 프로젝트 마감일을 준수하였습니다. 지난 4년간은 특정 기업을 대상으로만 코칭하였으나,  “올바르게 일하는 문화” 초석을 다지고 “지속적으로 개선하고 성장하는 환경”을 국내의 모든 기업들이 도입하고 글로벌 수준의 경쟁력을 가지고 지속 성장할 수 있도록 하는 바램으로 2015년 공개세미나를 개최합니다시작합니다.

1부는 Hybrid Agile & Agility로써 왜 지속적 성장을 위한 경영환경으로서의 Agility 문화의 필요성과 당위성을 설명드립니다. 이는 글로벌 표준인 SAFe 3.0 (Scaled Agile Framework) 모델과 이를 PMI의 Project, Program, Portfolio 아울러 OPM3과 연계되는 Talent 관리의 중요성과 이의 관제센터가 되는 PMO의 연관성을 설명드리면서, Agile & Agility 도입에 필요한 체크리스트를 표준에 입각하여 정리해 드립니다.  

2부는 국내 콜센터 솔루션의 분야전문가이시고 KT PMO 아키텍트 담당이셨던 두봉수 부장님께는 어떻게 도입하고 적용하여 성공하였는지에 대한 노하우를 직접 전수 받으시는 기회와, 회사의 성공적인 Hybrid Agile 추진을 위한 인적 네트워크를 갖는 시간이 되었으면 하는 바램입니다. 아울러 저희 프로젝트리서치(주)의 강남 강의실(파트너 세임페이지)개소식도 겸하는 것이니 만큼 내방해 주셔서 PM/PMO 정보 나누시면 좋을 것 같습니다.  

흔히 이슈트래킹으로 사용하고 있는 Atlassian의 Jira, Confluence (자매회사인 아키텍트그룹) 의 콜라보를 통해 프로젝트 통합 관리 체계로 업그레이드된 Hybrid Agile (Visual PMO)로 어떻게 거버넌스, 일일/주간회고, RFP > 상세설계 > 단위시험 > 통합시험 > 인수시험까지의 모든 과정을 요구사항추적매트릭스를 통해 구현했는지에 대한 실무적인 내용도 언급되는 자리이니, Jira 와 Confluence 를 가지고 계시면서 어떻게 프로젝트 관리로 활용할지 고민하시는 분이나 PMO거버넌스 체계 고민하시는 분, 아울러 Agile 도입에 실패하신 사례가 있으신 분, 아울러 Waterfall에 익숙한데 Agile에 대한 확신이 없으신 분께는 확실히 도움이 되실리라 장담합니다. 

신청은 온오프믹스 (여기클릭) 하시면 됩니다.  다음주에 월요일에 뵙겠습니다. 감사합니다. 

약도(네이버지도) : http://bit.ly/projectresearch-gn  (세임페이지 ; http://same-page.co.kr) 

PMBOK 표준 및  PMP 자격증 주관사이자, 전세계 최대 PM기관인 PMI 에서 출시한 2020년 까지의 PM 수요에 대한 보고서 요약 정리해보았습니다.

원문 : http://www.pmi.org/~/media/PDF/Business-Solutions/PMIProjectManagementSkillsGapReport.ashx

2020년까지 1570만개의 새로운 프로젝트 관리 (PM, Project Management) 직업이 전세계적으로 생겨날 것이며, PM 분야 전문가 들은 이러한 혜택을 보게될 것이다라는 전망을 내 놓았습니다.

특히나 제조, 서비스, 금융/보험, 오일/가스, ICT, 건설 및 기간산업을 포함한 7개의 프로젝트 속성이 매우 짙은 산업군에서 총 6.6조$ 규모의 프로젝트가 생성된다고 합니다.

미국 시장을 기준으로 매년 12% 이상의 역량있는 프로젝트 관리자가 필요하며, 2020년 기준 620만명의 PM 이 필요하다고 합니다. PMP 자격보유자는 동일 직군 대비 약 16% 정도가 급여 체계가 높으며, 이는 통산 1500여 만원 정도를 더 받는다고 합니다.  미국 기준으로는 제조 및 서비스 분야에서만 263만명이 필요한데, 특히나 헬스케어 부분의 증가율이 2010년부터 매년 평균 30% 이상 성장할 것이라고 예측하고 있습니다.

전세계적으로는 2010년도 134만명의 PM 수요가, 2020년이 되면 415만명의 PM이 필요하여 30% 이상 예측되고, 규모적으로는 5조$에서 12.5조$ 규모로 팽창할 것이라고 예측하고 있습니다. 특히나 중국, 인도가 PM 시장을 리드할 것이라고 보고 있는데, 중국이 810만명, 인도가 400만명의 PM이 필요하다고 하네요.

호주, 브라질, 캐나다, 중국, 독일, 인도, 일본, 사우디아라비아, UAE, 영국 등 주요 10여개국 기준으로 독일을 제외하고는 매년 증가가 예측되고, 인도는 60%, 중국 30%, 아랍 40% 이상의 수요가 늘어날 것이라고 예측하고 있습니다. 10개국 모두 GDP가 증가될 것이라 예측하고 있으며, 특히 중국과 인도를 주축으로 140% 이상 성장이 예상된다고 보고 하고 있습니다.

PMI 의 주옥같은 The Pulse of Profession 보고서 중 의사소통을 강조하는 보고서를 요약 해 보았습니다. ( 원문 : http://www.pmi.org/~/media/PDF/Business-Solutions/The-High-Cost-Low-Performance-The-Essential-Role-of-Communications.ashx )

기업의 구성은 “프로젝트 관리”를 필수적으로 해야하며, 프로젝트 성공은 결과적으로 비즈니스 성공으로 엮어 집니다. 글로벌 경쟁시대로 진입함에 따라 조직 전략에 따른 우선 순위 기반으로 포트폴리오, 프로그램, 프로젝트가 Alignment 되어야하고, 이를 위해 수용가능한 혁신이 필요합니다. 궁적적으로는 경제 위기에 효과적으로 대처하기 위한 효율적, 효과적 접근 방식으로 “보다 적은 자원으로, 보다 많이”라는 접근방식의 키워드가 필요한 것이죠.

프로젝트의 성공을 위해서는 투명하고 효과적인 의사소통 체계가 중요합니다. 실패한 프로젝트의 20%는 이러한 의사소통의 실패로 도래되죠.

불충분한 의사소통은 통계적으로 프로젝트 리스크 13.5% 중 절반이나 해당하는 56%가 리스크 비용으로 대두됩니다. 프로젝트 전체를 놓고 보면 7.5% 가 불충분한 의사소통으로 야기되며, 금액적으로 따지만 1조원  프로젝트규모라면 750억이 의사소통 리스크로 감내해야하는 비용이 되는 것이죠. 결코 만만한 비용이 아닙니다.

통계적으로도 의사소통이 활발하고 원활한 조직일 수록 프로젝트 성공율이 30-40% 정도 높습니다. 어찌보면 당연한 통계이죠.

프로젝트가 최초 수립한 사업 계획/목표에 도달하는 비율도 의사소통이 활발한 팀이 그렇지 못한 팀보다 약 20-30%의 성공율이 더 높습니다.

결과적으로 효율적으로 의사소통을 벌이는 프로젝트 팀/ 조직은 그렇지 않은 기업보다 최소한 5배/ 30% 이상 프로젝트 성공율이 높습니다.

또한 프로젝트의 의사소통 계획서가 수립되어 이를 제대로 이행하는 프로젝트 팀의 성공율 역시 그렇지 않은 팀보다 30% 높죠.

제대로된 의사소통 계획서는 프로젝트의 요구사항 식별, 프로젝트의 소통 내용 및 주기, 프로젝트 범위/일정/예산/품질/자원/리스크의 조율, 이해관계자/Stakeholder, 아울러 프로젝트 내부 팀웍 향상에 대해 차이를 보입니다.

기업이나 조직은 이러한 의사소통의 효율성 (적어도 30% 이상은 프로젝트 성공율을 높인다)를 인지하고, 이를 위해 1. Business 가치를 향한 의사소통 체계, 2. 이해관계자 레벨별 소통 기법 개발, 3. 프로젝트 가치를 기반으로한 의사소통 체계 및 4. Best Practice 기반의 의사소통 실무 체계 적용 및 활용/개선을 꾸준하게 인지하고 노력해야 합니다.

정부/공공 프로젝트에서 Visual PMO 사업 도입이 결정되었습니다. 이를 기념하기 위해서 프로젝트리서치(주)의 대표적인 솔루션인 Visual PMO 솔루션을 약식 소개드립니다. 

회사의 프로젝트 관리 체계를 고도화를 위해서는 PM코칭 프로그램과 PMO 솔루션 프로그램 두가지가 쌍끌이 처럼 함께가야 합니다. 좋은 차만 있다고 운전을 잘하는 것이 아니듯이, 좋은 차와 좋은 드라이빙 스쿨은 별도로 하지만 통합하여 같이 움직여야한다는 원리죠.  PM코칭 프로그램은 Global 표준인 PMBOK을 기준으로 정보공학 혹은 CBD 등과 같은 waterfall 모델 뿐만 아니라 Agile 및 Hybrid Agile 기법을 PM 관점에서 어떻게 리드해야하는지를 시뮬레이션 게임 기법으로 60%이상 실습 기반의 워크샵 프로그램 입니다. 이미 삼성전자와 삼성SDS를 주축으로 Visual PM 프로그램만 1500 시간이 넘겼으며, 강의 평가를 남겨주신 분들도 1천분이 넘습니다. PMS 솔루션인 Visual PMO 는 RM (요구관리, 스펙관리, 시험계획 및 시험결과 관리 ), TM (WBS, FBS, QA, QC) , CM (형상관리 및 코드리뷰), KM (지식관리) 크게 4가지 모듈로 구성되어 있어서, 단일 프로젝트는 물론 멀티프로젝트, 혹은 프로그램/ 포트폴리오 관리까지 단일 시스템으로 통합하여 할 수 있습니다. 아울러 조직자원의 프로젝트별 투입 및 상세 Task 및 형상 이력까지 요구사항의 추적성을 가지고 실시간으로 관제가 가능합니다. 

각각의 프로젝트는 전체 Project 대쉬보드, 부서별 Product 프로젝트 및 개인 대쉬보드를 포함하여 실시간으로 과거의 내용이 추적됩니다. 

Agile 기법이라고 무조건 성공할 수 있는 것은 아니고, 회사 특성에 맞는 프로세스 테일러링과 회사에 맞는 Agile 프로젝트 상황판, 아울러 6개월이 지난 시점에서 글로벌 Agile 자격증인 PMI-ACP 취득 과점이 포함되어 있습니다. Global PM을 기준으로 지식과 도구, 즉 “문무”를 겸비한 프로그램이죠. 

프로젝트 기간 동안 일간/주간/월간, 스프린트/이터레이션/릴리즈, 마일스톤을 구분하고, 이를 기존 익숙한 Waterfall  및 Agile 각각의 지원은 물론 Hybrid Agile 모두 Dashboard를 구축함으로써, 동일 프로젝트를 익숙한 기법인 Waterfall 이나 Agile 로 입맛에 따라 관리하는 시각을 달리 혹은 통합하는 구조입니다.   아울러 요구사항에서 SRS/Spec으로, 다시 Spec/SRS 에서 WBS/FBS 및 이에 맞는 시험계획 및 결과에 대해 추적성을 가지고 있고, 요구사항추적매트릭스가 실시간으로 집계 됩니다. 아울러 이렇게 작성된 요구사항, FBS 혹은 시험계획은 향후 프로젝트에서 재사용 할 수 있습니다. 아울러 프로젝트와 프로덕트의 형상에 맞는 형상관리 지원 체계를 지원하여 누가 언제 어떻 파일을 어떻게 수정했는지가 보이고, 이는 향후 개발자 교체에 따른 인수/인계시 시스템에 의해 단번에 확인할 수 있습니다. 

프로젝트 지원의 의미는 행정지원, 하자보수, 교육자료는 물론 중간에 담당자가 변경되더라도 지속적인 성장을 하도록 하고, 기존 만들어진 단위/통합/인수 시험에 대한 재활성을 확대하며, 시험결과 중 defact 사항은 담당자에게 Todo 항목으로 자동으로 이관되어, 업무를 놓고 있으면 Dashboard에서 경고로 알람을 띄워줍니다. 이를 통해 PM/개발자에게 불필요한 커뮤니케이션을 야기하지 않고, 오롯이 프로젝트 본연의 업무에만 집중할 수 있는 환경이 구성됩니다. 

보통은 6개월 정도면 Visual PM + Visual PMO 효과를 보게 되는데, 저희가 제공하는 프로그램은 초기에 상당히 많이 집중이 되어 있습니다. 비행기가 첫 이륙할 때부터 정착할 때까지 에너지를 많이 쏟아내는 것 처럼요.  나머지 기간은 try & catch / agile 방식으로 프로세스 및 프로젝트 관리 문화에 대한 튜닝 과정, 즉 순항 과정을 거치게 됩니다. 궁극적으로는 자생할 수 있는 프로젝트관리 문화 틀/뿌리를 만드는 것이지요. 

Visual PM + Visual PMO 체계가 올바로 뿌리내림 했을 때 얻는 효과는, 프로젝트의 의사소통이 되는 Dashboard의 가시 및 명료화, 프로젝트 구성원들이 Agile 실무역량을 이론이 아닌 체화로 혹은 프로젝트 관리 관점으로 향상되며, 요구사항에 대한 추적성 및 보고서 자동 집계로 본연의 업무에만 집중할 수 있게 끔 됩니다. 이미 KT  IPCC PMO 체계에서 효과를 보았습니다. 500억 규모, 상시 상주 인력 100명, 프로젝트 20개의 거버넌스를 위한 Visual PMO 체계에 대한 구성 및 화면 요약을 보고 싶으시다면, 맨위의 슬라이드쉐어의 이미지를 클릭하시면 됩니다. 

회사의 프로젝트 관리 체계 특히나 커뮤니케이션 체계에 어려움이 있거나, 제품의 형상 관리 혹은 프로젝트 관리 조직의 자원 관리가 올바르게 되지 않거나, 아니면 프로젝트 본연의 일보다 보고서 만드는 일이 더 많다고 느껴지거나, 프로젝트 요구사항 관리를 체계적으로 하고 싶은 경우, 아울러 시험절차와 시험결과를 재사용하면서 그 근거를 시스템으로 체계적으로 남겨야하는 조직이 있으시면 편히 문의 주십시요. 

SM 분야의 ITIL/ITSM 으로, 아울러 프로젝트 분야에서는 PRINCE2로 유명한 Axelos 에서 PRINCE2 Agile 이라는 글로벌 표준 Agile 가이드를 출시하여서, 이를 PMI-ACP (PMI Agile Certified Professional) 자격증 체계와 비교해 보았습니다.

우선 PMI의 표준 체계와 자격 체계의 리더십은 전세계 시장의 90%에 육박하는 파워를 가지고 있습니다. 이미 PM전문가 자격증인 PMP는 전세계적으로 66만명에 이르고 있고, PMI-ACP 자격증도 8500명에 이르고 있죠. PM 분야에서는 글로벌 독보적인 존재라고 해도 과언이 아닙니다.

국내에서는 잘 알려지지 않았지만, PM 지식 체계로 전세계적으로 약 6-8% 정도, 유럽 내에서는 약 40% 정도의 점유율을 보이고 있는 Axelos 에서 PRINCE2 (2009년 갱신) 이외에 6월 PRINCE2 Agile 이라는 Agile PM 지식 체계를 출시하였는데, 너무나 잘 구성되어 있어서 감히 추천해 봅니다.  전체 약 350 페이지 정도의 Agile 실무 가이드 및 최초 글로벌 표준 Agile 지식 체계라 보시면 됩니다 .

이에 반해 PMI-ACP ( PMI 애자일 공인 전문가 ) 자격증 가이드는 지식 체계는 없고, 단지 아래의 12 권의 책을 필독서로 하고, 필수적으로 Agile PM 및 팀원이 알아야할 지식 목록을 가이드 하는 수준으로 되어 있습니다. (실제 본문 페이지는 약 13 페이지 정도 됩니다.)

PRINCE2 Agile 과 PMI-ACP 체계의 가장 큰 차이는 지식 체계이냐, 아니면 인증 시험을 위한 체크리스트의 가이드 인 것 처럼, PRINCE2 Agile은 7 원칙, 7 테마, 7 프로세스 및 5 애자일 특화, 26개의 산출물과 57개의 Agiel PM의 체크리스트를 다루고 있습니다. 이에 반해 (2015년 갱신된) PMI-ACP 자격제도는 7가지 도메인에 62가지 체크리스트와 도구 및 기법, 지식과 스킬 구분으로 되어 있습니다.

전체적인 지식 체계를 비교해 보면 배치만 다르고 다뤄야하는 지식 체계는 거의 유사합니다. Detail의 차이죠.

우선 놀라운 것은 PRINCE2 Agile 은 PRINCE2의 확장판이라고 할 만큼 PRINCE2의 구조에 완벽하게 들어 맞았습니다. R&D 특화 혹은 제품개발에 특화된 PRINCE2으 면모가 Agile 확장에서도 여지 없이 보여준 것이죠. 7가지 원칙이 “애자일 원칙/철학”과 거의 들어 맞았습니다. 가치/Value 기반이라든가, 경험으로 부터 꾸준히 향상 하는 개념, 역할과 책임을 분명히 나눠 진행, 릴리즈/스프린트/이터레이션 구분의 스테이지 관리, 예외/추가요구 관리, 제품 개발에 집중이라든가, 프로젝트 환경에 맞춰 테일러링 하여 써야한다는 가이드 처럼요.

중요한 것은 프로세스적 접근 방식이 아닌 문화/태도적으로 접근해야하며, 이에는 투명성, 협업, 풍부한 의사소통, 자기주도적, 설명 확대 위주의 방식을 강조해야함이고, 이게 결국 Agile 바로미터가 되는 항목이라고 가이드 하고 있습니다.

7가지 주제에 관련되어서는 비전의 명확화와 스프린트 Zero 에서의 준비, R&R의 명확화를 하되 고객 전문가 및 대표, 공급자 전문가 및 대표가 함께 어울려 R&R 구성으로 되어야 하고, 프로젝트에 적극적으로 참여해야한다고 가이드 하고 있습니다.

아울러 품질 기준에 대해서는 “완료조건”과 “선행준비/조건”을 기반으로 테스트 주도, 인수조건 위주의 유저스토리의 중요성을 언급하고 있습니다. 이 모든 Business Case/ Plan은 Product Description으로 도출되어야 한다는 BDD, FDD 방식을 가이드 하고 있습니다.

이렇게 품질이 기본으로 확인된 범위에 대해 일정 수립을 스프린트/팀, 릴리즈/스테이지 개념으로 구분하여 설명하였고, 이의 측정으로 플래닝포커기법이라든가, 티셔츠 사이즈 기법으로 추정하면 된다는 아날로그식 기법을 설명하고 있고, Risk 에 대해도 가이드 하고 있습니다.

전체적인 일정은 범위는 칸반 보드로, 일정은 번 차트로 구성하면 된다고 가이드하고 있습니다. 놀랄만치 글로벌 표준 체계 PRINCE2의 7가지 테마를 훼손시키지 않고, 그 체계를 그대로 Agile로 설명하는 것과 이것이 딱 들어 맞는 것에 대해 계속 탄성만 질렀던 것 같습니다.

프로세스 부분은 기존의 7가지 프로세스가 Agile 개념에 맞추어 테일러링 되어 있습니다. SU (Start Up a Project) 부분은 Product Roadmap/Vision에 해당하고, IP (Initiate a Project)은 Product Backlog로, CS (Control Stage) 부분은 Release로, MP (Managing Product Delivery)는 Sprint 리뷰 및 회고로, SB (Stage Boundary)는 Kanban/Burndown에 의한 범위/일정 관리로, Close 부분은 회고/교훈으로 매핑됩니다. 어찌보면 기존 PRINCE2의 개념적인 부분이 PRINCE2 Agile에서는 실용적 기법으로 구체화 되어 기술되어 있다고 생각하시면 됩니다.

중요한 것은 PRINCE2 Agile 의 조직 환경에 맞는 테일러링 부분인 데, 이 부분도 Baseline 과 Actual Line(로그/시정보완사항), 아울로 보고화 회고 체계로 되어있고, 각 26개의 문서 산출물의 목차가 정리되어 있어서 쉽게 프로젝트 기획 및 통제를 리드할 수 있습니다.

PRINCE2에 없고 Agile 특성화 된 부분은 Part III. 에서 절리되었는데, 애자일 바로미터, 요구사항, 풍부한 대화, 자주/반복적 릴리즈와 애자일 특성화 계약 기법에 대해 설명하고 있습니다. 애자일 바로미터에서는 애자일이 결국 프로세스가 아닌 MindSet/ 문화 측면으로 접근하고, 이를 꾸준히 측정하고 개선해야한다고 설명하고 있습니다.

PRINCE2 에서와 마찬가지로 PRINCE2 Agile의 부록은 정말 유용합니다. 26개의 문서 산출물 목차가 정리되어 있는 부분과, 프로젝트를 이행함에 있어 각각의 역할별 권한 정리, 아울러 57개에 달하는 애자일 수행 체크리스트, 제품 기반 애자일 기획 샘플, 아울러 애자일의 가치와 원칙, 스크럼/XP/SAFe/DSDM/KANBAN/LEAN 의 핵심 개념을 설명한 부록과, 기존 프로젝트 관리 기법에서 Agile로 이행하기 위한 가이드 및 조언, 마지막으로 스크럼 기법 가이드로 부록만 하더라도 풍부한 설명과 실용적인 내용으로 구성되어 있어서 상당히 유용하게 사용할 수 있습니다.

이에 대비하여 PMI-ACP 가이드는 말 그대로 애자일 공인 전문가 자격증을 취득하기 위해서 숙지하고 있어야할 지식 영역과, 도구/기법, 지식/스킬에 대해 타이틀/설명 위주로 되어 있습니다. 도메인 영역은 9페이지에 걸쳐서 62개의 체크리스트로 구성이 되어 있는데, 분량상으로 PRINCE2 애자일 80 페이지와는 차이가 많이 납니다.

도구와 기법 역시 3페이지에 걸쳐서 도구/기법 제목만 나열되어 있는데 반해서, PRINCE2 AGILE은 70 페이지에 달해 기술 하고 있습니다.

지식과 스킬 부분도 1페이지에 걸쳐서 PMI-ACP 가이드에서 설명하고, 상세한 내용은 12권의 권장 도서를 참고하는 형태로 되어있는데, PRINCE2 Agile 에서는 114페이지에 걸쳐서 설명이 되어 있죠.

어찌보면 지식체계인  PRINCE2 Agile과 자격시험 가이드인 PMI-ACP를 비교한다는 것은 넌센스일수도 있으나, 프로젝트를 Agile로 진행하기 위해 PM , 스크럼마스터 혹은 팀원들이 알아야할 핵심 사항을 기술하고 설명한다는 차원으로는 의미가 있을 것 같습니다.  아쉬운 것은 전세계 PM 계를 좌지우지 하는 PMI에서 Agile 지식체계를 정리하지 못하고, 12권의 가이드만 제시한 부분이 너무나 아쉽습니다.PMI의 다른 자격증 체계는 다 표준/가이드가 있는 상태인데, 유독 Agile과 PMI-PBA (비즈니스 분석 전문가) 2개의 자격증이 이런 형태네요. 물론 Agile이 여러 방법론으로 분기되고, 각각의 전문가에 의해서 리드되는 형태에서 저작권 문제로 표준 지침서를 만들지 못하리라 생각은 들지만, 그래도 자격증 제도라는 것은 표준화된 지식 체계가 먼저이고, 그 이후에 자격증 제도를 만들어야 하지 않나 싶습니다. 오히려 이 부분은 후발주자인 Axelos 가 지식체계를 먼저 구성하고, 향후 자격체계로 가려는 올바로된 방법이 아닌 가 싶습니다.

반가운 것은 그래도 유럽 진영의 Big Mouse인 Axelos를 통해서 PRINCE2 Agile 표준 지침서가 만들어졌다는데, 의의를 두고 애자일 코칭 부분도 이 것을 기준으로 프로젝트 관리 방법을 제대로 정립/테일러링의 시발점이 된 것 같아서 반가움에 정리를 마칩니다.

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로  Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 첫 주제로 Agile의 핵심이 무엇인지 살펴 보고자 합니다. 

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다.  
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리 
• 4. Agile 역할과 책임 
• 5. Agile 지식체계  
• 6. Agile 도구와 기법 
• 7. Agile 10 실천 흐름 
• 8. Agile PMO 핵심 
• 9. Agile PMO 체크리스트
• 10. Agile PMO 모델 비교 

제1부. Agile 핵심

1. 애자일은 프로세스가 아닌 인본주의 협업 문화 입니다.

2. Agile은 Agile 선언문 기반으로 발전 및 확산되고 있습니다.

3. Agile의 완전체인 Agile 원칙

4. 삼성 마하경영과 실천적 도구로서의 Agile

 

1. 애자일은 프로세스가 아닌 인본주의 협업 문화 입니다.

애자일 기반으로 프로젝트 개시 결정을 하면서 가장 많이 겪는 질문이 “우리는 검증된 Waterfall 을 사용하지, Agile은 우리 회사 조직에 맞지 않다” 라는 것입니다. 엄밀히 이 말은 Agile을 올바로 이해하지 못한  잘못된 의견입니다. 통상적으로 Agile을 Scrum 혹은 XP 기반의 기법으로만 알고 계신 분이 있는데, 엄현히 이것은 Agile을 실천하는 도구이지, Agile의 핵심 철학은 Waterfall을 위시한 기존의 프로젝트 관리 기법을 존중하면서, 사람들과의 동작하는 제품 기반으로 협력적으로 소통한다는 가치에 좀 더 포커스를 두고 있습니다.  다시 말하면 Waterfall 기반에 Agile을 혼합하여 쓸 수도 있다는 것이죠. 결코 Agile은 Waterfall의 대체제가 아닙니다.

2. Agile은 Agile 선언문 기반으로 발전 및 확산되고 있습니다.

Agile 이라고 알고 있는 Scum, XP,  Kanban 등등은 애자일 전체 구성 중 일부에 지나지 않습니다.  Scrum, XP 이외에도 개발과 운영개념을 하나로 융합한 DevOps과 엔터프라이즈 Agile에 접목시킬 수 있어 프로젝트, 프로그램, 포트폴리오 및 조직관리 측면을 언급하고 있는 SAFe 모델, 아울러 스타트업의 핵심 가치 기반의 접근 방식인 Lean Startup 등 여러가지 파생 모델들이 개발되고 확산되고 있습니다. 이에 가장 큰 기준이 되는 것은 “공정과 도구보다 개인과 상호작용을, 포괄적인 문서보다 작동하는 제품을, 계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.” 라는 Manifesto/철학이며, 이를 토대로 파생 기법이 만들어지고 확산되고 있는 거죠. 아울러 이는 IT 분야 뿐만 아니라, 전 산업 분야를 다 포괄합니다.

3. Agile의 완전체인 Agile 원칙

앞서 Agile의 철학을 이야기 했다면, 이제 부터는 지침/원칙에 대해서 이해해야 합니다. (영문, 한글)

Agile 원칙  (주번역 : 박성철)

1. 가치있는 제품을 조기에 그리고 지속적으로 인도해 고객을 만족시키는 것을 가장 우선으로 여긴다.
2. 개발 후반이라고 해도 요구사항의 변경을 환영한다. 애자일 프로세스는 변경을 고객의 경쟁적 우위 요인으로 삼는다.
3. 작동하는 제품을 수 주에서 수 개월의 주기로 자주, 가능한 더 짧은 기간에 인도한다.
4. 프로젝트 기간 내내 업무 전문가와 개발자가 매일 함께 일해야 한다.
5. 동기부여된 개인을 중심으로 프로젝트를 구축하라. 그들에게 필요한 환경과 지원을 제공하고 업무를 완수할 것으로 믿어라.
6. 개발팀에게 그리고 팀 내에서 정보를 전파하는 가장 효율적이고도 효과적인 방법은 얼굴을 직접 보고 대화하는 것이다.
7. 작동하는 제품이 진도를 측정하는 제 1 척도이다.
8. 애자일 프로세스는 지속할 수 있는 개발을 장려한다. 후원자들과 개발자들과 사용자들은 일정한 보폭을 끝까지 유지할 수 있어야 한다.
9. 기술적 탁월함과 좋은 설계에 대한 끊임없는 관심은 기민성을 강화한다.
10. 단순함, 안 해도 되는 일은 최대한 안 하게 하는 기교, 이것이 핵심이다.
11. 최고의 아키텍쳐와 요구사항과 설계는 자기 조직화된 팀에서 나온다.
12. 팀은 정기적으로 더 효과적으로 일할 수 있는 방법을 숙고하고 그에 따라 자신의 행동을 조율하고 수정한다.

위의 4가지 선언 및 12원칙을 살펴보면 일하는 원칙에 대해서만 이야기 하고 있지, 어디에도 Scrum, XP 등 기법/프로세스에 해당하는 내용이 없습니다. 즉 이러한 선언문/원칙을 이해하지 못하고 단지 Daily Standup 미팅이라든가 Kanban 구분을 하는 것은 애자일 준수하는 것이 아닌 그냥 Kanban, Scrum 기법을 이행한다고 할 수 있죠. 이것이 국내의 많은 기업들이 Agile 도입 후 실패하거나, 팀 내에서만 머무는 핵심적인 이유입니다. 즉, 기법이 아닌 가치/문화/철학기반하에서 출발해야한다는 것이죠.

4. 삼성 마하경영과 실천적 도구로서의 Agile

어찌보면 삼성전자에서 시작하는 Agile도 Scrum, XP , Lean 기법으로만 접근하는 것이 아닌 Agile의 철학 및 원칙을 올바르게 해석해서, 삼성의 문화와 접목시키려는 시도입니다. 이것이 삼성에서 이야기하는 마하경영의 실천 도구인 것이죠. 즉 20년전의 품질 개혁으로 시작된 신경영이 현재의 글로벌 TOP의 삼성을 일구었고, 이제는 가치/Vaule/사람을 위시한 마하경영으로 체질과 구조를 근본적으로 개혁하여 차세대를 이끌어 가겠다는 의지라고 해석할 수 있을 것 같습니다.

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로  Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 두번째 주제로 Agile 을 제대로 수행하고 있는지에 대해 자가진단 할 수 있는 체크리스트를 안내 합니다. 

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다.  
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리 
• 4. Agile 역할과 책임 
• 5. Agile 지식체계  
• 6. Agile 도구와 기법 
• 7. Agile 10 실천 흐름 
• 8. Agile PMO 핵심 
• 9. Agile PMO 체크리스트
• 10. Agile PMO 모델 비교 

제2부. Agile 체크리스트 

1. Agile 성숙도 판별 기준 

2. PRINCE2 Agile 체크리스트 

3. PMI-ACP 체크리스트 

4. Scrum 체크리스트 

 

1. Agile 성숙도 판별 기준 

애자일을 시행한다는 기업을 보고, Agile 가치 및 원칙을 준수하면서 하는지 아니면 Daily Stand-up, Kanban 기법만 사용하는지에 대해서는 다음 3가지만 확인하면 판가름 납니다.

첫째, Epic > User Story > Backlog > Definition of Done이 아주 명쾌하게 정의되어 있어야 합니다. 특히나 Definition of Done/검수조건은 Task/Backlog의 완결성을 확인하는 주요 잣대입니다. Agile을 실행하는 조직에서 Task/Backlog/FBS만 있고, Definition of Done/검수조건이 없다면 이는 Agile을 흉내만 내는 것라 단언할 수 있습니다. 

둘째, 회고 문화가 주기적으로 수반되어야 합니다. 회고/교훈은 프로젝트 관리 성숙도를 높일 수 있는 필수 도구 입니다. 팀원 모두 돌아가면서 일전의 Sprint/Iteration에 대해서 활용점 회고와 개선점 회고를 전체적으로 평등한 커뮤니케이션 상태에서 해주어야, 개인은 물론 조직, 프로젝트에서도 긍정적인 영향/개선을 할 수 있습니다. 

셋째, Velocity 관리입니다. 이때 주의해야하는게 Agile 수행 1-2년기간은 Velocity Matrix를 구축하는데 역량을 쏟아야지 Velocity를 평가하면 안됩니다. 초기  프로젝트 업무/Backlog 유형 라이브러리 및  개인 분야별 역량 라이브러리를 기준으로 회사/조직에 맞는 성숙도 velocity database를 구축하는데 힘을 쓰고, 이후에는 초기 예측한 velocity와 실제 수행된 velocity의 gap의 근본 원인과 문제 해결에 중점을 두어야 합니다. 이것이 평가에 반영되려면 1년차는 DB구축, 2년차는 시험 운영, 3년차가 Velocity 평가가 의미가 있을 것 같습니다.  Agile은 어차피 회사의 전략적 포트폴리오/프로그램/프로젝트 관리와 조직 역량 관리를 바탕으로 장기적인 안목을 가지고 문화 개혁 운동으로 접근하는 것이 올바른 방식이기 때문입니다. (이는 연재 후반부 Agile PMO시 다시 언급하도록 하겠습니다.)

요약하면 애자일 가치와 원칙을 제대로 이행하고 점진적으로 조직의 비전을 생각하면서 환경을 만들어 나가는 방향으로 이끌어야 된다는 것이죠. 

2. PRINCE2 Agile 체크리스트 

PM 진영에서의 첫 글로벌 Agile PM 표준이라고 할 수 있는  Axelos Prince2 Agile 에서 애자일을 올바르게 수행하고 있는지에 대해 자가 진단 점검할 수 있는 Agile Health-check 을 소개 합니다. 항목을 보면 파악되겠지만, 프로세스와 기법 뿐만 아니라, 태도/환경이 포함되어 있다는 점이 Waterfall과 가장 차이가 나는 부분이죠. 애자일을 수행하고 있는 조직에서는 본 Health check로 자체 진단을 해보시기 바랍니다. 

PRINCE2 Agile Health-check

1. 태도 

• 협력과, 신뢰, 그리고 비난없는 문화를 가지고 있다.
• 프로젝트 관리 팀에 의해 자기주도적 문화가 지원되고 있다. 검사와 적용 아울러 지속적 개선을 위한 문화다.
• 투명성이 대세다.
• 팀은 정기적으로 가치와 이익에 대해서 이야기 나누고 있다.
• 사물을 간단하게 보는 태도를 가지고 있다.
• 모든 이해관계자는 프로젝트의 최신 정보를 갱신받고 있다.
• 이사회는 프로젝트에 관계된 사람들과 주기적으로 상호소통 하고 있다.
• 상호 협력에 의해 기획이 점진적으로 구체화 되어가고 있으며 업무가 할당되고 있다. 화기애애한 분위기와 유머가 잘 유지되고 있다.

2. 환경

• 사람들이 행복해하고 있고, 재미있게 일하고 있다. 
• 팀이 안정적으로 보호막 안에서 간섭없이 상호 협력적으로 일을 하고 있다.
• 프로젝트의 변화에 대해 익숙하고 민첩하게 대처한다.
• 고객이 모든 단계에 대해 참여하고 관여한다.
• 프로젝트 현안에 대해 고객관점에서 다양한 시각으로 접근한다. 도출된 결론 혹은 산출물은 모든 사람에게 명쾌하다. 
• 피드백에 대해 갈망하고, 고객이 진정으로 무엇을 원하는지를 수집하기 원한다. 
• Agile 학습이 조직 전체에 대해 확산되고 있다. 의사소통이 매우 괜찮고, 빠르다.
• 사람들은 권한이 위임되어 있고, 통제가 가볍게 되가고 있다.
• 의무사항은 정말 의무사항이다.
• 프로젝트 팀과 운영팀은 Agile을 이해하고 있다. 이것은 Agile을 하는 것과는 다른 의미이다. 프로젝트에 임하는 사람들의 마음가짐이 전반적으로 Agile하다.
• 주기적 release는 실제 운용상 사용을 목표로 하고 있다.
• 무엇이 고정적이고 유연한 것인지를 결정하는 5요소(데드라인, 품질수준, 변화수용, 팀안정성, 고객은 모든 것이 필요치 않음)에 대해 잘 알고 있다.
• 주기적 발행으로 인해 심각한 일들이 일상적으로 발생할 수 있음을 인지하고 있다. (release/sprint 리뷰).
• 모든 역할은 명쾌하게 정의되었고 이해되었다.
• Waterfall(PRINCE2) 이 agile 로 해석되기 시작한다.

3. 프로세스

• 예외사항 처리가 철저히 관리된다.
• 통제 수준은 불확실성 수준과 기준으로 맞춘다.
• Work package 가 잘 구성되었으며, 명쾌하기 때문에 의사소통에 문제가 없다. 
• 요구사항과 user story가 숨겨진 것 없이 잘 기술 되었다. 
• 일하는 방식은 이익이 point에 의해 주기적이고 점진적으로 전달되고 있다.
• 프로젝트 기간 내내 시종일관 동일한 패턴으로 일을 한다.
• 명확하게 ’done’, ‘ready’ 를 식별하고, 업무 합의 과정이 투명하다.
• 기획과 업무하는 방식이 기능 중심과 시간제약 방식이다.
• MVP(Minimum Viable Product)가 모두에게 투명하다. 그리고 프로젝트 역할에 대한 이해와, 학습에 의한 개선 방식을 이해하고 있다. 품질 확인과 시험은 독립적인 방식으로 진행한다. 
• 품질 확인 방식으로 개선된다. 그리고 이것은 제품의 형상을 구체화하는 방향으로 진행된다.
• 기획은 단기, 중기, 장기 계획을 포함한 모든 기획요소들과 병행하며, 불확실성에 대한 요소를 고려한다.
• 경험에 의해 실증적인 기획이 이뤄진다.
• 초기 요구사항은 불필요한 상세화를 피하는 형태로 형성한다. 프로젝트 보증은 이러한 민첩성에 기반하여 가치를 높이는데 중점을 둔다.

4 기법

• 우선순위는 항상 조정된다. 이는 시간제약 속에서 이뤄지진다. 시간 연장이 필요할 때는 사람을 추가투입 한다. 모든 정보는 (벽면을 활용하여) 가시적이고, 항상 최신 정보로 유지된다.
• 우선순위를 정할 때 팀은 범위와 품질 두가지 사항을 모두 고려한다.
• 검수 조건이 모두 잘 기술된 형태로 항상 존재한다.
• 예측은 팀 기반 활동에 근거한다.
• 산출물은 Lean 해야하며, 각 유형의 내용을 전달하기 위해 올바른 채널이 사용되고 있다. 
• 데모를 자주 하고 있다.
• 리스크는 때로는 Spike, 프로토타입과 실험에 의하여 완하하고 있다.
• Burn charts는 진척사항을 명확하게 보기 위하여 다양하게 사용되고 있다. 
• User story는 대화와 의사소통을 활발하게 유도하고 있다.
• Kanban은 단지 Kanban보드 뿐만 아니라 전체적으로 적용되어 사용하고 있다.
• Workshops은 상황에 맞게 주기적으로 실행하고 있다.
• Stand-ups은 매일매일 10-15분 내외로 빠르게 이행하고 있다.
• 사람들은 ‘요구사항’, ‘user story,’ ‘feature’, ‘epic’ 등의 용어에 대해 명확히 이해하고 있다. 
• 제품기술서는 품질 항목을 기준으로 유연하게 적절한 수준으로 기술되어있다.

3. PMI-ACP 체크리스트 

2010년에 PM진영에서 첫 자격증에 해당하는 PMI-ACP는 올해 처음으로 Value/Principles 을 기준으로 갱신이 되었습니다. 이 전에는 도구/기법에 focus를 두었다면, 이번 갱신 본에서는 Agile을 가치와 원칙을 포함하여 제대로 구성한 것 같습니다. 단 아직도 PRINCE2 Agile 처럼 PMI에서 제시하는 Agile BOK가 없어서 아쉽습니다. Agile을 잘 이행하고 있는지에 대한 점검 지식 체계는 있어서 이를 공유하면 Health Check 정도가 될 것 같습니다. 이의 내용을 분석해보면 이역시 도구와 기법과 더불어 가치/환경/태도/대인관계/인본주의 항목을 중점하는 것을 볼 수 있습니다. 

PMI-ACP Agile Health-Check

Domain#1 : Agile 원칙과 마음가짐

• Task 1 애자일 원칙을 모델링하고 애자일 가치에 대한 토론을 통해 애자일 원칙을 수호한다. 이는 모든 팀은 물론 고객과 팀 사이에서의 마인드셋을 개발하는 것을 포함한다. 
• Task 2 업무를 효율적으로 진척시키기 위해 Agile의 가치와 원칙을 모든 구성원들이 잘 이해하고 있고, Agile 실무기법과 일반적인 용어에 대해 숙지하고 있다. 
• Task 3 조직을 보다 효율적 및 효과적으로 만들기 위해, 조직적 교육 체계, 시스템 변경과, 프로세스와 행동, 그리고 사람들에게 이에 영향력을 끼치기 시작하는 변화를 지원하기 시작했다.
• Task 4 투명성과 신뢰를 높이기 위해 실제 공정율과 팀의 성과를 정보방열판(Kanban)과 같은 가시적으로 관리하고 유지하고 있다. 
• Task 5 팀원들의 경험과 실수를 허용하는 안전하고 신뢰할 수 있는 팀 환경이 전파되고 있어, 이를 통해 팀원 스스로 배우고 꾸준히 개선할 수 있도록 한다. 
• Task 6 보다 효율적이고 효과적으로 일하는 방법을 찾기 위해 새로운 기술과 프로세스 아이디어에 대해 실험적으로 적용하고 창의적으로 개선하고 있다.
• Task 7 지식 공유 부재를 막고 병목효과를 줄이기 위해, 프로젝트 팀으로 하여금 함께 협력하고 일하게 함으로써 지식을 공유하는 것을 프로젝트 구성원들에게 장려하고 있다. 
• Task 8 안전하고 존경하는 환경을 만들어, 팀 구성원 사이에 숨어있는 대인관계를 장려한다. 꾸준한 개선을 위한 새로운 방식을 시험하고 자기주도적이고 권한부여 기법 꾸준히 모색한다.
• Task 9 팀원들 스스로 격려하여 높은 성과를 내며 스스로 개선할 수 있도록 모든 역량을 다 발휘할 수 있도록 서번트 리더십을 적용하고 있다.

 

Domain#2 : 가치 지향적 주도

2.1 긍정적 가치 정의

• Task 1 이해관계자에게 가치를 극대화하고, 비-가치 사항을 최소화하기 위해 점진적으로 구체화될 사항을 식별하기 위한 인도물을 정의한다. 
• Task 2 가치를 적시에 전달하기 위해 기능에 대한 상호 합의된 검수조건을 만족하기 위한 요구사항을 구체화 한다. 
• Task 3 가치의 전달을 극대화 하기 위해, 조직적 특성과 경험치를 고려하여 프로젝트에 기반한 팀의 프로세스를 정의하고 조정한다.

2.2 Avoid Potential Downsides

• Task 4 가치에 대한 초기 식별과 전달을 위해, 조직의 요구사항을 시장 기능에 접합하도록 작고, 가시적으로 작은 제품부터 시작하여 점진적으로 구체화 되어가는 출시를 기획한다. 
• Task 5 리스크를 초기에 식별하고 적은 비용으로 대응하기 위해, 이해관계자와 적정한 주기로 구체화하는 규모를 제약하고, 리뷰를 자주한다. 
• Task 6 비즈니스의 가치를 확인하고 극대화하기 위해, 고객과 사용자 피드백을 받을 수 있는 기회를 점진적으로 늘리도록 한다.

2.3 우선순위

• Task 7 인도물의 가치를 극대화하기 위해 이해관계자와 합의를 통해 단위 기능의 우선순위를 조정한다. 
• Task 8 점진적 개발의 일반적인 비용을 줄이기 위해 업무 결과에 대한 진척 방식과, 제품의 품질에 대해 주기적인 성과 리뷰를 수행한다. 
• Task 9 인도물을 통한 가치와 품질을 향항시키기 위해, 환경과 운영 그리고 인프라 항목을 꾸준하게 식별하고 우선순위를 조정한다.

2.4 점진적 개발

• Task 10 이해관계자와 수행 업무에 대한 조정, 아울러 업무의 기획을 점검 혹은 피드백을 받기 위한, 내부 운영 리뷰나 체크포인트를 점검하기 위한 리뷰를 수행한다. 
• Task 11 인도물에 대한 개발과 비협력으로 인한 리스크에 대한 밸런스를 조정하여, 백로그를 통해 전반적으로 프로젝트 가치를 극대화하고, 리스크를 감소시킨다. 
• Task 12 가치를 극대화 하기 위해 환경에 대한 변화나 이해관계자의 필요 혹은 선호사항을 적용하기 위해 요구사항에 대한 우선 순위를 주기적으로 조정한다. 
• Task 13 실패 확율을 최소하 하기 위해 솔루션이 사용될 환경을 고려하여 (운영 및 보안과 같은) 비기능 요구사항을 식별하고 우선순위 한다.
• Task 14 프로세스나 제품/서비스 전반에 대해 꾸준한 개선 사항을 식별하고 협력하기 위해, 제품에 대해 검사, 리뷰 및 시험을 잦은 빈도로 수행한다.

Domain#3 : 이해관계자 참여도

3.1 이해관계자의 필요 이해

• Task 1 이해관계자의 관심, 필요 및 기대사항에 대한 지식을 프로젝트 팀에서 확실히 이해하기 위해 비즈니스 주요 이해관계자들을 식별하고, 그들에게 정기적이고 잦은 리뷰를 격려한다.
• Task 2 프로젝트가 진행되는 상황 전반에 걸쳐 정보의 왜곡 없이 투명하게 가치를 전달하기 위해, 프로젝트 초기부터 종료될 때 까지 (현재 및 미래의) 이해관계자로 하여금 모든 지식과 경험을 이야기하게 하여 식별하도록 한다.

3.2 이해관계자 참여 확실성

• Task 3 참여자를 동기를 주고 효율적으로 협업하기 위해, 핵심 이해관계자들 사이의 협력에 대한 합의사항을 공식화 시켜, 이해관계자와의 관계를 구축하도록 한다. 
• Task 4 신규 이해관계자가 적정하게 참여할 수 있도록, 프로젝트와 조직의 변화에 따른 적정한 이해관계자의 참여를 꾸준히 관리한다.
• Task 5 의사결정의 품질을 개선하고 소요시간을 줄이기 위해, 집단적 의사결정 및 갈등해결 기법을 촉진하여 협력적 행동을 조직 구성원들끼리 수행하여 협력할 수 있도록 한다.

이해관계자 기대치 관리

• Task 6 이해관계자의 기대치를 맞추고 신뢰를 얻기 위해, 상위 수준의 비전과 목표를 개발하고, 이에 대해 프로젝트의 점진적 형태 (제품, 인도물, 릴리즈, 주기)에 대한 비전을 공유한다. 
• Task 7 기대치를 맞추고 신뢰를 구축하기 위해 성공 조건, 인도물, 이해관계자들 간에 촉진 식별되어 합의된 수용 조건들을 공유하고 관리한다. 
• Task 8 핵심 이해관계자들이 적정한 의사결정을 하게 하기 위하여, 프로젝트 팀 성과에 대한 소통, 작업 품질, 장애요소 및 리스크 사항을 포함한 업무 상황을 투명하게 제공한다. 
• Task 9 이해관계자 효율적인 기획을 하기 위해, 필요 사항을 명확히 하고 적용 사항에 대한 가치의 밸런스에 대한 척도와 예측치를 제공한다.

 

Domain#4 : 팀 성과

4.1 팀 구성

• Task 1 팀이 일체단결하고 구성원들의 참여를 극대화하여 성과를 공유할 수 있도록, 다른 팀들과의 협력적 관계와 내부 프로세스를 궁리하면서 협력하도록 한다. 
• Task 2 최소한의 지연으로 비즈니스의 가치를 창출하기 위해, 프로젝트 목표에 대한 성취 사항을 공유하고 이에 필요한 대인관계와 기술항목을 팀이 개발하도록 돕는다.

4.2 팀 권한 위임

• Task 3 팀 규모와 병목 현상을 줄이고, 높은 성과를 내는 cros-functional 팀을 구축하기 위해 팀 구성원등로 하여금 분야별 전문가가 될 수 있도록 격려한다. 
• Task 4 복잡성을 효과적으로 해결하고 관리할 수 있도록, 권한부여와 리더십을 독려하여 자기주도적인 업무 환경이 구축될 수 있도록 한다. 
• Task 5 프로젝트 팀이 프로젝트 전반에 걸쳐 사기진작이 높고, 동기부여 및 생산성이 높아질 수 있도록 팀과 개인의 동기부여와 동기를 꺽는 항목을 꾸준히 발견한다.

4.3 협력과 참여

• Task 6 오해 및 재작업을 줄이기 위해 한 곳에 있거나, 협력 도구를 활용하여 프로젝트 팀과 적정한 외부에 있는 이해관계자의 긴밀한 의사소통을 촉진한다. 
• Task 7 프롲게트 결과물이 예측가능하고, 가치 전달이 효율적으로 되기 위해 방해되는 모든 것들을 줄인다.
• Task 8 프로젝트 팀 구성원들로 하여금 그들의 동기가 프로젝트의 전반적은 목표가 일치되는지를 확신을 위해, 비전을 공유하게 하는 프로젝트와 팀의 목표를 배치를 프로젝트 팀으로 부터 참여하도록 한다.
• Task 9 프로젝트 팀원 등로하여금 그들의 생산성을 이해시키고, 보다 정확한 예측을 위해 이전 주기와 릴리즈의 실질 성과를 측정하게 끔하고, 프로젝트 팀으로 부터 가속도(velocity)를 측정하게 끔 한다.

 

Domain#5 : Adaptive 기획

5.1 기획 수준

• Task 1 적정한 수준의 다양한 수준 (전략, 릴리즈, 주기, 일일)의 기획을 점진적 구체화 기법으로 수행하게 하며, 프로젝트의 예측가능한 인도물/결과물과 이를 바탕으로 한 기회가 되는 요소들에 대해 점진적으로 밸런스를 맞추도록 한다.
• Task 2 참여 수준을 향상시키고, 불확실성을 감소시키기 위해 핵심 이해관계자의 참여를 독려가혀 기획 사항들을 가시적이고 투명하게 기획하도록 하며, 기획 결과로 선언할 수 있도록 한다. 
• Task 3 기대한 인도물에 대해 일반적 이해를 높이기 위해, 프로젝트가 이해관계자의 기대치를 점진적 참여 수준을 높여 구체화 해나가도록 한다. 

 

5.2 Adaptation / 적응 

• Task 4 가치를 극대화고자 프로젝트의 인도물에 대한 성격/크기/복잡성/위험성을 포함한 주기적인 회고 기반의 결과를 바탕으로 기획 프로세스의 흐름을 꾸준히 유지한다. 
• Task 5 비즈니스 가치가 극대화 인도되기 위해, 팀의 학습, 경험 전달, 이해관계자 피드백과 결함에 기반하여 프로젝트의 요구사항, 일정, 예산 및 우선순위 조정을 기획요소에 반영하고 조정한다.

5.3 Agile 규모 및 예측

• Task 6 팀의 가속도 및 외부적 환경에 독립될 수 있는 프로젝트 사이즈를 결정하기 위해서 점진적으로 성과를 측정할 수 있는 기법을 적용하기 위해 항목의 크기를 조정한다. 
• Task 7 예측 범위를 결정하거나 갱신하기 위해 유지보수 항목과, 운영 요구사항과 기타 항목들에 대한 수용 능력을 조정한다. 
• Task 8 프로젝트 관리의 시작 포인트를 개발하기 위해 프로젝트 인도에 필요한 필요 노력과 이에 대한 현재 수준의 가용력을 적용하여 범위, 일정, 원가 항목 항목에 대해 초기 예측 한다. 
• Task 9 프로젝트를 관리하기 위한 프로젝트 인도물이 필요로 하는 수준을 이해하기 위해, 범위, 일정, 원가 예측 수준을 재조정 한다. 
• Task 10 예측을 완료하기 위해서, 자원 한계, 프로젝트 규모, Velocity 메트릭스의 변경 데이터를 꾸준히 활용한다.

Domain#6 : 문제 인식 및 해결

• Task 1 직면 문제를 해결하고, 팀의 생산성을 방해하는 장애물을 제거하거나 가치를 전달하는데 방해되는 요소를 식별하기 위해서 소통과 실험을 장려하는 개발되고 안전한 환경을 구축한다. 
• Task 2 이슈를 야기한 항목을 개선하기 위한 프로세스를 개선하고, 적정한 시간내에 해결하게 하기 위해, 프로젝트 내에서 다양한 관점에서 프로젝트 팀이 위협을 도출하고, 이슈의 해결에 대해 참여하고 학습할 수 있도록 한다. 
• Task 3 인도물의 가치를 극대화 하기 위해 이슈는 적정한 팀 구성원들이 해결할 수 있고, 해결할 수 없는 가벼운 이슈에 대해서는 기대치 혹은 관점을 리셋해버릴 수 있는 점을 확신시키고 있다. 
• Task 4 책임성을 구분하고 , 행동을 장려하며, 현재 진행 사항에 대한 담당과 해결 상태를 확인하기 위해 위협과 이슈에 대한 목록이 가시적으로 모니터링 되고, 우선 순위가 조정되면서 관리하고 있다. 
• Task 5 투명성을 보장하기 위해서, 위협과 이슈 사항들에 대한 목록과 활동 사항이 백로그 형태로 상태가 관리되고 소통되고 있다.

Domain#7 : 꾸준한 개선 (제품, 프로세스, 사람)

• Task 1 팀 생산성을 확신하기 위해, 팀의 관습, 조직 문화와 결과 목표를 주기적 리뷰를 통해 프로젝트 프로세스에 테일러링하여 적용하고 있다. 
• Task 2 팀, 프로젝트, 조직 효율성에 대해 지속적인 개선을 위해 회고와 실험적 개선을 꾸준히 주기적으로 실행하고 있으며, 이를 통해 팀 프로세스를 개선하고 있다. 
• Task 3 제품의 가치를 향상하기 위해, 점진적인 인도와 빈번한 데모를 통해 제품의 피드백을 요구한다. 
• Task 4 팀 내의 분야별 전문성을 개발하기 위해, 프로젝트 구성원들로 하여금 그들의 스킬을 개발하기 위한 지속적 학습을 받을 수 있는 환경을 제공한다.
• Task 5 개별적인 효율과 팀의 효과성을 꾸준히 개선하기 위해 가치 stream을 분석하고, 낭비를 제거하도록, 기존의 프로세스 항목을 대처한다.
• Task 6 식별된 문제의 재발행을 방지하고, 전체 조직의 효과성을 높이기 위해서, 프로젝트와 조직 전반에 지식과 실무기법을 확산하여, 시스템적인 개선을 하도록 한다.

4. Scrum 체크리스트 

Agile 체크리스트는 아니지만, Agile 원칙의 90%를 수용하고 있는 Scrum을 잘 수행하고 있는지에 대한 체크리스트입니다. Scrum 진영 공식 문서가 아닌  스웨덴 출신 Henrik Kniberg 의 필요에 의해 만들어진 문서인데, 상당히 정리를 잘 해 놓았습니다. 영문에 대해 PDF 및 PPT 모두 다운로드 받을 수 있습니다. 

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로 Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 세번 째 주제로 Agile의 가치관리가 왜 중요한지 살펴 보고자 합니다.

앞서 “Agile 핵심 – Agile은 인본주의 협업 문화 입니다.”에서 언급했듯이 애자일은 “공정과 도구보다 개인과 상호작용을, 포괄적인 문서보다 작동하는 제품을, 계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.” 라는 Manifesto/철학을 기반으로 합니다. 어찌보면 변화의 흐름에 맞서 상호소통과 협력을 기반으로 동작하는 제품을 점진적으로 만들어나가는 과정 속에서 배우고 적응하고 개선하도록 하겠다는 밑바탕을 깔고 가는 것입니다. 단, 궁극적인 가치가 무엇이고 이를 위해 무엇을 먼저해야하는가를 항상 염두해 두는 것이 가치 관리의 시작 점입니다.

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다. 
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리
• 4. Agile 역할과 책임
• 5. Agile 지식체계
• 6. Agile 도구와 기법
• 7. Agile 10 실천 흐름
• 8. Agile PMO 핵심
• 9. Agile PMO 체크리스트
• 10. Agile PMO 모델 비교

제3부. Agile 가치 관리 

1. Plan-driven model

2. Value-driven model

3. 요약

1. Plan-driven model

프로젝트 관리에서는, 계획-주도기반 기법으로 Waterfall 모델이 대표적으로 사용되고 있으며, 이는 시스템요구사항 > 소프트웨어 요구사항 >  분석 >  설계 > 구현 > 시험 > 종료 단계로 대표되고 있습니다. 이러한 계획-주도기반은 다양한 산업에서 효과적으로도 입증 되었죠. 하지만 이 방식은 순수한 R&D 프로젝트나 소프트웨어 산업에서는 좀 낮는 성공율을 보이고 있습니다. 그 이유는 다음과 같습니다.

• 정교한 스펙을 작성하는 것은 구현 및 시간을 예측하기 위함이지 가치를 부가하기 위함이 아니다. (지금까지도 스펙을 보다 상세하게 구현할 수록, 리스크를 잘 관리할 수 있다고 생각한다)
• Waterfall 기반의 소프트웨어 프로젝트에서 WBS를 작성 시 프로젝트의 복잡성 예측을 표현할 방법이 모호하다.
• 정확한 예측이 어렵거나 불가능하다.
• 프로젝트가 계획대로 구현되어가는지에 대한 추적이 어렵고 정확한 현황을 파악하기 어렵다. 또한 업무가 여부에 대한 구분이 모호하다.
• 프로젝트가 빈약한 기획 및 치명적인 결함으로 일정 지연, 예산 초과될 가능성이 높다.
• 실행 과정 중에 예상치 못한 일들이 발생한다.
• 요구사항이 올바르지 않거나 명확하지 않기 때문에 실행 준비가 덜 되어 있다. 어떤 것들은 제외되거나 변화하거나 갱신되기 때문에 이러한 것들을 해결하는 과정에 시간이 소비 된다.
• 완료되었다고 생각했던 항목들이 그렇지 않게되어,  완료될 때 까지 예측할 수 없는 일정주기 갱신을 계속 해야한다.
• 품질 이슈로 개발 업무들을 정확히 예측할 수 없다.
• 불명확한 요구사항 관련 이슈로 변경 요청이 늘어날 수 밖에 없어 팀원들이 산만해지기 시작한다.
• 고객으로 부터  변경 요청을 프로젝트 막바지 단계에서도 받게 되는데, 이는 프로젝트 초기부터 변경 사항에 대한 훈련이 되어있지 않기 때문이다. 또한 사용자들은 그들이 가장 시급하게 원하는 사항들이 아직까지도 구현이 안되었다는 것을 프로젝트 막바지에 확인하게 된다.
• 통합 과정이 생각했던 것 보다 오래 걸리고, 보다 복잡하다.
• 품질 결과로 인해 수정하고 보완해야할 작업들에 할당되는 시간이 보다 더 필요하게 된다.

결국 소프트웨어 프로젝트에서는 불확실성 상태에서 시작하는 것이고, 불확실성이 증가함에 따라 계획 기간 및 개발 자금, 자원, 시간을 잘못된 기능 구현에 낭비하고 있거나 질낮은 품질의 기능을 양상하기도 합니다. 프로젝트가 착수 되면, Waterfall 모델은 요구사항을 확정짓고 서명을 통해 확인 받으면서 단계별로 넘어가게 됩니다. PM은 요구사항을 수집하고 분석하는데 기간이 얼마나 걸리게 될지 예측하고, 이를 근거로 프로젝트 계획서를 만들게 됩니다. 프로젝트 계획서는 프로젝트가 특정 기한내에 끝내도록 되어있고, 그 기한이 고객과 다시 합의하는 과정을 거치도록 되어있습니다.

모든 요구사항은 확정되었고, 변하지 않는다는 가정 제약 하에서 프로젝트 계획을 완료한다는 것이 기본적인 전제/논리입니다.  하지만 현실 세계에서는 그렇지 못하죠. 요구사항은 확정된 적이 없으며, 매번 변합니다. 요구사항이 변경될 때 마다 프로젝트 계획서에 영향을 끼치게 됩니다. 그 결과 완료 예정일 역시 변경해야 합니다. 불행하게도 이는 불가항력적이고, 팀원에게 이행하여야할 일정의 압박을 가하게 됩니다. 이것이 프로젝트 착수 후 일반적으로 갖게되는 통제불능 상태로의 직면 단계인거죠. 이런 문제를 해결하기 위해 Agile 이라는 방법이 대안이 제시되었으며, 협력적 협업 모델을 독려하고 가능한 계획 범위 내에서 적응하게하는 기법이 바로 계획-주도형이 아닌 가치-주도형 기법이라 할 수 있습니다.

2. Value-driven model

가치-주도형 애자일 기법은 앞서의 계획-기반형 모델과는 확연히 다릅니다.  Agile 기법은 프로젝트 착수 단계의 요구사항은 확정 본이 아닌 언제라도 변경될 수 있다는 것을 전제로 합니다. Agile 마음가짐은 특정일에 무조건 납품해야한다고 제약/룰을 만들어 버립니다.  이 방식은 결국 정해진 시간과 자원과 이에 대비되는 ,  불확실한 요구사항은 방관한다는 사항을 확정 해버리는 방식입니다. 어찌보면 소프트웨어 개발 프로젝트의 현실성에 가장 근접한다고 볼 수 있습니다.  모든 요구사항에 대해 일정 제약내 모두 다 완수할 수 없다면, 현실적으로 우선순위 정해 고객이 가장 중요하고 가치있다고 생각하는 것 부터 먼저 차근차근히 구현해 내가는 방식입니다.

“주어진 기간내 완료할 수 없는 요구사항은 무엇인가”라는 질문으로 시작합니다. 이것이 결국 가치-주도형 기법 인 것이죠. 확정된 기일 까지 모든 요구사항을 완료할 수는 없습니다. 때문에 고객에게 가장 중요시 여기는 가치를 최우선으로 제공하기 위해서 구현해야할 기능과 시스템으로 지원해야할 사항이 무엇인가’를 끊임없이 자문하는 것이 중요한 핵심입니다.

이 방식은 불확실성과 리스크를 일시에 제거하기 위한 방식은 아닙니다. 프로젝트 전체 생애주기 동안에 계속되어야하며, 매번 적용과 적용 결과에 대해 상호간에 배우고, 적응하고 개선한다는 것을 전제로 합니다. 프로젝트가 수행될 수록 피드백을 발빠르게 끊임없이 반복함하고, 업무들을 잘게 나누고 경험을 녹여서 개선된 방향으로 이끌도록 합니다. 결국 리스크를 줄이고, 경험과 데이터를 기반으로 꾸준히 개선되는 방식인 것이죠. 예산적인 측면에서도 프로젝트 예산을 스프린트 혹은 릴리즈로 잘게 나눠 관리하여, 프로젝트 전체로 한번에 관리하는 것 보다는 보다 유연하게 대응할 수 있게 됩니다.

다시 정리하면, 불확실성이 높은 환경에서는 업무가 언제 종료될 지, 얼마나 많은 자원이 투입될 지 , 주사위 놀이 처럼 정확하게 예측할 수 없습니다. 여기에는 많은 리스크 요인들이 프로젝트에 영향을 미칠 수 있으며 실패확율이 높아지며 프로젝트 일정 지연, 프로젝트 예산, 회사가 사업의 우선 순위가 변화, 고객도 변화에 관심을 가지는 상황에 직면하게 되는 등등의 상황에 놓이게 됩니다. 이러한 상황이 직면하게 되면, 투자비는 소진되고, ROI는 기대치보다 낮아지게되면서 리스크가 증가되게 끔 됩니다. 가치-주도적 접근 방식은 프로젝트를 많은 단계 개념(스프린트)으로 잘게 나눔으로 리스크를 줄이는 기법입니다. 리스크는 존재하지만 스프린트-주기 만큼으로 줄어들게 되고, 이를 통해 이해관계자가 프로젝트 수행 여부에 대한 의사결정을 자주 빠르고 올바르게 할 수 있게 되는 것이죠. 프로젝트 중간에 프로젝트 투자대비 결과가  빠르게 인지가 가능하다라는 의미로 재해석 할 수 있습니다.

점진적 납품 확인 방식의 Agile 기법은 리스크를 줄이는 것 뿐만 아니라 투자대비 올바른 제품이 적정한 시점에 납품되는지 ROI를 통해 확인할 수 있는  장점 또한 있습니다. 제품/프로젝트를 계속 해야하는지에 대한 의사결정 기회를 자주 가질 수 있게 된다는 뜻이죠. 예를 들어 5개월 후 자금의 문제가 예측되면, 최우선 가치 기능을 프로젝트 착수 기간 부터 구현하여, 최초 투자대비 ROI를 초기에 확신시키며 프로젝트를 계속 이행 혹은 막대한 손실을 입기전에 바로 중단할 수 있습니다.

3. 요약

가치-주도형 모델은 기획 초기부터 필요로하는 것에 대해 공감을 얻으면서 적응해나가는 모델이며, 기획하고 실행하고 배우고 적용하는 일련의 흐름이 프로젝트 생애주기 안에 녹아져있습니다. 불확실성이 특히나 많은 오늘날 기획이 누락될 수도, 상황이 변화할 수도 있기 때문에, 계획은 언제라도 재기획 되어야 한다는 전재로 시작합니다. 전체 작업 분량과 정해진 기간 내에서 가치 위주로 분배되고, 각각의 시간 제약의 주기마다 결과물이 계획한 대로 구현되었는지를 확인하고, 리스크를 측정하며, 조율하고 수정하는 기법이 가치-주도형 모델이라고 할 수 있습니다.

기본 글 : https://www.scrumalliance.org/community/articles/2014/april/plan-driven-versus-value-driven-planning

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로 Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 세번 째 주제로 Agile의 가치관리가 왜 중요한지 살펴 보고자 합니다.

Agile의 핵심은 지시형의 업무 진행 스타일을  탈피하고, 각 개인의 능력과 실력을 존중하면서 상호간에 맞춰가는 방식입니다. 이러한 자율적인 방식은 서로간의 역할과 책임 (R&R, Role & Responsibility)가 상당히 중요합니다. 본인이 무엇에 대한 권한과 책임이 있는지에 대한 명확한 선을 바탕으로 상호간의 존중과 전문성을 최대한 이끌어 내는 환경을 만드는 것을 책임진다는 것이 애자일 철학의 밑바탕인 것 같습니다.

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다. 
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리
• 4. Agile 역할과 책임
• 5. Agile 지식체계
• 6. Agile 도구와 기법
• 7. Agile 10 실천 흐름
• 8. Agile PMO 핵심
• 9. Agile PMO 체크리스트
• 10. Agile PMO 모델 비교

제4부. Agile의 역할과 책임.

1. Product Owner  ( 혹은 Project Manager, Project Leader)

엄밀히 Agile (Scrum) 방식에 가장 적합한 것은 SI/프로젝트관리 보다는 Solution/프로덕트관리에 Focus가 맞춰져 있다고 봐야합니다. Product/Solution의 기준은 제품 1.0이 이미 시장에 출시되었고, 그에 대한 업그레이드 (1.x) 혹은 고도화 (2.x)를 진행할 때 입니다. 즉 고객사 프로젝트 보다는 자사 제품에 좀 더 잘 맞는다고 해야할 것 같습니다. 고객사 프로젝트/SI의 경우는 제품의 범위/일정/비용이 명확하게 책정되어있기 때문에 이에 대한 유연성을 발휘하기가 어렵기 때문입니다.

자사제품/Product/Solution을 진행할때 가장 힘을 가져야되는 해당 제품의 총괄책임자, 즉 Product Owner입니다.  애자일의 창시자 멤버였던 Ken Schwaber과 Jeff Sutherland의 스크럼가이드에 의하면 Product Owner의 정의는 다음과 같습니다.

Product Owner 역할

1. 제품 백로그 항목들을 분명하게 설명
2. 목표와 미션들을 가장 성공적으로 달성할 수 있도록 제품 백로그에 있는 항목들을 
우선 순위화
3. 개발팀이 수행하는 작업의 가치를 최적화
4. 제품 백로그가 가시적이고, 투명하고, 
모두가 이해했는지를 확인 하고, 
스트럼 팀이 다음 스프린트에 무슨 작업을 
해야 하는지 제시
5. 개발팀이 제품 백로그 항목들에 대하여 
필요한만큼 올바르게 이해하고 있는지 확인

이를 요약해보면 제품의 향후 로드맵을 바탕으로 장기적, 혹은 단기적으로 출시해야할 기능을 구체적으로 명시화해야하고, 이를 개발팀에게 지시가 아닌 비전/가치 등의 동기부여로 당위성을 스스로 인지할 수 있도록하는 환경을 만드는 사람이라고 요약하면 될 것 같습니다. 장단기적인 명세가 구체화 되었더라도, 2주/3주 단위의 스프린트에서 시장 및 자원의 상황에 따라, 우선 순위를 다시 조율/조정하는 역할을 가지고 있는 사람인것이죠. 중요한 것은 조율/조정이지, 지시가 아니라는 점 입니다.

1. Project Teams ( 혹은 프로젝트 팀원)

과거 형태로 프로젝트 팀원들은 PM/PL 이 지시하는 대로 수행하는 사람이었다면, 애자일의 프로젝트 팀원들은 좀 다르게 움직여야 합니다. 스크럼가이드에는 Product Teams의 정의는 다음과 같습니다.

Product Teams 역할

1. 개발팀은 자기 조직화 (Self-Organizing) 팀입니다. 스크럼 마스터를 포함하여 어느 누구도 
어떻게 해야 제품 백로그를 출시 가능한 기능이 되도록 점진적으로 만들어낼지 개발팀에 지시할 수 없습니다;
2. 개발팀은 완성된 기능을 점진적으로 추가하여 제품을 만드는 데 필요한 모든 기술이 있는 교차기능 (cross-functional) 팀입니다;
3. 스크럼에는 각자 수행하는 일에 상관없이 개발팀 멤버들이 개발자 이외의 다른 직함은 가지지 않습니다. 이 규칙에 예외는 없습니다
4. 스크럼에는 개발팀 안에 하위팀 (sub-teams) 이 없습니다. 설령, 테스트 또는 비즈니스 분석과 같은 특정 도메인에 대한 지식이 
필요하더라도 하위팀을 따로 두지 않습니다. 이 규칙에도 예외는 없습니다.
5. 개발팀내의 각 개발자들은 특정 기술이나 전문 분야가 있을 수 있지만, 제품에 대한 책임은 개발팀 전체에 있습니다.

요약하면 개발팀은 지시받는 팀이 아닌 자기주도적인 팀이며, 단일 제품의 형상을 완료하기 위해서 개발,디자인,품질 등 기능분야 전문가가 함께 모여있어야하며 동등한 레벨이어야 한다는 것입니다. 스펙 및 일정은 팀원들이 협의하여 결정을 하며, 개별 책임이 아닌 공동 책임제에 의해서 진행한다 입니다. 즉 철저하게 Professionalism 으로 자신이 맡은 구간을 스펙/개발/검증까지 책임을 진다입니다. 바꾸어말하면 신입사원 같은 경우는 프로젝트 팀원이 될 수 없는 것이죠. 철저하게 팀원들을 위한  리그를 위한 환경을 만들어주어야한다는 것입니다.

1. Scrum Master (스크럼마스터 혹은 스크럼코치, 애자일코치)

통상적으로 애자일/스크럼을 처음 시작하는 환경에서 Scrum Master (혹은 Agile Evangelist, Agile Coach) 역할을 할 사람이 중요합니다. Product Owner와 Product 팀원들에게 인본주의 철학 바탕하에서의 Agile 의 기법을 실무적으로 전수해줘야하기 때문입니다. Scrum Master는 직접 프로젝트 개발에 참여하지는 않지만,프로젝트 구성원들이 개발에 전념할 수 있도록 주변에서의 모든 환경을 만들어주는 사람입니다.  스크럼가이드에는 Scrum Master의 정의는 다음과 같습니다.

스크럼마스터의 PO/PM/PL 에게의 역할 

1. 제품 백로그를 효과적으로 관리하기 위한 기술 찾기
2. 제품 백로그 항목들이 명확하고 간결할 필요가 있다는것을 스크럼팀 이이해할 수 있도록 도움
3. 경험적인 환경 (empirical environment) 에서 사용하는 제품 계획을 이해
4. 최상의 가치를 내기 위해 제품 백로그를 어떻게 조정해야할지를 제품 책임자가 알고 있는지 확인함
5. 애자일 (agility) 의 이해와 실행
6. 요청이나 필요에 따라 스크럼 이벤트를 원활하게 진행

스크럼마스터의 팀원에게의 역할 

1. 자기 조직화된 교차기능 팀으로 거듭나기 위한 
개발팀 코칭
2. 개발팀이 가치 있는 제품들을 만들어 낼 수 있도록 도움
3. 개발팀의 개발 진행에 있어 장애되는 요소들을 제거
4. 요청이나 필요에 따라 스크럼 이벤트를 원활하게 진행
5. 스크럼이 아직 완전히 자리잡지 않고 이해되지 않은 조직 환경에서의 개발팀 코칭

스크럼마스터의 조직/회사에게 역할

1.  해당 조직에 스크럼이 잘 자리 잡을 수 있도록 안내하고 코칭
2.  조직 내에서 스크럼 실행을 계획
3.  직원 및 이해관계자들이 스크럼과 경험적 제품 개발에 대해 
 잘 이해하고 확립할 수 있도록 도움
4.  스크럼 팀의 생산성을 향상시키기 위한 변화 만들기
5.  조직에서 스크럼 적용의 효과를 높이기 위해 다른 스크럼 마스터들과 협력

요약하면 스크럼마스터는 (1) PO/PM/PL에게는 제품에 대한 회사와 제품의 로드맵을 명확히 이해하고, 이를 팀원들과 조화롭게 구축할 수 있는 환경을 마련할 수 있는 역량을 깨닿게 하고, (2) 팀원에게는 능동적/자기주도적으로 회사가 필요로하는 제품을 순간순간 협의 및 설계하여 공동으로 협업하면서 추진할 수 있도록 역량을 키워주면서, (3) 회사에게는 이러한 열린 인본주의 협업 문화가 잘 뿌리박고 성장할 수 있도록 하되 꾸준한 개선/KAIZEN 문화의 토양의 환경을 만들 수 있도록 제반 노력을 다하는 것 입니다.

1. Yahoo의 Agile R&R 예시

Yahoo 조직에서는 위에서 언급한 대로 PO는 제품의 ROI에 대해 책임을 지며, 출시일별 출시기능에 대한 조정과, 각 작업간의 우선순위를 조율하는 역할을 가지고 있고, 스크럼마스터의 경우 프로젝트 팀이 스스로 4가치 가치와 12가지 원칙을 잘 지킬 수 있도록 환경을 구축하는 역할을, 프로젝트 팀원은 Two-Pizza Rule (피자 두판을 함께 할 수 있는 조직 규모)에 따라 5-9명 사이로 제품의 모든 기능을 구사할 수 있는 기능 인원으로 구성하여 자기주도적으로 기획하고 품질에 대해 책임지는 역할로 정의하고 있습니다. 상당히 실무적인 접근 방식이죠.

요약하면 애자일의 경우 Top-down 하향식 지시 문화가 아닌, Bottom-up 상향식 자기주도적 협업 문화를, 방종이 아닌 자율체계로 본인들이 스스로 개선하면서 나갈 수 있는 역할과 책임 구조를 가지고 있는 프레임웍이 아닌가 싶습니다. 중요한 것은 10년 20년 먼 미래를 바라보고, 점진적으로 개선시켜 완성해 나간다는 마음가짐으로 시작해야 한다라는 점인 것 같습니다.

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로 Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 본회는 5회로써 Agile 개념하에서 실무적인 방법론/프레임워크별 설명을 드리려 합니다. 

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다.  
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리 
• 4. Agile 역할과 책임 
• 5. Agile 지식체계  
• 6. Agile 도구와 기법 
• 7. Agile 10 실천 흐름 
• 8. Agile PMO 핵심 
• 9. Agile PMO 체크리스트
• 10. Agile PMO 모델 비교 

2001년도 Agile 이라는 개념이 ICT 산업분야에서 출시되고 15년이란 세월이 흐르면서, 성장하고 확대되면서 모든 산업에까지 영향을 미치고 있습니다. 전세계 PM 표준을 좌지우지하는 미국 PMI와 영국 AXELOS 기관에서도 이러한 사회적 영향력을 고려하여 PMI-ACP 혹은 PRINCE2 Agile이라는 표준과 자격 체계를 출시하여 영향력을 키우고 있습니다.  Agile의 개념하에 많은 파생 방법론들이 생성되어 때론 사양화 되고, 때로는 다른 산업까지 파급력을 높이고 있습니다. 본 컬럼에서는 애자일=IT 라는 편견을 좀 깨고자 이러한 지식체계를 구분하여 설명하고자 합니다. 

주요 Agile 지식체계 (방법론, 프레임워크)

• Lean Startup
• Lean
• Kanban
• Scrum
• DSDM
• SAFe
• DevOps
• XP
• FDD
• DAD
• Crystal
• ASD

Lean Startup

스타트업 회사를 만들고 관리하기 위한 방법론으로, 전체 산업분야에 대하 제품을 빠르게 출시하여 고객에게 전달하기 위한 기법으로, 원조는 모든 산업에 적용할 수 있는  비즈니스모델캔버스 로 국내에 많이 알려져있고, 이를 스타트업버전으로 축약시킨 내용이라고 이해하시면 됩니다. 

Lean

불필요한 업무를 제거하고 가치를 극대화히기 위한  프로세스에 중점화하는 기법입니다. “Lean/린”이라는 단어는 1990년대 도요타 생산시스템 (TPS, Toyota Product System)에 의해 버려야할 7가지 업태로 많이 알려졌고, PM 분야에서도 2000년도 중반부터 Value 라는 키워드로 확산되고 있고 있습니다.  

Kanban

진행/진척 업무를 가시적으로 보여주면서 통제함으로서, 전체 업무 흐름을 개선하고 시스템을 혁신하는 기법으로, 칸반은 이론보다는 예제만 보면 쉽게 이해가 됩니다.  http://bit.ly/agilepm-kanban. 개인적으로도 가장 손쉬운 프로젝트 관리 시스템으로도  배울 필요도 없이 현장에서 바로 적용하여 사용할 수 있는 Kanban을 추천합니다. 

Scrum

팀원들이 주기적인 시간제약 환경 속에서, 스스로 복잡한 업무/문제들을 해결해나가면서 제공할 수 있는 가치를 극대화하여 창의하고 생산성을 높이는 기법 

스크럼가이드(원문/원조) : http://www.scrumguides.org 

스크럼가이드(한글) : http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf

DSDM (Dynamic System Development Method, 혹은  Agile PM)

모든 산업분야에서 꾸준한 비즈니스 개선을 위해, 시간제약 환경하에서 주기적으로 시스템을 개선하기 위한 기법입니다. 영국/유럽에서는 DSDM을 바탕으로 Agile PM이라는 키워드로 확산되고 있는 앞서 설명드린 PRINCE2 Agile의 원조 개념이 되는 기법입니다. 

SAFe (Scaled Agile Framework)

(ICT특화) 대규모/엔터프라이즈 조직에서의 애자일 접근 기법으로 프로젝트, 프로그램, 포트폴리오 및 조직관리 차원으로 Agile을 적용하기 위한 기법으로 http://www.scaledagileframework.com 가 공식 홈페이지입니다. DAD와 더불어 아직까지는 Best Practice 보다는 개념으로 소개되고 있으며, PMI의 PMO ( PM > PgM > PfM 및 OPM3)의 개념과 상당히 매핑되는 분야가 많습니다. 

DevOps (Development & Operations)

(ICT특화) 제품이 개발되고 난 후 운영/AS 단계까지 확대되는 시점에 필요한 협력적 협업 기법으로 “개발 > 품질 > 운영”으로 이 역시도 개념만 있을 뿐 공식적인 실체/주관 기관이 없습니다.  이와 가장 유사한 개념인 Axelos의 PRICE2 와 ITSM 혹은 CMMi가 오히려 더 검증된 실무 체계이지 않나 싶습니다. 

XP (eXtreme Programming)

(ICT특화) Scrum 이나 Kanban 기법을 소프트웨어공학에 접목시켜 주기적으로 제품 형상화를 구체화하는 기법으로, 아무 극한의 상황에서 개발을 한다는 개념으로 이해하면 됩니다. 극한의 환경이란 개발/코딩을 함에 있어 짝으로 개발하고, 빌드/ 단위시험 / 짝개발협상/ 인수시험을 일일 기준으로 반복하여 주간 계획 및 월간 릴리즈 개념으로, 마치 로봇 처럼 일정간격으로 쉬지않고 극한 개발 환경을 구성한다는 개념입니다. https://en.wikipedia.org/wiki/Extreme_programming XP의 경우 Visual PMO 같은 PLM/ALM/SWE 도구가 필수적입니다. (공유폴더와 엑셀로 개발 프로젝트를 관리하는 시대는 구석기 시대죠 )

FDD (Feature Driven Development)

(ICT특화) 제품의 기능에 중심을 두고 주기적으로 소프트웨어개발 기법입니다. PM 개념으로 재해석하면 WBS  (Work Breakdown Structure)가 아닌 FBS (Feature Breakdown Structure) 개념으로 프로젝트를 주도하겠다는 개념입니다. 프로젝트가 아닌 제품 혹은 R&D 위주에서는 효과적인 방법인 것 같습니다. https://en.wikipedia.org/wiki/Feature-driven_development  흔히 일반분들의 오해가 WBS만 작성되면 프로젝트가 완료되는 줄 알고계시는데, 엄밀히는 WBS를 바탕으로 FBS 가 완성됨으로써 이를 기반으로 프로젝트를 성공시키는 개념이라고 봐야합니다. 

DAD (Disciplined Agile Delivery)

(ICT특화) 대규모/엔터프라이즈 프로세스 결정모델로, 사람중심-학습기반의 하이브리드 접근 기법. 리스크-가치 주도 라이프사이클로 대규모에 접합하며 확장성을 보유하고 있는 기법으로 DAD v2.0 모델부터는 SAFe 모델 + XP 모델 + DevOps의 조합과 유사합니다. 하지만 이또한 개념적으로만 접근한 모델이죠.  http://www.disciplinedagiledelivery.com

Crystal

(ICT특화) 주기적 개발 기법 (2001 출시)

ASD (Adaptive Software Development)

(ICT특화) 주기적 개발 기법 (2000 출시) 

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로 Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 본회는 6회로써 Agile 진영에서 이야기하는 도구와 기법에 대한 설명을 드리려 합니다.  작성 기준은 PMI에서 제시하는 PMI-ACP를 기준으로 하였습니다. 중요한 것은 이 모든 것을 다 수행하는 것이 아닌, 필요한 연장 목록을 가지고 적정하게 사용하는 것이 올바른 방식입니다. 

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다.  
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리 
• 4. Agile 역할과 책임 
• 5. Agile 지식체계  
• 6. Agile 도구와 기법 
• 7. Agile 10 실천 흐름 
• 8. Agile PMO 핵심 
• 9. Agile PMO 체크리스트
• 10. Agile PMO 모델 비교 

1. Agile 분석 및 설계 (Agile Analysis and Design)
2. Agile 예측 (Estimation)
3. 의사소통 (Communications)
4. 대인관계기술 (Interpersonal skills)
5. 평가지표 (Metrics)
6. 기획/감시 및 적응 (Planning, Monitoring, and Adapting)
7. 프로세스 개선 (Process Improvement)
8. 제품 품질 (Product Quality)
9. 리스크 관리 (Risk Management)
10. 가치 기반 우선순위 (Value-Based Prioritisation)

1. Agile 분석 및 설계 (Agile Analysis and Design)

• product roadmap: 제품이 나아가야할 방향 및 스펙이 간략이 언급된 문서 혹은 도식화로, 연간 혹은 적어도 몇 개월간의 제품의 형상 및 스펙에 관련된 문서
• user stories/backlog :  사용자의 이야기로서 요구사항에 관련된 문서와 이를 구현하기 위해 구체화한 명세 
• story maps : 사용자의 이야기를 마인드맵 등과 같이 구분/분류하여 도식화한 문서 
• progressive elaboration : 점진적 구체화로 요구사항 혹은 명세는 단번에 완성되는것이 아닌 점진적으로 완료시키는 기법 
• wireframes : 사용자 UX/UI를 목업 형태로 미리 스케치하는 기법 
• chartering : 제품/프로젝트의 가치/속성을 정의하는 문서 
• personas : 제품/모듈의 특성을 구분짓는 정의서 
• agile modeling : 
• workshops : 분석/설계시에 팀 구성원 (이해관계자 및 팀원)들과 함께 워크샵을 일이키는 기법 
• learning cycle : 실제 기획에서 구현까지의 사이클을 몇번 수행해보고, 이의 경험치를 바탕으로 설계를 상세히 하는  기법
• collaboration games :  Broken Skype, Crazy Chat, Collaborative Origami, Listening Game, Movers & Shapers, Human Knot, 123 go, Columbian Hypnotist, Non Musical Chairs, Yes and, Magic Stick, Singing Clapping Numbers. 등 협렵적 / 협업을 높이는 게임 기법으로, 자세한 설명은 무료 eBook 을 참고하세요. 

2. Agile 예측 (Estimation)

• relative sizing/story points/T-shirt sizing : 유사 업무로 예측하는 기법, T-셔츠 사이즈와 같은 스토리 포인트를 도출 기법 
• wide band Delphi/planning poker : 광활적 델파이 기법 / 플래닝 포커에 의한 집단 지성에 의한 의사결정 기법 
• affinity estimating : 유사성 기준으로 카테고리화 하는 기법 
• ideal time : 제품/모듈이 완료되어야할 이상적인 시간 제시 

3. 의사소통 (Communications)

• information radiator : 정보방열판으로 Kanban / 간판 보드로 많이 불림 
• team space agile tooling : Trello, Visual PMO와 같은 애자일 도구를 통한 팀 환경 구성 
• osmotic communications for co-located and/or distributed teams : 동일 지역 혹은 분석 팀을 위한 공감기법의 의사소통 기법 
• two-way communications (trustworthy, conversation driven) : 신뢰 및 대화 기반의 의사소통 
• social media–based communication : 기업형 SNS 도구를 활용한 의사소통 (예: Yammer , Slack ) 
• active listening : 적극적 청취 자세로 구성원들의 의견을 구체화하면서 수렴하는 기법  
• brainstorming : 브레인스토밍으로 구성원들과 비판없는 열린 아이디어 제시 도출  
• feedback methods : 안건에 대한 의견 제시 기법 

4. 대인관계기술 (Interpersonal skills)

• emotional intelligence : 감성지능 
• collaboration : 협업 기법 
• adaptive leadership : 적응형 리더십 
• servant leadership  : 섬김 리더십 
• negotiation : 협상 기법  
• conflict resolution : 갈등해결 

5. 평가지표 (Metrics)

• velocity/throughput/productivity : 가속도/ 생산성 측정 기법 
• cycle time : 업무 주기 완료 시간 측정 
• lead time : 업무 수행 완료 시간 측정 
• EVM for agile projects : 기성고 방식(PV, EV, AC, SV, CV, SPI, CPI, BAC, EAC, VAC, TCPI) 으로 프로젝트를 $으로 환산 측정
• defect rate : 업무 수행 대비 결함율 측정 
• approved iterations : 승인된 주기
• work in progress : 진척 상황 공유를 통한 측정 

6. 기획/감시 및 적응 (Planning, Monitoring, and Adapting)

• reviews :  단위 업무 혹은 주기 업무별로 리뷰 업무 수행 
• Kanban board:  칸반/간판 보드를 통한 계획 및 통제 기법 
• task board : 프로젝트 업무 보드 기법 
• timeboxing: 정해진 시간 제약 속에서 업무를 수행하는 기법 
• iteration and release planning : 주기 및 릴리지 계획 기법 
• variance and trend analysis : 
• WIP limits : 동시에 수행하는 업무를 제한하는 기법 
• daily stand ups : 매일 15-20분 범위내에서 서서 업무 공유/협의 미팅 기법 
• burn down/up charts : 번다운(계획대비 완료)/번업(생성대비 해결) 표에 의해 진척 기법 
• cumulative flow diagrams : 번다운/번업 기법의 누적 차트 기법 
• backlog grooming/refinement : 프로젝트 수행 환경 변수로 인해 백로그를 정비하는 기법 
• product-feedback loop : 제품 피드백을 순환적으로 계속 이행 기법 

7. 프로세스 개선 (Process Improvement)

• Kaizen : 6시그마에서 도입된 점진적으로 꾸준히 개선시키는 기법 
• the Five WHYs : 문제 / 요구사항의 근본을 확인하는 기법 
• retrospectives, introspective : 회고라는 단어로, 팀의 활용/개선점을 꾸준히 공유하는 기법 
• process tailoring/hybrid models : 프로세스를 팀에 맞게 적용시키거나, 다른 방법론들의 장점을 섞어서 적용하는 기법 
• value stream mapping : 가치 위주 흐름도를 만들어 진행하는 기법 
• control limits : 통제도에 의한 통제 기법 
• pre-mortem (rule setting, failure analysis) : 프로젝트 사전에 규칙 설정 기법 
• fishbone diagram analysis : 문제에 대한 원인 도출 기법 

8. 제품 품질 (Product Quality)

• frequent verification and validation : 잦은 적합성 검증기법
• definition of done : 검수조건 및 완료 기법을 명세화하여 업무 스펙을 명확히하는 기법 
• continuous integration : 꾸준한 빌드 통합으로 보통 SW개발 측면/XP(eXtreme Programming) 기법 중 하나
• testing, including exploratory and usability : 탐험적 혹은 사용성을 포함한 테스트 기법 

9. 리스크 관리 (Risk Management)

• risk adjusted backlog : 리스크 관리 명세 기법 
• risk burn down graphs : 리스크 소멸도 기법 
• risk-based spike : 리스크 해결을 위한 기술 검토 
• architectural spike : 리스크 구조 해결 검토 

10. 가치 기반 우선순위 (Value-Based Prioritisation)

• ROI/NPV/IRR : 투자수익율 ROI(Return On Investment), 순현재가치법(NPV, net present value), 내부수익율법(IRR, internal rate of return) 기법 
• compliance :  제품이 커버해야 할 산업 호환성 준수 여부 (예: 자동차 ISO26262, 헬스케어 IEC62304등) 
• customer valued prioritisation : 고객 가치 기반 우선 순위 기법  
• requirements reviews : 요구사항 리뷰 기법 
• minimal viable product (MVP)  : 제품의 최소한 기능 명세 
• minimal marketable feature (MMF) : 사장에서 필요로하는 명세 
• relative prioritization/ranking MoSCoW : 필수(must have), 있어야 함(should have), 있어도 됨(could have), 지금은 아님 (won’t have)이라는 구분 짓는 기법 
• Kano analysis : 고객의 환경을 이해하는 기법으로 기본, 흥미, 성능 요소등으로 구분짓는 기법 

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로 Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 본회는 7회로써 Agile 을 실행함에 있어서 올바름 흐름을 제시함으로써, 누구나 쉽게 글로벌 표준 흐름대로 쉽게 적용할 수 있는 실사구시 Agile 모델을 제시하고자 합니다. 

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다. 
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리
• 4. Agile 역할과 책임 
• 5. Agile 지식체계
• 6. Agile 도구와 기법
• 7. Agile 10 실천 흐름 
• 8. Agile PMO 핵심 
• 9. Agile PMO 체크리스트
• 10. Agile PMO 모델 비교 

1. Project Charter 
2. User Story 
3. Backlog 
4. Definition of Done 
5. Definition of Ready 
6. Story Point
7. Burn-down chart 
8. Sprint Plan 
9. Daily Scrum 
10. Sprint Review 

1. Project Charter 

Project Charter, 즉 프로젝트 헌장이란 프로젝트의 핵심 가치가 담겨있는 요약서 입니다. 이 프로젝트가 어떠한 가치 혹은 혜택을 내포하고 있으며, 마일스톤, 예산, 투입구성원, 특히나 PM 의 역할과 책임, 아울러 이를 승인하는 스폰서의 서명이 포함되어 있는 문서입니다.  사람에게 주민등록증이 있다면, 프로젝트는 차터가 이 주민등록증 처럼 고유 식별을 할 수 있는 것이죠. 차터는 일종의 암행어사의 마패 처럼, 암행어사/PM으로 하여금 왕/스폰서의 권한으로 추진하는 권한 위임장인 문서라 요약할 수 있습니다. 

2. User Story 

프로젝트 관리의 본질을 “고객의 요구사항을 만족시키는 것”입니다. 이를 위해 프로젝트 관리의 첫 단추인 요구사항을 체계적으로 수집하고 관리하고 갱신하는 것은 매우 중요한 업무입니다. Agile에서는 이러한 요구사항을 User Story라는 명세로 관리하고 있습니다. 철저하게 고객 관점에서 “나는 OO로서 OO을 해야한다. 그럼으로 인해서 OO을 얻는다”라는 사용자/고객의 시각으로 정리하는 것입니다. 서술식으로 누구나 쉽게 이해할 수 있도록 작성 되며, 후에 단위 업무 설계의 기초/반석이 됩니다. 

3. Backlog

모든 프로젝트에 없어서는 안되는 소통 기준선이 WBS(Work Breakdown Structure)입니다. WBS가 없는 프로젝트는 프로젝트가 아니죠. 애자일 진영에서는 WBS 역할을 해주는 프로젝트 기준선이 Backlog 입니다. 차이는 WBS 경우 업무 기준으로 분류가 된다면, Backlog는 형상 기준으로 분류가 된다는 점입니다. 다른 말로 이야기하면 자전거를 만들때  WBS는 자전거 부품을 준비한다 > 자건거를 조립한다 > 자전거를 검수한다 > 자전거를 납품한다 형태로 계층구조도가 만들어지는 반면, Backlog는 프레임, 핸들, 안장, 앞바퀴, 뒤바퀴, 체인, 브레이크 등 제품을 형상하는 구조화를 시키는 것이 다르죠. 어찌보면 Backlog 자체를 구체적으로 시각화 할 수 있습니다. 이러한 백로그는 프로젝트 팀원들과 소통하는 기준이 됩니다. User Story는 고객과의 소통 기준이라면, Backlog는 엔지니어와의 소통 기준인 것이죠. 즉 PM은 고객언어와 엔지니어 사이에서 이 Backlog를 기준으로 명확하게 소통해주어야 합니다. 

4. Definition of Done

앞서 Backlog 기준의 단위 업무 (Work) 혹은 단위 기능 (Feature)도 중요하지만, 이의 완벽성을 기하기 위해 필!수!적!으로 Definition of done , 즉 검수조건이 중요합니다. 해당 기능이 다 되었는지 아닌지를 판단할 수 있는 판단 근거가 되는 것이죠. 애자일의 성숙도가 높은 기업은 이러한 검수조건을 상당히 체계적으로 관리하고 있습니다. ICT 분야에서는 이러한 항목이 테스트케이스, 테스트셋 (단위시험, 인수시험) 등으로 불리기도 합니다. 

5. Definition of Ready

단위 업무를 수행, 혹은 단위 기능을 개발하게 될 때 유사한 것을 먼저 개발하는 것이 효율적일 것입니다. 기 정의된 Backlog 와 Definition of done을 기준으로 유사한 것을 그룹화하여 묶어 놓고, 이의 친화성 및 우선 순위를 매기는 작업을 해야, 향후 프로젝트를 수행 일정을 수립할 때 기준 자료가 될 수 있습니다. 

6. Story Point

보통 PM 진영에서는 프로젝트 일정을 Delphi , PERT, Parametric Estimation 기법을 이용해서 수립하는데 반해서, Agile 에서는 이를 팀원들이 Backlog와 검수조건을 기초로 하여 팀원 모두가 개발 시간이 얼마나 걸릴 것인지를 서로 이야기하여, 이를 평균값으로 구해줍니다. 이렇게 함으로써 팀원 모두가 프로젝트 전체 형상과 업무에 대해 모두 이해하게끔 되는거죠. 초기에 시간은 걸리더라고 팀원 모두 프로젝트의 가치와 구체성을 형상화하는 과정에 참여한다는 의미가 있습니다. 

7. Burn-down chart

프로젝트 진척은 일반적으로 Gantt 차트를 많이 사용합니다. Gantt 차트의 구성을 보면 할일(WBS)과 이의 연계성, 시작예정일과 종료예정일을 기준으로 일정(Bar Chart) 계획 및 실적을 관리하게 끔 되어있습니다. 즉 일정을 기준으로한 진도율이 기준이라는 것이죠. 애자일에서는 일정 기준 진도율이 아닌 Backlog가 총 몇개이고 몇 개가 남았는지를 가지고 이야기 합니다. 다시말해 작업의 개수, 혹은 형상/기능의 개수를 가지고 프로젝트를 관리하게 되고 이를 시각적으로 표현한 것이 Burn-down 차트(소멸도) 입니다. 프로젝트 관리를 아주 깔끔하게 시각적으로 관리해주는 도구요. Burn-down 차트는 일정을 기준으로 작성되고 앞서 범위에 대한 user story, backlog, definition of done  항목은 칸반보드 (간판보드, Kanban, Information-radiators)에서 시각적으로 관리합니다. 

8. Sprint Plan 

일반적인 프로젝트가 주간 < 월간 < 마일스톤 계층 개념으로 계획 수립이 이루어 진다면, 애자일에서는 2주에서 3주 단위로 업무를 균등하게 계획 수립을 하게 끔 됩니다. 즉, 주간이라는 단어보다는, 2-3주 단위를 하나의 Iteration 혹은 Sprint라는 단어로 사용하게 됩니다. 그리고 이러한 2-3주 기간 동안에 해야할 사항에 대해 구체적으로 명세화 하되, 최대 4시간을 넘지 않는 범위내에서 기획하게 되며, 이 기획에는 Risk에 대한 기획 또한 포함됩니다. 이 과정을 통해 범위는 칸반/Kanban, 일정은  소멸도/Burn-down에 정밀하게 표현이 되며, 단기적인 업무 계획/목표가 되는 것입니다. 

9 Daily Scrum

프로젝트 일정 현황 공유를 매일매일 기립 회의 형태로 하루 15-20분을 넘지 않는 범위로 수행합니다. 서서하는 이유는 회의를 효율적으로 하기 위해서이고, 이때의 진행 방법은 PM이 팀원들에게 지시하는 것이 아닌, 팀원 스스로가 본인이 작성한 Backlog와 Definition of done을 스스로 일일의 완료사항과 계획사항을 돌아가면서 이야기하도록 가이드 합니다. 이 행위는 결국 팀원 스스로의 동기부여/Self-motivation 정신으로 업무를 수행할 수 있는 환경을 만들어줍니다. PM은 단지 질문으로 팀원들이 자각할 수 있게만 하면 됩니다. 

10. Sprint Review

프로젝트에서 중요한 것은 꾸준한 개선입니다. WBS/Backlog는 Rolling Wave라는 항목을 써서 점진적으로 구체화 하듯이, 프로젝트의 경험은 쌓이고 쌓여서 점진적으로 효율성이 개선되어야 합니다. 이에는 좋은 점은 계승 발전시키고, 개선한 점은 도출하여 개선, 안좋은 점은 재발되지 않도록 모든 팀원이 인지하고 동반성장해야 합니다. 이러한 분위기, 개선/Kaizen 환경에서 프로젝트를 수행할 수 있도록 해주는 것이 스프린트 리뷰활동입니다. 이의 핵심 activity는 회고/Retrospective인데, PM쪽에서는 이를 교훈/Lessons Learned라고 불르기도 합니다. 애자일을 잘 수행하는 조직은 이러한 교훈/회고/리뷰 문화가 잘 구현되어 있고, 이를 언제라도 열람/조회/활용할 수 있도록 KM/지식DB 화 하여 관리하고 있습니다. 

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로 Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 본회는 8회로써 Agile 핵심을 마치고 Enterprise Agile 로 확장함에 있어서 무엇을 핵심 가치로 두어야 하는지에 대해서 이야기 하고자 합니다. 

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다. 
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리 – 무엇을 먼저해야 의미가 있을까?
• 4. Agile 역할과 책임 – 업무에 책임지고 집중할 수 있는 환경을 구축
• 5. Agile 지식체계 – 목적에 적합한 방법론 및 프레임워크를 맞춤식으로 도입하여 꾸준한 개선을 하는 것이 올바른 방식입니다.
• 6. Agile 도구와 기법 – 처해진 환경에 적합한 연장을 올바르게 사용 하기
• 7. Agile 10 실천 흐름 – 글로벌 표준 흐름으로 프로젝트의 경장 유지
• 8. Agile PMO 핵심 – Enterprise Agile도 PMO 관점으로 접근해야 합니다. 
• 9. Agile PMO 체크리스트
• 10. Agile PMO 모델 비교 

프로젝트리서치의 접근방법은 Global 표준을 기반으로 실사구시 측면에서 실용적으로 접근하는 기법을 이용하고 있고, PM은 ISO-21500, PMBOK 및 PRINCE2 범주 안에서 PMO는 PMI PMO, Program, Portfolio 및 OPM3 범주 안에서 Activity를 이루고 있습니다. Agile의 경우 PM 진영에서 바라보는 PMI ACP 시각과 AXELOS의 PRINCE2 Agile 범주 안에서 움직이고 있죠. 문제는 단일 프로젝트 관리를 위한 Agile framework은 존재하는데 반해, 멀티 프로젝트 관제를 위한 Agile framework, 즉 Enterprise Agile (혹은 Agile PMO) 의 글로벌 표준은 존재하지 않는다는 것입니다. 단지 실무적으로  SAFe 3.0 혹은 Less  정도가 제시되고는 있으나 글로벌 표준은 아니고, 구체적인 process 위주의 항목까지 작성되지 않았습니다. 대안으로 PMO 진영에서의 framework을 최대한 Agile focus화하여 접근하는 방법이 가장 실수를 덜하는 방식이라고 할 수 있을 것 같습니다. Enterprise Agile에 대해서 잘 설명한 “Enterprise Agile Made Easier” 을 요약 번역하는 것으로 Agile PMO를 설명하고자 합니다. 

1. 포트폴리오, 프로그램, 프로젝트 관리 구분 

앞서 7회에 걸쳐서 단일 프로젝트 관리에 집중을 했다면, Agile PMO (Enterprise Agile)에서는 프로그램과 포트폴리오의 시각으로 고도화하여 관제를 해야합니다. 

포트폴리오 관리는 회사의 가치를 극대화 하기 위해서 자원, 우선순위와 비즈니스 기회를 수립하고 실현화 시킵니다. 포트폴리오의 가장 핵심적인 질문은 “우리가 우리의 전략에 부합하는 극대의 투자대비 효과를 극대화 시키고 있는가?”라는 점입니다. 포트폴리오 관리자는 비즈니스 착수에 필요한 자금을 승인하고, 지출되는 항목에 대해 올바르게 진척/공정사항을 리뷰하는 것입니다. 

프로그램 관리는 선정된 사업의 실현을 위해 최소의 자원으로 최대의 효과를 내기 위한 일련의 코디네이션입니다. 프로그램 관리는 사업의 전략의 실현시키기 위한 연결 고리 역할을 하여, 인도물과 인도물 구현에 필요한 자원을 구체화합니다. 추가적으로 회사의 포트폴리오 전략맵, 비즈니스에 대해 기대하고 있는 가치를 올바로 반영하기 위한 대한 정보와 추진 사항 갱신을 책임집니다. 일반적으로 Agile PMO (Enterprise Agile) 에서는 특정 제품과 제품 라인에 특화되어 관리합니다. 포트폴리오는 하나 이상의 프로그램으로 구성된 것이죠. 

프로젝트 관리는 실제 동작하는 제품을 높은 품질 수준으로 효과적으로 인도하기 위해 구성원들을 조직하고, 도구를 적정히 사용하는 것을 의미합니다. 프로젝트 관리자는 구현되고 있는 결과물/인도물에 책임이 있습니다. 추가적으로 프로젝트 관리자는 상위 프로그램 관리자에게 프로젝트 현황을 항상 보고하며 갱신합니다. 

2. Agile 관리 원칙 

각각의 프로젝트, 프로그램, 포트폴리오에서 바라보는 관점이 다르고, 많은 점이 유사해 보이지만, 차이점에  맞춰 각각의 계층별로 명확한 의사소통과 더불어 관리해야합니다. 결국 단일 프로젝트를 위한 Agile 가치와 원칙들이 기업용으로 명확하게 구분하여 관제되어야 한다는 것입니다. 

가치 기반으로 리더는 비전을 제시하고, 팀원들은 팀은 각각의 흐름 기반의 업무 항목을 협업하여 협업하는 것을  프로세스화 하여 꾸준한 개선을 촉진시키는 것이 Agile PMO 의 역할이라고 할 수 있습니다. 

3. 가치에 기반을 둔  “높은 성과 조직” 

대규모 기업이 임원진인  CxO (C-Level)에서 모든 프로젝트<프로그램<포트폴리오를 정확히 구분하여, 이것이 기업에 미치는 영향력을 가치를 기반으로 움직여야 한다는 점과 Product 리드팀, 기업 아키텍트팀, 출시팀, 시스템팀, 개발팀, 콤포넌트팀 및 기능팀으로 구분하여서 프로젝트,프로그램,포트폴리오에 부합되는 역할로 회사의 모든 프로젝트를 올바로 관제할 수 있는 구조가 되는 것입니다. 

 4. 계층화 및 워크플로우 

이러한 계층은 사업기획/가시화에서 기능으로, 기능에서 이야기로 계속 Breakdown 분류체계를 이뤄나가는 것을  Rolling-wave형태로 계속 반복해서 구체화시켜야 합니다.  

5. 꾸준한 개선

중요한 것은 Agile 뿐만 아니라 Agile PMO도 한때의 유행으로 지폈다 꺼지는 한때 인기의 기법이 아닌, 기업이 존재하는 한 모든 조직에서 끊임없이 회고하고 개선하고 하는 것들을 기업 문화로 정착시켜 버려야지 올바른 관리를 할 수 있다는 것이 Agile PMO (Enterprise Agile)의 핵심 가치 입니다. 제가 생각하기에 Agile , Agile PMO 모두 중요한 키워드가 “회고 기반의 개선 문화 정착” 이라고 해도 과언이 아닐 것 같습니다. 

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로 Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 본회는 9회로써 Agile PMO를 구성하기 위한 기본 체크리스트를 점검해 보고자 합니다.  

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다. 
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리 – 무엇을 먼저해야 의미가 있을까?
• 4. Agile 역할과 책임 – 업무에 책임지고 집중할 수 있는 환경을 구축
• 5. Agile 지식체계 – 목적에 적합한 방법론 및 프레임워크를 맞춤식으로 도입하여 꾸준한 개선을 하는 것이 올바른 방식입니다.
• 6. Agile 도구와 기법 – 처해진 환경에 적합한 연장을 올바르게 사용 하기
• 7. Agile 10 실천 흐름 – 글로벌 표준 흐름으로 프로젝트의 경장 유지
• 8. Agile PMO 핵심 – Enterprise Agile도 PMO 관점으로 접근해야 합니다. 
• 9. Agile PMO 체크리스트 – 향후 10년 Enterprise Agile 도약을 위한 반석 체계
• 10. Agile PMO 모델 비교 – 전체적인 거버넌스 체계 안목이 있어야 올바른 관리 체계 이행이 가능합니다. 

단일 프로젝트의 Agile 관리 체계와 수십개 수백개의 프로젝트에 대한 동시 관제 체계는 구분되어야 합니다. 즉 개인의 Agile 프로젝트 관리 기법과 조직/기업의 Agile PMO 관리 기능은 “회고/교훈을 바탕으로한 꾸준한 개선”이라는 주제로 각기 다른 대상으로 접근해야한다는 것이죠. 제가 Agile PMO 컨설팅 하면서 사용하는 PMI PMO 기준의 점검 항목지 입니다. 프로젝트, 프로그램, 포트폴리오 및 조직 관리에 해당하는 5대 구분 24 기능으로 되어있습니다. 

1. 프로젝트 성과 감시 및 통제

• 경영진에게 프로젝트 상태 보고  – 기업내에서 일어나고 있는 모든 프로젝트 현황에 대해 정량적 및 정성적으로 일목요연하게 정리되어 보고되어야 합니다.
• 프로젝트 성과 감시 및 통제 – 모든 프로젝트는 기준선/Baseline을 가지고 있어야 하고, 이 기준선에 대비한 준수여부 및 갭 관리를 해야합니다. 
• 프로젝트 정보 시스템 구현 및 운영 – PMO/ALM 도구와 같이 모든 구성원이 통합적으로 프로젝트를 기획 > 구현 > 검수 및 변경/통제/이슈에 대해 단일한 시스템으로 업무를 진척해야 합니다. 
• 프로젝트 스코어보드 개발 및 유지 – 기준선/Baseline 준수율, 공정율, EVM(기성고), Value 등등 회사가 지향하는 방향에 대해 해당 항목이 KPI 화 되어 꾸준한 개선을 위한 기초 항목으로 관리 되어야 합니다. 

2. PM 역량 및 방법론 개발

• 표준 방법론 개발 및 시행 – Waterfall, Agile , Water-Agile-Fall (Hybrid Agile)등 회사내의 표준 방법론에 대해 글로벌 표준을 바탕으로 존재의 의미가 아닌 적용/실제의 실사구시를 위해 테일러링 되어야 합니다. 
• 조직내 프로젝트 관리 촉진 – 프로젝트 관리는 담당자만 있다고 되는 것이 아닙니다. 임원진/C-Level 역시 전사적인 관점에서 가치 기준선을 바탕으로 프로젝트를 올바르게 바라봐 주어야 하고, 이를 전사적으로 통일된 시각으로 거버넌스 할 수 있게끔 담당자들을 통해 촉진제 역할을 해주어야 합니다. 
• 교육 등을 포함한 역량 강화 – 회사의 프로젝트 관리는 똑똑한 인재 몇 사람이 하는 것이 아닙니다. Stakeholder/이해관계자 – Sponsor – Boss – 팀원 모두가 동일한 시각과 동일한 언어로 프로젝트 소통을 해주어야 합니다. 이는 몇몇 우수한 PM의 언어가 아닌, 글로벌 표준 프로젝트 관리 언어로 접근을 해야 불필요한 오해없이 오로지 프로젝트 언어로 프로젝트 기준선을 가지고 투명하게 소통할 수 있습니다. 이를 위해서는 PM뿐만이 아닌 Stakeholder, Sponsor 및 프로젝트 팀원까지도 최소한의 프로젝트 관리에 대한 역량/지식이 필요합니다. 
• PM을 위한 멘토링 – PM에 의해서만 프로젝트가 관리되는 조직은 위험 합니다.  운동 선수들고 코치가 필요하고, 전문 뮤지션도 보이스 코치가 필요하듯이 PM 역시도 이를 객관적인 입장에서 PM의 전문성을 높이기 위한 혹은 해당 프로젝트의 객관성을 높이기 위한 코칭이 필요합니다. 
• 표준화된 도구 제공 – 조직이 커지면 커질수록 문제가 생기는 부분이 단일 도구입니다. 개인별로 혹은 조직별로 도입한 도구들이 전사적으로 하나로 합쳐지지 못하고 별개의 시스템으로 동작할 때, 이만큼 거버넌스에서 어려운 것도 없습니다. 동일한 기준선의 시각으로 동일한 언어로 이야기하는 것도 중요하고, 동일한 도구로 누구나 혼돈 없이 프로젝트에 임할 수 있게끔 하는 환경도 중요합니다. 

3. 멀티 프로젝트 관리

• 프로젝트 간의 조율 – 모든 프로젝트를 다 잘하는 것도 중요하지만, 한정된 자원으로 프로젝트에 임하다보면 프로젝트 자원을 바탕으로한, 혹은 프로젝트 들간의 선후행을 바탕으로한 프로젝트의 조율이 매우 중요합니다. 특정 부서이기주의 혹은 직급이 높은 사람이 있는 프로젝트에의해 다른 프로젝트들이 좌지우지 되어서는 안되는 것이죠. 
• 새로운 프로젝트 식별, 우선순위 및 선택 – 프로젝트를 수행할 시 매출 뿐만 아니라 편익과 가치에 바탕으로 프로젝트를 선정해야할 것 입니다. 궁극적으로 가치적인 측면으로 접근하면, 프로젝트 팀원들 또한 프로젝트를 바라보는 시각이 바뀌게 됩니다. 
• 하나 이상의 포트폴리오 관리 – 회사가 다수의 포트폴리오를 어떻게 가져가는지 역시도 가치 관리의 큰 맥락 중의 하나입니다. 
• 하나 이상의 프로그램 관리 – 여러개의 프로젝트가 융화되어 있는, 즉 상호 연관성이 있고 동일한 그룹에 있는 멀티프로젝트를 프로그램이라고 합니다. 국내는 프로그램이라는 메가프로젝트, 빅 프로젝트등의 다른 언어로 쓰이고 있지만 표준 용어로는 프로그램 관리입니다. 하나의 프로그램은 여러 PM과 같이 융화되어야하고, 이중 Focus를 개발과 운영, 아울리 이익에 중점을 두고 프로그램 관리를 체계적으로 향상 시켜야 합니다. 
• 프로젝트 간의 자원 배정 – 회사의 모든 일은 궁극적으로 제한된 인력을 포함한 자원으로 해야합니다. 프로젝트, 프로그램, 포트폴리오와 가치와 우선 순위에 따라 이러한 자원간의 배정/배분 아울러 공정한 레벨링과, 평가와 보상체계가 중요합니다. 

4. 전략/가치 관리

• 고위 경영진에 대한 조언 – 프로젝트/프로그램/포트폴리오가 올바른 가치와 명확한 기준선이 수립되어 통제되기 위한 모든 계획 뿐만 아니라 걸림돌이 보고 되어야 합니다. 이는 글로벌 표준 체계에 의해 투명하게 조언되어야지, 개인의 사욕을 바탕으로한 공중지사(公中之私)의 내용이면 안됩니다. 
• 전략 기획에 참여 – 회사의 전략은 임원뿐만 아니라 이러한 회사내의 프로젝트/프로그램/포트폴리오 관리 전문가 그룹인 (Agile) PMO 조직 역시도 포함하여 전략을 추구해야 합니다. 임원이 가야할 방향에 대한 제시라면, (Agile) PMO는 방향/목표까지 가기위한 전략과 전술 아울러 체력까지 구체적인 단계까지도 기획을 하는 것이죠. 이것이 올바른 가치관리의 첫 시작입니다. 
• 가치/이익 관리 – 회사에서의 가장 중요한 것은 물론 이익이겠지만, 이보다 상위에 있는 개념이 “가치”라는 측면입니다. 가치가 없는 이익은 영혼없는 육체와 같죠. Agile의 핵심 철학은 회사내의 모든 구성원이 건전한 혹은 올바른 가치를 추구하고, 이를 바탕으로 자발적인 동기부여를 유도하는 것이 첫 시작입니다. 
• 네트워킹과 주위 환경에 대한 조사 – 프로젝트는 나 혼자 하는 것이 아닌, 주변 혹은 협력사, 아니면 프로젝트/프로그램/포트폴리오로 도출되는 제품이나 서비스를 사용하여 또 다른 가치를 만드는 고객을 포함한 이해관계자들의 전체적인 조화입니다. 이는 “꾸준한 개선”이라는 테마로 항상 열린 마음과 투명한 공정 관리를 통해서 이루게 되는 것이죠. 

5. 조직 관리

• PMO 성과 감시 및 통제 – PMO는 기업 내의 모든 프로젝트에 대해 기준선을 가지고 있어야 합니다. 아울러 그 기준선은, 그 조직의 체력에 바탕으로한 현실적인 기준선이어야 하는 것이죠. 목표치를 너무나 가혹하게 이상적으로 수립하고, 이를 팀원에게 강요하는 것은 단기적인 실적은 가능할 지언정, 장기적인 측면으로는 마이너스입니다. 현재 조직원들의  velocity를 바탕으로한 합리적인 기준선/Baseline을 바탕으로, 이를 적정한 시점에 적정한 관점으로 감시하고 통제하면서 기준선/Baseline대비 현재선/Actualline의 차이/Gap을 최소화 해야하는 것이 글포벌 표준이 제시하는 가이드입니다. 철저하게 객관적인 시각을 유지하는 것이죠. 
• 프로젝트 문서 보관 관리 – 프로젝트의 산출물 및 인도물들은 회사의 지식DB에 archive 되어야 하며, 누구나 해당 문서를 열람하고 활용할 수 있어야 합니다. 이것이 “꾸준한 개선”을 위한 기반 환경입니다. 
• 종료 프로젝트 리뷰 실행 – 아울러 프로젝트의 모든 게이트웨이/마일스톤 혹은 종료 단계에서는 해당 프로젝트에 대한 Review 를 필히 거처야지만 좋은 점은 다음 프로젝트에 적용하여 개선할 수 있고, 개선점 역시도 다른 프로젝트에 적용하여 개선할 수 있습니다. 프로젝트 리뷰는 프로젝트 팀원/조직의  velocity 의 기준데이터는 물론, 회사 자산내에서 Risk / 교훈 DB 로 저장되고 활용되어야 합니다. 
• 프로젝트 감사 실행 – 모든 프로젝트는 프로젝트 감사를 실행해야 합니다. 회사/조직의 혹은 프로젝트의 policy를 잘 지키고 있는지, Value 측면에서 혹은 EVM 측면 아니면 다른 프로젝트/프로그램/포트폴리오가 가지는 특성적인 측면에서 투명하게 관리되고 있다는 confidence를 가지고 있어야 불협화음 없이 조직의 프로젝트를 잘 관제할 수 있게 되는 것입니다. 
• 교훈/회고 DB 실행 및 관리 – 모든 프로젝트의 경험과 교훈은 데이터베이스화 되어서 누구라도 열람하고 활용할 수 있어야 합니다. 
• 리스크 DB 실행 및 관리 – 아울러 프로젝트의 문서, 감사, 교훈/회고 자료들은 주기적으로 전사적 포트폴리오, 프로그램, 프로젝트 RISK DB에 갱신되어 재사용 되어야 합니다. RISK는 Negative 리스크 뿐만 아니라 Positive RISK 측면으로도 관리되어야 하며, 각각의 항목이 정성적 뿐만 아니라 정량적인 항목으로 기록이 되어있어야 ‘꾸준한 개선’을 위한 기초적인 예측 및 대응계획이 명확히 수립될 수 있습니다. 

상기 프로젝트, 프로그램, 포트폴리오 및 조직 관점에서 Agile PMO 의 체크리스트를 살표보았습니다. Agile PMO라고 해서 표준 PMO 체계와 별반 다른 것이 없습니다.  모두 다 “가치를 향한 꾸준한 개선”으로 집중되어 있다라고 보시면 되겠습니다.  

“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로 Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 본회는 마지막 10회로써 Agile PMO 프레임워크의 종류 및 구성에 대해 설명하고자 합니다. 

[Agile PM/PMO 연재 순서]

• 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다. 
• 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
• 3. Agile 가치 관리 – 무엇을 먼저해야 의미가 있을까?
• 4. Agile 역할과 책임 – 업무에 책임지고 집중할 수 있는 환경을 구축
• 5. Agile 지식체계 – 목적에 적합한 방법론 및 프레임워크를 맞춤식으로 도입하여 꾸준한 개선을 하는 것이 올바른 방식입니다.
• 6. Agile 도구와 기법 – 처해진 환경에 적합한 연장을 올바르게 사용 하기
• 7. Agile 10 실천 흐름 – 글로벌 표준 흐름으로 프로젝트의 경장 유지
• 8. Agile PMO 핵심 – Enterprise Agile도 PMO 관점으로 접근해야 합니다. 
• 9. Agile PMO 체크리스트 – 향후 10년 Enterprise Agile 도약을 위한 반석 체계
• 10. Agile PMO 모델 비교 – 전체적인 거버넌스 체계 안목이 있어야 올바른 관리 체계 이행이 가능합니다. 

Agile PMO, 즉 Enterprise Agile 을 올바르게 갖추고 조직의 민첩성을 높이면서 점진적 개선하기 위해서는 이의 근간이 되는 framework을 튼튼히 가져가는 것이 상당히 중요합니다. 경험적 바탕도 중요하지만, 무엇보다도 글로벌 표준을 바탕으로 테일러링 해야 향후에 모델 확장에서도 유리하고 compliance 인증 체계를 통한 Project Assurance를 확보할 수 있는 것이죠. 현존하는 (혹은 가장 근접한) Agile PMO 의 Framework을 소개하는 것으로 본 연재를 마치고자 합니다. 

1. PMI PMO : http://www.pmi.org/

PM 분야에서 전세계에서 가장 영향력이 큰 조직이 PMI라는 기관입니다.  프로젝트 관점으로 프로젝트 관리 (범위, 일정, 원가, 리스크, 형상 가이드 포함)  < 프로그램 관리 < 포트폴리오 관리 및 조직성숙도 모델, 개인역량관리 모델을 가지고 있습니다. 아울러 프로젝트 < 프로그램 < 포트폴리오 및 조직과 개인 역량을 하나로 합친 “PMI PMO” 가이드 문서가 있습니다. [Agile특집] Agile PMO 체크리스트 – 향후 10년 Enterprise Agile 도약을 위한 반석 체계 에서도 이러한 PMI PMO 체크리스트를 요약 정리해 놓았으니 참고 하시기 바랍니다. 

PMI의 PMO의 Framework의 큰 구조는  프로젝트 < 프로그램 < 포트폴리오 및 조직관리 체계에 아우리는 지식체계와 체크리스트 기반으로 구성되어 있다고 보시면 되고, 각 회사마다 처해진 상황이 다르기 때문에 PMO 역할 구분이 되어 있다고 보시면 됩니다. 

2. AXELOS P3M3 : https://www.axelos.com

유럽 AXELOS (구 OGC/영국) 진영에서의 프로젝트 관리 표준 체계도 상당히 실용적이고 실증적으로 구성이 되어 있습니다. 프로젝트 < 프로그램 < 포트폴리오 및 PMO 및 조직역량체계는 물론 운영관리 체계까지 전체적인 Framework이 갖춰져 있습니다. 앞서 PMI 진영이 지식체계로 구성되어 있다면, AXELOS는 R&R, 체크리스트, 템플릿이 가미된 실무체계로 구성되어 있다고 보시면 됩니다. 

3. SAFe (Scaled Agile Framework) : http://www.scaledagileframework.com

앞서 PMI 및 Axelos 가 정통 PM 진영에서의 PMO 체계라면, Agile 진영에서 나온 첫 Agile PMO 체계이지 않나 싶습니다.  역시나 구성은 프로젝트 < 프로그램 < 포트폴리오 및 조직관리 체계로 구분이 되어있어서, 각각의 레벨 및 단계에서의 역할과 규정이 정해져 있습니다. 아직까지는 지식체계, 체크리스트 체계가 없는 단순한 구조도이지만, 향후 계속 발전되지 않을까 싶습니다. 전체적인 맥락은 PMI 혹은 Axelos과의 구조가 동일하다라고 보시면 됩니다.  전문컨설턴트 인증 프로그램과 같은 자격체계로 영역을 확산하고 있습니다. 

4. LeSS (Large-Scale Scrum) : http://less.works 

전 노키아 지멘스 네트웍에서의 경험을 바탕으로 만든 LeSS Frmwork을 Crag & Bas  두 사람에 의해 만들어 졌고, 이에 대한 실무적 연합이 네덜란드를 기반으로 만들어지고 있는 중입니다. 아직 큰 인지도는 없지만 몇몇 컨설턴트에 의해 사용되고 있는 Framework 입니다. 

이렇게 크게 PMI, AXELOS, SAFe 및 LeSS 와 같은 Agile PMO 프레임워크를 알아 보았습니다. 전체적으로 Agile의 경우 프로젝트 관리 방법론과 SW공학이 섞여 있는 만큼 분별있는 구분과 Enterprise 레벨에 맞는 성숙도 모델을을 개발하여 지속적으로 이를 측정하고 발전시켜야 한다고 생각합니다. 아직까지는 Enterprise Agile (Agile PMO)에 대한 표준 Standard가 없는 편이어서 가급적 PM/PMO 기반의 Enterprise Project Governance 시각으로 프레임워크를 테일러링하는 것이 올바른 시작 방법인 것 같습니다.