프로젝트관리란? (프로젝트 성공률 1% 높이기)

프로젝트관리란?
앞서서 프로젝트에 대한 정의를 살펴봤다. 그렇다면 이 프로젝트를 관리한다는 것은 무엇을 의미하는가? 이 지점에서 관리라는 용어도 살펴보고 가자. 관리란 흔히 사람을 통제하고 지휘 감독하는 것이나 여러 시설이나 물건의 유지·개량 따위를 꾀하는 것을 말한다. 이를 프로젝트에 대입해 보면 목표를 세우고 계획을 짜며 일들을 수행하고 목표를 달성해 가는 과정에서 필요한 수많은 자원과 시간 그리고 노력은 프로젝트의 관리 측면이다. 이는 매우 필수적이고 중요하며 프로젝트와 관리가 별개가 아닌 하나로서 인식해야 할 필요성을 느낀다.

그래서 프로젝트관리는 “프로젝트 요구를 만족시키기 위해 지식, 기술, 도구 및 기법들을 프로젝트 활동 중에 사용하는 것“이라 할 수 있다. 다시 말해 프로젝트 요구사항을 충족시키고 만족시키는 것, 이를 위한 모든 요소를 잘 이해하고 관리하여 목적한 바를 달성해 나아가고 더 나아가 프로젝트의 성공적 완료를 가능케 한 자원, 특히 조직의 역량을 확보하고 강화하는 것이 그 이면이라고 본다.

그러면 이러한 프로젝트의 성공률은 얼마나 될까? 다소 오래된 자료이긴 하나 지금까지도 유효한 Standish Group의 2010년 Chaos Summary를 보면 30% 정도의 프로젝트만 성공한다고 한다. 그렇다면 나머지 70%는 실패한다는 이야기인데 그 원인은 주로 1) 요구사항의 부정확성 2) 사용자 환경의 이해 부족 3) 불충분한 자원 4) 비현실적인 사용자 기대치 5) 관리지원의 부족 6) 변경 관리의 미흡 7) 프로젝트 계획의 미비 등이라고 한다. 이는 곧 관리 부재의 결과이고 특정 몇몇 사람이 아닌 조직 전체의 문제로 비친다. 특히 관리의 제약 측면에서 살펴보면 다음과 같다.

 

프로젝트 관리의 3대 제약
프로젝트는 아래 3가지에서 절대 벗어나지 않는다. 이는 프로젝트의 성공과 실패를 구분하는 기준이며 모든 단계의 품질을 좌지우지한다.

● 범위
: 프로젝트에 존재하는 필요와 기대 사이의 요구사항이다. 프로젝트 초반 고객의 요구사항을 제대로 파악하지 못하면 범위는 계속 흔들린다. 상세한 요구사항은 프로젝트의 첫 단추다. 이를 위해 요구사항관리라는 별도의 프로세스를 만들어 놓고 있으며 이를 통해 유기적인 범위관리에 신경을 쓴다.

● 일정
: 프로젝트의 시작과 끝, 그 기간이다. 프로젝트계획 시 범위에 기반한 일정을 수립하지만 철저한 관리가 되지 않는다면 일정은 자연스럽게 지연이 된다. 프로젝트관리자는 일정에 민감해야 한다. 전체 일정과 하루 일정. 진척도는 관리되어야 하며 이슈가 발생하면 전파하고 해결책을 찾아야 한다.

● 원가
: 프로젝트에 할당된 예산은 타당한가? 제대로 된 수요조사와 시장조사를 통해 원하는 사양에 충족한 것들을 선별, 구매했는가? 특히 인건비는 제대로 평가받고 있는가? 예산이 부족하다고 제일 먼저 인건비에 손을 대지는 않았는가? 그래서 실력 있는 개발자들을 외면하고 있지는 않은가? 아니면 한 사람에게 너무 의존하는 것은 아닌가?

프로젝트 관리 3대 제약

 

