로그인 회원가입 고객센터
레포트자기소개서방송통신서식공모전취업정보
카테고리
카테고리
카테고리
카테고리
campusplus
세일즈코너배너
자료등록배너

성공한 PMO의 가치는 프로젝트 끝난 뒤 더욱 빛난다


카테고리 : 레포트 > 기타
파일이름 :091130110237_.jpg
문서분량 : 1 page 등록인 : etnews
문서뷰어 : 뷰어없음 등록/수정일 : 09.11.26 / 09.11.26
구매평가 : 다운로드수 : 0
판매가격 : 300

미리보기

같은분야 연관자료
보고서설명
성공한 PMO의 가치는 프로젝트 끝난 뒤 더욱 빛난다
본문일부/목차
차세대 시스템을 왜 굳이 ‘차세대(Next Generation)’라고 부를까? 예산과 인력, 시간 등 자원이 많이 투입됐기 때문일까? 만일 이런 이유로 차세대라는 수식어를 붙인다면 앞으로 웬만한 기업이 새로 구축하는 시스템은 모두 차세대시스템이라고 불러야 할 것이다.
 금융권을 중심으로 2000년대 초반부터 시작된 리호스팅 움직임이 차세대시스템 구축으로 확대된 것은 기업 IT 환경을 근본적으로 재검토해야 할 필요성이 커졌기 때문이다. 엄청난 비용과 인력이 필요한 프로젝트를 진행하면서 리스크 부담이 큰 빅뱅 방식으로 구축한 것도 이런 점에서 불가피한 선택이었다.
 PMO 조직과 서비스가 등장한 것도 방대하고 복잡한 프로젝트가 제대로 관리하기 위한 것이었다. 하지만 프로젝트 진행 과정의 위험을 관리하고, 성공 가능성을 높이는 것은 PMO 서비스가 갖는 의미의 일부에 불과하다. PMO 서비스가 진정으로 가치를 발휘하는 것은 차세대시스템 프로젝트가 완료된 시점 이후부터라고 해도 과언이 아니다.
 ◇차세대시스템의 진정한 가치는 ‘경험’=차세대 프로젝트나 PMO에 참여한 인력은 시스템 오픈과 동시에 원래 업무로 복귀하는 것이 일반적이다. 그리고 같은 조직에서 대형 프로젝트가 다시 발생할 경우 과거 프로젝트나 PMO를 경험한 인력들이 새로운 프로젝트에 참여하는 경우는 드물다. 결국 경험이 적은 인력들이 선배들이 겪었던 것과 똑 같은 고민과 고생을 되풀이하는 것이 현실이다.
 이것은 차세대 프로젝트의 소중한 경험과 자산을 낭비하는 것이나 마찬가지다. 시스템이 오픈된다고 해서 프로젝트가 마무리되는 것은 아니다. 오히려 그 시점부터 CIO는 △현업과의 관계 재설정 △IT 프로세스를 개발 중심에서 운영 중심으로 전환하는 방법 △운영 중심의 IT조직 재구성 △IT 인력의 재배치와 교육 등 과제들을 붙잡고 씨름하게 된다.
 차세대시스템 오픈 후 옛날과 같은 모습으로 IT 운영 조직을 구성할 경우 CSR(Customer Service Request:현업 개선 요청 사항) 처리가 점점 지연되고 결국 새로운 개발 프로젝트로 문제를 원점부터 다시 해결해야 하는 악순환에 빠져들 수 있다. 이런 고민과 악순환은 차세대 프로젝트 및 PMO 활동에서 얻은 역량을 잘 보존하고 활용하는 것으로 해결할 수 있다.
 물론 궁극적인 대안은 운영 시점부터 장기간에 걸쳐 안정적으로 진행 가능한 IT 거버넌스 체계를 수립하는 것이다. 하지만 이것은 원론적, 이상적인 목표며 국내 기업의 현실로 봤을 때 앞으로도 상당 기간 현실화하기 어렵다. 특히 대규모 비용이 발생한다는 점에서 차세대 프로젝트를 수행한 기업이 당장 적용하기는 어려운 것이 사실이다.
 결국 차세대 프로젝트와 PMO 활동의 경험을 보다 실천적으로 활용해야 한다. 이런 고민을 통하여 우리에게 적합한 운영 중심의 IT 프로세스와 IT 조직, IT 인력을 검토해야 하며 그 결과의 총화로서 IT 진화(Transformation)를 모색해야 한다.
 ◇프로젝트의 지식 자산을 "운영"에 활용해야=IT 조직은 차세대 프로젝트와 PMO 활동을 통해 최신 기술 및 베스트 프랙티스에 기반한 지식 자산을 습득한다. 이렇게 지식 자산이 만들어지는 과정을 살펴보자.
 첫째, 마스터플랜 수립" 업무 분석 및 개선안 도출" 설계" 개발" 테스트 등 프로젝트 주요 단계를 거치면서 다양한 방법론의 적용 여부를 검토한다. 이를 IT 조직의 현실에 맞게 재정의하고 실행하며 시행착오도 거치면서 보완하게 된다.
 통합 테스트 수행 중에는 실제 시스템 운영에서 발생할 수 있는 다양한 상황을 가정하고 거기 대비한 운영 절차도 수립해 시뮬레이션도 진행한다. 시행착오를 거치면서 경험한 공학 및 기술 관점의 업무 내용은 개발 방법론 및 다양한 절차, 지침서 등 산출물로 정리된다.
 둘째, 비즈니스와 기술 구조의 재해석이 중요하다. 일상적으로 IT시스템을 운영하는 시기에는 이런 재해석을 시도하기 어렵다. 재해석을 바탕으로 프로젝트 팀은 평상시 드러나지 않던 기업 전체의 모습을 확인하고 변화관리의 기본 정보를 만든다. 흔히 전사 아키텍처(EA:Enterprise Architecture)라고 부르는 산출물이 이러한 작업을 거쳐 만들어진다.
 셋째, 외부 및 내부 인력으로 구성한 PMO 활동을 통해 다양한 관리 기법을 정의하고 이를 프로젝트 전체에 적용하게 된다. PMO는 객관적인 정보(진척, 이슈, 리스크 등)를 바탕으로 의사소통을 활성화하고, 초기에 정의된 전사 아키텍처 정보를 기반으로 시스템의 품질이 일정한 수준을 유지하도록 관리한다. PMO가 검토한 후 도입한 베스트 프랙티스에 근거해 기업IT 조직은 자신에게 가장 적합한 관리 기법을 경험하게 된다.
 ◇차세대 경험은 IT 조직 혁신의 ‘종자돈’=차세대 프로젝트를 통해 얻은 관리 능력, 아키텍처 능력, 공학 능력, 기술 능력 등 경험 자산은 시스템 오픈 이후 IT 프로세스와 조직, 인력 등의 성숙 수준을 향상시키는 핵심 기반이 된다. 차세대 프로젝트 이후 얻을 수 있는 혜택은 다음과 같다.
 ▶후행적 경험에 기반한 IT프로세스의 내재화=차세대 프로젝트에 적용하는 프로세스는 두 축으로 구성된다. 첫 번째 축은 PMO 관리 프로세스로 일정, 이슈, 품질, 아키텍처, 공정 등을 관리한다. 두 번째는 개발 프로세스로 분석, 설계, 구현, 테스트, 이행 등으로 구성된다.
 프로젝트 초기에 이 두 프로세스는 일단 선험적 이론 수준에서 적용한다. 국제 표준과 베스트 프랙티스에 기반한 보편적인 방법론 및 프로세스가 그것이다. 선험적 이론 수준이기 때문에 초기에는 많은 시행착오를 거치게 되며, 그 과정을 거치면서 프로젝트 팀은 IT 조직 특성에 맞게 PMO 관리 프로세스와 개발 프로세스를 수정한다.
 선험적 이론 수준의 프로세스는 수정과 실행의 반복 과정을 거쳐 후행적 경험 수준으로 성숙되며, 각각의 IT 조직에 적합한 프로세스로 다시 정의된다. 이러한 과정이 ‘내재화(Internalization)’이다. 내재화란 자신의 생각이나 성격 내부에 여러 가지 가치관이나 습관, 생각, 사회적 기준 등을 받아들여 자신의 행동으로 실현하는 프로세스라고 말할 수 있다.
 프로젝트에서 내재화된 프로세스를 문서 보관함에 넣고 잠가버리면 안 된다. 시스템 오픈 이후에도 이 프로세스가 기업 IT 운영에서 살아 움직이는 원칙과 지침이 되도록 해야 한다. 그렇게 하려면 차세대 프로젝트 과정에서 이러한 미래를 내다보고 준비하는 것이 최선이다.
 현재 차세대 프로젝트가 진행 중인 A 기업의 경우 정의된 개발 프로세스를 설계 모델, 프로그램 소스와 연계하여 통합 관리할 수 있는 관리 시스템을 구축해 활용한다. 업무 특성에 맞는 IT 프로세스를 구축하고 이를 자동화 단계로까지 끌어올린 사례다.
 이런 기업은 시스템 오픈 이후에도 큰 혼란 없이 프로젝트 중 정의한 IT 프로세스를 운영 과정에 바로 적용할 수 있다. 장기적으로 IT 서비스의 품질 목표를 달성하여 안정적으로 제공할 수 있게 된다.
 ▶비즈니스 및 IT 역량 강화 위한 조직 구성=차세대시스템의 성공을 위해서는 자원(인력)을 최대로 활용하는 조직을 구성해야 한다. 프로젝트 초기에는 분석 및 설계 중심으로, 개발 단계에서는 개발팀 중심으로 조직을 구성한다. 통합 테스트 단계에서는 현업 사용자와 협업 테스트가 가능한 조직을 구성한다.
 리스크를 최소화하기 위해 프로젝트 기획 및 품질관리 단위 조직을 구성하여 프로젝트를 지원하도록 한다. 프로젝트 중 다양한 조직을 구성하고 그 안에서 역할을 수행한 경험을 통해 기업의 IT 인력은 한 단계 더 성숙한다. 이러한 경험 자산을 지속적으로 유지 및 활용하며 고도화·구체화하기 위해서는 운영 단계에 들어가서도 그 역할을 지속할 수 있도록 조직을 구성하고 담당자를 지정해야 한다.
 여기서 가장 먼저 챙겨야 할 과제가 BRM(Business Relationship Management) 조직 구성이다. 차세대 프로젝트에 참여한 현업의 역할(비즈니스 분석 및 혁신, 현업부서와의 의사소통 등)을 대신하는 BRM 조직은 프로젝트의 경험이 비즈니스 역량 강화로 이어지는 핵심 고리가 된다. BRM 조직을 통해 차세대 팀은 IT 중심이 아니라 비즈니스 중심으로 생각하게 되며 나아가 비즈니스 혁신 과제에서도 IT 조직의 주도성을 확보할 수 있다.
 두 번째는 전사 아키텍처 정보 기반으로 IT 기획 및 투자 의사결정이 이루어지고, EA 기반의 표준과 원칙이 프로세스로 실행 및 관리되도록 EA 관리 조직을 구성하는 것이다. 기존의 IT기획 조직을 확장해 EA 조직을 구성할 수도 있으나 아키텍처 중심의 전문성을 확보한다는 차원에서 보면 EA 관리 조직을 IT기획 조직과 분리하는 것이 바람직하다.
 마지막으로 프로젝트 리스크를 최소화하는 역할을 수행한 PMO 기능을 유지하는 것이 중요하다. 차세대 프로젝트를 통해 IT 조직은 PMO 중심으로 의사소통을 하고 중요 사항의 의사결정을 하는 방식이 효과적이라는 점을 체득했다. 이 학습 효과가 지속되기 위해서는 시스템 오픈 이후에도 의사소통과 의사결정의 효율을 유지하고 고도화시킬 방안이 필요하다. CIO 직속의 ‘상설 PMO’ 조직을 구성하는 것도 대안이 될 수 있다.
 기업 IT 환경에서는 차세대 프로젝트 이후에도 시스템 증설 요구가 계속 제기된다. 이런 요구를 합리적인 기준으로 검토하고, IT 비전과 전략에 상응하는 판단을 내리는 것은 매우 중요하다. 차세대 프로젝트를 완료한 후 이런 요구를 경험한 기업이 늘어나면서 ‘팽창 관리’라는 개념이 등장했다. 상설 PMO는 차세대 시스템의 팽창 관리를 전사 아키텍처 정보에 기반해 계획적으로 수행, 차세대 시스템이 누더기로 전락하는 것을 막아야 한다.
 최근 차세대 시스템을 오픈한 B 기업은 프로젝트 중 구성된 현업 태스크포스의 일부 인력을 IT조직에 잔류시켜 상설 BRM 조직을 구성했다. 물론 BRM 조직의 규모는 프로젝트 당시보다 줄어들었다. 하지만, 프로젝트 당시의 비즈니스 프로세스 분석 및 설계 업무뿐만 아니라 오픈 이후에도 현업 사용자들이 불편하다고 느끼는 부문을 먼저 식별해 대안을 수립하는 점진적인 혁신 활동을 수행해 주목할만한 효과를 거두고 있다.
 ▶IT운영 인력의 전문성 강화=프로젝트가 마무리 단계에 접어들면 IT 운영 인력 가운데 프로젝트에서 핵심 역할을 못한 인력을 대상으로 시스템 관련 교육 및 기술 이전을 실행한다. 그러나 프로젝트 핵심 인력과의 기술 차이는 넘기 힘든 벽이다. 이것은 프로젝트 이후 IT 조직의 현실적인 문제로 다가온다.
 CIO는 IT 인력의 안정성을 유지하기 위해 지원 인력에 대한 변화관리 계획을 사전에 수립해 이들이 프로젝트 완료 이후에도 시스템을 안정적으로 운영하도록 지원해야 한다. 사후 교육뿐만 아니라 프로젝트 도중의 다양한 방법론 및 프로세스, 기술 교육에 이들 인력이 지속적으로 참여하는 것이 중요하다.
 통합 테스트 단계에서는 운영 인력이 비즈니스 관점에서 종합적으로 테스트할 수 있도록 계획을 수립해야 한다. 이때 업무량의 과부하가 될 가능성이 높다. 통합 테스트 단계에서 IT 운영 인력의 업무 과부하는 어느 정도 불가피하지만, 최대한 단기간에 집중적으로 수행하도록 해야 한다.
 변화관리와 병행해 장기적 관점에서 IT인력이 ‘전문 아키텍트’로 성장할 수 있도록 전사 관점에서 IT 직무와 필요한 기술요소, 교육과정 등으로 구성된 ‘IT인력 경력 개발 경로’를 정의해야 한다. 이 경로를 통하여 IT운영 인력이 조직 내에서 경력을 발전시킬 수 있다는 비전을 각 개인에게 제시해야 한다.
 차세대 프로젝트에는 많은 전문가들이 다양한 역할로 참여한다. 투입 인력의 구성 내용을 정밀하게 분석하고 내재화한 데이터는 IT운영 인력의 전문화를 진행하는 기초 자료가 된다. C 기업의 경우 IT 직무의 재정의 작업을 통해 인력 개발 경로를 다시 규정하고, 최상위 직무의 하나로 아키텍트 직무군을 설정했다. 초급 설계자 및 개발자가 전문 아키텍트로 성장할 수 있는 대안을 제시, IT 인력의 전문화 및 안정성을 제고한 것이다.
 차세대 프로젝트 및 PMO를 통해 기업들은 다양한 시도를 하고 또 많은 오류도 저지른다. 중요한 것은 이 모든 것을 비용이 아닌 장기적 투자로 생각하는 태도이다. 프로젝트의 경험 자산을 체계적으로 정리하고 IT 운영 시점에 연속성을 유지하면서 관리한다면 기업 IT 조직은 어떤 위기도 슬기롭게 극복할 수 있는 강한 체질로 변화할 것이다.
 slkim@2e.co.kr

