brunch

매거진 슬기로운 PM 생활

라이킷 17 댓글 5

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Don Lee Apr 11. 2022

소 잃고 외양간 고치지 말자 -실패 프로젝트 전조 현상

#7 슬기로운 PM 생활 - 실패하지 않는 프로젝트 관리

우리나라 IT 프로젝트의 90% 이상은 성공합니다. 하지만 실제 조직 내부에서 프로젝트의 성공은 45%도 되지 않는다는 통계가 있습니다(이노타스 보고서). 실제 프로젝트를 하면서 종료 시점에는 거의 조건부 프로젝트 종료로 종결되는 경우가 많이 있습니다. 지금도 많은 회사에서 프로젝트를 수행하고 있을 것입니다. 중간 점검을 통해 수행하고 있는 프로젝트가 건전한지 한번 체크해 볼려고 합니다. 소 잃고 외양간 고치지 않기 위해 사전 체크하는 측면에서 필자의 경험을 공유하고자 합니다.

프로젝트에는 많은 역할들이 존재하고 있습니다. 자신의 위치에서 각 역할들이 잘 수행하고 프로젝트 관리자(Project Manager)가 고객과의 관계를 원활하게 조율할 때 성공적인 프로젝트를 만들 수 있습니다. 성공적인 프로젝트를 위해 프로젝트 실패 원인들을 분석하고자 합니다.

※ 발주사 : 프로젝트를 발주한 회사, 고객사
※ 수행사 : 프로젝트를 맡아 수행하는 회사 또는 구축하는 회사, 협력업체(파트너사)
※ RFI : 정보 요청서 (Request for Information ), 프로젝트 전에 솔루션의 정보를 요청하는 단계
※ RFP : 제안 요청서 (Request for Proposal), 프로젝트를 진행하기 위한 제안서를 요청하는 단계
※ PM : 프로젝트 관리자 (Project Manager, 이하 PM), 수행사 PM과 발주사 PM 이 있음
※ Project Stakeholder : 프로젝트 이해관계자, 프로젝트 수행시 관련 부서, 파트너사, CxO 등 관련자

프로젝트에서 가장 중요한 포인트

프로젝트의 첫 발자국과 마무리의 가장 중요한 이정표는 요구사항 분석 단계와 개발 후 요구사항에 대한 테스트 단계가 가장 중요합니다. 문제가 있는 프로젝트에 투입되어 가장 먼저 체크하는 부분은 프로젝트의 요구사항과 프로젝트의 WBS(Work Breakdown Structure, 작업 분류체계) 그리고 진행 일정표입니다. 가장 기본이지만 생각보다 정리가 안되어 있는 부분이기도 합니다.

필자가 해외 글로벌 기업에서 프로젝트할 때 수시로 본사 감사를 받으면 거의 대부분의 해외 감사들은 와서 기본 사항부터 체크합니다. 처음에는 짜증 났지만 필자 또한 소위 불이난 프로젝트에 불 끄기 위해 프로젝트에 들어가면 기본 사항부터 체크하는 게 기본이었습니다. 그만큼 기본이 중요하고 첫 단추에 문제가 있으면 프로젝트는 거의 사상누각(沙上樓閣, 모래 위에 세운 누각이라는 뜻으로, 기초가 튼튼하지 못하여 오래 견디지 못할 일이나 물건을 이르는 말)과 같이 문제가 생기는 프로젝트가 될 가능성이 많습니다.

프로젝트의 요구사항을 명확히 하고 이를 기반으로 작업 분류체계와 일정을 만들고 마지막에는 요구사항이 잘 만들어졌는지 현업과 함께 테스트를 진행하는 것이 가장 중요한 포인트입니다.

https://brunch.co.kr/@df79991e83ed416/26

프로젝트에서 가장 중요한 것은 작업분류체계(WBS)

#2 슬기로운 PM 생활 - 실패하지 않는 프로젝트 관리 | 작업분류체계(Work Breakdown Structure, 이하 WBS)를 만들기 위해서는 실제 일해 본 경험이 필요하다. 프로젝트를 시작하기 전과 진행 중에 가장 중

brunch.co.kr/@df79991e83ed416/26