성공과 실패
모든 프로젝트는 성공하여야 한다. 그 끝을 위해서 모든 이해당사자는 서로 협력한다. 하지만 성공과 실패의 기준이 무엇인가에 대해서는 의견이 분분하다. 알고는 있지만 서로 상대적인 개념 사이에서 위의 3가지 제약은 훌륭한 기준을 마련해준다. 이를 바탕으로 프로젝트를 관리하고 관리의 성공과 실패 여부는 핵심 이해당사자들에게 달려있다.

이해당사자. 이들은 프로젝트와 밀접한 경영진, 개발자, 관리자, 고객 등이 있다. 이 중에서 고객의 요구사항에 얼마나 잘 부응했는가가 성공을 가늠한다. 3가지 기준에 충실한 관리, 그러면서 고객 요구사항의 충족. 성공은 멀리 있지 않다. 그만큼 실패도 성공의 반대편 가까운 곳에 서 있다. 부정확한 요구사항, 사용자의 몰이해, 충분하지 못한 자원들, 비현실적인 기대치와 무관심, 변화무쌍한 상황들의 관리 부재, 이들을 아우르는 계획의 미비. 그렇다고 유명하단 프로세스나 방법론이 모든 문제를 해결해 줄 수는 없다.

프로젝트는 요리와도 같다. 여러 좋은 재료들을 모아 정해진 레시피대로 정성껏 요리하면 맛 좋은 음식 맛을 볼 수 있다. 이 요리에 있어 요리사는 전체적으로 볼 수 있어야 하고 집중하여 관리하며 문제가 발생했을 때 이를 개선하는 노력을 통한 최적화! 나에게 맛 좋은 음식도 중요하지만, 고객의 입맛에 맞게, 원하는 사항들을 충족시키고 더 나아가 미처 모르던 맛까지 제공한다면 프로젝트는 성공이라 말해도 부족하지 않다.

이해당사자
프로젝트에는 수많은 이해당사자가 존재하며 이들은 프로젝트의 성공 여부를 결정짓는 매우 중요한 개인 혹은 조직이다. 영어로는 stakeholder. ‘지주를 붙잡는 사람’이라는 뜻처럼 각각의 역할과 책임이 막중하다.

  º 프로젝트관리자: 프로젝트 수행 전반의 책임자
  º 고객: 프로젝트 결과물을 사용하게 될 개인 혹은 조직
  º 기능부서 관리자: 프로젝트팀원이 속한 부서의 관리자
  º 경영진: 프로젝트를 수행하는 조직의 최고 관리자
  º 프로젝트부서: 프로젝트를 수행하는 사람 혹은 조직

이들은 그 특성과 영향력 수준에 따라 분류할 수 있고 각자의 이해 분야가 다르기 때문에 여러 갈등의 양상을 보일 수 있다. 이에 프로젝트관리자는 갈등 당사자 간의 이해의 합의를 구하고 해결책을 제시해야 하고 고객의 입장에서 움직여야 한다. 그래서 조직적인 대응으로 PMO를 구성하기도 하고 프로젝트 조직을 프로젝트 상황, 기업조직구조, 방침 등에 따라 기능 조직, 매트릭스 조직, 프로젝트 조직 등으로 나누어 사전에 결정하고 깊게 운영하여야 한다.

 

 

※ 너는 너, 나는 나
얽히고 섥힌 사람들로 북적이는 프로젝트에서 프로젝트관리자는 너무나도 중요하다. 그런데 요즘은 이런 부담을 떠안기 싫어 도망가는 사람들로 PM을 할만한 사람 찾기가 하늘의 별 따기 수준이다. 저는 개발만 하고 싶어요! 라는 사람들도 업무를 알아야 개발이 될 텐데 하물며 PM은 어떠할까? 세상은 바뀌어도 PM은 가치는 영원하다.

프로젝트 계획 (소프트웨어 공학)

