프로젝트의 주요 기능을 분류해보면 계획, 조직화, 인력확보, 지휘, 통제가 있다. 여기서 인적자원과 관련한 조직화 및 인력확보는 매우 중요한 관리 요소이다. 그간 다뤄온 계획은 조직 목표 달성을 위해 업무 과정을 미리 설계하는 것인데 이러한 일들을 실제 행하는 인력, 팀, 조직은 목표 달성을 위한 R&R과 함께 작업을 배치, 부여하고 필요한 인력을 확보하고 교육하는 일련의 과정들이다.

프로젝트 조직

조직이란 이해당사자들의 상하 구조를 정의하고 하부조직 간의 관계를 이해시키며 개인과 하부조직의 책임과 권한을 명확히 하는 데 그 목적을 가진다. 이 목적에 따라 여러 관리기능을 활성화하고 예산과 경비 개념을 강조하며 프로젝트 진행 중 중간결과가 자연스럽게 보고되어 경영관리층의 의견이 쉽게 반영될 수 있도록 편성해야 한다. 더불어 업무팀 내에서의 단결력과 조직력이 강화되도록 운영되어야 함은 말할 것도 없다. 이러한 조직은 프로젝트 상황, 기업조직구조, 문화, 방침 등에 따라 그 설계 구조를 달리하는데 보통 3가지 형태의 조직구조를 갖는다.

🚩내부 효율성

: 직능/기능조직이다. 피라미드 형태의 계층으로 구성되며 현재 가장 많이 사용되는 유형 중 하나다. 주된 장점은 단순하고 업무 범위가 명확하다. 전문성이 높고 부서 내 의사 소통체계가 간결하다. 부서 내 명확한 책임과 역할이 이다. 하지만 단점 또한 많은 구성인데 부서 간 갈등이 발생할 소지가 크고 외부 고객 대응이 힘들다. 사일로 현상으로 편협된 활동과 의사결정이 발생하고 전체 프로젝트를 책임지는 부서가 없어서 동기부여가 매우 약하다.

🚩외부 효과성

: 프로젝트 조직이다. 프로젝트별로 조직이 구성되고 외부 환경이나 주어진 목표를 달성할 수 있는 최적의 형태이다. 이 조직의 주된 장점은 PM이 전체 프로젝트에 대한 권한을 쥐고 있으며 합류한 인력들에 대한 충성도가 높다. 팀원과 PM의 의사소통이 잘되고 과업 지향적이고 동질적 팀 분위기가 형성된다. 단점이라면 복수의 프로젝트가 운영될 때는 자원의 낭비가 발생하며 여러 노하우나 기술에 대한 개인 의존도가 높아 조직력에 문제가 생겼을 경우 대처가 어려운 편이다.

🚩내부 효율성 + 외부 효과성

: 상기 2가지 조직 형태의 장점을 모두 살린 조직, 일명 매트릭스 조직이다. 이 조직은 자원의 효율성을 극대화할 수 있고 수직/수평적 정보 공유가 가능하며 전체 프로젝트 상황을 한눈에 조망해 볼 수 있다. 다만 조직체계가 복잡하고 소속된 구성원들의 이해가 어려울 수 있다. 그만큼 관리 또한 복잡하고 의사결정의 리드타임도 길어질 수 있다. 조직을 목적에 맞게 자유롭게 세팅할 수 있으니 보통은 조직 내 능력 있는 인력들은 프로젝트에 참여시키지 않는 성향이 두드러진다.

프로젝트팀 관리

프로젝트는 영원한 조직이 아니고 목적 달성을 최우선으로 하기 때문에 그만큼 관리적 요소가 핵심적이다. 특히 PM의 주요한 역할 중 하나가 이 관리에 있다. PM은 팀원들과 밀접하게 움직이면서 그들의 개인적, 업무적 요구사항을 면밀히 파악하고 적절히 대응해야 할 필요가 있다. 그래서 어떤 팀원을 만나느냐도 중요하지만 어떤 PM을 만나느냐에 따라 프로젝트 자체의 향방이 달라질 수도 있다. PM은 조율과 리더십으로 팀원들에 대한 업무 의욕과 사기를 고취해야 한다.

다시 말해 프로젝트의 키는 PM이다. 이들의 주요 임무는 프로젝트 착수와 통제, 종료 등의 관리 활동으로 분류해 볼 수 있으며 각각의 활동들은 다음과 같다.

✔️ 착수: 프로젝트 파악, 팀원 선정, 프로젝트 환경구축, 공정계획 수립, 프로젝트 계획수립

✔️ 통제: 단계별 착수, 단계 진행, 완료

✔️ 종료: 종료 확인, 산출물 정리, 완료 보고

이러한 일들은 PM 개인적인 측면에선 매우 어려운 임무이다. 물론 조직의 보상이 있다고는 하나 책임과 권한, 리더십의 무게는 가볍지 않다. 그래서 PM의 능력에 대한 요구들이 있다. 보통은 인간적 능력을 바탕의 기술적인 능력과 관리적인 능력을 모두 요구받는다. 하지만 PM은 기술 전문가가 아니다. 물론 기술 기반의 관리자로서 그 역할을 가지고 갈 수도 있지만 일반적으로는 아니다. 그래서 그 상이함을 바로 인식하고 운영하지 않으면 수많은 갈등을 유발할 수 있다.

PM은 목표를 개발하지만, 기술자는 목표 성취가 우선이다. PM은 예산을 만들지만, 기술자는 예산을 맞춘다. PM은 관계성과 이해성을 내세운다면 기술자는 기술적 전문성을 앞세운다. PM은 의사소통이 우선이고 기술자는 지침 준수가 우선이다. 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개발: 프로토타이핑, 타스크분석, 시나리오기법
과포장: 프로토타이핑, 원가분석, 비용수익분석
계속적인 요구변경: 최대변경상한선, 점증적 개발
외부 모양 빈약: 벤치마킹, 성숙도분석
외부 기능 빈약: 사전검증, 대조확인
실시간 성능 빈약: 벤치마킹, 튜닝, 시뮬레이션
기술적 취약: 기술분석, 비용수익분석

조직 (프로젝트 성공률 1% 높이기)