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

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

프로젝트 조직

조직이란 이해당사자들의 상하 구조를 정의하고 하부조직 간의 관계를 이해시키며 개인과 하부조직의 책임과 권한을 명확히 하는 데 그 목적을 가진다. 이 목적에 따라 여러 관리기능을 활성화하고 예산과 경비 개념을 강조하며 프로젝트 진행 중 중간결과가 자연스럽게 보고되어 경영관리층의 의견이 쉽게 반영될 수 있도록 편성해야 한다. 더불어 업무팀 내에서의 단결력과 조직력이 강화되도록 운영되어야 함은 말할 것도 없다. 이러한 조직은 프로젝트 상황, 기업조직구조, 문화, 방침 등에 따라 그 설계 구조를 달리하는데 보통 3가지 형태의 조직구조를 갖는다.
 
🚩내부 효율성 
 : 직능/기능조직이다. 피라미드 형태의 계층으로 구성되며 현재 가장 많이 사용되는 유형 중 하나다. 주된 장점은 단순하고 업무 범위가 명확하다. 전문성이 높고 부서 내 의사 소통체계가 간결하다. 부서 내 명확한 책임과 역할이 이다. 하지만 단점 또한 많은 구성인데 부서 간 갈등이 발생할 소지가 크고 외부 고객 대응이 힘들다. 사일로 현상으로 편협된 활동과 의사결정이 발생하고 전체 프로젝트를 책임지는 부서가 없어서 동기부여가 매우 약하다. 
 
🚩외부 효과성
: 프로젝트 조직이다. 프로젝트별로 조직이 구성되고 외부 환경이나 주어진 목표를 달성할 수 있는 최적의 형태이다. 이 조직의 주된 장점은 PM이 전체 프로젝트에 대한 권한을 쥐고 있으며 합류한 인력들에 대한 충성도가 높다. 팀원과 PM의 의사소통이 잘되고 과업 지향적이고 동질적 팀 분위기가 형성된다. 단점이라면 복수의 프로젝트가 운영될 때는 자원의 낭비가 발생하며 여러 노하우나 기술에 대한 개인 의존도가 높아 조직력에 문제가 생겼을 경우 대처가 어려운 편이다.
 
🚩내부 효율성 + 외부 효과성
: 상기 2가지 조직 형태의 장점을 모두 살린 조직, 일명 매트릭스 조직이다. 이 조직은 자원의 효율성을 극대화할 수 있고 수직/수평적 정보 공유가 가능하며 전체 프로젝트 상황을 한눈에 조망해 볼 수 있다. 다만 조직체계가 복잡하고 소속된 구성원들의 이해가 어려울 수 있다. 그만큼 관리 또한 복잡하고 의사결정의 리드타임도 길어질 수 있다. 조직을 목적에 맞게 자유롭게 세팅할 수 있으니 보통은 조직 내 능력 있는 인력들은 프로젝트에 참여시키지 않는 성향이 두드러진다.
 
 

프로젝트팀 관리

프로젝트는 영원한 조직이 아니고 목적 달성을 최우선으로 하기 때문에 그만큼 관리적 요소가 핵심적이다. 특히 PM의 주요한 역할 중 하나가 이 관리에 있다. PM은 팀원들과 밀접하게 움직이면서 그들의 개인적, 업무적 요구사항을 면밀히 파악하고 적절히 대응해야 할 필요가 있다. 그래서 어떤 팀원을 만나느냐도 중요하지만 어떤 PM을 만나느냐에 따라 프로젝트 자체의 향방이 달라질 수도 있다. PM은 조율과 리더십으로 팀원들에 대한 업무 의욕과 사기를 고취해야 한다.
 
다시 말해 프로젝트의 키는 PM이다. 이들의 주요 임무는 프로젝트 착수와 통제, 종료 등의 관리 활동으로 분류해 볼 수 있으며 각각의 활동들은 다음과 같다.
 
✔️ 착수: 프로젝트 파악, 팀원 선정, 프로젝트 환경구축, 공정계획 수립, 프로젝트 계획수립
✔️ 통제: 단계별 착수, 단계 진행, 완료
✔️ 종료: 종료 확인, 산출물 정리, 완료 보고
 
이러한 일들은 PM 개인적인 측면에선 매우 어려운 임무이다. 물론 조직의 보상이 있다고는 하나 책임과 권한, 리더십의 무게는 가볍지 않다. 그래서 PM의 능력에 대한 요구들이 있다. 보통은 인간적 능력을 바탕의 기술적인 능력과 관리적인 능력을 모두 요구받는다. 하지만 PM은 기술 전문가가 아니다. 물론 기술 기반의 관리자로서 그 역할을 가지고 갈 수도 있지만 일반적으로는 아니다. 그래서 그 상이함을 바로 인식하고 운영하지 않으면 수많은 갈등을 유발할 수 있다.
 
PM은 목표를 개발하지만, 기술자는 목표 성취가 우선이다. PM은 예산을 만들지만, 기술자는 예산을 맞춘다. PM은 관계성과 이해성을 내세운다면 기술자는 기술적 전문성을 앞세운다. PM은 의사소통이 우선이고 기술자는 지침 준수가 우선이다. PM은 다른 사람의 과업을 평가하지만, 기술자는 자신의 과업을 평가한다.
 




 

팀원 관리 프로세스

팀원, 인적자원에 대한 관리영역은 조직계획, 팀원 확보 및 팀 개발 단계로 구성된다.
 
♾️ 조직계획
: 조직계획은 프로젝트 역할, 책임, 보고 관계를 확인, 문서화 및 할당하는 것이다. 대부분의 프로젝트에서 조직계획은 프로젝트의 가장 초기 단계에 행해진다. 그래서 지속적인 상태를 확인하기 위해서 프로젝트 전 과정에서 정기적으로 검토되어야 하며 초기 조직이 더 이상 효과적이지 않다면 즉시 변경해야 한다. 즉, 조직은 살아 움직이는 생명체이기에 문제가 생긴다면 바로 치료하고 조처를 해야 할 대상이다.
 
♾️ 팀원 확보
: 팀원 확보는 필요한 인적자원(개인 또는 조직)을 프로젝트에 배치하고 작업하는 것이다. 하지만 대부분의 환경에서는 최적의 자원을 이용할 수 없는 경우가 많으므로 PM은 이용 가능한 자원이 프로젝트 요건을 충족할 수 있도록 주의를 기울이고 관리하여야 한다. 팀원은 다양한 경로를 통해 확보되며 그들의 과거 경험, 관심 영역 및 활용 가능성을 포괄적으로 평가하여 채용한다. 특히 팀원 간 관계, 책임과 역할을 기반한 상호 연계성을 고려한다.
 
♾️ 팀 개발
: 팀 개발은 개인으로서 기여하는 프로젝트 관련자들의 능력을 향상할 뿐만 아니라 팀으로 기능을 하는 팀의 능력을 향상하는 것 모두가 포함된다. 이러한 개인적 개발은 팀 개발의 토대가 되며 팀 개발은 프로젝트 목적을 충족시키기 위한 프로젝트의 능력에 중요한 요소가 된다. 팀 개발은 프로젝트 전반에 걸쳐 발생하고 다중적인 책임이 얽혀 움직일 경우가 많다. 그래서 이를 관리하는 PM의 책임이 프로젝트의 성공을 좌지우지할 수 있다.
 
 
 
 
※ 도망가자?!
좋든 싫든 프로젝트를 맡게 되면 만감이 교차한다. 도전할만한 일이 눈앞에 있고 더 멋지게 해내고 싶은 자신감이 뿜어져 나오다가도 이 힘든 일을 또 어찌해야 할꼬 하면서 종료일이 군 제대일만큼 멀게만 느껴지기도 한다. 일을 진행하면서 많은 우여곡절이 있지만 이 또한 사람이 하는 일이라 스트레스도 만만하지 않다. 그래서 사람에 따라 우울증에 걸리기도 하고 심한 압박감에 몸이 아프다 못해 쌩하니 도망(?)가는 사람을 보기도 했다. 가슴 아픈 일이지만 실제 업무에서 많이 벌어지는 일이고 가면 갈수록 잦아지는 것이 누굴 탓할 것은 아닌 것 같다. 정말  할 말은 많지만 말이다.

품질 (프로젝트 성공률 1% 높이기)

품질!

품질은 제품의 가치를 나타내는 척도로 제품/서비스가 그 목적을 만족시키는가의 여부를 결정하기 위한 평가의 대상이 되는 고유한 특성을 말한다. 이에 대한 정의들이 꽤 많은 편인데 IEEE에서는 주어진 요구사항을 만족시킬 수 있는 SW의 기능과 특성을, ISO/IEC 9126에서는 명시적이나 묵시적인 필요를 만족시키는 능력과 관련된 소프트웨어 특성 및 특징을 말한다. 
 
그래서 품질 또한 관리의 대상으로 정책을 가동하고 있으며 측정과 더불어 명확한 목표를 가지고 제시된다. 이러한 품질목표는 제품과 프로세스에 대한 의미가 모두 내포되어 있다. 제품 측면에서는 고객의 제품 품질 요구사항을 식별하고 프로세스 측면에서는 프로젝트에 적합한 수행 공정을 정의한다. 
 
 
🚩소프트웨어 품질
 :  소프트웨어 프로젝트에서는 수명주기에 따라 개발 초기 프로젝트의 특성과 품질 요구사항을 철저히 파악하여 품질목표를 설정하고, 개발단계에서는 이 충족 여부를 그리고 운영단계에서는 사용 중 품질을 점검하게 된다. 이는 개발 완료 상태에서의 평가만으로는 소프트웨어의 신뢰성과 안정성을 보장할 수 없고 개발이 완료된 상태에서의 개선은 개발에 투입된 것 이상의 시간과 비용이 발생하기 때문이다.
 