프로젝트 문제와 범위 정의

소프트웨어 개발 시 일정이 지연되거나 비용이 초과고 기대했던 품질에는 못 미치는 산출물, 그에 따라는 여러 유지비용의 증가 등과 같은 문제들은 기본적으로 계획의 부재에서 오는 경우가 많다. 개발 일정을 준수하면서 질 좋은 소프트웨어를 개발 생산하기 위해서는 정밀하고 세심한 계획수립이 필요하다. 소프트웨어 개발 프로젝트 초기 단계에서 프로젝트의 목표를 기반으로 여러 불분명한 사안들을 확인해 가면서 계획을 수립하는 것은 매우 어렵다. 하지만 계획작업을 통해 불분명한 목표, 사용자 요구사항 및 제약사항 등을 명확히 하는 것이 필요하다. 이러한 계획은 보통 문제의 범위를 확인, 정의하고 필요한 활동들을 정하며 세부적인 일정계획과 비용을 추정하고 최종적으로 계획서를 작성하는 절차로 이뤄진다. 

다시 말해 프로젝트 계획은 대상업무와 문제들을 고객이 이해하는 용어로 정확하기 정의하고 기술하는 것으로 시작한다. 문제는 철저하게 고객의 입장에서 정의되어야 하며 기술관련 전문용어 등을 사용해서는 안된다. 문제를 정의하는 것은 범위를 정하는 것이다. 이는 개발대상의 기능, 성능, 제약조건, 인터페이스 등의 프로젝트에 대한 타당성과 신뢰성 및 초기 계획을 작성가능한가에 대한 판단 근거로 쓰인다. 문제 정의는 제일 먼저 그 배경을 이해하여야 한다. 이를 위해선 고객과의 면담, 현장답사 및 실제 업무를 수행하는 실무자의 실제 업무를 관찰하거나 직접 수행을 해보기도 한다. 그러면서 객관적 시각에 문제를 파악한다. 이 모든 것이 끝나면 문제 해결을 위한 준비를 한다.

 




일정 계획

일정은 프로젝트 개발에 있어 모든 프로세스를 구성하는 작업들을 파악하여 그 우선순위와 기간을 산정하며 진행한다. 이에 모든 작업들을 수준별로 나열을 하며 산출물이 있다면 각각 기술해 준다. 프로젝트의 규모가 작다면 큰 일이 아닐 수도 있으나 대규모의 프로젝트에서는 작업도출과 더불어 각 작업들 간의 상관관계를 면밀히 검토하여야 한다. 이때 보통은 PERT/CPM을 활용하며 최종적으로 간트차트 등을 사용하여 거시적 관점에서의 일정을 관리할 수 있도록 한다. 이렇듯 소프트웨어 공학은 엔지니어링 작업으로서 정확하고 현실적인 계획을 수립하고 작업 수행에 소요되는 여러 자원들을 최적화하여야 한다. 이에 따라 프로젝트의 진척도를 실시간으로 점검할 수 있고 계획과 비교하여 문제가 있을 시에 다방면의 조치로 문제해결이 가능하다.

간트차트로 보여지는 프로젝트 작업들, 일정표는 그 수준에 맞춰 분해가 이뤄지고 계층적으로 구성하여야 하는데 이를 위해 WBS(Work Breakdown Structure)를 사용한다. 이는 작업들이 모여 소요 일정이 예측되며 이를 통해 프로젝트 전체 일정을 예측할 수 있다. WBS는 큰 단위의 업무를 관리하기 쉬운 작은 단위의 작업으로 나누기 위한 도구이다. 여기서 관리 가능한 작은 작업들은 업무 지시를 하는 단위가 되며 작업시작일, 종료일, 소요기간, 담당자, 필요 자원 등을 병기하여 관리한다. WBS는 일정계획 작업의 입력값이며 작업 분해는 프로젝트가 어떤 작업으로 구성되었는지를 알아내는 것이고 일정 계획은 이들 작업을 어떤 순서로 할 것인가를 정하는 일이다.

  • 소프트웨어 개발모형 선정, 단계별 작업을 분해 후 작업결과 정의
  • 각 작업간 상호의존관계 정리
  • 각 작업소요기간 정의 및 프로젝트 완료에 필요한 최소기간 산출
  • 프로젝트 규모추정을 통한 M/M 산출
  • 확정 결과 정리 및 공유

 