실패하는 프로젝트의 전조 현상

불명확한 프로젝트 범위(Scope)

일반적인 프로젝트의 시작점에는 대부분 요구사항이 불명확할 수 있습니다. 발주사와 수행사가 같이 요구사항을 명확하게 정리하는 것이 필요합니다. 설령 프로젝트 초기에 분위기가 험악해진다고 해도 요구사항을 명확히 해야 프로젝트 마지막에 같이 웃을 수 있습니다. 실패하는 프로젝트의 전조 현상 중 하나는 프로젝트 초기에 웃고 즐기고 술 마시고 다들 여유로운 시간을 보낸 프로젝트는 마지막에 문제가 생기는 경우가 많습니다.

https://brunch.co.kr/@df79991e83ed416/22

RFP(제안요청서) 쓰는데 자격이 필요하다.

#1 슬기로운 PM 생활 - 실패하지 않는 프로젝트 관리 | 프랑켄슈타인(Frankenstein) 같은 프로젝트 요구사항으로 우리 시스템 정말 성공할 수 있을까? '갑'이라는 이유로 마음대로 써서 던져진 RFP(Reque

brunch.co.kr/@df79991e83ed416/22

프로젝트 멤버(Member)

프로젝트는 발주사와 수행사가 같이 진행하는 것이 정석입니다. 프로젝트 수행할 때 고객사는 PM만 있고 수행사만 진행하는 프로젝트는 나중에 프로젝트 결과를 보는 시점에 많이 힘들어 할 수 있습니다. 외부에서 온 파트너사들은 기업 내부의 업무와 기업의 산업에 대해 발주사 인력보다 알지 못합니다. 프로젝트의 요구사항의 이해와 업무 프로세스 정의를 같이 정의하면서 수행사 프로젝트 멤버가 구축/개발하기 위한 이해를 높여줄 필요가 있습니다. 상상만의 프로젝트 요구사항 분석은 많은 위험을 동반합니다. 꼭 현업들과 인터뷰하여 눈높이를 맞추는 작업이 필요합니다. 프로젝트 수행사 멤버들만의 프로젝트 진행하는 프로젝트는 프로젝트 말에 프로젝트 결과에 대해 "이 산이 아닌가 봐"를 외치는 경우가 많습니다.

수행사 인력 때문에 프로젝트 지연되는 주요 원인
- 수행사(갑/을/병/정) 인원에 대한 인간 존중(의사 존중) 필요
- 회의 시 범죄자 또는 사기꾼 취급
- 범죄자 자백 형태의 회의 진행
- 개발자와 소통 부족 (동상이몽)
- 개발인력의 과도한 야근 요구
- 처음부터 끝까지 월화수목금금금
- 프로젝트 팀워크 부족
- 개발자의 책임감
- 야반도주 프리랜서 인력

ERP(Enterprise Resource Planning, 전사적 자원 관리)이나 CRM(Customer Relation Management, 고객 관리) 프로젝트에서는 일반적으로 PI(Process Innovation, 이하 PI)가 필요합니다. 하지만 이러한 PI를 수행할 때 외부 컨설턴트나 수행사 인력만으로 진행하면 문제가 발생할 확률이 높습니다. 발주사에도 우리가 향후 사용하는 프로그램을 만드는 작업이기에 전담 인력이 같이 참여하고 이때 참여 인력은 파워 유져 그룹(Power User Group)으로 향후 전사 교육이나 확산을 할 때 같이 참여하는 것이 좋습니다. 또한 프로젝트에 참여한 인력은 부서 간 업무 이견 발생할 때 조정하는 역할을 수행할 수 있습니다. 프로젝트 내외부의 정치적인 알력이 있을 때는 문제가 발생할 수 있기에 파워 유져 그룹과 프로젝트 스테이크홀더(Project Stakeholder, 프로젝트 이해관계자)의 도움으로 정리하는 작업이 필요합니다.