소프트웨어는 수명주기와 맞물려 품질을 다룬다. 구현단계에서는 디버깅을 통한 증명을, 상세설계/시험 단계에선 테스트를 통한 검증(Verification)을, 기본설계/통합테스트 단계에서는 품질관리를 통한 확인(Validation)을, 요구분석/인수테스트 단계에서는 품질보증을 통한 인증(Certification)을 한다.
 
이러한 활동에는 비용이 발생하기 마련이다. 이 품질비용은 사용자 요구사항 수준을 고려하여 적정 비용 선을 설정하며 크게 예방비용, 평가비용, 실패비용으로 분류하고 관리한다. 이를 통해 총 품질비용과 최적의 품질수준을 찾아낸다.
 
🚩프로세스 품질
:  제품에만 집중되어 있던 품질은 프로세스 관점에서 높은 품질 수준을 유지하기 위한 중요성을 인식하면서 관심이 높다. 제대로 된 프로세스는 높은 품질의 제품생산 확률이 증가한다는 것은 알기 때문이다. 이에 대한 연구는 CMM/i, SPICE, Bootstrap 기법 등 여러 가지며 프로세스 품질에서 중요한 개발 방법, 도구 적정 여부, 표준 적용 및 관리과정의 적정성을 상세히 다루고 있다.
 
♾️ ISO9000 시리즈: ISO9000-1(품질경영/품질보증 표준), ISO9001(설계/개발/생산/서비스 품질보증), ISO9002(생산/설치 품질보증), ISO9003(최종 검사/시험 품질보증)
 
♾️ ISO/IEC 12207: 소프트웨어 생명주기 내 품질 활동을 5가지 기본 프로세스와 8가지 지원프로세스, 4가지 조직 프로세스로 구성
♾️ CMM/i: 소프트웨어 프로세스 실행 수준을 성숙시키기 위한 능력 심사와 결과에 따른 프로세스 개선 도구로 활용하며 초기 – 관리 – 정의 – 정량적 관리 – 최적화 5단계로 성숙도를 관리
♾️ ISO/ICE 15504(SPICE): ISO9000에서 프로세스 개선 활동과 성숙도 기반의 평가지침을 보완하기 위해 개발
 
🚩프로덕트 품질
: 구현된 제품의 품질로 소프트웨어 제품의 품질이 기술되고 평가될 때 적용되는 속성과 품질을 나타내는 변수들을 품질특성이라고 한다. 이를 다루기 위한 표준은 ISO/IEC 9126, ISO/IEC 14598에서 자세히 다룬다.
 




 

품질관리 프로세스

품질관리 프로세스는 품질계획 프로세스, 품질보증(QA) 프로세스, 품질통제(QC) 프로세스로 구성되며 품질시스템에서 이러한 프로세스를 거쳐 품질정책, 목표, 책임 그리고 그것의 구현을 결정을 총괄하는 관리기능 활동이다.
 
🚩품질 계획
 : 품질 표준이 프로젝트에 적절한지 식별하고 그것을 어떻게 만족시켜야 하는지를 결정한다. 이는 프로젝트 계획에서 매우 중요한 단계이며 프로젝트 계획의 다른 활동들과 병행되어 정기적으로 진행한다. 
 
🚩품질보증
: 프로젝트의 프로세스 및 산출물에 대해 검증, 확인, 검토, 감리 및 품질보증 활동을 개선하여 프로젝트 요구사항을 충족하도록 관리한다. 이는 프로젝트 품질 표준을 충족한다는 확신을 고객에게 제공하기 위해 품질시스템에서 정의된 체계적인 품질보증 활동을 하기 위함이다. 
 
🚩품질통제
:  프로젝트 작업 결과가 품질 표준에 부합하기 위해 작업 결과물이 품질 표준에 적합한지를 감시하고 불만족스러운 결과에 대해서는 원인을 제거하는 방법을 제시한다. 이때 쓰이는 도구나 기술은 보통 inspection, Pareto diagram, 표본추출검사, 원인 결과분석 등이 있다.
 
 

CMMI(Capability Maturity Model Integration)

CMMI는 2000년 미국 국방성의 지원으로 산업계와 정부, 카네기멜론대학의 소프트웨어공학 연구소(SEI)가 공동으로 개발한 CMM의 후속 모델이다. 이는 CMM의 종류가 너무 많이 생긴 문제점을 개선하기 위해 개발되었는데 여러 입장에서 각각의 모델별로 별개 적용하는 것이 아닌 전체 관점에서 적용하기 위한 툴로 보면 된다. 즉, 기존 CMM이 소프트웨어 개발모델에 한정된 것과 달리 시스템과 소프트웨어 영역을 통합하여 기업의 프로세스 개선 활동을 광범위하게 지원하는 것이 주된 특징이다. 
 
CMMI는 모델이다. 이것은 과정이 아니며 소프트웨어 개발 및 시스템 엔지니어링에서 사용 중인 것으로 입증된 일련의 조직 동작을 제공한다. 이런 방법에 모델을 사용하는 이유는 프로세스 개선 작업에는 조직 작동 방식, 필요한 기능 및 해당 기능이 상호 작용하는 방식이 필요하며 모델은 이를 충족하고 지원할 수 있기 때문이다. 이러한 모델을 사용할 때 이점이라면 의사소통에 도움이 되는 공통 프레임워크 및 언어를 제공하는 것이 가장 크다 할 수 있고 합의된 표준 제공으로 여러 불일치를 해결하는 데 도움을 줄 수 있기 때문이다.
 
 
 
 
※ 품질 책임!
얼마 전 복지시스템을 신규시스템인 차세대 사회보장 정보시스템 “행복e음”으로 교체하면서 발생한 오류로 여러 유관기관의 업무가 마비된 사건이 있었다. 그 실상이 낱낱이 밝혀지며 특정 누구 한 사람의 잘못이 아닌 이 프로젝트 참여한, 정부를 비롯한 모든 이해당사자의 안일함과 무책임함에, 한마디로 총체적 난국인 상황에 모두가 말을 잃었다. 과연 이러한 저품질 산출물은 어떻게 만들어졌고 왜 오픈을 강행했던 것인가? 정말 아무도 이 품질 상태를 보지 못한 것이었을까? 

의사소통 (프로젝트 성공률 1% 높이기)

의사소통의 관리는 프로젝트 정보가 시의적절하고 적정한 생성, 수집, 분리, 저장, 배분 등을 위해 필요한 프로세스들의 집합이다. 이를 통해 프로젝트와 관련된 이해당사자들이 필요로 하는 정보와 의사 교환을 할 수 있다. 우리가 진행하는 프로젝트에는 수많은 자원이 투입되는데 일하기 위한 가장 중요한 자원은 사람이다. 이 사람들은 출신도 학력도 성별도 취향도 성격도 모두 제각각이기에 이들 간의 의사소통이 미흡하거나 부재할 경우 우리가 생각할 수 있는 모든 재앙이 현실이 될 수 있다.
 
 

의사소통

의사소통? 그거 누구나 다 아는 거지. 意思疏通. 의사소통은 크게 이야기하여 의미 있는 정보를 전달하는 과정이라고 할 수 있으며 두 명 이상의 사람 사이에 구두나 여러 방법으로 의사나 감정을 전달하고 반응하며 상호 간의 의미를 추론하는 과정들을 말한다. 이런 의사소통의 방법들은 워낙 다양하고 눈에 보이고 보이지 않는 것들이 섞여 있는데 프로젝트에서는 보다 명시적이고 명확한 소통 방법이 필요하다. 즉, 중요한 것은 여러 이해당사자의 프로젝트 정보요구를 식별하는 것이다.
 
 

의사소통 관리

프로젝트 내 의사소통에서 가장 중요한 것은 다시 이야기하자면 이해당사자들의 프로젝트 정보 요구사항을 식별하는 것이다. 그래서 의사소통 관리계획은 프로젝트 관련 조직이나 개인에게 일관성 있게 정보가 전달되어야 하며 이를 통해 의사결정이 올바르게 이뤄지도록 해야 한다.
 
이러한 의사소통 관리계획 시에는 
🚩 어떤 정보가 언제 수집되어야 하는가
🚩 누가 이 정보를 접수할 것인가
🚩 수집된 정보의 취합, 저장에는 어떠한 방법을 사용할 것인가
🚩 보고는 누가 누구에게 하는가
🚩 보고체계는 어떻게 정의할 것인가
🚩모든 보고 단계별 정보의 배포 주기는 어떻게 결정할 것인가
등을 깊이 있게 고려해야 한다. 이를 위해서 여러 문서양식, 템플릿 및 시스템을 적극적으로 사용하면 의사소통의 부가적인 업무를 줄이며 이해관계자별로 상이한 형태들을 하나로 통일시킬 수 있고 필요시 자료들을 선별하여 공유하는 등 시간과 비용을 획기적으로 개선할 수 있다. 그래서 이러한 관리에는 시스템을 최대한 활용해서 운영한다.
 
 

의사소통 종류와 프로세스

프로젝트에서 의사소통의 종류에는 몇 가지가 있다.
 
✔️ 회의: 이해당사자들 간의 상호 작용과 이해를 명확화한다. 사전 준비와 마무리가 필요하고 회의를 잘 끌어내 갈 퍼실리테이터(회의 구성원 간 상호작용을 촉진하여 목적을 달성하도록 돕는 전문가)의 도움을 받아 효율적인 관리를 통해 시간과 비용의 낭비를 줄여야 한다.
✔️ 보고: 이슈, 문제점 및 여러 상황을 주기/비주기적으로 알릴 필요가 있을 시 진행한다. 보고를 위해서는 사안의 근거가 필요하고 충분한 정보를 바탕으로 보고받는 주체에 따라 차등적인 내용이 필요하다. 
 