비용 추정

소프트웨어 개발에 있어 비용을 정확히 예측하기는 매우 어려운 일이다. 특히 계획단계에서는 불분명한 사항들이 많고 여러 환경적인 요소로 비용에 대한 입장차도 존재한다. 그럼에도 불구하고 기준을 바탕으로 수립되는 소프트웨어 개발 비용예측은 특히 투입되는 개발자와 기간에 매우 큰 변수로 작용한다. 이에 과거 프로젝트의 경험이 중요하며 특히 유사 프로젝트가 있다면 규모와 비용, 인력들을 감안하여 예측을 어느 정도 가능하게 한다. 그러므로 정확한 예측은 프로젝트 성공율을 높이는 필수 조건이다. 이에 비용 예측방법도 매우 다양하며 인건비의 경우 소요기간을 기준으로 하거나 프로그램 규모를 기준하는 방법으로 크게 나뉜다.

첫번째 방법은 소요기간 기준이다. 이는 프로젝트 내 작업들에 소요되는 기간을 구하고 여기에 투입인력과 참여도를 반영하여 최종 인건비를 산출한다. 이 방법은 상향식이라 불리우며 단순히 헤드카운팅이라고도 하는데 시스템 개발에 필요한 모든 작업에 대한 노력들을 하나하나 계획할 수 있는 장점이 있으나 객곽적이 못한 추정 가능성이 있을 수 있다. 두번째 방법은 하향식으로 프로그램 규모를 추정하고 과거 경험을 바탕으로 예측 규모에 대한 소요인력과 기간을 추정한다. 프로그램 규모는 원시코드의 라인수(LOC)나 시스템의 기능을 정량화한, 좀더 복잡한 기능점수(Function Point) 등올 산출할 수 있다. 

 




조직 구성

경영관리에서 조직이란 개개인의 역할을 잘 정의하고 할당하여 프로젝트 목표 성취를 하기 위한 것이다. 이는 기업이나 단체 등 다수의 사람이 모여서 하나의 목표를 이루기 위한 방안으로 조직이 생겨난 것이다. 이러한 조직 구성의 목적은 공통된 목표를 위하여 상호 협력을 하는 것으로 프로젝트에서도 동일하게 적용된다. 이런 조직구성은 조직의 생산성과 효율에 얼마나 많은 영향을 미치고 그 결과가 어떻게 나타나냐에 대한 근본 원리를 따진다. 소프트웨어 개발 프로젝트에서 소프트웨어는 타 제품과는 다른 특징들로 인해 어떠한 조직을 구성하여 진행했느냐에 따라 소프트웨어 개발에 많은 영향을 미친다. 즉 소프트웨어의 품질을 향상시킬 수 있는 소프트웨어의 특성을 잘 살린 조직 구성이 필요한 것이다.

조직의 선택에 영향을 주는 요소는 비용 예측에 사용되는 요소와 유사하다. 알맞은 조직 구성은 프로젝트 기간과 매우 밀접하다. 장기 프로젝트의 경우 구성원들의 사기를 높이고 이직과 이탈을 막기 위하여 개개인의 만족도가 중요 시 된다. 경험이 많은 인력과 적은 인력이 적절하게 섞여야 하며 상호 간 배우고 배울 수 있는 관계 설정도 필요하다. 대규모 프로젝트의 경우 요구의 변경과 명세가 어려운 특성으로 인하여 프로젝트 후반에 신규 인력을 투입하면 일정은 그만큼 지연된다. 이는 인력 상호 간 의사소통의 통로 이슈와 기존 업무의 인수인계 등에 따른 시간을 고려한다고 해도 해소되지 않는 난제이다. 다시 말해 작업의 특성과 조직 구성원 사이의 의사소통의 횟수는 조직의 규모에 맞춰야 하며 필요 이상의 결과에 집중하지 않게 적정 선을 지키는 것이 중요하다.

