프로젝트 조직
프로젝트팀 관리
Economics, Management, IT
다시 말해 CPM은 프로젝트 계획, 리소스 할당 및 작업 일정 계획에 대한 통찰력을 제공하며 이를 사용해야 할 이유는 몇 가지가 있다.
🚩 향후 계획 개선: 현재 진행상태와 기대치를 비교, 현재 프로젝트의 데이터를 추후 프로젝트 계획에 반영한다.
🚩 효과적 자원관리: PM이 작업 우선순위를 정하는 데 도움이 되고 자원을 적재적소에 배치하는 법을 지원한다.
🚩 업무 지연 방지: 네트워크 다이어그램을 이용하여 프로젝트 종속성을 계획하여 일정을 계획한다.
< Critical Path 예 >
PM. 그는 누구인가?
어느 고객이건 사이트이건 프로젝트가 시작될 때 우선순위가 가장 높은 일 중의 하나는 PM, 프로젝트관리자를 구하는 것이다. 우리가 하고자 하는 프로젝트를 맡아줄 최적의 적임자를 찾는 것이다. 다른 구성원이나 조직들이 완비되었어도 PM이 없다면 선장 없는 배나 다름이 없다.
그렇다면 PM은 무엇인가? 프로젝트관리자는 간단히 말해 프로젝트의 성공적 수행을 책임지는 사람이다. 프로젝트의 성공에는 PM이 필수이며 PM은 자신이 원하는 팀을 꾸리고 활동을 지원하며 여러 이해당사자의 업무를 조정하고 협업을 조정한다. 사람과 사람 사이의 갈등도 조율하고 각종 위험 요소를 미연에 방지하고 해결책도 찾아야 하며 이를 통해 궁극의 책임을 지는 사람.
그래서 PM의 어깨 또한 무겁다. 그래서 이를 감당할만한 권한과 책임 또한 같이 주어진다. 작은 프로젝트는 규모의 차이이지 하는 일은 똑같다지만 그래도 부담은 다소 적을 수 있고 최악의 경우 인력수급이 제대로 안 될 경우에는 여러 사람(?)이 합심해서 프로젝트를 꾸려나갈 수도 있다. 그러나 정답은 아니다. PM은 그 자리에 있어야 할 인물이다.
프로젝트관리자의 역할들
위에서 보면 과연 PM을 할 사람이 있을까 하는 생각이 절로 든다. 하지만 오랜 경험과 통찰, 이슈 해결에 흥미를 가지고 이력 관리를 하는 사람 또한 적지 않다. 다만 서로가 원하는 인연이 필요할 뿐. 환경 탓은 부차적이다. 그래서 PM은 준비해야 한다.
🚩계획수립, 자원관리, 보고
: 현장을 돌아보고 자리에 앉아 현실적인 계획을 짜야 한다. 단순히 책상머리에 앉아만 있으면 안 된다. 모든 조건이 만족하지 않는다면 더더욱 현장을 뛰어다녀야 한다. 이를 토대로 내가 손에 쥔 것이 무엇인지, 무엇이 필요한지 판단하고 이를 구하고 배정해야 한다. 계획대로 일을 진행하기 위해선 인력과 자원을 필요할 때 지원받을 수 있게끔 상하 위 소통의 끈을 놓지 말고 정확히 보고한다. 단순 문제 제기는 아무런 도움이 되지 않는다. 항시 대안을 마련하여 신속 정확한 의사결정이 될 수 있도록 한다.
🚩책임, 조정, 의사소통
: 프로젝트 초기 고객의 요구사항을 명확히 파악하고 범위 확인을 통해 업무를 수행한다. 하지만 모든 일에는 반드시 예외가 발생하고 계획대로 되는 일은 거의 없다. 그래서 변경 사항에 대한 통찰력과 함께 그 파급효과 등을 사전에 고려하고 원활하게 운영될 수 있도록 조정이 필요하다. 여기서 품질은 기본적으로 챙기면서 모든 단계의 업무가 유기적으로 잘 흘러갈 수 있게 의사소통력 또한 필요하다.
🚩의사결정, 관리, 훈련
: 책임과 권한이 있기에 의사결정을 내릴 수 있다. 다만 올바른 의사결정을 위해선 거시적인 안목과 관리가 필요하다. 그 순간 최선의 의사결정을 내릴 수 있는 데이터가 필요하고 이는 모든 구성원으로부터 교육훈련 등을 통해서 상호 지원받아야 한다. 팀원에 대한 격려와 수행력을 향상하고 여러 자리를 통해 갈등을 해소하는 것. 일보다 사람이 힘들다는 것을 몸소 체험하게 될 자리에 PM이 서 있다.
🚩발주, 계약, 검수
: 관리의 영역은 넓다. 이러한 업무를 지원해 주는 조직이 있을 수도 있지만 우선은 PM의 손을 타게 되어있다. 그래서 단순히 현업업무에만 집중하면 안 된다. 발주자의 역할로서 인력이든 다른 자원이든 PM의 손을 거쳐 움직여야 한다. 특히나 행정적 위험이 곳곳에 도사리고 있는 업무인 만큼 검증과 피드백을 통해 확인에 확인이 필요하다.
🚩조직 지원과 협력
: 위와 같은 외부 조직 등과의 업무를 위한 일도 있지만 내부 조직 또한 하나의 고객으로서 매우 중요하다. 그 말은 이들의 지원 또한 무시할 수 없다는 것을 말한다. 그래서 유관부서와 긴밀한 의사소통과 공유가 필요하고 서로의 업무 영향력을 고려한 협력이 필요하다. 프로젝트를 원만히 진행하기 위한 든든한 버팀목이자 지지자들은 멀어 어딘가가 아닌 바로 내부에 있다.
PM. 그들에게 필요한 것들
그렇다면 PM은 무엇을 갖춰야 할까? 너무 많은 것들이 있지만 그래도 중요한 몇 가지를 꼽으라면 다음과 같다.
– 관리역량
– 기술력
– 의사소통력
– 리더십
관리역량은 하루아침에 만들어지지 않는다. 물론 성향이나 내재적인 역량을 갖춘 사람도 있으나 보통은 학습과 경험을 통해 얻을 수 있다. 이에 따르는 많은 공부 또한 필요하다. 이는 기술력 못지않은 전문성도 필요로 하기에 실제 업무를 통해 하나둘 만들어가는 노력이 따라야 한다.
기술력은 프로젝트의 세부 활동을 지시하고 검증할 수 있는 역량이다. 전문지식을 보유하고 있으면 이해당사자들에게 보다 넓고 깊은 영향력을 행사할 수 있다. 이런 부분이 미흡할 경우에는 당연히 신뢰를 얻기가 어렵다. 물론 PM을 세분화해서 관리 PM이나 기술 PM 등으로 나눌 수도 있지만 이건 그런 환경이 될만한 프로젝트가 아니고서야 꿈도 꿀 수 없다.
성공의 소통이다. 일이 어렵고 쉽고를 떠나 결국 일은 사람이 해내는 것이다. 무엇이 되었던 서로 얼굴을 마주하고 문제를 해결해 나갈 수 있는 서로 간의 영향력이 중요하다.
마지막으로 리더십이다. 관리자라 관리만 하면 되지 무슨 리더십이 뭐냐고 할 수도 있지만 PM은 관리를 기반한 리더이다. 그래서 리더의 역량 또한 가져야 한다. 수많은 가정하에 유연함을 무기로 How가 아닌 What에 집중하면서 책임지는 솔선수범의 자세를 경주한다면 약간은 모자라더라도 PM을 역할을 충분히 해낼 수 있다.
※ 어떻게 한번 해볼래?
연차가 쌓이고 직위가 올라가면 한 번쯤 받아보는 자리. 선택의 여지가 주어질 수도 있지만 대부분은 지명을 통해 앉게 되는 그 자리. 왕의 자리까지는 아니지만도 그 무게를 견뎌내야 하는 것은 익히 봐와서 안다. 그래서 도망가고 싶어진다. 난 못할 것 같다. 큰일이 나면 어떨까 싶다. 밥맛이 없어지고 머리가 하나둘 빠진다. 어서 이 프로젝트가 끝나길 기다리지만 달리 생각하면 이때가 아니면 언제 해볼 수 있을까 하는, 기회가 주어짐에 감사하게 된다. 그래서 버틸 힘이 되나 보다. 이 세상 모든 PM 들 파이팅!!!
프로젝트 생명주기!
일을 진행하는 과정에 있어서 그 단계와 절차들이 있는데 프로젝트에선 이를 생명주기(life cycle)로 표현하며 여러 단계(phase)를 통합적으로 지칭한다. 프로젝트 수행조직은 하나의 프로젝트를 여러 개의 단계로 구분, 관리하는데 이 단계는 프로젝트의 구성단위로 볼 수 있고 각 단계는 단계별로 중요한 산출물이 완료되는 시점이다. 이러한 단계는 종료 검토를 통해 다음 단계로 진행할 것인지를 결정하고 이 단계들이 모여 최종적인 프로젝트가 완성된다.
모든 프로젝트는 단계로 나눠진다고 이야기했다. 크든 작든 프로젝트와 상관없이 이 단계들은 일정한 생명주기를 가지는데 큰 틀에서는 엇비슷하다고 볼 수는 있으나 크게는 업종에 따라서도 그 내용이 상이하다. 그래서 동종업계의, 유사 프로젝트 성격을 가진 자료들을 바탕으로 이러한 생명주기를 참고하고 갖춰볼 수도 있다. 그러면서 내 프로젝트에 맞게끔 적용하거나 변경할 수 있다.
프로젝트관리 생명주기?
그간 프로젝트, 프로젝트관리, 생명주기 등 각각의 용어에 대해서 알아보았다. 그렇다면 프로젝트관리 생명주기는 무엇인가? 헷갈릴 수도 있지만 앞선 용어들을 참고해서 의미를 생각해 보자. 프로젝트 생명주기가 아닌 프로젝트관리에 대한 생명주기는 관리 절차, 관리프로세스라고 볼 수 있고 이는 각각 착수, 계획, 실행, 감시/통제 및 종료로 구성된다. 아래를 봐보자.
🚩착수
: 프로젝트의 시작이다. 고객이 프로젝트의 발의를 결정하고 수행조직에 전달되어 준비되는 이벤트이다. 첫 시작이기 때문에 이것저것 챙길 것이 많다. 그중에 몇 가지만 추려보면, 프로젝트 요구사항분석, 예비 범위 확인, 일정/예산 산정, 제약조건 확인, 이해당사자 분석, 성과기준 마련, PM 결정과 권한 부여, 팀 꾸리기 등이 있다. 이 모든 예비작업이 정의되고 기술되어 Big Picture로서 프로젝트계획이 수립된다.
🚩계획
: 앞서 그린 큰 그림을 바탕으로 프로젝트를 세세하게 계획한다. 프로젝트 관리계획, 실질적인 범위 기술서, WBS(Work Breakdown Structure), 각각의 액티비티와 우선순위, 기간, 자원할당, 비용산정, 품질계획, 인력/의사소통 관리, 위험관리 등 관리의 추상화 레벨을 내려가며 할 일들을 정리해 나간다. 이 계획들이 빠짐없이 세세하게 구축이 되어야만 프로젝트의 성공률을 끌어올리는 실마리가 될 수 있다.
🚩실행
: 이제 본격적인 활동의 시작이다. 프로젝트 구성원들에 대한 다양한 기초교육을 바탕으로 유관 조직, 기관, 업체들에 대한 선정 내지 작업지시, 본격적인 품질보증 활동을 토대로 도입된 방법론에 따라 지속적이고 점진적인 진행을 시작한다. 어떻게 보면 실행은 전체 프로젝트에서 약 20~30%에 해당하는 단계이다. 나머지 70~80%는 단순하게는 문서 형태로 귀결되는 모든 단계의 활동 산출물들이 담당한다. 근래에 들어 이런 부담을 줄이는 경량화되고 빠른 방법론들이 사용되고 있다. 다만 모든 경우를 포괄하는 것은 아니다.
🚩감시/통제
: 프로젝트의 빅브라더가 해야 할 일이다. 매 단계의 성과를 품질 기반으로 측정하고 진척을 관리한다. 문제가 발생하면 시정조치와 피드백을 받고 그 효과성을 평가하여 프로젝트에 재귀적 반영을 한다. 변경에 민감하며 비용을 통제한다. 위험 유발요인을 집요하게 추적하며 모든 활동을 감시한다. 감시라는 용어가 다소 거부감이 들 수도 있지만 감시가 몇몇 관리자가 하는 행위뿐만 아니라 프로젝트 모든 구성원이 해야 할 일이기에 그렇게 생각할 필요는 없다. 성공하고자 한다면, 성공의 책임은 모든 이해당사자 각각이다.
🚩종료
: 대망의 마무리 단계. 그간의 업무들을 총체적으로 정리, 마감한다. 산출된 결과물들을 고객에게 인도하고 승인을 득하며 프로젝트 전 과정을 통해 배울 것들, Lessons Learned를 문서화하고 공유한다. 점유된 자원들을 하나둘 해제하며 프로젝트는 서서히 끝날 기미를 보이며 종료된다. 완료 평가와 함께 최종 보고를 하고 고객관리 방안과 미결사항 등에 대한 복안을 논하고 오랜 시간의 마침표를 찍는다.
< 프로젝트관리 생명주기 >
관리영역들
업무를 하면서 우리 알고 있는 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과 팀원들이 프로젝트를 계획, 실행, 통제하고 성과를 평가하는 데 필요한 일련의 표준 및 가이드라인을 제공한다. 이를 통해 프로젝트를 실천하면 프로젝트의 성공 가능성을 높이고 리스크를 최소화하는 데 도움을 준다.