✔️ 발표: 공식적인 장소에서 여러 이해당사자에게 문서화된 시청각 자료를 활용하여 발표자의 설명과 함께 정보를 전달하는 것이다. 다만 일방적인 정보전달이 될 수 있으며 청자가 이 정보를 제대로 이해했는지는 파악하기 어렵다.
✔️ 시스템: 이메일, 메신저, 협업툴 등을 활용한 공식/비공식적 방법으로 시공간의 제약 없이 의사소통을 할 수 있는 훌륭한 도구이다.
✔️ 비공식적 접촉: 전화, 방문 등 열린 의사소통을 위한 자유로운 환경을 조성하는 방법이다. 다만 개인적이고 공식화하지 않는 접촉은 공식적인 의사소통 채널을 무너뜨릴 수 있어 조심하여야 한다.
 
그리고 의사소통의 프로세스는 다음과 같다.
 
1️⃣ 계획 수립: 프로젝트 이해당사자의 정보 및 의사소통 요구 결정, 즉 누가 어떤 정보를, 언제 필요로 하고 어떻게 전달할 것인가에 대한 결정 단계로 안건이 될 요구사항을 문서로 정리한다.
2️⃣ 정보 배포: 필요 정보를 적시에 프로젝트 이해당사자들이 활용할 수 있도록 공유하는 단계로 의사 소통계획에 대한 문건을 전달한다. 이는 의사소통 이전에 전달이 되어야 한다.
 
3️⃣ 성과 보고: 업무 수행과 관련한 정보를 수집, 배포하는 것으로 상태 보고, 진도 측정 및 예측이 포함된다.
4️⃣ 의사소통 종료: 단계 또는 프로젝트 완성을 공식화하기 위해 정보 발생, 수집, 배포하는 것으로 이해당사자들의 요구사항을 만족시키고 이슈를 해결하기 위해 의사소통을 관리하는 것이다.
 




 

의사소통 양식들

회의는 되도록 짧게 하라고 한다. 더 나아가선 회의가 필요 없도록 하자고는 하지만 현실적으로 어렵다. 그러다 보니 많은 회의가 실패로 끝나는데 그 특징들을 보면 회의만 하고 논의는 없고, 논의는 하지만 결정되는 것이 없으며 결정했지만 실행이 없어서 결국 아무도 책임을 지지 않는 것(남 탓!)이다. 그래서 앞선 프로세스와 종류를 적절히 선택하고 관리한다면 매우 효과적이고 효율적인 의사소통을 할 수 있다. (기록을 남겨야 한다.)
 
♾️ 회의록: 목적과 개요, 시간, 자료 숙지, 의사결정 위주의 정리, 쟁점에 대한 독립적 회의, wrap-up 등 정리와 함께 회람하여 오해가 없도록 한다.
♾️ 보고서: 정기 보고를 기반으로 일간/주간/월간/분기별 등 공식 보고를 하며 기타 비정기적인 수시 보고 등을 하는데 필요한 프로젝트에 적합한 양식을 개발, 사용한다.
♾️ 공문: 조직 간 공식적 문서로 프로젝트 진행단계별로 필요시 처리한다. 다만 잦은 공문은 피로감을 높일 뿐이며 이는 프로젝트를 중심의 조직 간 이해와 배려로 업무 순조롭게 진행하는 노력이 필요하다.
 
 
 
 
※ 커피 한잔, 담배 한 개비
일은 힘들다. 하지만 일보다 더 힘든 건 사람이다. 특히나 프로젝트에서 만나는 사람은 동료 아니면 적이고 필요하다면 적과의 동침도 서슴없이 해야 할 때가 있다. 내 마음같지 않다. 이럴 때는 사실 비공식적 접촉이 사람 사이의 기름칠을 하는데 좋은 방법이다. 요즘은 술도 별로 마시지도 않고 업무가 끝나면 바로 퇴근해버리는 일상들이지만 업무시간에서도 방해받지 않는 범위 내에서 커피 한잔, 담배 한 개비(담배도 잘 안핀다. 다른 좋은 것이 뭐가 있을까?)에 많은 업무가 실마리를 찾을 수도 있어 무조건 좋다 나쁘다는 것으로 판단하기엔 무리가 있다. 그러니 무조건 배척하기보다는 적당하게 활용해보면 어떨지.

예산 계획 (프로젝트 성공률 1% 높이기)

프로젝트 관리계획을 개발하는 데 있어 큰 3가지가 일정, 범위 및 예산이 있다. 이 3가지가 긴밀하고 유기적으로 연계되어 결국엔 성공적인 관리계획을 수립하게 된다. 앞선 일정, 범위와 더불어 이번에는 예산에 대해서 살펴보자.
 
 

예산관리

승인된 예산 범위 내에서 프로젝트를 완료하기 위한 활동. 앞서 이야기한 일정, 범위와의 관계를 보자면, 만약 일정을 앞당기려면 범위를 줄이거나 원가를 높여야 하고, 원가를 줄이려면 범위를 줄이거나 일정을 늘려야 한다. 특히 돈과 관련한 특성상 모두 다 중요하지만 예산만큼 민감한 사안도 없다. 하지만 이 3가지가 삼위일체처럼 움직여야 함은 변함없다. 이렇듯 중요한 예산관리는 일반적으로 예산을 산정하고 편성하여 통제하는 3단계를 거치는 다음을 보자.
 
✔️ 예산산정: 프로젝트 활동에 소요되는 자원의 원가를 예측한다.
✔️ 예산편성: 프로젝트 전체적인 원가의 예측치를 각각의 활동에 배정한다.
✔️ 예산통제: 편성된 예산, Cost baseline을 기준으로 예산이 적절한 시기에 제대로 쓰였는지를 감시한다.
 
 

예산 산정

비용은 단위 공정별로 원가 산정과 이를 바탕으로 총원가를 산정한다. 이를 통해 추정원가 요약 및 상세로 공유되며 추정원가는 단위를 통일해야 하고 프로젝트 진행상 변경을 고려하여 모든 사항을 상세하게 구별하고 기술하는 것이 중요하다. 이러한 예산산정의 방법들이다. 
 
🚩Top down
: 전문적 결정의 한 형태로 유사 추정이라고도 한다. 즉, 앞서 수행된 다양한 형태의 유사 프로젝트의 실제 비용을 확인하고 이를 향후 원가 추정의 근거로 쓰는 방법이다. 이는 원가 추정 시 필요정보의 양이 제한적이고 명확하지 않을 때 사용하며 이미 수행 프로젝트의 유사도와 추정인력의 전문성에 따라 신뢰도가 높아진다. 다만 이의 수행 원가는 적게 소요되지만 다른 방법들에 비해 정확도가 떨어질 수 있으며 활동별 원가를 추정하기가 어려워진다.
 
🚩Bottom up
: 프로젝트 개별 작업목록 각각의 비용을 합산하여 프로젝트 총원가를 추정하는 방법이다. 이 방법의 정확성은 개별작업목록의 규모에 따라 다르며 작업목록의 크기가 작을수록 원가의 정확성이 높아진다.
 
🚩Parametric
: 모수 기법으로 함수 모델을 근간으로 정량적 통계를 사용하여 비용, 시간, 자원 등 프로젝트를 완료하는 데 필요한 예상 자원의 양을 계산한다. PM은 추정치 계산 시 과거 데이터 또는 프로젝트를 기반으로 변수 또는 특성을 사용하는데 그 정확성은 모델링 도출에 사용되는 기초 데이터가 정확할수록, 모델에서 사용되는 변수가 측정 가능할수록, 프로젝트 작업 규모에 상관없이 모든 것이 관리되고 측정 가능할수록 높아지기 마련이다.
 
이러한 기법을 바탕으로 예산 산정이 된다면 조직과 프로젝트 차원에서 예산을 집행한다. 즉, 액수가 큰 프로젝트는 기업의 자본 유동성이나 재무 상태에 큰 영향을 끼칠 수 있기 때문에 지출 시기를 잘 관리하여야 한다. 또 이런 시기가 계획과 어긋난 경우 즉각 대처할 수 있는 모니터링 시스템을 가동해야 한다. 여기엔 기성고(Earned Value) 등의 여러 측정치를 주기적으로 관리한 데이터들이 기반이 된다.
 




 

원가 

PM이 하는 일은 워낙 많기도 하지만 그중에서 이 원가를 책임지는 중차대한 역할을 가지고 있다. 즉, 승인된 예산 내에서 프로젝트를 어떻게 잘 끝마칠 수 있을까 하는 고민의 시작은 원가와 밀접하다. 그런데 사람이 주 자원인 소프트웨어 개발 같은 경우 원가를 무시하거나 중요하게 생각하지 않는 경향이 있다. 인건비만 알면 된다는 입장인데 이 또한 그리 간단한 것이 아니다. 여하튼 프로젝트 원가와 조직 원가의 상관관계를 잘 이해하여야 하며 모든 내용을 숙지하고 활용해야 한다.
 
프로젝트 원가는 크게 인건비, 재료비, 경비로 나뉜다.
 
✔️ 인건비: 프로젝트에 참여하는 인력에게 지출되는 비용이다. 대부분 특정 기간에 지급하기로 한 금액과 실제 투입된 기간에 따라 산정한다. 다양한 인력의 상황에 여러 변수가 있을 시에는 국가/정부 기관에서 배포되는 노임단가를 기준으로 조정하기도 한다.
✔️ 재료비: 기자재, 장비 도입 및 구매에 사용되는 비용이다. 대상이 무언가에 따라 직/간접재료비로 구분하기도 하며 검수 기준에 맞춰 계획하고 집행한다. 비목은 산업 및 사업 등에 따라 다소 상이하게 부를 수도 있지만 큰 틀에서 이해하면 된다. (이 또한 가이드라인이 있으니 여기에 따르면 된다)
 