발주사 인력 때문에 프로젝트 지연되는 주요 원인
- 고객사의 업무 분담 없음 (Owner ship 없음)
- Project 일정에 대한 Ownership 없음
- 품질관리에 대한 Ownership 없음(감사반에서 체크함)
- PI 요원에 대한 불성실
- 커뮤니케이션의 부재 (Mail 또는 e-Office)
- PI(전담반)의 분담 영역의 부재 (전담반이 권한 없이 Claim 제기만 함)
- PI(전담반)의 기존 업무 때문에 참여 부족
- 부서 간 업무 이견 발생 시 조정자 부재
- 구성원들의 적극적 참여 부진, 간부들 무관심 (실무현장의 조직적 반발과 거부)
- 확고하지 못한 추진 주체 (프로젝트 책임자 및 지원세력 미비)
- 의사결정에 대한 빈번한 번복
- 기 설명된 내용에 대한 계속적인 제반복
- 경영진의 관심 부족

https://brunch.co.kr/@df79991e83ed416/32

프로젝트에서 중요한 것은 구축 업체 선정과 인력 구성

#6 슬기로운 PM 생활 - 실패하지 않는 프로젝트 관리 | 프로젝트에서 가장 중요한 요소 중 하나는 인력입니다. 솔루션은 기능 관점에서 중요하지만 이렇게 선정된 솔루션을 구현하는 인력이 더 중

brunch.co.kr/@df79991e83ed416/32

최고 경영진의 관심

프로젝트를 진행할 때는 프로젝트 멤버뿐만 아닌 프로젝트 오너(Onwer) 그리고 경영진들과 공감대가 필요합니다. 경영진의 관심이 없는 프로젝트는 필요가 없는 프로젝트이거나 사내에 영향이 없는 프로젝트일 가능성이 많습니다. 최고 경영진들이 모든 프로젝트에 대해 집중할 수는 없으므로 프로젝트 오너를 중심으로 프로젝트 스테이크홀더(Stakeholder)들과 지속적인 관심과 프로젝트의 목적에 충실할 수 있도록 관리할 필요가 있습니다. 최고경영진의 관심이 없는 프로젝트 또한 실패할 확률이 높아지는 프로젝트의 하나가 될 수 있습니다.

의사결정 및 작업 관리

프로젝트를 진행하면 의사결정을 해야 하는 부분이 많습니다. 문제가 있는 프로젝트를 보면 결정했던 의사결정에 대해서 빈번하게 번복되는 현상을 볼 수 있습니다. 실제 프로젝트에서 번복되는 경우도 있지만 빈번하게 반복되면 프로젝트 진행을 할 수 없습니다. 한두 번은 모르겠지만 지속적인 의사결정의 번복이 되면 프로젝트 멤버의 집중력도 떨어지고 프로젝트 개발하고 나면 번복되는 과정을 거치면 프로젝트 인력과 기간에 대해서도 문제가 발생합니다.

프로젝트를 진행하면 추가적인 요구사항이나 기존 요구사항에 대한 변경 사항 또한 많이 발생합니다. 이렇게 추가로 발생된 요구사항에 대해서는 우선순위를 선정하여 진행할 필요가 있습니다. 기존 것은 당연히 하고 새로운 추가된 것은 밤새 하라는 물리적인 시간이 부족하고 개발하는 인력 또한 이러한 상황에 대해서 정리해서 프로젝트하는데 문제가 발생하지 않습니다.

앞서 언급한 프로젝트 스테이크홀더(Project Stakeholder)와 경영진들의 공감대 형성과 의사결정에 대한 방향성, 보고 체계 등이 사전에 잘 정리되어 있어야 프로젝트 의사결정에 대해서 번복되거나 우선순위 조정하는데 문제가 없습니다.

구축 솔루션의 이해

솔루션 구축 프로젝트는 솔루션의 이해 부분도 중요합니다. 솔루션을 잘못 이해하고 잘못된 개념에서 프로젝트를 진행하는 것도 문제가 될 수 있습니다. 솔루션은 독립적으로만 구동되지 않습니다. 구축 솔루션 및 연관 시스템에 대한 인터페이스에 대해서도 중요합니다. 프로젝트 초기에는 인터페이스 파악이 되지 않지만 솔루션 인터페이스에도 많은 시간과 개발 인력이 필요합니다.

