소개
프로젝트는 종종 의미합을 조작할 수 있게 하는 것이 전략적 계획의 조직입니다. 프로젝트 제품 및 서비스를 개발 하 고 운영 효율성을 얻기 위해 예상 된다. 비즈니스는 점점 더 계획되고 있으며 프로젝트에 대한 글로벌 지출은 매년 수십억 달러의 순서로 이루어집니다(윌리엄스,2005). 이유는 명백하다. 프로젝트는 자원의 효율적이고 효과적인 사용을 촉진하는 프로젝트 관리 관행을 채택 할 수있는 기회를 제공합니다. 그러나,프로젝트 관리 규율과 직업의 발전에도 불구하고,일반적인 경험은 많은 프로젝트가 실패 제안(윌리엄스,2005),이는 중요성과 프로젝트 관리 프로세스 및 성능을 개선 할 필요성을 강조.
일반적으로 조직은 프로젝트 목표를 달성하고 고객의 기대를 충족시키기 위해 전통적인 프로젝트 관리 모범 사례를 구현하기 위해 노력합니다. 그러나 프로젝트 관리 지식 기관의 모든 권장 프로세스 및 관행이 모든 프로젝트에 관련 될 수있는 것은 아닙니다. 종종,선택적 접근 방식은 크기,유형,복잡성 및 프로젝트가 수행되는 산업에 따라 프로젝트의 특정 요구에 맞게 프로젝트 관리 프로세스 및 관행을 채택하는 데 의미가 있습니다. 그것을 처리하기에 다른 접근을 위해 그런 필요는 계획사업 관리 문학안에 잘 문서화된다 계획한다.
소프트웨어 개발 프로젝트는 소프트웨어 제품을 빠르게 개발하는 동시에 신뢰할 수 있도록 견고하게 개발해야 하는 상충되는 과제에 종종 직면하게 된다(뵘,2002). 빠르게 변화하는 기술 개발에 보조를 맞추는 것을 목표로 하는 프로젝트는 종종 계획 및 구현 단계에서 범위 변경을 거칩니다. 따라서,이 프로젝트는 기존의 프로젝트와는 다른 도전이있다. 기존 프로젝트 관리 관행에 대한 몇 가지 조정 및 수정이 개발되어 프로젝트를 위해 실행되므로 민첩한 프로젝트 관리와 같은 새로운 프로젝트 관리 방법론이 도입됩니다.
애자일 프로젝트 관리 방법론—자주 변화하는 범위에 더 큰 적응성을 가진—반복 또는 단계적 계획과 지속적인 통합을 사용합니다. 핵심 원칙은 프로젝트 범위를 부드럽게 유지하는 것입니다. 이 방법론은 협업을 촉진하고 고객 만족도를 높입니다. 그러나 애자일은 고객의 견고성 및 신뢰성에 대한 요구를 충족시키면서 빠른 속도로 소프트웨어를 개발하는 완벽한 솔루션은 아닙니다. 이러한 맥락에서,뵘(2002)는 기존의 프로젝트 관리 및 가능하고 바람직 민첩한 소프트웨어 개발 방법론의 조합을 추천했다. 보완적인 접근 방식은 민첩한 방법과 계획 중심의 방법 모두의 이점을 유지하고 동시에 많은 약점을 완화 할 수 있도록 맞춤화 된 위험 기반 접근 방식을 개발하는 것입니다(보엠&터너,2003).
본 연구 논문은 상기와 다른 컨설팅 프로젝트를 관리하기 위한 결합된 접근방식의 위 제안들(2002 년 보엠,2003 년 보엠&터너,2003 년)을 검토하는 것을 목표로 한다. 이 컨설팅 프로젝트는 관리하고 프로젝트에 프로젝트 지원을 제공하기 위해 생각된다. 그들은 종종 정부 부문에서 시작됩니다. 그것은 컨설팅 프로젝트는 소프트웨어 개발 프로젝트 아니다;오히려,그들은 그것을 프로젝트에 프로젝트 지원을 제공.
이 연구에서 우리는 민첩한 프로젝트 관리 관행이 컨설팅 프로젝트와 얼마나 관련이 있는지에 대한 이해를 개발하는 것을 목표로합니다. 이 연구의 목적은 애자일 프로젝트 관리 사용의 이점,적합성 및 기존 프로젝트 관리의 측면을 애자일 프로젝트 관리와 결합하여 프로젝트 성과를 향상시키기 위해 프로젝트를 컨설팅하는 것입니다. 다음 섹션에서는 애자일 프로젝트 관리 방법론에 대한 광범위한 문헌 검토를 사용하여 기존 프로젝트 관리에 비해 애자일 방법의 두드러진 특징과 프로젝트 관리에 대한 고유 한 접근 방식을 확인했습니다. 문헌 검토는 애자일 소프트웨어 개발 사용의 주요 개념과 이점에 대한 이해를 개발하는 데 도움이되었습니다. 또한,문헌 검토 결과를 바탕으로,우리는 개발 및 컨설팅 프로젝트의 이해를 개발하기 위해 구조화 된 설문지를 사용하여 연구 방법을 제시했다. 이후에 제시된 데이터 분석 및 토론은 연구의 중요한 통찰력과 결과를 제공합니다. 우리는 그것을 위한 우리의 연구 결과 그리고 권고를 가진 종이를 상담 프로젝트 종결합니다.
문헌 검토
포괄적 인 계획에 의해 주도되는 전통적인 프로젝트 관리 관행은 프로젝트 사양이 명확하게 정의 될 때 사용될 수 있습니다. 반면에 프로젝트 수명 기간 동안 사양이 자주 변경되는 경우 프로젝트 관리에 대한 전통적인 접근 방식이 효율적으로 작동하지 않을 수 있습니다. 소프트웨어 개발 프로젝트는 종종 최소 사양으로 간주되어 프로젝트 구현 중에 이러한 사양을 자주 변경합니다. 또한 소프트웨어 프로젝트 개발 기간이 짧습니다. 기존 프로젝트 관리 기법에 비해 민첩한 방법은 이러한 프로젝트의 개발 기간이 짧기 때문에 소프트웨어 개발 프로젝트에 적합합니다(하나 카와&오쿠라,2004).
일반적으로 애자일 프로젝트 관리와 같은 다양한 소프트웨어 개발 방법은 고객 만족도 향상,결함 비율 감소,개발 시간 단축 등을 약속하며,이는 급변하는 프로젝트 요구사항에 대한 해결책으로 작용한다(&터너,2003). 애자일 프로젝트 관리와는 달리,스테이지 게이트 모델은 컨셉 아이디어에서 궁극적으로 제공되는 제품에 이르기까지 작업 프로세스를 사용합니다. 이 모델은 프로젝트 관리를위한 다양한 제품 개발 단계를 기반으로 프로젝트 관리 라이프 사이클 단계를 개발합니다. 스테이지 게이트 모델과 애자일 프로젝트 관리 사이의 중요한 차이점은 제품이 제 시간에 완료되도록 요구 사항 변경을 최소화하려는 이전의 시도입니다(카리스트롬&룬슨,2005). 소프트웨어를 개발하는 또 다른 방법은 스크럼,소규모 교차 기능 및 자체 관리 팀을 사용하는 일련의 프로젝트 관리 원칙(샤츠&압델샤피,2005). 스크럼은 각 팀 구성원과 제품 소유자가 각 개발 항목의 시작 부분에 함께 작업해야하며 방법론은 기존 개발 프로세스에 대한 래퍼 역할을합니다. 따라서 샤츠와 압델샤피는 스크럼이 프로젝트 성공을 측정하기 위한 기준 계획이 없을 것이라고 주장했다. 그러나,민첩한 프로젝트 관리는 소프트웨어 개발 프로젝트에 그것의 더 중대한 융통성 그리고 적응성 때문에 이 학문을 위해 고려됩니다.
위에서 설명한 이점 외에도 민첩한 방법론은 격동적이고 끊임없이 변화하는 환경에 적용 할 수 있습니다(하이스미스&콕번,2001). 또한 애자일 방법은 시장,기술 및 프로세스에 대한 적응성을 강조합니다(멜로,2005). 애자일 방법론은 중요한 기능에 우선 초점을 맞추는 접근법이며,그 결과 기능에 대한 초기 피드백을 찾을 것입니다(카리스트롬&룬슨,2005). 일단 중요한 특징이 확인되면,프로젝트 매니저는 아무 지연도 없다는 것을 보증할 것이다. 카리스트롬과 룬 슨은 애자일 프로세스가 자원,고정 계획 및 장기 계획 지원을 피할 것이라고 지적했습니다.
그러나 애자일 방법론이 모든 소프트웨어 개발 프로젝트에 적합한 것은 아닙니다. 인용 스콧 앰블러,개발자 애자일 방법,뵘(2002)은 생명에 중요한 시스템과 같은 보증 소프트웨어에 대한 전통적인 계획 중심의 프로젝트 관리 방법론을 권장했습니다.
애자일 방법은 혼돈과 불확실성이 특징인 까다로운 프로젝트 환경으로 인해 도전적인 요구와 요구를 충족시키기 위해 재능있는 인재로 구성된 프로젝트 팀이 필요합니다. 콘스탄틴(2001)의 연구 조사를 인용하여 뵘(2002)은 민첩한 방법에는 유능한 사람이 필요하다고 제안했습니다. 또한,애자일은 대규모 팀에게는 적합하지 않다(하이스미스&콕번,2001).
애자일 방법은 일관된 팀을 고용하는 것이 분명하다(카리스트롬&룬슨,2005). 카리스트롬과 룬 슨은 작고 관리 가능한 작업,지속적인 통합 및 자동 테스트와 같은 추가 민첩한 기능을 확인했습니다. 결과적으로 민첩한 프로젝트 팀은 좋은 내부 커뮤니케이션,높은 품질 및 통제력을 가진 느낌을 특징으로합니다(카리스트롬&룬슨). 그들은,그러나,애자일 팀에 대한 잠재적 인 격리를 직시.
커뮤니케이션,문서 기반 진행 관리 및 품질 관리 측면에서 전통적인 프로젝트 관리의 일반적인 관행은 애자일 소프트웨어 개발 방법과 일치하지 않습니다(하나 카와&오쿠라,2004). 개발 목표의 지속적인 재배치를 위한 대면 상호작용은 애자일 방법론에서 일반적으로 선호된다(멜 닉&마우어,2004). 멜 닉과 마우어는 전통적인 방법과 애자일 방법의 차이점을 강조하면서 짧은 지식 전달과 직접 커뮤니케이션 및 협업이 소프트웨어 개발에서 선호된다고 제안했는데,이는 종종 정보의 왜곡과 손실에 취약한 긴 지식 전달 체인이 사용되는 전통적인 프로젝트 관리 관행과는 대조적입니다.
계획 중심의 전통적인 프로젝트 관리 관행과 애자일 방법의 중요한 차이점 중 하나는 애자일 방법이 전통적인 프로젝트 관리에서 문서 및 계획의 형태로 자주 사용되는 명시 적 지식보다는 프로젝트 팀의 암묵적인 지식에서 민첩성을 포착한다는 것입니다(보엄,2002).
또 다른 차이점은 프로젝트를 위해 작성된 문서의 양과 유형입니다. 계획 중심의 전통적인 프로젝트 관리는 상세한 계획,모니터링 및 제어 문서를 강조합니다. 설계 근거,이유와 정당성을 표현하는 문서는 고도로 자동화 된 절차를 사용하여 작성되며 이러한 설계 근거는 민첩한 문서로 사용됩니다(사우어,2003).
코람과 보너(2005)는 협업,소규모 팀,짧은 릴리스 일정,타임 복싱 및 지속적인 테스트와 같은 애자일 방법의 일반적인 기능을 확인했습니다. 프로젝트 관리자는 고도의 협업 환경을 보장 할 책임이 있습니다. 이를 위해 애자일 방법은 소규모 팀과 프로젝트 당 몇 개의 하위 팀이 협업을 촉진하도록 장려합니다. 결과적으로 민첩한 방법은 팀 활동을 조정하는 데 더 적은 프로세스 및 계획이 필요할 수 있습니다. 애자일 방법은 또한 짧은 릴리스 일정을 사용하며 2 주에서 6 개월까지 다를 수 있습니다. 시간 권투는 금 도금 및 범위 크리프를 줄이는 데 도움이 프로젝트 결과물의 릴리스에 대한 고정 기간을 부과하는 개념이다. 지속적인 테스트는 제품 품질과 통합을 보장합니다. 또한,코람과 보너는 프로젝트 관리자가 특정 계획을 따르기보다는 변화에 대응하는 데 중점을 두고 진행 상황을 추적하고 비즈니스 결정을 내려야 한다고 제안했다.
시간 권투는 최선의 추측에 의해 예측할 수없는 계획으로 이어지고 고정 된 날짜는 개발 단계에서 예기치 않은 놀라움을 가져올 수 있습니다(패튼,2003). 이 반복적 인 프로젝트 계획 프로세스의 또 다른 결말은 애자일 방법이 완료 비율에 따라 진행 상황을 모니터링 할 수 없다는 것입니다(패튼,2003).
소규모 하위 팀이 계획에 참여하면 동기 부여 된 소프트웨어 개발 엔지니어가 생길 것이며,프로젝트 초기에 기술적 인 문제가 제기되고 구현에 대한 저항이 거의 없을 것입니다(카리스트롬&룬 슨,2005). 또한 민첩한 접근 방식으로 프로젝트 범위를 정의하면 비용 절감 효과가 나타납니다(맥거번,2002). 애자일 방법은 계획 기반의 요구 사항을 사용하고,또한 우리가 범위를 제어 할 수있게된다(맥거번).
지금까지의 모든 참고 문헌과 토론 등을 사용하여(리틀 그린,필립스,필거&폴더바르트,2004;리틀,2005;아브라함손,워스타,시포넨,&론카넨,2003;일리바,이바노프,&스테파노바,2004;린드발,2004),표 1 은 전통적인 프로젝트와 애자일 프로젝트 간의 요약 비교를 제공한다 관리 관행.
표 1: 민첩한 프로젝트 관리와 기존 프로젝트 관리 간의 비교
| 프로젝트 단계 | 전통적인 | 민첩한 |
| 개시 |
|
|
| 계획 |
|
|
| Execution |
|
|
| 모니터링 및 제어 |
|
|
| 재고 정리 |
|
|
문헌 검토 요약
애자일 프로젝트 관리 방법론은 소프트웨어 개발 프로젝트에 일반적으로 사용됩니다. 그것에는 자주 변화하는 범위에 더 중대한 적응성이 있습니다. 결과적으로 애자일 프로젝트 관리는 프로젝트 수명 내내 반복적 또는 단계적 계획과 지속적인 통합을 사용합니다. 애자일 프로젝트 관리의 핵심 원칙은 프로젝트 범위를 부드럽게 유지하는 것입니다. 애자일 프로젝트 관리 방법은 전통적으로 중요하지 않은 것으로 간주되는 요소에 중요성을 할당하여 전통적인 프로젝트 관리 방법과 다릅니다. 애자일은 상대적으로 더 높은 중요성을 할당합니다:
- 프로세스 및 도구에 대한 개인 및 상호 작용
- 포괄적인 문서화를 통한 프로젝트 실행
- 계약 협상을 통한 고객 협업
- 프로젝트 계획 변경에 대한 대응
민첩한 방법은 프로젝트 요구 사항을 충족할 수 있는 유연성을 강조합니다. 또한 프로젝트 계획의 변경을 시작하기 위해 고객 피드백에 의존합니다. 이 방법론은 적절한 최종 사용자와 목표를 식별하는 접근 방식을 사용하여 프로젝트 결과물을 공식화하고 비즈니스 프로세스의 수행 요구를 충족시킵니다. 애자일 방법을 사용하면 고객 만족도 향상,결함 비율 감소,개발 시간 단축 등의 이점이 있습니다. 또한 민첩한 방법은 프로젝트 결과물의 기술 기능에 대한 초기 피드백을 사용하기 때문에 빠르게 변화하는 요구 사항에 대한 해답입니다. 애자일 메서드는 요구 사항이 채워지지 않도록 합니다. 애자일 방법의 주요 특징은 프로젝트 팀 내외부의 효과적인 커뮤니케이션이며,더 많은 요구 사항을 추가하는 유연성을 입증했습니다.
이러한 혜택은 조직이 더 나은 고객 서비스를 제공하는 데 도움이됩니다. 또한,그들은 세계화와 무료 마케팅 철학이 제품 및/또는 서비스를 더 빠르고 저렴하며 더 잘 제공 할 수있는 기대를 높이는 고객의 인식에 영향을 미치는 현재 경제와 관련이 있습니다.
그러나 애자일 방법은 표 1 에서 볼 수 있듯이 단점이없는 것은 아닙니다. 범위를 자주 변경하면 프로젝트 진행 상황을 모니터링하는 데 어려움이 있습니다. 또한,배운 교훈의 형태로 암묵적인 지식을 캡처하는 것은 쉽지 않다. 범위 변경 제어,문서화,종합 계획,품질 관리 및 위험 관리는 애자일 방법을 사용할 때 우리가 박탈 할 수있는 전통적인 프로젝트 관리의 중요한 이점입니다.
연구 방법론
우리는 데이터를 수집하기 위해 개인 인터뷰와 설문지를 모두 사용했습니다. 우리는 두 섹션으로 구성된 구조화 된 설문지를 개발했습니다. 첫 번째 섹션은 프로젝트 및 그 특성에 대한 세부 정보를 캡처하도록 설계되었습니다. 이 섹션은 프로젝트 인구 통계 및 프로젝트 관리 관행과 관련된 13 개의 질문으로 구성됩니다. 그들은 필요한 경우 개방형 응답을 제공 할 수있는 옵션으로 연구 참가자에게 제시되었습니다.
두 번째 섹션은 프로젝트 관리 실무 진술에 초점을 맞추었고 참가자들은 1 은”강하게 동의하지 않는다”,5 는”강하게 동의한다”로 5 점 척도로 이러한 진술에 응답하도록 요청 받았다.”다음 진술은 프로젝트 관리 관행의 중요한 공통 신조를 다루고 전통적이고 민첩한 프로젝트 관리 관행을 대조하는 데 사용되었습니다.
- 프로젝트 성공을 측정하는 기준은 프로젝트의 목표와 목표에 기반합니다.
- 이 프로젝트는 요구 사항에 의해 주도됩니다.
- 이 프로젝트는 변화에 적응할 수 있습니다.
- 여러분의 의견으로는,프로젝트 관리 노력이 예상 결과를 달성했다.
- 팀은 포괄적인 문서를 통한 프로젝트 실행에 중점을 둡니다.
- 계약 협상에 대한 고객 협력은 팀에 더 효과적입니다.
- 이 프로젝트는 잘 정의 된 프로젝트 범위를 가지고 있습니다.
- 프로젝트 관리 관행은 프로젝트 수명주기를 따릅니다.
- 프로젝트에 대한 반복 또는 단계적 프로젝트 계획이 이어집니다.
- 이 프로젝트는 다음과 같은 표준 준수와 같은 문서 요구 사항을 가지고 있습니다.
- 프로젝트 전반에 걸쳐 사용자 승인 테스트 절차를 따릅니다.
- 프로젝트 관리자는 고객의 개입 없이 프로젝트 관련 결정을 내릴 권한이 있습니다.
이 진술에 대한 응답은 13 개의 질문 중 첫 번째 세트의 적절한 질문과 함께 분석됩니다. 두 섹션에 대한 응답은 의미있는 분석을 위해 프로젝트에 대한 자세한 이해를 제공했습니다.
연구 결과
설문지는 연구 당시 진행 중인 20 개의 컨설팅 프로젝트에 대한 데이터를 캡처하도록 구성되었습니다. 프로젝트 중 65%는 시간 및 자재 계약 유형 프로젝트이고 나머지는 확고한 고정 가격 유형입니다. 시간 및 재료 프로젝트 중 55%는 프로젝트 기간이 2 년 이상입니다.
대부분의 프로젝트 팀은 소규모이며 15%만이 10 명 이상의 회원을 보유하고 있습니다. 프로젝트 팀 구성원 간의 커뮤니케이션과 관련하여 응답자의 60%는 프로젝트 요구에 대한 공식적인 커뮤니케이션만을 사용했습니다; 30%는 공식 및 비공식 커뮤니케이션을 모두 사용했으며 나머지 10%는 비공식적 인 방법에만 의존했습니다.
응답자 2 명 중 1 명은 프로젝트가 프로젝트 계획을 사용했다고 답했다. 관련 질문에서 프로젝트 계획이 없는 프로젝트 중 80%는 반복 계획을 사용하지 않았습니다.
범위 변경은이 연구의 중요한 측면입니다. 프로젝트 중 70%는 적어도 한 번 범위 변경을 경험했습니다. 프로젝트 범위 변경을 경험 한 사람들 중 60%는 두 번 이상 경험했습니다. 클라이언트가 범위 변화를 결정하는 동안,고문은—클라이언트의 동의에—프로젝트 관리 계획에 있는 품질 관리 계획을 포함할 수 있다. 프로젝트에 대한 품질 관리 계획이 있는지 묻는 질문에 응답자의 65%는 품질 관리 계획을 사용하지 않았다고 답했습니다.
결과 토론 및 분석
연구 결과는 먼저 결과를 검증하고 두 번째로 효과적인 경영 전략을 개발하기 위해 질문과 다른 모든 질문 사이의 상호 관계를 신중하게 검토하여 분석되었습니다. 또한 이러한 결과를 분석하여 어떤 민첩하고 전통적인 프로젝트 관리 관행을 조합하여 컨설팅 프로젝트에 대한 강력한 프로젝트 관리 접근 방식을 개발할 수 있는지 조사했습니다.
목표 및 목표에 따른 프로젝트 성공 기준
프로젝트는 목표 및 목표를 충족하면 성공한 것으로 간주됩니다. 응답자의 60%만이”프로젝트 성공을 측정하는 기준은 프로젝트의 목표와 목표에 기반합니다.”응답자의 약 30%가 동의하지 않았습니다. 추가 분석에 따르면 동의하지 않는 이유는 이러한 프로젝트가 끊임없이 변화하는 조건과 요구 사항을 경험했거나 고객이 프로젝트에 대해 명확하지 않았기 때문입니다. 궁극적으로 이러한 프로젝트는 빈번한 범위 변경을 경험했습니다. 특정 사례에서 프로젝트 목표와 목표가 변경되었습니다.
프로젝트의 성공 기준이 목표 및 범위 변경,프로젝트 유형 및 프로젝트 계획의 존재로부터 파생된다는 사실 사이에는 연관성이 없다는 점은 흥미 롭습니다. 즉,조직의 전략 계획에서 프로젝트 기준을 도출하는 것은 범위 변경 및 프로젝트에 계획이 있는지 여부와 관련이 없습니다.
프로젝트 요구 사항
일반적으로 프로젝트 스폰서의 요구 사항이 명확하게 식별 된 후 상세한 프로젝트 계획이 개발됩니다. 프로젝트 계획 개발 및 실행은 원칙적으로 이러한 요구 사항에 의해 주도되어야합니다. 따라서,하나는 프로젝트 관리자가 문에 동의 할 것으로 예상,”이 프로젝트는 요구 사항에 의해 구동된다.”연구 결과는 응답자의 60%가 자신의 프로젝트가 요구 사항에 의해 구동되고 있다고 말했다 것으로 나타났다. 성명서에 동의하지 않은 응답자의 약 20%는 프로젝트 계획을 사용하지 않고 프로젝트를 실행한다고 답했습니다.
이 진술에 대한 응답으로 중립적 인 응답자의 약 20%는 프로젝트에서 범위 변경을 경험하지 않은 프로젝트 관리자입니다. 다른 모든 응답자,성명서에 동의하거나 동의하지 않은 응답자는 현재 프로젝트에서 적어도 한 번 범위 변경을 경험했습니다.
일반적으로 프로젝트가 계획에 따라 실행되지 않으면 실행 중에 요구 사항이 확인되지 않거나 프로젝트 요구 사항이 변경 될 것으로 가정 할 수 있습니다. 그러나이 연구에서는 두 번째 진술에 동의 한 사람들 중 50%만이 계획을 사용하지 않고 프로젝트를 관리했기 때문에”프로젝트 계획을 사용하지 않고 프로젝트 구현”과”프로젝트가 요구 사항에 의해 주도되지 않는다”사이의 연관성을 확립 할 수 없습니다.
변화 적응성
20 개 프로젝트 중 18 개가 프로젝트 변경에 성공적으로 응답했습니다. 변화에 대한 적응성은 프로젝트가 민첩한 프로젝트 관리 방법론을 사용하는 후보가 될 수있는 주요 특성으로 간주됩니다. 이 연구에서 대표되는 컨설팅 프로젝트는 범위 변경을 처리 할 수있는 적응력이 있음을 보여주었습니다.
프로젝트 관리 노력 달성 예상 결과
결과는 고객이 대부분의 프로젝트(70%)에서 결과에 만족 함을 시사합니다. 그러나 이러한 응답은 프로젝트 관리자의 관점에서 개발 된 프로젝트 진행 및 제품에 대한 다른 중요한 설문 조사 질문에 대한 응답과 관련이 없습니다. 이유는 명백하다. 프로젝트는 여전히 시간과 비용 초과를 경험하고있었습니다. 소프트웨어 제품을 제공하는 최종 결과는 만족 스럽지만 프로젝트 관리 프로세스는 성공적으로 실행되지 않았습니다. 추론은 이정표 개발,모니터링 및 제어와 같은 전통적인 프로젝트 관리 관행을 채택하면 프로젝트를 성공적으로 관리하는 데 도움이 될 수 있습니다.
프로세스 대 대면 커뮤니케이션의 중요성
커뮤니케이션은 프로젝트와 관련된 역할,책임,정책 및 절차를 이해하고 협력을 장려하는 열쇠입니다. 궁극적으로 커뮤니케이션은 응집력있는 프로젝트 팀으로 이어지고 팀 구성원이 공동 작업하고 의사 결정에 참여하도록 장려합니다. 이 연구에 참여한 10 명의 프로젝트 관리자 중 7 명은 대면 상호 작용과 짧은 커뮤니케이션 체인이 프로세스와 도구보다 더 중요하다는 데 동의했습니다.
결과는 대면 커뮤니케이션의 중요성과 프로젝트 팀 구성원 간의 의사 소통 수단 간의 강력한 연관성을 보여줍니다. 대면 커뮤니케이션이 프로젝트 프로세스보다 더 중요하다는 것에 동의하지 않는 사람들은 프로젝트 팀원들 사이에서 비공식 커뮤니케이션을 사용하는 반면,대면 커뮤니케이션이 더 중요하다고 생각하는 사람들은 공식 및 비공식 커뮤니케이션을 모두 사용했습니다.
문서화에 대한 프로젝트 실행에 집중
프로젝트 문서는 종종 간과되고,따라서 조직은 프로젝트 계획과 실행에서 배운 중요한 교훈을 박탈당한다. 이 연구에서 표현 된 모든 프로젝트가 연방 정부 프로젝트라는 것을 고려할 때 응답 프로젝트 관리자의 70%가 팀이 포괄적 인 문서를 작성하는 것과 비교하여 프로젝트 실행에 초점을 맞추 었다는 데 동의 한 것은 흥미 롭습니다. 프로젝트 관리자가 문서화가 프로젝트 실행보다 더 중요하다고 생각한 몇 가지 경우에서 추가 조사는 고객이 모든 경우에 프로젝트에 대해 우유부단하다는 것을 밝혀 냈습니다.
계약 협상에 대한 고객 협력
계약 협상은 외부 프로젝트의 필수 기능입니다. 협상하는 동안,양 당사자는 자신의 이익을 보호에 초점을 맞출 것이다. 계약 협상은 프로젝트의 여러 단계에서 이루어질 수 있습니다. 특히 프로젝트 실행 중에 협업을 통해 이러한 문제를 처리하는 것이 바람직하며,그렇지 않으면 계약 연장 등의 문제가 발생할 수 있습니다. 이 연구에서 표현 된 모든 프로젝트가 계약임을 감안할 때 응답 프로젝트 관리자의 절반 이상(60%)이 계약 협상보다 고객 협업이 더 중요하다고 생각하는 것이 고무적입니다. 그들은 협업이 프로젝트 팀에 더 잘 작동한다고 제안했습니다.
협력이 협상만큼 중요하지 않다는 것을 암시하는 불일치가 있었던 곳에서는 두 가지 흥미로운 사실이 그 프로젝트와 관련이 있었다. 다른 모든 프로젝트는 프로젝트 이해 관계자와의 의사 소통 수단으로 직접 접촉을 사용했지만 이러한 프로젝트는 명령 체인 통신을 사용했으며 고객은 프로젝트에 대해 우유부단했습니다. 이 두 가지 요소는 협업을위한 어려운 조건을 의미합니다.
프로젝트 및 잘 정의 된 프로젝트 범위
프로젝트는 일반적으로 불확실성 및 알려지지 않은 요인과 관련이 있으며,이는 모호성을 초래합니다. 따라서 프로젝트 초기 단계에서는 자세한 범위와 사양을 개발할 수 없습니다. 프로젝트의 범위는 프로젝트 전반에 걸쳐 지속적으로 변경됩니다. 때로는 프로젝트의 원래 목표도 변경 될 수 있습니다. 조사 대상 프로젝트 중 40%는 잘 정의 된 범위를 가지고 있으며 다른 45%는 그렇지 않았습니다.
그러나 프로젝트의 80%는 이전에 제시된 주장의 유효성을 검사하는 범위 변경을 한 번 이상 경험했습니다.
프로젝트 관리 관행 및 PMBOK®가이드 프로젝트 수명 주기
PMBOK®가이드를 개발하고 정교한 프로젝트 관리 프로세스 수명 주기;그것은 철저하고 포괄적이다. 그러나 모든 프로젝트 관리 라이프 사이클을 모든 프로젝트에 적용할 필요는 없다. 그 채택은 프로젝트 별이어야합니다. 예상대로,프로젝트 관리자의 45%는 피엠복 가이드 프로젝트 라이프 사이클의 프로젝트 관리 관행을 따랐고,또 다른 45%는 그렇지 않았다.
반복 또는 단계적 프로젝트 계획
범위 정의 및 프로젝트 관리 계획은 프로젝트 계획의 일부입니다. 앞에서 설명한 바와 같이 범위 및 사양에 대한 자세한 개발은 프로젝트 초기에 개발할 수 없습니다. 결과적으로 프로젝트의 범위는 프로젝트 전반에 걸쳐 지속적으로 변경되며,이는 애자일 방법의 중요한 특성 인 반복 또는 단계적 프로젝트 계획의 중요성을 강조합니다. 프로젝트에 대해 반복 또는 단계적 프로젝트 계획을 따르는지 여부를 묻는 질문에 응답자의 절반이’예’라고 답했으며 15%만이 반복적 인 프로젝트 계획을 따르지 않았습니다. 반복적 인 프로젝트 계획의 실천에 동의하지 않는 모든 사람들은 처음부터 프로젝트 계획을 가지고 있지 않다는 점에 주목하는 것이 흥미 롭습니다.
문서 및 표준 준수
프로젝트 문서는 과거 데이터 분석을위한 참고 자료로 사용되며 조직이 프로젝트 관리 프로세스를 지속적으로 개선하고 표준을 개발하는 데 도움이됩니다. 이 문서는 또한 배운 교훈을 식별하고 프로젝트 관리 성숙으로 이어질 프로젝트 관리 시스템을 수정하는 데 도움이됩니다. 프로젝트 문서 시스템 설계 가이드 역할을 합니다. 특히,많은 정부 프로젝트가 옴브 300 가이드라인을 준수해야 합니다. 응답자 중 80%는 관리 중인 프로젝트들이 표준 준수와 같은 문서 요구 사항을 가지고 있다고 답했다. 그러나,컨설팅 프로젝트에 대 한 이러한 요구 사항은 제한 된 범위에 적용 됩니다.
사용자 승인 테스트 절차
고객 만족은 프로젝트 결과물 항목의 품질과 성공의 주요 척도입니다. 따라서 사용자 승인 테스트 절차가 중요하다고 간주됩니다. 서비스와 같은 보다 적게 명백한 프로젝트 결과물의 경우에 조차 프로젝트 성공의 근본적인 측정은 소비자 만족도입니다. 그러나 그것은 주관적입니다. 응답자의 30%만이 프로젝트 전체에서 사용자 수락 테스트 절차를 따랐으며 응답자의 45%는 그렇지 않다고 답했습니다.
프로젝트 관련 결정을 내릴 수있는 권한 부여
일반적으로 프로젝트 관리자는 이러한 결정이 프로젝트 범위 또는 프로젝트 결과물에 큰 영향을 미치지 않는 경우 고객의 개입없이 프로젝트 관련 결정을 내릴 수있는 자유 손을 부여해야합니다. 15%만이 프로젝트 관리자가 고객의 개입없이 프로젝트 관련 결정을 내릴 수있는 권한이 있다고 동의했습니다. 약 40%는 중립을 유지하고 나머지 45%는 프로젝트 관리자가이 힘을 가지고 있지 않다고 말했다. 이러한 프로젝트가 외부 및 정부 프로젝트라는 점을 감안할 때 이러한 결과는 의미가 있습니다.
결론
우리의 연구 결과는 프로젝트의 대부분이 요구 사항에 의해 주도된다는 것을 보여줍니다. 이 연구에 제시된 거의 모든 프로젝트는 변화에 적응할 수 있음을 보여주었습니다. 비공식적 인 의사 소통은 공식적인 프로세스 및 시스템보다 더 중요한 것으로 간주됩니다. 이 연구의 프로젝트가 정부 업무와 관련이 있다는 것을 고려할 때,결과는 프로젝트 팀이 포괄적 인 문서를 통해 프로젝트 실행에 초점을 맞추고 있음을 보여줍니다. 또한 계약 협상에 대한 고객 협업은 프로젝트 팀에게 더 효과적입니다. 자주 프로젝트 범위 변경 반복 또는 단계적 프로젝트 계획의 중요성을 의미;애자일 프로젝트 관리의 중요한 특성. 이 연구에서 대표되는 모든 정보 컨설팅 프로젝트가 계약임을 감안할 때 연구 결과는 정보 컨설팅 프로젝트에 대한 민첩한 방법론을 공식적으로 채택하고 계획 중심의 이정표 개발 및 모니터링,사용자 수용 절차 및 품질 관리 관행과 같은 전통적인 프로젝트 관리 관행과 결합하는 것이 좋습니다.
프로젝트에 대한 민첩한 방법의 적합성은 프로젝트 계획,모니터링 및 제어에 관한 문서와 관련된 계약상의 의무입니다. 우리는 이러한 프로젝트에 대한 민첩한 방법을 수정하는 데 주의를 기울여야 합니다.
도전 과제는 민첩성,변화에 대한 신속한 대응,유연하고 간단한 계획,지속적인 통합 및 전통적인 프로젝트 관리 관행의 포괄적 인 프로세스 중 일부를 통합하면서 애자일 방법의 다른 이점을 유지하는 것입니다.