✔️ 경비: 프로젝트 원가 중 인건비와 재료비를 제외한 모든 금액을 말한다. 이는 업종이나 기업 회계규정 등에 따라 달라질 수 있다.
 
그러면 조직 차원에서의 원가는 어떤가? 조직을 구성하는 인력들, 즉 PM, 사업부, 경영자 및 투자자가 보는 원가는 모두 다를 수밖에 없다. PM은 직접비 중심으로, 사업부는 재무 관점의 판매비를, 경영자와 투자자는 영업이익과 경상이익을 중심으로 본다. 이 또한 프로젝트 보고 주기에 따라 관리되고 보고되며 의사결정에 매우 중요한 자료가 된다. 
 
 
 
 
※ 관리 PM? 개발 PM?
규모가 좀 있는 프로젝트에 들어가면 PM도 여러 종류가 있다. 물론 전문인력을 앉혀서 제대로 관리하는 것도 중요한데 그렇지 않은 프로젝트는 한 사람이 모든 것을 다해야 하는 경우가 다반사다. 그러다 보니 PM에 따라 각기 강점인 부분들을 제외하곤 나머지는 모자라거나 모르는 부분이 있을 수밖에 없다. 하지만 그렇다고 주저앉아 있을 수는 없다. 해내야 할 일을 어깨에 얹고 있는 이상 열심히 배우고 익히고 경험하는 수밖에. 뭔가 위로의 말을 기대했다면 미안하지만, 없다. 그냥 하는거다. 단! 도망가지 마라.

일정 계획 (프로젝트 성공률 1% 높이기)

일정 관리

일정 관리는 프로젝트가 납기 내 완료될 수 있도록 보증한다. 범위관리가 무엇에 관한 것이라면 일정 관리는 언제 어떻기에 관한 것이다. 그렇다면 누구나 다 아는 일정은 그 일정일까? 프로젝트에서 일정은 다양한 의미를 내포하는데 역할로 본다면 다음과 같다.
 
✔️ 프로젝트의 시작과 종료 시점, 상호관계 및 마일스톤의 설정
✔️ 프로젝트 외부에서 발생하는 활동과의 조율
✔️ 프로젝트 내부의 활동 간 연관관계 설정
✔️ 수행 기간 동안 활동별 자원할당과 진행
✔️ 주요 자원 요소들 및 장애 파악
✔️ 위험 요소 파악
 
그러면 일정도 기준이 있을까? 있다. 일정을 작성할 때는 수행 기간과 우선순위를 따진다. 여기엔 시작 일자와 완료 일자를 기준으로 잡는 방법 두 가지가 있다.
 
✔️ 시작 일자 기준: 프로젝트 시작을 명시하고 활동 기간과 연관관계에 따라 종료 일자를 도출
✔️ 완료 일자 기준: 프로젝트 종료를 명시하고 활동 기간과 연관관계에 따라 시작 일자를 도출
 
이렇듯 프로젝트 일정은 복잡해 보일 수 있으나 정해진 프로세스가 있으며 업무 범위를 명확히 하여 프로젝트를 수립하고 통제함을 기본으로 한다. 이를 통해 범위와 원가를 잡을 수 있는데 그 구성엔 활동을 정의하고 순서를 배열하며 각각 자원과 기간을 산정하여 일정을 작성하는 흐름이다.
 
 

Critical Path

Critical Path(주요공정)는 임계경로 분석법(CPM:Critical Path Method)으로 불리는 프로젝트 관리계획 및 통제 기법으로 많이 사용된다. 이는 일련의 프로젝트 활동 일정을 짜기 위한 수학적인 알고리즘으로 시작부터 끝까지 프로젝트를 완수하는 데 드는 시간을 측정하고 가장 긴 의존 활동을 식별하여 결정한다. 이 방법은 1956년부터 1958년까지 미국 듀퐁(Dupont)사가 건설계획을 추진하면서 개발하였고 이 시기 즈음하여 미국 GM과 해군이 PERT(Program Evaluation and Review Technique)라는 것을 만들었다. 이것들은 모든 형태의 프로젝트, 예를 들어 건축, 소프트웨어 개발, 제품 개발, 각종 공학 및 연구 프로젝트에 널리 쓰이고 있다.
 
그래서 흔히 들어본 PERT/CPM이 바로 이것이다. PERT는 계획단계에서 공사 기간 단축이 요구되는 때에 비관치, 낙관치, 실제 가능치를 고려하여 공수를 산정한다. CPM은 최소의 비용 증가로 공사 기간을 단축하려 하는 방법으로 각 작업의 시간당 비용증가율을 비교하여 산정하는데 PERT는 활동 수행 기간 추정에 확률 개념을 반영한다는 측면에서 CPM과 구분된다.
 

다시 말해 CPM은 프로젝트 계획, 리소스 할당 및 작업 일정 계획에 대한 통찰력을 제공하며 이를 사용해야 할 이유는 몇 가지가 있다.

🚩 향후 계획 개선: 현재 진행상태와 기대치를 비교, 현재 프로젝트의 데이터를 추후 프로젝트 계획에 반영한다. 
🚩 효과적 자원관리: PM이 작업 우선순위를 정하는 데 도움이 되고 자원을 적재적소에 배치하는 법을 지원한다.  
🚩 업무 지연 방지: 네트워크 다이어그램을 이용하여 프로젝트 종속성을 계획하여 일정을 계획한다.  

 
 

Critical Path

< Critical Path 예 >

 
Critical Path는 종속성이 중요한데 이는 활동 중 시작일과 종료일 사이의 관계를 말하여 활동 간 논리적 관계를 이야기한다. 이때 지연과 선행을 염두에 두고 작업을 하여 WBS 활동의 전후 관계를 살피고 네트워크 다이어그램을 작성한 뒤 연관관계를 파악하여 프로젝트 종료일과 여유시간을 찾아 공정을 마련한다.
 
✔️ 지연(lag)은 작업 종료 후 후행 작업을 기다리는 시간이다
✔️ 선행(lead)은 작업 종료 이전 후행 작업이 시작되어 두 작업이 중첩된 시간을 말한다.
✔️ Critical Path는 여유 시간이 없는 일련의 업무와 작업으로 프로젝트 납기일에 영향을 끼치는 활동들의 집합이다.
 

 

공수 산정

산정은 프로젝트팀원에 의해 이뤄져야 하며 실제 업무수행을 통해 시행착오를 거쳐야지만 체득할 수 있는 기술이다. 여기엔 여러 가지 방법들이 있는 대표적으로는 이전 유사한 프로젝트의 경험을 바탕으로 산정하거나 다수의 프로젝트 수행으로 구축된 DB나 방법론을 쓰기도 하고 PERT나 Function Point도 사용한다. 우리나라의 경우에는 한국소프트웨어산업협회에서 소프트웨어 사업 추진 시 SW 개발비 등에 대한 적정 대가를 산정하기 위한 기준으로서 “SW 사업 대가 산정 가이드”를 공표하니 이 자료를 자세히 참고해 보는 것도 업무 진행에 많은 도움을 받을 수 있다.
 
 

일정 관리 도구

도구들은 너무도 많아 일일이 나열하기도 뭐하다. 하지만 가장 기본이 되는 두 가지 정도만 챙겨도 도구 사용엔 별다른 문제가 없을 것이다.
 
🚩마일스톤 : 목표를 달성하기 위해 중간중간 발생하는 주요한 이벤트로 프로젝트 기간 중 주요 달성 및 완료의 표식이며 주요 산출물의 달성일을 말한다. 마일스톤은 할당된 기간이 없고 일정표상에 비어있는 다이아몬드(◇)로 기술하며 프로젝트 상 중요한 일자에 stakeholder와의 의사소통에 중요하게 쓰인다.
 
🚩간트차트 : 일명 Bar 차트로 진척 보고나 통제용으로 주로 쓰인다. 전체 프로젝트의 시작과 종료 기간을 한눈에 볼 수 있고 모든 활동이 기술되어 있어서 프로젝트 내 진척도에 대한 확인 및 의사소통에 주로 사용된다. 작성은 간단하게는 엑셀과 함께 전문화된 많은 툴이 있어 프로젝트 맞는 것을 골라 적극적으로 사용하는 것이 좋다.
 
 
 
 
※ 사용하실 겁니까?
도구가 없었을 땐 손으로 그렸지만, 지금은 그럴 필요가 전혀 없다. 다만 도입보다도 중요한 것은 경영층과 관리자층의 의지이다. 막상 도입은 했는데 쳐다보지도 않는다면 아래에선 죽어라 하고 헛일만 하는 것일 뿐. 이럴 바에 개발에라도 더 신경 쓰길 원하는 것이 그들의 마음이다. 현실과 괴리되어 흘러가는 프로젝트는 죽은 것이나 다름없다. 괜스레 사람들 빠져나간다고 뭐라 말고 나부터 돌아보자.

범위 계획 (프로젝트 성공률 1% 높이기)

“아니 그때 다 이야기된 것 아니었나? 뭐가 이렇게 자꾸 나와?”
 
 

프로젝트 범위

무슨 일이든 정해진 범위가 있다. 해야 할 일이 무엇이고 어디까지 해야 한다는, 각각의 일들이 기간을 가지고 있고 우선순위가 있지만 이 모두는 한 박스에 넣어진다. 넘칠 것 같으면 다른 박스에, 아니라면 더 작은 박스로 옮길 수도 있다. 이렇듯 일에 맞는, 범위에 맞는 일을 정해놓지 않으면 서로 얼굴 붉힐 일만 남을 뿐이다.
 
