프로젝트는 어떻게 시작하는가?

프로젝트는 비즈니스 요구사항을 중심으로 진행한다. 프로젝트를 제의한 사람(Sponsor)는 요구사항을 인지하고 구현을 요청해야한다. 결론적으로 프로젝트에서 비즈니스 요구사항이 가장 중요한 뼈대가 되는 것이다. 이러한 비즈니스 요구사항은 시스템의 기능을 결정하고 이때의 비즈니스 가치가 명확하게 드러나야 한다.

시스템 요구사항(System Request)

시스템 요구사항(System Request)은 프로젝트를 공식적으로 제안하기 위해 작성하는 1~2장 분량의 요약 문서이며, 프로젝트에서 가장 중요한 것 중 하나이다. 요구사항에는 아래 5가지 요소를 필수적으로 포함시켜야한다.

• Project Sponsor
  프로젝트를 구상한 사람이자, 비즈니스적 측면에서 프로젝트의 주요 포인트를 짚어주는 사람이다.
• Business need
  시스템을 구상할 때의 비즈니스와 관련된 이유를 나열한 것이다.
• Business requirements
  시스템이 제공되었을 때, 비즈니스가 가지는 가능성을 말한다.
• Business value
  시스템이 조직에 생성되어 도입되면, 이로 인해 발생하는 이점(이익)을 말한다.
• Special issues or constraints
  시스템을 구현과 관련된 문제나 상위 관리자가 내린 결정들을 말한다.

예비 프로젝트 승인

시스템 요구는 상위 관리자의 승인에 따라 작성된다. 제공된 정보를 기반으로 이 프로젝트를 진행하는 것이 메리트가 있는지를 평가한다. 가치있는 프로젝트는 승인(1차)되고, 결과적으로 타당성 분석을 통한 추가적인 검증을 거친다. 이를 통해 정말 실현 가능한지에 대해 파악하게 된다.

타당성 분석 (Feasibility Analysis)

제안된 프로젝트에 대한 기회와 한계를 이해할 수 있는 요소이다. 프로젝트의 디테일한 비즈니스 케이스를 검증하며 프로젝트가 진행되는 내내 평가된다. 타당성 분석은 아래의 몇가지 방식으로 분류할 수 있는데, 기술적, 경제적, 조직적 관점에서 살펴볼 수 있다.

기술적 타당성

사용자와 분석가는 비즈니스 애플리케이션 영역에 대한 이해도를 말한다. 현재 보유한 기술력과 경험으로 이 프로젝트의 성공을 기대할 수 있는지를 평가하는 영역이다.

평가 요소 : 해당 기술에 대해 얼마나 경험이 있는지, 프로젝트 규모가 우리가 감당할 수 있는 수준인지, 그리고 기존의 시스템과 호환이 가능한지 등을 확인한다.

이를 평가할 때는 만약 이전에 사용한 프로젝트가 있으면 해당 프로젝트와 비교를 해보고, 처음이라면 IT 전문가의 조언을 받아 리스크를 분석한다.

경제적 타당성

경제적 타당성은 투입되는 전체 비용 대비 회사가 얼마나 이득을 취할 수 있는지를 확인하는 평가이다. 크게는 4가지의 과정으로 이루어진다.

우선 1) 비용과 이익을 계산하고, 2) 가치에 대한 비용과 이익을 부여한다. (이부분이 추상적이라 어려울 수 있으나 가장 중요하고, 무형 자산의 경우에도 수치화시켜 포함해야한다.) 그리고 이를 바탕으로 3) 현금 흐름을 결정하고 결론적으로 4) 재정적 타당성을 평가한다.

타당성 평가에는 몇가지 지표를 이용할 수 있는데, NPV, ROI, BEP가 있다.

NPV

가장 명확한 지표 중 하나이며, 단순히 유출 대비 유입의 양이 얼마나 많은지를 확인할 수 있는 지표이다. 이 때, PV(present Value)는 현금 흐름의 양을 말하고   $PV = (1+금리)^{n(년)}$ 으로 표현한다.

NPV 공식은 이러한 PV를 기반으로 $PV 이익 - PV 비용$ 으로 표현된다.

NPV가 0보다 크거나 같으면 프로젝트가 진행되어도 좋은 신호이며, 만약 0보다 작은 경우에는 적합하지 않다고 이해할 수 있다.

ROI

ROI(Return on Investment)는 NPV를 기반으로 계산되며, $\frac{NPV}{\sum PV(Cash \,\,\,outflows)}$ 으로 표현할 수 있다.

BEP

BEP(Break Even Point)는 손익분기점까지의 시간을 의미하고, 손익분기점을 맞기까지의 시간을 계산해 구한다. 당연하게도 이 값이 크면 프로젝트가 가지는 리스크는 정비례하게 커진다.

Tangible Cost vs Intangible Cost