박스:IT 프로세스 내재화 시대, SW 설계자의 하루

 오후 5시 30분. 차세대 프로젝트 종료 후 안정화 단계에 접어든 현업 담당자 A는 퇴근 준비를 하고 있다. 이 때 화면에 뜨는 에러 메시지. ‘그러면 그렇지!’ A는 화면에서 ‘시스템 오류 신고 버튼’을 클릭해 에러 화면을 자동 캡처하고 에러 내용을 간략하게 기술해 SW 설계자에게 전송한 다음 퇴근한다.
 익일 오전 8시 30분. SW 설계자 B는 출근과 함께 소스 분석기 프로그램을 켠다. 프로그램에는 어제 저녁 A가 보낸 에러 메시지와 함께 다른 현업이 작성한 요구사항 변경 사안이 리스트되어 있다. B는 ‘오늘 오전엔 XXX 컴포넌트의 결함을 보완하고 영향도가 큰 YYY 컴포넌트는 모듈 개발자들과 함께 상황을 파악해야겠다’고 생각한다.
 오전 9시 30분. B는 어제 저녁 보고된 결함 중 XXX 컴포넌트 보완에 필요한 공수를 산정하기 위해 소스 분석기의 FP(Function Point) 기능을 활용한다. 결함 및 추가 요건을 보완하기 위해서는 2개 테이블을 수정해야 하며 컴포넌트의 인터페이스에는 문제가 없으므로 내부 로직만 수정하기로 한다. 기존에 작성한 UI 스펙과 UML 설계 산출물을 소스 분석기를 통해 프로그램으로 로딩해 보완하고 산출물을 개발자에게 전달한다. YYY 컴포넌트의 영향도 분석 회의를 위해 관련 모듈을 소스 분석기를 통해 파악하고 회의 소집 메일을 보낸다.
 오후 1시 30분. SW 설계자 C와 D는 회의에 들어오기 전 소스 분석기를 통해 해당 모듈의 변경이 자신들의 모듈에 미치는 영향도를 파악했다. 회의는 영향도 파악, B의 모듈 보완 기간 파악, 이후 C와 D 모듈에 반영하기 위한 기간까지 파악하고 1시간 내에 마쳤다.
 오후 2시 30분. B는 설계를 변경하고 각 개발자에게 변경 결과를 통보한 후 오전에 전달한 XXX 컴포넌트 보완 사항의 진행 결과를 파악한다. 소스를 리버스해 진행 상황을 파악한 설계자 B는 보완 개발이 자신이 의도한 설계와 다른 방향으로 진행 중임을 파악하고 해당 개발자에게 설계 내용에 대한 추가 정보를 전달하기 위해 간단한 미팅을 진행한다.
 오후 5시 30분. B는 오늘 수행한 업무를 팀장에게 보고하기 위해 ITSM 시스템에 접속한다. 시스템에는 어제 저녁 등록된 요청 건에 대한 진행 상황이 표시되어 있다. 진행 상태를 확인한 B는 내일 오전에는 XXX 컴포넌트의 단위 테스트를 진행하고 YYY 컴포넌트는 개발 상황을 파악하기로 계획한다.
 이러한 일과는 당연해 보이지만 직접 기업 현장에서 애플리케이션을 개발하고 운영하는 IT 업무 종사자들이 항상 동경해오던 모습이다. 즉, 현실에서는 이루어지기 어려운 ‘이상’에 가깝다는 얘기다.
 하지만 이런 이상은 조만간 현실화될 것으로 보인다. 필자가 참여하는 프로젝트에서는 요구사항 도출(변경)→SW 설계→애플리케이션 개발 등 과정에서 각자의 역할이 엄격하게 지켜지고 있다. 두 단계로 나누어 진행된 프로젝트를 통해 SW 개발 프로세스는 어느 정도 내재화됐으며, UML 등 다수 모델링 언어에서 표방하던 산출물 기반의 커뮤니케이션이 가능하다는 것을 보여주었다.
 SW 개발은 설계가 한번에 완벽하게 구현되지 않기 때문에 실패하는 경우가 생겨나고 프로세스가 준수되지 않는다. 그래서 이번 프로젝트에서는 내재화 수준을 업그레이드하기 위해 소스 분석기를 개발, 설계에서 구현에 이르는 과정을 일부 자동화했다.
 소스 분석기 프로그램은 화면 설계서, UI 스펙, UML 모델, 구현 소스 중 화면 설계 이후 설계 단계에서 작성되는 산출물을 시스템의 데이터로 만든다. 설계자가 개발자에게 전달하는 산출물과 구현 이슈에 따른 설계 피드백 과정을 자동화함으로써 프로젝트나 운영 중 1 대 다(1:N)의 관계로 발생하는 설계자와 개발자의 커뮤니케이션 비용을 줄이고 변경을 지속적으로 반영하게 강제화한다.
 