그럼 프로젝트에서 범위는 뭘까? 범위는 프로젝트가 고객에게 제공해야 할 서비스의 집합체로 계획을 수립하고 통제하는 대상이자 시작점이다. 이에 따라 계획의 적정성, 실현 가능성 및 구체성이 결정되고 범위가 변경된다고 하면 다른 영역들에 지대한 영향을 미친다. 예산이 모자를 수도 있고 투입인력이 탈출할 수 있으며 프로젝트 자체가 폐기될 수도 있는 중차대한 일이다.
 
프로젝트 범위는 그만큼 중요하다. 그래서 이의 관리를 위해 기본방침으로 잡는 것들이 있다. 첫째. 꼭 필요한 일들로 범위를 최소화하는 것이다. 총합으로서 또는 이를 구성하는 단계 내 범위를 최소화, 군집화하는 것이다. 둘째. 범위의 변경 또한 최소화한다. 범위가 변경되면 작업이 중단되거나 계획을 다시 수립해야 하고 많은 재작업이 발생할 수 있기 때문이다. 셋째. 불필요한 작업을 방지해야 한다. 특히 고객의 요구사항을 제대로 파악해야 하며 이를 통해서 고객의 지나친 요구사항들을 제어해야 하기 때문이다.
 
 

범위의 계획

범위 기술서가 우선 필요하다. 수많은 입력값을 토대로 작성한다. 입력값들은 프로젝트 착수 단계에서 고려된 계획과 제약사항들을 분석하여 의사결정과 이해관계를 정리하는데 중요한 단서가 된다. 이러한 일련의 일들은 PM이 주로 작성하고 여러 수행조직과 고객에게 프로젝트 범위에 대한 합의 기준, 의사소통 기준 및 프로젝트 종료 기준을 마련하는 목적을 갖는다.
 
여기서 범위 기술서는 WBS나 SOW와 차이점이 있다. SOW(Statement Of Work)는 보통 작업지시서, 작업 기술서 또는 시방서라 부르며 공급할 제품/서비스에 대한 상세한 설명을 담고 있다. WBS(Work Breakdown Structure)는 말 그대로 업무 분해 구조로 범위 기술서에 정의된 정보를 바탕으로 제품/서비스를 개발하는 과정에서 필요한 여러 단계의 작업 요소들을 상세하게 구성하고 조직화하는 것이다. 그래서 범위 기술서로 범위 기준을 설정하고 이 내용을 바탕으로 작업을 지시하며 이 작업을 수행하기 위해 범위를 정의하고 관리 틀을 만들어 운영한다고 보면 된다.
 
 

범위의 정의

프로젝트 범위를 한눈에 볼 수 있는 것이 뭐가 있을까? 앞서 이야기한 WBS가 이 범위를 산출물 중심으로 프로젝트 여러 요소를 군집화해 보여준다. WBS는 반복되는 분할로 더 작고 관리하게 편한 크기로 작업을 나눠 프로젝트 산출물을 체계화했다고 보면 된다. 이는 보통 PM과 프로젝트팀에서 작성하는데 이를 통해 프로젝트 전체를 조망하고 관리할 수 있는 매우 중요한 문서이다.
 
그래서 WBS는 외부적으로 PM과 고객, 내부적으로는 PM과 상위 관리자 간의 실질적 계약으로 볼 수 있으며 모든 계획의 근간이 된다. 그래서 정해진 업무 외 추가적인 요구사항이 나온다면 그 수용 여부에 대해서 고객을 설득할 수 있는 증거물로도 그 역할을 톡톡히 한다. 
 
 
WBS 작성은 범위 기술서를 바탕으로 한다. 목적을 염두에 두고 기능요구사항을 정의한 뒤 이의 달성을 위해 주요 액티비티를 정의한다. 이후 관리를 용이하게 하고 누락을 없애기 위해 계층적 분할을 하며 조직화하고 군집화한다. 여기까지 되었다면 일정을 산출하고 원가와 연계시킬 수 있으며 진척도를 관리할 지표로 사용할 수 있다.
 




 

WBS (Work Breakdown Structure)

WBS의 핵심 구성요소에는 Work Package(작업패키지) 가 있다. 이는 측정 및 관리가 가능한 WBS 최하위 작업 요소라고 보면 된다. 즉 분할의 최소단위인데 보통 80시간(2주) 내의 기간을 가지게끔 분할 규모를 설정한다. 또한 유일한 ID로 관리하는데 이를 Code of Account라고 한다. 전체적으로 보면 프로젝트 – 단계(Phase) – 작업(Task) – 작업패키지가 그것이다. 산출물 또한 중요한데 이것은 액티비티의 결과로 만들어지며 최하위 작업패키지에 매핑한다.
 
그래서 작업패키지를 어떻게 잡는가가 관건인데 의 적정 수준은 크게 두 가지로 본다. 첫째. 너무 개괄적인 분해는 아닌지? 둘째. 너무 세밀한 분해는 아닌지? 이렇게 보면 어떻게 잡으라는 말인가 하고 의문이 들 수 있는데 이 역시나 경험이 필요하다. 어느 하나 똑같은 경우는 없으며 프로젝트마다 모두 다르기 때문에 많은 시도와 결과를 통해 적정한 규모로 만들어가는 노력이 필요하다. 다만 이를 평가하는 일종의 법칙이 있다.
 
 
하나는 1~10%의 법칙인데 전체 프로젝트 기간을 영업일 기준으로 산정하고 여기에 1%에서 10%의 범위로 규모를 나누는 것이다. 또 하나는 1보고 기간의 법칙이다. 이는 작업 지연을 최소화하기 위한 것으로 프로젝트 최소 감시 주기 이내로 작업을 분할하는 것이다. 예를 들어 주간 보고가 최소 감시 주기라 하면 이 이상을 벗어나는 작업은 마지막에 가서야 결과를 통보받을 수 있기 때문에 그 위험성이 증가할 수 있는 것이다.
 
 
 
 
※ WBS 만들기
요즘 툴들이 너무나도 좋아져서 기본적인 내용만으로도 작업이 가능하다. 하지만 말이 좋아 그렇지 WBS를 만드는 일은 만만하지 않다. 역시나 어디까지 할 일을 분할해야 하는가에 대한 고민은 머리를 빠지게 한다. 그래서 여기서도 MECE(Mutually Exclusive, Collectively Exhaustive)를 중요하게 쓸 수 있다. 중복됨 없이 하나라도 누락되지 않게끔 정리하고 80시간 이내로 자르며 이것이 최소 감시 주기를 벗어나지 않게만 해도 반은 성공이다. 여기까지도 힘 드는가? 그렇다면 동료와 같이 작성하자. 왜냐면 프로젝트는 나 혼자만 하는 것이 아니니까 말이다.

프로젝트 착수 (프로젝트 성공률 1% 높이기)

이제 시작이다!

프로젝트의 시작을 어디서부터냐고 물어보면 모두 제각각일 것이다. 왜냐면 처음 프로젝트를 기획한 단계부터 최종 계약이 성사되고 이후 수행을 위한 단계, 그리고 마무리까지 이해관계자가 모두 다 다르기 때문이다. 그간의 앞선 내용들에선 주로 기획부터 계약까지의 행정적 단계를 이야기했었고 여기의 참가자들은 현장의 관리자급 이상이 될 수 있다. 하지만 실제 프로젝트의 구성원으로 프로젝트를 끌어내 갈 현업의 입장에서는 이제부터가 진짜 프로젝트라고 볼 수 있다.
 
이제 프로젝트는 PM이 선임되고 필요한 인력들이 속속 합류하고 있다. 웬만한 규모 이상이라면 별도의 프로젝트 장소도 섭외가 되고 업무에 필요한 각종 장비도 마련된다. 몇 명 없고 비어있던 사무실에 활기가 돌고 눈에 띄게 바삐 움직이는 사람들과 손끝에 전달되는 타격감은 프로젝트의 긴장도를 슬슬 높여간다. 곧 일할 맛 나는 프로젝트 현장이 눈 앞에 펼쳐진다.
 
프로젝트라는 이름의 배는 모든 이들을 태우고 부두를 떠나고자 밧줄을 풀고 있다. 아직은 어수선하지만 들뜬 분위기를 다잡고 목표한 항구에 도달할 때까지 한마음 한뜻으로 나아가기 위해 선장은 리더십을 발휘한다. 굳이 형식을 따지자면 임무 수여와 같은 프로젝트 헌장을 만들곤 하지만 꼭 이런 형태가 아니더라도 프로젝트의 구심점을 잡아 프로젝트의 공식적인 출항을 다양한 형태로 기념한다. 같은 장소, 같은 시간 속에서 조직은 결속을 다져나간다.
 
※ 프로젝트 헌장: 프로젝트 사명서 형태로 볼 수 있다. 프로젝트의 목적과 목표, 범위, 산출물, 마일스톤을 크게 명시한다. 이를 통해 구성원과 고객의 프로젝트 이해도를 높이고 합의를 끌어내고 궁극적인 의사소통을 원활히 할 수 있는 근간을 마련한다. 특히 성과 측정 기준을 제시하여 거시적 관리 시점을 갖도록 한다.
 

 

프로젝트 관리계획

중요한 문서로 수립되는 단계이다. 관리계획에서 다루는 주요 내용은 프로젝트 전반에 걸쳐 세부 계획들을 정의, 준비, 통합, 조정하기 위한 필수적인 활동들이다. 그 면면을 보자면 중복/누락 업무 방지, 기간 준수, 예산운영, 품질 유지, 위험관리, 의사소통 기준과 방법, 용어/지표 정의 및 일관된 업무 활동 세팅 등이다. 당 문서는 단지 작성되는 것에만 그치지 않고 관리 프로세스를 통해 개정, 변경된다. 문서로만 존재하는 것이 아니라 이를 토대로 모든 활동을 진행하고 제어한다. 그만큼 중요하고 프로젝트와 같이 이 또한 생명주기를 가진다고도 볼 수 있다. 다음은 관리계획에 있어 주요한 구성 요소들이다.
 