각각 유형 비용, 무형 비용을 말하며, 유형 비용은 시스템을 통해 조직이 얻는 이익(수익)을 모두 포함하는 비용을 말하고, 무형 비용은 숫자에 기반하기보다는 직관과 믿음에 기반을 두는 비용을 말한다.

조직적 타당성

시스템이 사용자들에게 얼마나 잘 수용되고 조직의 지속적인 운영에 얼마나 잘 통합될 것인가를 나타내는 지표이다.

평가 요소 : 시스템의 도입이 현재 조직에 목표와 부합하는지, 그리고 Project Champion, 관리자, 최종 사용자 등의 이해관계자(Stakeholder)를 분석한다.

공장의 생산 라인에 로봇 시스템이 도입되는 것을 반발하는 것과 비슷한 의미를 가지며, 시스템의 도입으로 조직의 변화가 잘 이끌고 잘 수용되는지를 평가하는 것이 이 평가의 주 목적이다.

타당성 평가의 맹점은, 한번의 평가로 끝나는 것이 아니라 프로젝트가 이뤄지는 내내 진행되는 평가로, 지속적으로 재평가를 통해 프로젝트가 잘 순항하고 있는지를 확인해야한다.

Project Selection Issue

승인 위원회는 시스템 요구사항과 타당성 평가를 바탕으로 업무를 진행한다. 비즈니스 요구사항과 시스템 구축의 위험성을 검토하여 프로젝트를 신중하게 선택한다.

포트폴리오 관리

동시에 포트폴리오 관리도 이어지는데, 여기서 포트폴리오란 조직이 전체적으로 가져가고자하는 프로젝트가 있는 큰 물줄기를 말한다. 전체 프로젝트의 포트폴리오에서 해당 프로젝트가 어느정도 위치에 자리하고 있는지를 확인하고, 균형 잡힌 프로젝트 포트폴리오를 구성하기 위해서는 이에 대한 절충이 필요하다. 설령 실행이 가능한 프로젝트 일지라도 포트폴리오의 문제로 인해 거부되거나 연기되는 결정이 내려질 수 있다.

Project Management

프로젝트 관리의 4가지 주요 절차

프로젝트를 관리할 때 우리가 주요하게 거쳐야할 4가지의 절차가 있는데, 1) 프로젝트의 규모를 식별하고, 팀원과 조직의 상황에 맞게 2) 업무 일정을 구성하고 관리한다. 그리고 일정에 맞게 3) 인력을 배치하고 마지막으로 4) 프로젝트의 활동을 조정한다.

프로젝트 관리는 서로 연관관계를 가지기에 하나를 수정하면 다른 것도 같이 수정해야한다.

프로젝트 견적

시간과 노력의 가치에 값을 매겨 예상 값어치를 산정하는 과정이다. 프로젝트에서 사용한 방법론, 경험이 있는 개발자, 실제 이전 프로젝트를 측정하며, 이를 통해서 예상 값어치를 산정한다. 처음에는 단순 범위의 수준으로 러프하게 매겨지다 프로젝트가 진행되고 구체화함에 따라 견적 또한 더욱 상세하고 두터워진다.

기능 점수(Function Point)

프로젝트가 승인되고 본격적인 계획을 들어가면 PM은 프로젝트의 규모, 비용, 개발 소요기간을 최대한 정확하게 예측해야한다. 이전에는 개발자의 경험에 의존해 되는대로 예측하기도 하였으나, 1979년 IBM의 Allen Albrecht가 Function Point라는 기능을 고안한 이후에는 이 방법을 적극 사용하여 객체적이고 정량적인 방식으로 산정한다.

이 기법은 5가지의 핵심 기능을 분해해 개수와 복잡도를 측정한다.

• Input : 사용자가 시스템으로 데이터를 집어넣는 기능을 말한다.
• Output : 시스템이 데이터를 가공해 사용자에게 결과물로 보여주는 기능을 말한다.
• Query : DB의 정보를 검색과 조회를 통해 화면에 Display한다.
• File : 시스템 내부에서 자체적으로 유지, 관리하는 논리적 데이터 집합이다.
• Program Interface : 외부 다른 시스템과의 통신을 위해 필요한 게이트를 말한다.

Function Point를 계산하는 데 몇 가지 절차가 존재하는데, 아래의 그림들을 중심으로 그. 흐름을 파악해 볼 수 있다.

Function Point 측정

1. Function Point 계산	1-(1). Function Point 적용

2. 소요 인력 산정	3.Schedule Time 계산

Use Case

Use Case Diagram

Use Case는 여러 시나리오를 포함하는 기능을 말하고, Actor는 외부 에이전트가 수행하는 역할이다. 인간이나 하드웨어 등의 내용이 수행하며, 이러한 Actor와 Use Case 사이의 흐름을 작성한 문서로 보면 된다.