<필자소개>
 김상일 투이컨설팅 이사/PMO팀장
 PMO, 방법론(IE/CS/CBD/PM), IT 거버넌스 및 조직혁신 전문가로 수출입은행, 우리은행, LIG손해보험, 한진해운, SK텔레콤 프로젝트에서 PMO를 수행했으며 아시아나IDT, 수협은행, KBS, SK텔레콤 등 SM 중심 조직 대상으로 IT프로세스 및 조직혁신과 CMMi 등 IT거버넌스 컨설팅을 수행했다.
연관검색어
성공한 PMO의 가치는 프로젝트 끝난 뒤 더욱 빛난다

구매평가

구매평가 기록이 없습니다
보상규정 및 환불정책
· 해피레포트는 다운로드 받은 파일에 문제가 있을 경우(손상된 파일/설명과 다른자료/중복자료 등) 1주일이내 환불요청 시
환불(재충전) 해드립니다.  (단, 단순 변심 및 실수로 인한 환불은 되지 않습니다.)
· 파일이 열리지 않거나 브라우저 오류로 인해 다운이 되지 않으면 고객센터로 문의바랍니다.
· 다운로드 받은 파일은 참고자료로 이용하셔야 하며,자료의 활용에 대한 모든 책임은 다운로드 받은 회원님에게 있습니다.

저작권안내

보고서 내용중의 의견 및 입장은 당사와 무관하며, 그 내용의 진위여부도 당사는 보증하지 않습니다.
보고서의 저작권 및 모든 법적 책임은 등록인에게 있으며, 무단전재 및 재배포를 금합니다.
저작권 문제 발생시 원저작권자의 입장에서 해결해드리고 있습니다. 저작권침해신고 바로가기

 

⼮üڷٷΰ ⸻ڷٷΰ thinkuniv ķ۽÷