🚩각종 산출물 집합
  • 프로젝트팀에서 선정한 프로젝트관리 프로세스
  • 단계별 산출물 (산출물이 꼭 문서 형태가 아닐 수도 있음) 
  • 프로세스 진행에 필요한 도구와 기법
  • 변경 사항 감시 및 통제 방법
  • 형상 관리
  • 이해당사자 간 의사소통 기법 및 방법
  • 성과평가 및 품질측정
  • 필요시 보조계획
 
🚩보조계획 (복잡도 증가)
  • 범위관리 계획
  • 프로젝트에 필요한 단계별 계획 (일정, 원가, 품질, 인력, 의사소통, 위험, 구매관리 등)
 
🚩기타
  • 마일스톤, 자원 현황관리, 기준선, 장애 관리대장 등
 
 

관리 도구 

PMIS(Project Management Information System)/PMS(Project Management System)라 불리는 도구들은 프로젝트가 존재하던 과거부터 있었고 그간의 개발 방법과 기술의 발전은 현시점에서 다양한 형태의 관리 솔루션들을 보여주고 있다. 이런 도구들은 주로 프로젝트 전반, 계획수립, 일정 관리, 진척 관리, 비용관리, 자원관리, 보고서 작성, 통계, 위험관리 및 의사소통 또는 이러한 여러 단계 중 특정 단계에 집중되어 있기도 하다. 그에 따라 다양한 회사에서 많은 솔루션을 선보이고 있어 이를 사용하는 입장에서 무엇을 선택해야 할지 난감한 경우가 많다. 특히나 근래엔 협업툴이 인기를 끌면서 접근법을 달리한 PMS의 형태를 띠기도 한다. 아래는 가트너에서 최근에 발표한 PMS 들인데 많기도 하다.
 

Best Project Management Software - 2023

< Best Project Management Software – 2023 >
 
이렇게 다양한 PMS 중 우리는 과연 무엇을 선택해야 하는가? 이 선택의 순간에 보통 2가지 관점으로 접근해 볼 수 있는데 첫째는 프로젝트 프로세스 및 조직에 얼마나 반영을 잘 시킬 수 있는지, 둘째는 필요로 하는 기능들을 얼마나 충족시켜 주는지이다. 더불어 사용자가 얼마나 쉽게 사용할 수 있는가도 매우 중요하다. 여기서 사용자 프로젝트 이해당사자들인데 이들은 소속이나 역할, 직위, 능력 등이 다양하기 때문에 관점에 기인한 중지를 모아 신중하게 결정하는 것이 좋다. 또한 기본적으로 갖추고 있는 조직, 인력, 문화 등 내재 역량 또한 무시할 수 없다.
 
이는 돈으로 살 수 없는 경우도 많으며 서로 간의 이해가 첨예하게 부딪히는 일도 다반사이고 업종이 무엇이냐에 따라서도 매우 다르기 때문에 현명한 선택이 요구된다. 만약 잘못된 선택으로 인하여 프로젝트 중반에 이를 변경할 일이 생긴다면 비용도 그렇지만 모든 것을 도구에 맞춰 진행해온 프로젝트 자체가 큰 위험에 빠질 수도 있기 때문이다.
 
 
 
 
※ 엑셀이 좋아!
MS Office의 엑셀은 정말 훌륭한 도구다. 기업 조직 내 시스템이 갖춰진 정도가 모두 다르더라도 가 가운데는 항상 엑셀이 존재한다. 그래서 비싸게 시스템을 도입해놔도 엑셀을 고집하는 경우가 많다. 하지만 프로젝트에서 선정한 도구가 있다면 이를 충분히 잘 활용하는 것에 집중함이 필요하다. 이 또한 의사소통 도구로 선택했기 때문이다. 그러니 엑셀은 잠시만 뒤로 하고 먼저 써보고 이야기하자. 써보지도 않고 뭐라 뭐라 말하는 것은 꼰대! 나 하는 거지 않는가?

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

PM. 그는 누구인가?
어느 고객이건 사이트이건 프로젝트가 시작될 때 우선순위가 가장 높은 일 중의 하나는 PM, 프로젝트관리자를 구하는 것이다. 우리가 하고자 하는 프로젝트를 맡아줄 최적의 적임자를 찾는 것이다. 다른 구성원이나 조직들이 완비되었어도 PM이 없다면 선장 없는 배나 다름이 없다.

그렇다면 PM은 무엇인가? 프로젝트관리자는 간단히 말해 프로젝트의 성공적 수행을 책임지는 사람이다. 프로젝트의 성공에는 PM이 필수이며 PM은 자신이 원하는 팀을 꾸리고 활동을 지원하며 여러 이해당사자의 업무를 조정하고 협업을 조정한다. 사람과 사람 사이의 갈등도 조율하고 각종 위험 요소를 미연에 방지하고 해결책도 찾아야 하며 이를 통해 궁극의 책임을 지는 사람.

그래서 PM의 어깨 또한 무겁다. 그래서 이를 감당할만한 권한과 책임 또한 같이 주어진다. 작은 프로젝트는 규모의 차이이지 하는 일은 똑같다지만 그래도 부담은 다소 적을 수 있고 최악의 경우 인력수급이 제대로 안 될 경우에는 여러 사람(?)이 합심해서 프로젝트를 꾸려나갈 수도 있다. 그러나 정답은 아니다. PM은 그 자리에 있어야 할 인물이다.

 

프로젝트관리자의 역할들
위에서 보면 과연 PM을 할 사람이 있을까 하는 생각이 절로 든다. 하지만 오랜 경험과 통찰, 이슈 해결에 흥미를 가지고 이력 관리를 하는 사람 또한 적지 않다. 다만 서로가 원하는 인연이 필요할 뿐. 환경 탓은 부차적이다. 그래서 PM은 준비해야 한다.

🚩계획수립, 자원관리, 보고
: 현장을 돌아보고 자리에 앉아 현실적인 계획을 짜야 한다. 단순히 책상머리에 앉아만 있으면 안 된다. 모든 조건이 만족하지 않는다면 더더욱 현장을 뛰어다녀야 한다. 이를 토대로 내가 손에 쥔 것이 무엇인지, 무엇이 필요한지 판단하고 이를 구하고 배정해야 한다. 계획대로 일을 진행하기 위해선 인력과 자원을 필요할 때 지원받을 수 있게끔 상하 위 소통의 끈을 놓지 말고 정확히 보고한다. 단순 문제 제기는 아무런 도움이 되지 않는다. 항시 대안을 마련하여 신속 정확한 의사결정이 될 수 있도록 한다.

🚩책임, 조정, 의사소통
: 프로젝트 초기 고객의 요구사항을 명확히 파악하고 범위 확인을 통해 업무를 수행한다. 하지만 모든 일에는 반드시 예외가 발생하고 계획대로 되는 일은 거의 없다. 그래서 변경 사항에 대한 통찰력과 함께 그 파급효과 등을 사전에 고려하고 원활하게 운영될 수 있도록 조정이 필요하다. 여기서 품질은 기본적으로 챙기면서 모든 단계의 업무가 유기적으로 잘 흘러갈 수 있게 의사소통력 또한 필요하다.

🚩의사결정, 관리, 훈련
: 책임과 권한이 있기에 의사결정을 내릴 수 있다. 다만 올바른 의사결정을 위해선 거시적인 안목과 관리가 필요하다. 그 순간 최선의 의사결정을 내릴 수 있는 데이터가 필요하고 이는 모든 구성원으로부터 교육훈련 등을 통해서 상호 지원받아야 한다. 팀원에 대한 격려와 수행력을 향상하고 여러 자리를 통해 갈등을 해소하는 것. 일보다 사람이 힘들다는 것을 몸소 체험하게 될 자리에 PM이 서 있다.

🚩발주, 계약, 검수
: 관리의 영역은 넓다. 이러한 업무를 지원해 주는 조직이 있을 수도 있지만 우선은 PM의 손을 타게 되어있다. 그래서 단순히 현업업무에만 집중하면 안 된다. 발주자의 역할로서 인력이든 다른 자원이든 PM의 손을 거쳐 움직여야 한다. 특히나 행정적 위험이 곳곳에 도사리고 있는 업무인 만큼 검증과 피드백을 통해 확인에 확인이 필요하다.

🚩조직 지원과 협력
: 위와 같은 외부 조직 등과의 업무를 위한 일도 있지만 내부 조직 또한 하나의 고객으로서 매우 중요하다. 그 말은 이들의 지원 또한 무시할 수 없다는 것을 말한다. 그래서 유관부서와 긴밀한 의사소통과 공유가 필요하고 서로의 업무 영향력을 고려한 협력이 필요하다. 프로젝트를 원만히 진행하기 위한 든든한 버팀목이자 지지자들은 멀어 어딘가가 아닌 바로 내부에 있다.




PM. 그들에게 필요한 것들
그렇다면 PM은 무엇을 갖춰야 할까? 너무 많은 것들이 있지만 그래도 중요한 몇 가지를 꼽으라면 다음과 같다.

  – 관리역량
  – 기술력
  – 의사소통력
  – 리더십

관리역량은 하루아침에 만들어지지 않는다. 물론 성향이나 내재적인 역량을 갖춘 사람도 있으나 보통은 학습과 경험을 통해 얻을 수 있다. 이에 따르는 많은 공부 또한 필요하다. 이는 기술력 못지않은 전문성도 필요로 하기에 실제 업무를 통해 하나둘 만들어가는 노력이 따라야 한다.

