위키원
"PMS"의 두 판 사이의 차이
| 1번째 줄: | 1번째 줄: | ||
| − | ''' | + | '''프로젝트 관리 시스템'''(PMS : Project Management System)은 프로젝트의 정량적인 성과 및 진행 지표를 체계적으로 관리하기 위한 것이다. 프로젝트 진행 현황과 성과물의 체계적인 관리 뿐만 아니라 시스템화를 통한 프로젝트 관리의 용이성을 확보하여 업무 생산성을 향상시킬 수 있다. 프로젝트 관리 활동은 작업계획, 위험도(리스크) 평가, 작업 완료를 위한 자원 추정, 작업 조직, 인적/물적 자원 획득, 업무 할당, 활동지시, 프로젝트 집행 제어, 진전보고, 결과 분석을 포함한다.<ref name='PMS란'>〈[https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8_%EA%B4%80%EB%A6%AC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4 PMS란]〉, 《위키백과》</ref> |
== 개요 == | == 개요 == | ||
| − | 프로젝트 관리 | + | 국내외 많은 IT조직에서 소프트웨어 프로젝트 관리 향상을 위하여, PMS(Project Management System)를 도입하고 있다. |
| + | 이러한 추세는 단순한 수작업으로 SW 프로젝트 관리를 수행하기에는 체계의 복잡성이나 업무의 양 자체가 매우 크다는 것을 입증한다. 실제로 PMS와 같은 자동화 시스템 없이 다수의 프로젝트를 체계적인 관리 한다는 것은 현실적으로 불가능하다. 때문에 수많은 조직에서 앞다투어 PMS를 도입하고 있다. <ref name='PMS 개요'>〈[http://itscope.co.kr/kr/04_project/project01.php PMS의 개요]〉, 《ITSCOPE》</ref> | ||
| + | |||
== 특징 == | == 특징 == | ||
== 기능 == | == 기능 == | ||
| + | |||
| + | == 고려사항 == | ||
| + | |||
| + | === 프로젝트 특성 반영 === | ||
| + | 소프트웨어 프로젝트와 일반 제조산업 프로젝트의 가장 큰 차이점은 소프트웨어 개발은 제조에 비해 매우 극단적인 지식 활동이라는 것이다. 다시 말해 지식활동으로서 일어난 소프트웨어 개발 활동의 비 정형적 특성들(지식의 공유, 지식 자산의 재사용, 소통, 진행 과정의 변경과 진화 등)이 고려되어야 한다. | ||
| + | |||
| + | === 의존성 최소화 === | ||
| + | 제조나 타 산업군과는 다르게 소프트웨어 개발의 기술/기법/방법론 등은 빠르게 진화한다(e.g. OOAD, CBD, IE 등) | ||
| + | 하지만 특정 개발 방법론에 의존적인 관리 시스템은 빠르게 변화하는 신 기술 환경에 맞추어 적응할 수 없다. | ||
| + | |||
| + | === 비 프로젝트 활동에 대한 고려 === | ||
| + | 소프트웨어 개발 조직의 특성상 일반적으로 개발자들의 공수는 투입된 프로젝트에 대한 직접 투입 공수보다 비 프로젝트 업무(회의, 유지보수, 기획 등)에 많이 소모되는 경향이 있다. 이러한 비 프로젝트 활동은 리소스 관점에서 프로젝트의 품질에 직접적인 영향을 주게 되므로 반드시 관리되어야 한다. | ||
| + | |||
| + | === 역량 수준 고려 === | ||
| + | 비 지식산업에서 쓰이는 많은 PMS에서는 프로젝트 구성원들의 업무 능력에 대한 차이를 고려하지 않은 채 단순히 태스크 할당의 성격으로 업무를 진행하는 경우가 많다. 그러나 소프트웨어 프로젝트의 경우, 소프트웨어 공학에 대한 역량 차이에 따라 구성원들의 태스크 수행품질도 크게 좌우된다. 단순히 한두 번의 교육으로 이룰 수 없다. 이러한 특성을 충분히 고려하여 관리시스템에 필요 지식이 녹아 들어 있어야 처음 접하는 소프트웨어 엔지니어들도 원활하게 사용할 수 있다. | ||
| + | |||
| + | === Best Practive에 대한 제공 필요 === | ||
| + | 건축, 제조 분야와는 다르게 소프트웨어 산업 분야에서는 CMMI, SPICE 등 과 같이 소프트웨어 개발 조직의 역량 수준에 따른 Best Practice들을 제시하고 있다. 이는 지식 산업의 특성이다. 소프트웨어 프로젝트 관리 시스템은 이러한 Best Practice를 지원하는 것에 그치지 않고, 나아가 실무와 Best Practice 간 매끄러운 연결고리 역할을 수행해야 한다. | ||
| + | |||
| + | === 협업 특성 고려 === | ||
| + | 소프트웨어 개발은 단순한 업무 지시와 개별 작업만으로 수행될 수 없다. 구성원들은 주어진 역할 별로 업무를 수행하되 | ||
| + | 협업과 소통이 함께 수행되어야 한다. 이 또한 지식 산업으로서 소프트웨어 개발 활동의 빼놓을 수 없는 특성이다. | ||
| + | |||
| + | === 프로젝트 타입 특성 고려 === | ||
| + | 2명이 한달 동안 하는 소규모 프로젝트와 50명이 1년동안 하는 대규모 프로젝트는 각각의 특성과 환경은 매우 다르다. 이러한 특성을 무시한 일원화된 관리는 소프트웨어 프로젝트의 실패를 야기할 수 있다. 그러므로 다양한 프로젝트 타입 별 특성에 대한 고려가 필요하다. | ||
| + | |||
| + | === 멀티 프로젝트에 대한 컨트롤 타워 기능 === | ||
| + | 멀티 프로젝트에 대한 체계적인 관리와 통제 기능은 개별 프로젝트의 성공을 좌우한다. | ||
| + | |||
| + | === 타 도구와의 연계 지원 === | ||
| + | 소프트웨어 개발 및 관리에 있어서 PMS외 다양한 도구에 대한 지원 및 주변 시스템과의 연계가 필요하다. | ||
| + | 이러한 주변 도구와의 연계는 조직 차원의 업무 효율성을 높이게 된다. | ||
| + | |||
| + | === 측정 데이터의 지속적인 축적 === | ||
| + | 동일한 소프트웨어 프로젝트를 동일인이 진행한다고 하여도 프로젝트를 수행할 때 마다 프로젝트의 생산성, 품질 등의 성과는 다르게 나타날 수 있다. 이는 소프트웨어 프로젝트는 제조 프로젝트처럼 간단한 수학 공식을 적용해 그 성과에 대한 예측을 수행하는 것이 불가능한 인적자원 중심의 지식 산업이기 때문이다. 이러한 특성을 고려하여 소프트웨어 프로젝트에서는 보다 정확한 예측을 위하여 다양한 프로젝트 측정과 척도에 대한 통계적 관리 지원이 필요하다.<ref name='PMS 고려사항' /> | ||
{{각주}} | {{각주}} | ||
2020년 9월 1일 (화) 10:30 판
프로젝트 관리 시스템(PMS : Project Management System)은 프로젝트의 정량적인 성과 및 진행 지표를 체계적으로 관리하기 위한 것이다. 프로젝트 진행 현황과 성과물의 체계적인 관리 뿐만 아니라 시스템화를 통한 프로젝트 관리의 용이성을 확보하여 업무 생산성을 향상시킬 수 있다. 프로젝트 관리 활동은 작업계획, 위험도(리스크) 평가, 작업 완료를 위한 자원 추정, 작업 조직, 인적/물적 자원 획득, 업무 할당, 활동지시, 프로젝트 집행 제어, 진전보고, 결과 분석을 포함한다.[1]
목차
개요
국내외 많은 IT조직에서 소프트웨어 프로젝트 관리 향상을 위하여, PMS(Project Management System)를 도입하고 있다. 이러한 추세는 단순한 수작업으로 SW 프로젝트 관리를 수행하기에는 체계의 복잡성이나 업무의 양 자체가 매우 크다는 것을 입증한다. 실제로 PMS와 같은 자동화 시스템 없이 다수의 프로젝트를 체계적인 관리 한다는 것은 현실적으로 불가능하다. 때문에 수많은 조직에서 앞다투어 PMS를 도입하고 있다. [2]
특징
기능
고려사항
프로젝트 특성 반영
소프트웨어 프로젝트와 일반 제조산업 프로젝트의 가장 큰 차이점은 소프트웨어 개발은 제조에 비해 매우 극단적인 지식 활동이라는 것이다. 다시 말해 지식활동으로서 일어난 소프트웨어 개발 활동의 비 정형적 특성들(지식의 공유, 지식 자산의 재사용, 소통, 진행 과정의 변경과 진화 등)이 고려되어야 한다.
의존성 최소화
제조나 타 산업군과는 다르게 소프트웨어 개발의 기술/기법/방법론 등은 빠르게 진화한다(e.g. OOAD, CBD, IE 등) 하지만 특정 개발 방법론에 의존적인 관리 시스템은 빠르게 변화하는 신 기술 환경에 맞추어 적응할 수 없다.
비 프로젝트 활동에 대한 고려
소프트웨어 개발 조직의 특성상 일반적으로 개발자들의 공수는 투입된 프로젝트에 대한 직접 투입 공수보다 비 프로젝트 업무(회의, 유지보수, 기획 등)에 많이 소모되는 경향이 있다. 이러한 비 프로젝트 활동은 리소스 관점에서 프로젝트의 품질에 직접적인 영향을 주게 되므로 반드시 관리되어야 한다.
역량 수준 고려
비 지식산업에서 쓰이는 많은 PMS에서는 프로젝트 구성원들의 업무 능력에 대한 차이를 고려하지 않은 채 단순히 태스크 할당의 성격으로 업무를 진행하는 경우가 많다. 그러나 소프트웨어 프로젝트의 경우, 소프트웨어 공학에 대한 역량 차이에 따라 구성원들의 태스크 수행품질도 크게 좌우된다. 단순히 한두 번의 교육으로 이룰 수 없다. 이러한 특성을 충분히 고려하여 관리시스템에 필요 지식이 녹아 들어 있어야 처음 접하는 소프트웨어 엔지니어들도 원활하게 사용할 수 있다.
Best Practive에 대한 제공 필요
건축, 제조 분야와는 다르게 소프트웨어 산업 분야에서는 CMMI, SPICE 등 과 같이 소프트웨어 개발 조직의 역량 수준에 따른 Best Practice들을 제시하고 있다. 이는 지식 산업의 특성이다. 소프트웨어 프로젝트 관리 시스템은 이러한 Best Practice를 지원하는 것에 그치지 않고, 나아가 실무와 Best Practice 간 매끄러운 연결고리 역할을 수행해야 한다.
협업 특성 고려
소프트웨어 개발은 단순한 업무 지시와 개별 작업만으로 수행될 수 없다. 구성원들은 주어진 역할 별로 업무를 수행하되 협업과 소통이 함께 수행되어야 한다. 이 또한 지식 산업으로서 소프트웨어 개발 활동의 빼놓을 수 없는 특성이다.
프로젝트 타입 특성 고려
2명이 한달 동안 하는 소규모 프로젝트와 50명이 1년동안 하는 대규모 프로젝트는 각각의 특성과 환경은 매우 다르다. 이러한 특성을 무시한 일원화된 관리는 소프트웨어 프로젝트의 실패를 야기할 수 있다. 그러므로 다양한 프로젝트 타입 별 특성에 대한 고려가 필요하다.
멀티 프로젝트에 대한 컨트롤 타워 기능
멀티 프로젝트에 대한 체계적인 관리와 통제 기능은 개별 프로젝트의 성공을 좌우한다.
타 도구와의 연계 지원
소프트웨어 개발 및 관리에 있어서 PMS외 다양한 도구에 대한 지원 및 주변 시스템과의 연계가 필요하다. 이러한 주변 도구와의 연계는 조직 차원의 업무 효율성을 높이게 된다.
측정 데이터의 지속적인 축적
동일한 소프트웨어 프로젝트를 동일인이 진행한다고 하여도 프로젝트를 수행할 때 마다 프로젝트의 생산성, 품질 등의 성과는 다르게 나타날 수 있다. 이는 소프트웨어 프로젝트는 제조 프로젝트처럼 간단한 수학 공식을 적용해 그 성과에 대한 예측을 수행하는 것이 불가능한 인적자원 중심의 지식 산업이기 때문이다. 이러한 특성을 고려하여 소프트웨어 프로젝트에서는 보다 정확한 예측을 위하여 다양한 프로젝트 측정과 척도에 대한 통계적 관리 지원이 필요하다.[3]