솔루션 관련 프로젝트 지연 원인
- 잘못된 개념에서 프로젝트 출발
- 불분명한 목표(To-Be) 모델
- 솔루션(Solution)에 대한 불신 (대안 검토, 의견 충돌에 따른 무리안 대안 요구)
- 인터페이스에 대해 너무 소홀히 했음

https://brunch.co.kr/@df79991e83ed416/30

IT 솔루션 간에도 궁합이 있다.

#5 모두가 하고 싶어하는 디지털 트랜스포메이션 | 앞서 디지털 트랜스포메이션 프레임워크(Framework)에 대해 설명하면서 여러 기능들 간에 연계성 때문에 전체 관점에 모델 설계가 필요합니다.

brunch.co.kr/@df79991e83ed416/30

프로젝트 테스트

인력 부족으로 프로젝트 테스트 단계에서 프로젝트 수행사(구축사)의 인력만으로 진행하는 테스트는 실제 프로젝트를 오픈할 때 많은 문제를 발생시킬 수 있습니다. 개발자들은 많이 경험하지만 내가 만든 프로그램에 대해 내가 테스트를 하면 나도 모르게 내가 만든 로직 대로만 테스트를 보통 진행하게 됩니다. 실제 프로그램의 버그(Bug)를 찾아내야 되지만 실제 버그를 찾는 것은 어렵습니다. 개발자가 예측하지 못한 프로그램의 버그를 찾기 위해서 2가지 형태의 접근을 합니다. 프로젝트에 참석한 파워 유져 그룹이 자신의 업무를 대상으로 업무 및 프로세스에 대해서 테스트하는 것이 필요합니다. 두 번째는 해당 프로그램이나 업무에 전혀 상관이 없는 신입이나 인턴 직원들을 통해 블라인드 테스트(Blind Test)를 진행하는 것도 생각지도 못한 버그를 찾아내는 데 많은 도움을 줄 수 있습니다. 테스트를 통해 버그를 많이 찾아내는 것은 문제가 있는 것이 아닙니다. 실제 문제는 프로젝트 오픈 후 버그 때문에 프로젝트에 문제가 발생하는 것이 더 큰 문제기 때문에 테스트 시점에 집중해서 버그를 찾아내고 찾아낸 버그를 빠르게 수정(Fix)하여 개발된 솔루션이나 프로그램의 품질을 높이는 것이 더 중요합니다.

https://brunch.co.kr/@df79991e83ed416/29

인테리어 업체 사장과 IT PM의 공통점

#5 슬기로운 PM 생활 - 실패하지 않는 프로젝트 관리 | 전 챕터에서는 등산과 IT를 비교했었는데 이번엔 몇 년 전 집 이사를 하면서 인테리어 공사를 했었는데 인테리어업체 사장님과 필자가 비슷

brunch.co.kr/@df79991e83ed416/29

프로젝트 기간

요즘은 애자일(Agile) 프로젝트를 통해 프로젝트 기간을 짧게 하고 범위를 작게 하고 프로젝트를 빨리 진행하는 형태가 많습니다. 애자일이기에 프로젝트의 변경을 유연하게 하는 것이 필요합니다. 이러한 유연성은 프로젝트 변경을 수시로 하라는 이야기가 아닙니다. 실패하는 프로젝트의 전조현상 중에 하나는 무한정 늘어나는 프로젝트 기간을 들 수 있습니다. 진행하는 프로젝트의 마지막 단계가 되면 요구사항이 바뀌어서 기간이 계속 연장되는 경우가 있습니다. 이러한 프로젝트는 이 핑계, 저 핑계를 이유로 프로젝트의 기한이 계속 바뀌고 마지막에 연장이 되지 않으면 실제 외부적으로 문제가 터져 나서 손을 될 수 없는 프로젝트가 되는 경우가 있습니다.

끝나지 않는 프로젝트의 여러 핑계

- 계속 요구사항이 추가되고 기간이 늘어나는 프로젝트
- 프로젝트 마무리가 되지 않아 고도화 핑계로 계속되는 프로젝트
- 고객의 무한 테스트와 무한 수정사항에 따라 계속되는 프로젝트