기술력은 프로젝트의 세부 활동을 지시하고 검증할 수 있는 역량이다. 전문지식을 보유하고 있으면 이해당사자들에게 보다 넓고 깊은 영향력을 행사할 수 있다. 이런 부분이 미흡할 경우에는 당연히 신뢰를 얻기가 어렵다. 물론 PM을 세분화해서 관리 PM이나 기술 PM 등으로 나눌 수도 있지만 이건 그런 환경이 될만한 프로젝트가 아니고서야 꿈도 꿀 수 없다.

성공의 소통이다. 일이 어렵고 쉽고를 떠나 결국 일은 사람이 해내는 것이다. 무엇이 되었던 서로 얼굴을 마주하고 문제를 해결해 나갈 수 있는 서로 간의 영향력이 중요하다.

마지막으로 리더십이다. 관리자라 관리만 하면 되지 무슨 리더십이 뭐냐고 할 수도 있지만 PM은 관리를 기반한 리더이다. 그래서 리더의 역량 또한 가져야 한다. 수많은 가정하에 유연함을 무기로 How가 아닌 What에 집중하면서 책임지는 솔선수범의 자세를 경주한다면 약간은 모자라더라도 PM을 역할을 충분히 해낼 수 있다.

 

※ 어떻게 한번 해볼래?
연차가 쌓이고 직위가 올라가면 한 번쯤 받아보는 자리. 선택의 여지가 주어질 수도 있지만 대부분은 지명을 통해 앉게 되는 그 자리. 왕의 자리까지는 아니지만도 그 무게를 견뎌내야 하는 것은 익히 봐와서 안다. 그래서 도망가고 싶어진다. 난 못할 것 같다. 큰일이 나면 어떨까 싶다. 밥맛이 없어지고 머리가 하나둘 빠진다. 어서 이 프로젝트가 끝나길 기다리지만 달리 생각하면 이때가 아니면 언제 해볼 수 있을까 하는, 기회가 주어짐에 감사하게 된다. 그래서 버틸 힘이 되나 보다. 이 세상 모든 PM 들 파이팅!!!

프로젝트생명주기 (프로젝트 성공률 1% 높이기)

프로젝트 생명주기!

일을 진행하는 과정에 있어서 그 단계와 절차들이 있는데 프로젝트에선 이를 생명주기(life cycle)로 표현하며 여러 단계(phase)를 통합적으로 지칭한다. 프로젝트 수행조직은 하나의 프로젝트를 여러 개의 단계로 구분, 관리하는데 이 단계는 프로젝트의 구성단위로 볼 수 있고 각 단계는 단계별로 중요한 산출물이 완료되는 시점이다. 이러한 단계는 종료 검토를 통해 다음 단계로 진행할 것인지를 결정하고 이 단계들이 모여 최종적인 프로젝트가 완성된다.

모든 프로젝트는 단계로 나눠진다고 이야기했다. 크든 작든 프로젝트와 상관없이 이 단계들은 일정한 생명주기를 가지는데 큰 틀에서는 엇비슷하다고 볼 수는 있으나 크게는 업종에 따라서도 그 내용이 상이하다. 그래서 동종업계의, 유사 프로젝트 성격을 가진 자료들을 바탕으로 이러한 생명주기를 참고하고 갖춰볼 수도 있다. 그러면서 내 프로젝트에 맞게끔 적용하거나 변경할 수 있다.

프로젝트관리 생명주기?

그간 프로젝트, 프로젝트관리, 생명주기 등 각각의 용어에 대해서 알아보았다. 그렇다면 프로젝트관리 생명주기는 무엇인가? 헷갈릴 수도 있지만 앞선 용어들을 참고해서 의미를 생각해 보자. 프로젝트 생명주기가 아닌 프로젝트관리에 대한 생명주기는 관리 절차, 관리프로세스라고 볼 수 있고 이는 각각 착수, 계획, 실행, 감시/통제 및 종료로 구성된다. 아래를 봐보자.

🚩착수
: 프로젝트의 시작이다. 고객이 프로젝트의 발의를 결정하고 수행조직에 전달되어 준비되는 이벤트이다. 첫 시작이기 때문에 이것저것 챙길 것이 많다. 그중에 몇 가지만 추려보면, 프로젝트 요구사항분석, 예비 범위 확인, 일정/예산 산정, 제약조건 확인, 이해당사자 분석, 성과기준 마련, PM 결정과 권한 부여, 팀 꾸리기 등이 있다. 이 모든 예비작업이 정의되고 기술되어 Big Picture로서 프로젝트계획이 수립된다.

🚩계획
: 앞서 그린 큰 그림을 바탕으로 프로젝트를 세세하게 계획한다. 프로젝트 관리계획, 실질적인 범위 기술서, WBS(Work Breakdown Structure), 각각의 액티비티와 우선순위, 기간, 자원할당, 비용산정, 품질계획, 인력/의사소통 관리, 위험관리 등 관리의 추상화 레벨을 내려가며 할 일들을 정리해 나간다. 이 계획들이 빠짐없이 세세하게 구축이 되어야만 프로젝트의 성공률을 끌어올리는 실마리가 될 수 있다.

🚩실행
: 이제 본격적인 활동의 시작이다. 프로젝트 구성원들에 대한 다양한 기초교육을 바탕으로 유관 조직, 기관, 업체들에 대한 선정 내지 작업지시, 본격적인 품질보증 활동을 토대로 도입된 방법론에 따라 지속적이고 점진적인 진행을 시작한다. 어떻게 보면 실행은 전체 프로젝트에서 약 20~30%에 해당하는 단계이다. 나머지 70~80%는 단순하게는 문서 형태로 귀결되는 모든 단계의 활동 산출물들이 담당한다. 근래에 들어 이런 부담을 줄이는 경량화되고 빠른 방법론들이 사용되고 있다. 다만 모든 경우를 포괄하는 것은 아니다.

🚩감시/통제
: 프로젝트의 빅브라더가 해야 할 일이다. 매 단계의 성과를 품질 기반으로 측정하고 진척을 관리한다. 문제가 발생하면 시정조치와 피드백을 받고 그 효과성을 평가하여 프로젝트에 재귀적 반영을 한다. 변경에 민감하며 비용을 통제한다. 위험 유발요인을 집요하게 추적하며 모든 활동을 감시한다. 감시라는 용어가 다소 거부감이 들 수도 있지만 감시가 몇몇 관리자가 하는 행위뿐만 아니라 프로젝트 모든 구성원이 해야 할 일이기에 그렇게 생각할 필요는 없다. 성공하고자 한다면, 성공의 책임은 모든 이해당사자 각각이다.

🚩종료
: 대망의 마무리 단계. 그간의 업무들을 총체적으로 정리, 마감한다. 산출된 결과물들을 고객에게 인도하고 승인을 득하며 프로젝트 전 과정을 통해 배울 것들, Lessons Learned를 문서화하고 공유한다. 점유된 자원들을 하나둘 해제하며 프로젝트는 서서히 끝날 기미를 보이며 종료된다. 완료 평가와 함께 최종 보고를 하고 고객관리 방안과 미결사항 등에 대한 복안을 논하고 오랜 시간의 마침표를 찍는다.

Project Management Lifecycle
< 프로젝트관리 생명주기 >

관리영역들

업무를 하면서 우리 알고 있는 PDS, 즉 Plan – Do – See와 다르게 프로젝트는 시작과 끝에 따라, 여러 특성과 환경 등에 따라 그 생명주기는 각기 다르다. 그래서 앞선 5가지는 세부적으로 여러 가지 프로세스들로 구성되어 있다. 이는 흔히 PMBOK(Project Management Body of Knowledge, 현재 7판)이나 SWEBOK(Software Engineering Body of Knowledge, 현재 4판)등에 자세히 나와 있다. 프로젝트에서 이것을 모두 활용하기엔 다소 무리가 있고 그중 가장 핵심적인 단계들만이라도 제대로 관리한다면 프로젝트 성공률은 높아질 수 있다. 세세한 내용은 차차 다루기로 하고 여기서 알아 둘 것은 크게 두 가지이다. 프로젝트 목표 달성을 위한 Core 프로세스는 원가, 일정, 범위 단계, 그리고 목표 달성을 위한 수단으로써의 Facilitating 프로세스는 품질, 인력, 의사소통, 위험, 아웃소싱단계가 그것이다.

 

※ 한곳을 향해.
PM은 프로젝트를 성공적으로 완수하고 싶다. 격하게 하고 싶다. 그래서 나름의 넘치는 욕심과 의욕으로 시작하지만 높고 낮은 벽들에 계속 부딪히고 싸우면서 점점 의기소침해지고 소극적으로 변하며 전의를 잃기도 한다. 이때 무엇이 필요할까? 멘털이다. 멘털을 잘 붙들어 매어야 나 자신을 지킬 수 있다. 그리고 이걸 옆에서 지켜보는 구성원들은 PM을 이해하고 지지해줘야 한다. 설사 내부 총질(!?)을 해대는 상황이 발생할지라도 그건 나중 일이다. 팀은 왜 존재하는가?

소프트웨어 공학이란 (소프트웨어 공학)

“소프트웨어가 소수의 탁월한 능력을 갖춘 프로그래머에 의해 만들어지던 규모를 넘어서면서 소프트웨어 개발의 성패는 그 집단의 소프트웨어공학에 대한 숙달 정도에 크게 좌우된다.”

소프트웨어 공학의 첫 등장은 1968년 NATO가 지원한 한 콘퍼런스에서 시작되어 꽤 오랜 시간이 흘렀다. 이는 컴퓨터 소프트웨어 개발, 운영, 및 유지 보수에 관련된 체계적이고 표준화된 접근법에 대한 연구와 적용 기술로 이해된다. 이를 통해 고품질의 소프트웨어를 생산하고 시간과 비용을 최소화하며 고객과 사용자 요구사항을 충족하는 것이다.