Use Case Estimation

Use Case를 측정하는 과정을 가진다.

• Unadjusted Use-Case Points(UUCP)
  Actor 가중치 (1~3) / Use Case 가중치 (5,10,15)
  

• Technical Complexity Factor(TCF) : 13 factors
  TCF = 0.6 + (0.01 * TFactor)
  

• Environmental Factors(EF) : 8 factors
  EF = 1.4 + (-0.03 * EFactor)

• Adjusted Use Case Point(UCP)
  UCP = UUCP TCF EF

• Effort in Person-hours = UCP * 계수(20 or 28)

Creating And Managing The Work Plan

업무 식별

프로젝트에 필요한 업무를 식별할 때는, 주로 방법론에서 제공하는 표준 업무 목록을 참고하거나 "하향식 접근법(Top-Down)"을 사용한다. 높은 레벨의 업무를 식별하고 그것을 더 작은 단위로 나눈 뒤에, 이렇게 쪼개진 업무들을 계층적으로 구조화한 것을 작업 분할 구조도(Work Breakdown Structure, WBS)라고 한다.

업무 식별 단계에서 업무를 누락하게 되면, 이후에 특정 팀원들에게 갑작스럽게 과중한 업무가 배정되어 불만이 쌓이고, 최악의 경우 인력 이탈이나 프로젝트의 실패로 이어질 수 있다. 고로 PM은 업무를 빠짐없이 도출하고, 공정하게 로드 밸런싱(Load Balancing) 해주는 것이 매우 중요하다.

Project Workplan

WBS를 바탕으로 도출된 모든 업무 목록을 모아 전체적인 작업 계획을 작성하는 것을 말하고, 아래의 내용들이 명시되어야 한다.
– 작업명
– 작업 기간
– 현재 작업 상태
– 작업 간 종속 관계
– 마일스톤 (날짜)

Tracking Project Tasks

작업 계획이 수립되면, PM은 일정이 계획대로 진행되는지 시각적으로 모니터링하고 관리해야한다. 이때 주로 2가지의 차트를 사용하는데, 각각 Gantt Chart, PERT Chart이다.

• Gantt Chart : 막대 차트 형식으로, 프로젝트 진행상황을 언제든 파악하기에 용이하다.
• PERT Chart : 플로우 차트 형식으로, 주요 경로와 작업 의존도를 그리고 순서와 관계에 집중한 순서도이다,

Refining Estimates

Hurricane Model

불확실성의 원뿔을 허리케인 모델로 시각화한 그래프로, 가로축은 프로젝트의 진행 단계를 순차로 배치하고 세로축에는 소요 시간을 중심으로 구성한다. 이 때, 점선은 오차범위를 의미하고 원의 크기는 해당 시점에 예상되는 프로젝트 cost를 말한다.

프로젝트의 진행 순서는 아래와 같이 정의하고, 각각의 레벨은 특징과 상태를 지닌다.

Level 1 : 초기
초기에는 표준화된 프로세스가 거의 존재하지 않으며, 성공이 개발자 1~2명의 역량에 달린다. 그 사람이 나가면 프로젝트가 무너질 가능성이 급격히 높아진다.

Level 2 : 관리
프로젝트 단위로 일정한 규칙을 마련하는 시점이고, 계획을 세우고 일정과 비용을 관리하기 시작한다. 예전과 비슷한 프로젝트를 해낼 수 있는 지점이기도 하다.

Level 3 : 정의
회사(조직) 전체의 표준 프로세스가 확립된다. 이 시기를 기점으로 정확한 공통 가이드라인이 적용되고, 모든 팀이 메뉴얼에 따라 행동한다.

Level 4 : 정량적 관리
데이터와 숫자로 프로세스를 관리하며, 수치를 중심으로한 대화를 주고 받는다. 이로 인해 명확한 수치를 향상시키는 것을 목표로 하기에 결과 예측의 정확도가 향상한다.

Level 5 : 최적화
지속적인 개선과 혁신을 하는 시기로, 완성된 제품이 이미 완벽에 가까울 정도로 궤도에 올랐으나, 신기술을 도입하거나 데이터를 분석해 끊임없이 업그레이드를 하는 시기이다.

Managing Scope

Scope creep

Scope Creep은 프로젝트가 진행되는 도중에 새로운 요구사항이 계속해서 추가되면서, 결과적으로처음에 정했던 프로젝트의 범위(Scope)가 점점 늘어나는 현상이다. 이는 두 가지 관점을 가지는데, 일정 지연(Schedule overrun)과 예산 초과(Cose overrun)가 발생한다.

또한 주로 사용자가 요구사항을 늘리면 발생하게 되고, 초기예측의 불완전성을 인정하고 관리해야한다. 실제로 System Request에 비해 실제 비용은 4배(400%)까지도 차이가 발생할 수 있다.