요즘은 코로나19에 따른 수시로 발생하는 재택근무도 프로젝트 지연에 많은 영향을 주고 있습니다. 프로젝트 일정에 영향을 최소화시키기 위해서는 IT 환경(VPN, 협업도구 등)이 필요합니다.

프로젝트 관리

프로젝트 관리를 위한 방법론과 도구, 보고 체계 등 프로젝트에는 필요한 요소가 많습니다. 관리적인 측면에서 실패 요인을 정리했습니다.

프로젝트 관리 측면에서 지연되는 주요 원인
- 프로젝트 관리 도구 부재
- 프로젝트 목표 및 범위 설정상의 오류 (전사적 경영혁신으로 추진 못함)
- 프로젝트 진행에 대한 공유 부족
- 프로젝트 관리 방법론에 대한 이해 부족
- 요구사항 불분명(Project Scope에 대한 불명확성)
- 구축 솔루션과 요구사항 추적 불가
- 진척률에 목숨 거는 프로젝트 일정 관리
- 작업 명세서(SOW) 작성 미비 (범위 문제)
- 느린 의사결정 문제 또는 수시로 번복되는 의사결정
- 불명확한 의사결정(두리 뭉실한 지시)
- 기 결정된 안에 대한 빈번한 번복
- 다른 프로젝트에서 발생한 이슈까지 클레임 제기
- 수행사 결정에 대한 번복 및 Claim (반대 세력의 프로젝트 방해)
- 우선순위에 대한 선정 부재

실패하는 프로젝트의 주요 삽질

수시로 계약서 꺼내라는 고객 PM과 팀원을 고려하지 않고 Yes만 하는 수행 PM 최악의 프로젝트 조합입니다. 많은 요구를 한다고 모두 성공하는 것도 아니고 현실을 고려하지 않고 모두 Yes 한다고 성공할 수는 없는 게 실제 프로젝트입니다. 모두 Win-Win 할 수 있는 방향성을 찾는 게 중요합니다.

프로젝트를 수행하는 수행사와 발주사는 상호 신뢰가 있어야 됩니다. 상호존중이 없는 수행사와 발주사는 프로젝트에 문제 생길 수가 있습니다. 서로 존중할 수 없기에 서로 믿지 못하면 발주사는 개발된 프로그램을 믿지 못하고 수행사는 고객사가 의사 결정한 것에 대해 믿지 못하면 프로젝트의 진행이 진척될 수가 없습니다. 15년 전쯤 국내 대기업 프로젝트할 때 어느 PM은 계속 욕을 하며 갑질을 하는 경우도 있었지만 요즘은 이런 프로젝트는 없을 것이라고 믿습니다. 프로젝트할 때 서로 존중(인간존중/의견 존중)이 필요합니다.

프로젝트에서 프로그램 결과물보다 문서 결과물을 더 중시하여 목숨 거는 프로젝트도 실패할 확률이 높습니다. 프로젝트의 가장 큰 산출물은 프로젝트 결과와 사용자 운영자 매뉴얼이 중요합니다. 초기 요구사항 정의서 및 테스트에 대한 시나리오와 테스트 결과서가 중요합니다. 실질적인 프로젝트 산출물 중심으로 진행하는 것이 더 효율적일 것 같습니다.

프로젝트의 주요 삽질 사례
- 고객사에게 Yes만 남발하는 프로젝트 관리자(Project Manager)
- 소통 채널 문제 / 보고 체계 / CXO 소통 / Stakeholder 소통
- 개발 진척 관리 필요 (알아서 잘하는 프로젝트는 없음)
- 프로젝트 종료시 프로젝트의 평가 부재 (Lesson & Learn 필요)
- 실패를 되풀이 하지말자 (실패한 프로젝트의 원인 파악 및 공유)
- 미팅만 하는 프로젝트 (수시로 미팅 / 미팅하다 일할 시간이 없는 상태인 프로젝트)
- 발주사 정치판 프로젝트
(프로젝트는 뒷전이고 내부 인력들 간에 알력에 사공이 너무 많은 프로젝트)
- 수행사 정치판 프로젝트
(프로젝트는 뒷전이고 파트너들 간에 서로 자기 수익 때문에 정치질 하는 프로젝트)