프로젝트 팀 구성에 영향을 주는 다른 요소는 작업의 특성 및 팀 구성원 사이에 의사교류의 횟수이다. 의사소통이 원활할 수 있는 조직규모와 인력수는 매우 밀접하며 프로젝트의 복잡도와도 긴밀하다. 이에 공식적인 모형과 인원수도 산출할 수 있는데 중요한 것은 생산성에 촛점을 맞춘 균일한 규모의 조직을 구성하는 것이다. 이 규모는 소프트웨어의 특성과도 연계가 되며 팀은 원칙적으로 작업 수행에 제일 타당하게끔 조직되어야 한다. 그러기 위해선 관리자의 권한과 더불어 일정, 예산, 품질 등 여러 요소를 고려하여 조직 구성방법을 결정하여야 한다. 특히 소프트웨어 개발 팀구성은 의사결정권이 누구에게 있느냐에 따라 구별되며 리더의 역할, 권한, 의무에 따라 크게 3가지 형태의 구성방식을 갖는다.

  • 중앙집중형: 하나의 관리자의 지휘에 따라 움직인다. 기업 조직 내 일반적인 계층형 조직으로 상하관계가 명확하여 대규모 조직보다는 소규모 조직에 적합하고 이의 모듈화로 규모를 키울 수 있다.
  • 분산형: 의사결정을 민주주의식으로 하며 모든 작업은 공동의 작업이다. 팀 구성원 각자가 서로의 작업을 검토하고 타 구성원의 작업결과에 대하여 책임을 진다. 다만 의사소통 비용이 많이들며 이에 따른 생산성 문제가 있다.
  • 혼합형: 중앙집중형과 분산형의 단점을 보완하기 위해 구성된다.

 




위험분석

위험 분석은 프로젝트에 내재한 위험 요소를 인식하고 그 영향력을 분석하여 관리하는 활동이며 프로젝트를 성공시키기 위하여 위험 요소를 사전에 예측, 대비하는 모든 기술과 활동이 포함된다. 위험 요소에 대해 적절히 관리하지 못하면 프로젝트는 실패할 수 있다. 초기 단계에 위험 요소를 인식하고 그 영향을 분석하였어도 이를 다루는 일관성 있는 계획이 없으면 실패하기 쉽다. 이러한 위험을 줄이는 효과적인 방법은 프로토타이핑이나 점증적 개발 방법 있으며 중간 변경 위험을 대비하기 위한 모듈화도 생각해 볼 수 있다. 

< Boehm(Barry William Boehm, 미국 소프트웨어 엔지니어 및 교수, 나선형 모델 제)이 제시한 10가지 위험 요소와 관리 기법 >

  • 인력부족: 유능한 인력 수급, 팀구성, 교육
  • 비현실적 일정/예산: 구체적 비용/일정 예측, 원가분석, 재사용
  • 잘못된 기능의 SW개발: 프로토타이핑, 조직/직능분석
  • 잘못된 I/F개발: 프로토타이핑, 타스크분석, 시나리오기법
  • 과포장: 프로토타이핑, 원가분석, 비용수익분석
  • 계속적인 요구변경: 최대변경상한선, 점증적 개발
  • 외부 모양 빈약: 벤치마킹, 성숙도분석
  • 외부 기능 빈약: 사전검증, 대조확인
  • 실시간 성능 빈약: 벤치마킹, 튜닝, 시뮬레이션
  • 기술적 취약: 기술분석, 비용수익분석