그 결과물들은 공학적 원칙과 가이드라인으로 신뢰성, 확장성, 효율성, 보안성 및 사용성의 향상을 기대한다. 그래서 생명체와 같은 생명주기를 바탕으로 여러 기법, 도구 및 방법론이 고안되고 쓰이고 있다. 하지만 학문적 공학의 위치는 실제 현장에서 일하는 개발자들에게는 다소 생경하다. 이는 급변하는 IT 환경, 수요 대비 공급을 원활히 할 수 없는 교육적 생태계, 개발인력에 대한 대우 및 여러 편견 등으로 눈앞에 급한 불만 끄면 된다는 식의 대응에만 몰두한 결과이다.

현실은 현장에서 체득되는 지식도 있지만 학문적 고찰을 통한 지식과 지혜가 없이는 원하는 성과를 만들어낼 수 없다. 이는 수많은 무기를 지니고는 있으나 정작 아무런 전략, 전술도 세우지 않고 무작정 전장에 나서는 장수와 다를 바가 없다. 이제 개발자들은 모두 다시금 소프트웨어 공학을 찬찬히 살펴봐야 할 이유가 여기에 있다.

 

시작

무엇을 시작하든 제일 중요한 것은 “용어”를 제대로 알고 이해하는 것이다. 같은 용어라도 장소와 시간, 쓰임새 및 사람에 따라 모두 다를 수 있기 때문에 가장 먼저 다뤄야 할 용어를 정의하고 눈높이를 맞춰야 한다.

✔️ 프로그램
  : 프로그래밍 언어로 작성된 source code (정적)
✔️ 소프트웨어
  : 프로그램(source code)과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체, 즉 산출물, 사용자 매뉴얼 등 모든 것을 포함한 것 (동적)
✔️ 시스템
  : 필요한 기능을 실현하기 위해 관련 요소들을 어떠한 법칙에 따라 조합한 집합체

시스템은 모든 것은 포괄하며 소프트웨어도 시스템 내에서 다른 요소들과 상호 동작하는 하나의 시스템으로 볼 수 있다. 이러한 시스템의 기능과 성능이 잘 발휘되려면 시스템을 구성하는 모든 요소, 서브 시스템이 잘 작동되어야 한다. 즉, 제대로 만들어져야 하는데 소프트웨어의 경우 눈에 보이지 않는 비가시성과 복잡성을 모두 가지고 있다.

물리적인 하드웨어는 눈부시게 발전하면서 구체적인 성과들을 보여주는데 소프트웨어는 그렇지 못하다. 그러다 보니 소프트웨어를 등한시하게 되었으나 하드웨어를 작동시키는 것이 소프트웨어임을, 그 수요가 하드웨어 못지않게 폭발하면서 수많은 수요를 따라가지 못하게 되었고 여기서 소프트웨어 위기라는 것이 발생한다.

 

소프트웨어 위기

이러한 위기는 소프트웨어가 가지는 비가시성과 복잡성을 포함한 또 다른 특징이 있는데 첫 번째. 소프트웨어는 제조가 아닌 개발이라는 것이다. 제조와 개발이 비슷해 보이지만 가장 큰 차이는 제조는 능력별 결과물의 차이가 거의 없지만 개발은 개인의 능력이 매우 중요시되고 그 능력에 따라 결과물의 차이가 크게 난다는 것이다. 둘째. 소프트웨어는 소모되는 것이 아니라 품질이 떨어진다는 것이다. 소프트웨어는 소모성 상품이 아니다. 다만 계속 사용됨으로써 지속적인 사용자의 요구사항을 반영해야 하는데 이것이 여러 사유로 원활하지 않다면 품질은 자연히 떨어지게 되는 것이다. 셋째. 소프트웨어 관리 기술이 전체가 아닌 일부만 사용된다. 즉 개발 프로젝트에서 활용하는 관리지식체계(PMBOK)가 있는데 이를 필요한 부분만 일부 적용함으로써 그 효과를 제대로 보지 못하는 것이다.

✔️ 소프트웨어 위기
  : 소프트웨어 생산성에 대한 심각한 인식 

소프트웨어 위기는 생산성 외에도 많은 문제점을 가지고 있었다. 소프트웨어 개발 프로젝트는 예산을 초과하기 일쑤이고 개발일정의 지연도 반복되었다. 중요한 소프트웨어 개발에 필요한 개발자는 각자 가지고 있는 역량의 편차로 그 결과물의 수준을 예측 할 수가 없었으며 이는 결국 품질문제로 비화되었다. 다른 공산품과 달리 불량품에 대한 관리나 품질보증에 대한 정량적 개념이 부족했고 고객은 인도된 결과물을 신뢰할 수 없었다. 이러한 상황에서 문제를 재인식하고 타계하고자 하는 노력으로 공학적 접근이 대두되었다.

✔️ 공학
  : 기술적 문제를 발견하고 기술적 해결책을 제시하는 학문으로 과학적이고 잘 조직된 지식을 현실적인 문제해결에 체계적으로 적용하는 것

공학의 특성은 자연과학하고 다르며 여러 제약사항이 있는데 우선 기간이 정해져 있고 예산도 정해져 있다는 것이다. 이러한 조건 하에서는 결국 최종적으로 기간을 얼마나 단축하고 보다 적은 비용으로 가능할 수 있는가에 대한 과학적 해법을 마련하는 것이다. 이 관점에서 소프트웨어를 개발하는 과정에서, 공학에서 쓰이고 있는 원리들을 적용하여 개발을 해보겠다는 것이 소프트웨어 공학이라고 볼 수 있다. 보다 효율적인 개발을 통한 생산성을 높이고 품질 좋은 소프트웨어를 제작하려는 것이 소프트웨어 공학의 취지이자 목적이다.

 

소프트웨어와 공학

✔️ 소프트웨어 공학
  : 소프트웨어 개발에 필요한 이론이나 기술, 도구들에 관하여 연구하는 학문

다시 말해 소프트웨어 공학은 “품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞춰 제대로 개발하는 것”을 말한다. 이러한 품질과 생산성 두마리 토끼를 모두 잡아야 하는 소프트웨어 공학은 방법, 도구, 프로세스 및 페러다임을 가지고 있다. 이는 소프트웨어 개발을 위해 생명주기를 통한 단계별 방법들을 연구하고 효율성과 효과성을 획득하기 위한 적절한 도구의 사용, 사용자 요구사항에 맞게 개발하기 위한 절차와 단계들, 그리고 상황에 맞게 적용가능하고 유연한 철학이 그것이다.

✔️ 방법: 어떤 결과를 생성하기 위해서 적용하는 기법과 절차
✔️ 도구: 더 좋은 방법으로 작업하기 위한 기기 또는 자동화된 시스템
✔️ 프로세스: 도구와 기법을 사용하여 작업하는 순서
✔️ 패러다임: 개발 스타일

이러한 4가지 요소를 바탕으로 소프트웨어는 유기체와 같은 생명주기를 갖는데 이는 계획 단계, 분석 단계, 설계 단계, 구현, 테스트, 유지 보수하는 과정으로 소프트웨어 개발 과정에서의 생산성을 향상시키고 품질 좋은 소프트웨어를 생산하여 고객을 만족시키려고 하는 최종적인 목표에 방점을 찍는다. 생명주기 내 각 단계는 일련의 활동을 포함하며 전체 소프트웨어 프로젝트에 대한 계획과 관리를 수행하고 개발 과정의 체계적인 구조화와 일정 관리를 지원한다.

✔️ 소프트웨어 생명주기(Software Development Life Cycle)
  : 소프트웨어 제품 개발에서 시작하여 최종 사용자에게 배포되고, 유지 보수 및 폐기될 때까지의 전 과정으로 일반적인 작업단계는 다음과 같다.

  – 요구분석: 고객과 사용자의 요구와 기대를 조사하여 프로젝트 목표를 정의
  – 설계: 소프트웨어 기능, 구조, 데이터 흐름, 인터페이스 등을 결정
  – 구현(개발): 설계 문서를 토대로 소프트웨어 코드 작성
  – 테스트: 생길 수 있는 오류와 결함을 찾아내고 수정
  – 배포: 개발된 소프트웨어를 최종 사용자에게 전달, 설치하여 사용할 수 있도록 함
  – 유지보수: 소프트웨어가 효율적으로 동작하도록 지속적으로 업데이트하고 개선
  – 폐기: 소프트웨어 수명이 끝난 경우, 안전하게 제거하고 관련 데이터와 자원을 처리

 


※ SWEBOK(Software Engineering Body of Knowledge)
  : ISO/IEC 국제 표준화 기구와 IEEE(Institute of Electrical and Electronics Engineers)가 승인, 지원하고 전 세계 소프트웨어 전문가들이 협력하여 개발한 소프트웨어 공학 관련 전문 지식의 체계적 모음으로 소프트웨어 공학자들이 필요로 하는 기본 원칙, 개념, 기술 및 실천 방법을 포괄한다. 여기서 다루는 다양한 주제와 영역은 SDLC의 여러 단계에 지침을 제공하고 이는 소프트웨어 개발 및 관리의 범위와 효율성을 높이는 데 도움이 되며 소프트웨어 개발자에게 필요한 기술, 능력 및 전문적 역량을 개발하는 데 중요한 역할을 한다.

※ PMBOK(Project Management Body of Knowledge)
  : 프로젝트관리협회(PMI:Project Management Institute)에서 개발한, 프로젝트 관리에 관한 전문 지식의 체계적 모음으로 ‘프로젝트관리지식체계’라고 하며 PM과 팀원들이 프로젝트를 계획, 실행, 통제하고 성과를 평가하는 데 필요한 일련의 표준 및 가이드라인을 제공한다. 이를 통해 프로젝트를 실천하면 프로젝트의 성공 가능성을 높이고 리스크를 최소화하는 데 도움을 준다.