EPM: 중앙 집중식 또는 분산식
이 문서는 "트렌치에서" 컬렉션의 일부입니다. 조직에서 프로젝트 관리 시스템 구현을 결정할 때 해결하려는 문제를 이해해야 하는 방법을 설명합니다. 일부 경우 중앙화된 프로젝트 관리 시스템을 배포하는 것은 최상의 방법이 될 수 없습니다.
이 문서의 Word 버전을 다운로드하려면 EPM 중앙 집중식 또는 탈중앙화?를 참조하세요.
더 많은 문서를 보려면 "참호에서" 백서를 참조하세요.
EPM - 중앙 집중식 또는 탈중앙화?
저는 1980년대 초에 프로젝트 관리 업계에 처음 입사한 이래로 엔터프라이즈 프로젝트 관리를 지지해 왔습니다. 그렇다면 저는 항상 중앙 집중식 프로젝트 관리 쪽에서 투표할 것이라고 생각하지만 항상 그런 것은 아닙니다. 엔터프라이즈 프로젝트 관리의 의미에 대해 잠시 살펴보겠습니다.
EPM은 다른 사람들에게 많은 다른 것을 의미 할 수 있습니다. 이 열의 다른 문서에서 EPM 배포의 포커스가 한 조직에 대한 문서 관리 및 다음에 대한 통합 일정이 될 수 있는 방법에 대해 이미 설명했습니다. 그러나 Enterprise Project Management의 핵심은 프로젝트 관리 연습에서 사람들이 서로 상호 작용해야 한다는 개념입니다. 즉, 프로젝트 관리자 및/또는 프로젝트 관리 팀이 완전히 독립적으로 작동하지 않습니다. 그러나 이것이 이 "상호 작용"을 달성하는 유일한 방법은 중앙 집중식 프로젝트 예약 시스템을 갖는 것임을 의미합니까? 반드시. 일부 조직의 경우 프로젝트 관리 과제는 모든 프로젝트가 임시로 관리되기 때문에 요약, 엔터프라이즈 전체 프로젝트 관리 보고서를 생성할 수 없는 것일 수 있습니다. 이 경우 모든 프로젝트 관리 담당자 간에 공유되는 프로젝트 표준을 사용하는 것만으로 EPM을 달성할 수 있습니다. 이는 모든 사람이 사용할 수 있는 템플릿, 교육 자료, 문서 및 보고서 표준의 중앙 풀에서 가장 잘 달성할 수 있습니다. 아마도 간단한 SharePoint 사이트로 충분할 것입니다.
일부 조직의 경우 작업 중인 내용과 다음 포커스에 대한 리소스 간의 통신이 부족하여 프로젝트 관리 과제가 비효율적인 개인 일정일 수 있습니다. 이 경우 팀 및 팀 간 커뮤니케이션을 개선하여 EPM을 달성할 수 있습니다. 도구는 공유 일정, 인스턴트 메시징 또는 사람들이 우선 순위를 나열할 수 있는 공유 포털만큼 간단할 수 있습니다.
일부 조직에서는 프로젝트 관리 과제가 프로그래밍 개발 프로젝트에서 진행 중일 뿐입니다. 이 경우 Visual Studio Team Services 같은 제품에 이미 있는 도구로 충분할 수 있습니다. 프로그래밍 프로젝트에서는 거의 모든 순서로 많은 작업을 완료할 수 있으므로 수행 중인 개발 유형에 따라 위험 경로 일정 예약의 엄격성도 적절하지 않을 수 있습니다.
몇 년 전 항공사의 유지 관리 부서에서 일했던 기억이 났습니다. 직원은 매월 시작 시 자신의 일정을 선택할 수 있었고,이 조정되지 않은 경우 (종종 그 경우와 같이), 아무도 작동하지 않는 것을 확인하기 위해 교대 근무를 관리하기 위해 도착할 수 있었습니다. 그들의 프로젝트 관리 과제는 "언제 작업이 완료될 것인가?"가 아니라 "누구든지 출근하고 있습니까?" 였습니다. 이 경우 EPM은 시프트 예약 도구를 구현하여 수행되었습니다.
EPM 챌린지를 프로젝트 일정에 집중하는 경우에도 중앙 집중식 프로젝트 관리 시스템을 배포하는 것이 유일한 또는 최선의 대답이라는 것은 즉시 명확하지 않습니다. 프로젝트 관리 담당자가 서로 어떤 상호 작용을 해야 하는지 물어보는 것이 좋습니다. 리소스 충돌을 해결하기 위해 정기적으로 협업하거나, 조직의 다른 우선 순위를 확인하거나, 한 프로젝트의 진행률이 다른 프로젝트에 어떤 영향을 미치는지 확인해야 하는 경우 Project Server와 같은 도구를 보는 것이 완벽하지만, 종종 이 질문을 하지 않은 조직과 상호 작용하게 됩니다.
일부 조직에서는 적은 수의 스케줄러와 많은 수의 리소스를 찾을 수 있습니다. 규모가 좋은 조직에서도 이 구조는 수행 중인 산업 및 프로젝트 유형에 따라 구조가 될 수 있습니다. 얼마 전에 저는 EPM 챌린지에 적합한 솔루션을 선택했다고 확신하는 조직을 만났습니다. 그들은 나에게 해결책을 분명히 해달라고 요청했지만, 평소와 같이 먼저 프로젝트 관리 문제를 분명히 해달라고 요청했습니다.
그들이 화이트 보드에 자신의 환경을 설명하는 것을 마쳤을 때, 그들이 선택한 해결책이 문제를 해결하지 않을 것이라는 것이 분명했습니다.
이 경우 문제는 대규모 하청업체 풀에서 보고되는 프로젝트 진행률이 부족하다는 점이었습니다. 클라이언트는 실제로 해야 할 일은 하청업체에 시간 및 청구 유형의 작업표를 부과하는 것이라고 결정했습니다. 프로그램 디렉터는 낙담했습니다. "우리는 하청 업체 계약에 그것을 얻을 수 없을 거야,"그들은 말했다. 다행히 재무 부서의 한 구성원이 참석했습니다. "알다시피," 그 사람은 대답했다, "우리가 선택한 작업표를 작성하도록 요구하는 절은 이미 하청 업체 계약에 있습니다." 문제가 해결되었습니다.
솔루션에 오기 전에 문제를 해결하는 아이디어는 여기에서 자주 이야기하지만 채택하기가 어렵습니다. 논리적 사고는 자동화된 솔루션을 결정하는 순서는 다음과 같습니다.
문제 식별
솔루션 정의
솔루션을 자동화할지(그리고 그렇다면 방법) 결정
웹 사이트, 비디오 및 기타 위치에서 자동화된 솔루션 데모를 통해 이러한 사실을 잊어버리게 됩니다. 물론 어떤 종류의 문제가 없는 한 솔루션을 찾는 것은 아니지만 자동화된 솔루션은 매우 매력적으로 보이고 들리기 때문에 결국 다음을 수행하게 됩니다.
자동화된 솔루션 선택
솔루션 배포에 문제가 발생합니다.
자동화된 도구를 솔루션에 적용하는 방법을 정의하여 이 문제를 해결합니다.
원래 문제가 무엇인지 기억해 보십시오.
새로운 문제는 꽤 오랜 시간 동안 솔루션을 배포하게되고, 몇 주, 몇 달, 또는 심지어 몇 년 동안 고위 경영진의 누군가가 원래 문제가 해결 될 때 묻고 모두가 오히려 놀란 서로를 쳐다봅니다. 잊기 쉬웠습니다.
수년에 걸쳐 가능한 모든 종류의 자동화된 솔루션을 권장했습니다. 아, Project Server는 물론 옵션 중 하나였지만 Microsoft Project Pro와 SharePoint Server의 조합도 권장했습니다. Excel과 Outlook의 조합을 사용하는 것이 좋습니다. Project에서 타사 작업표를 사용하는 것이 좋습니다.
나는 한 번 큰 화이트 보드를 사용하는 것이 좋습니다. 정직. 이 조직은 제가 수년 동안 사업을 해왔던 조직이었습니다. 문제의 사람은 부동산 역할에 있었고 부동산에서 장기 임대를 갱신해야했습니다. 문제가 무엇인지 물었을 때, 그것은 분명히 일정 문제였습니다. 그 사람은 중요한 몇 가지 기한을 놓쳤고 엔터프라이즈 프로젝트 관리 도구가 문제를 해결할 것이라고 확신했습니다. 조직은 이미 향후 기한을 놓치지 않도록 보고서를 여러 임원에게 배포하도록 요청했습니다. "몇 명의 사용자가 있을까요?" 나는 물었다. "그냥 나야." 그가 대답했다. "한 번에 몇 개의 프로젝트가 있나요?" 저는 "7~8번"이라고 물었습니다. "그리고 각 프로젝트에 대해 얼마나 많은 최종 기한 마일스톤을 관리하나요? "매우 복잡합니다. 각 기한은 약 12개입니다." 그는 나에게 말했다.
이 가난한 동료를 위해 큰 중앙 집중식 EPM 시스템을 설치해서는 안된다는 것이 이미 분명했습니다.
"칸막이에 큰 흰색 보드를 놓고 다른 마일스톤에 색이 지정된 마커를 사용하는 것은 어떨까요?" 나는 물었다. "첫 번째 항목에는 파란색, 두 번째의 경우 녹색, 마지막에는 빨간색 등을 사용할 수 있습니다."
그는 개념에 매료, 풍부한 메모를했다. 나는 그날 어떤 서비스나 제품을 판매하지 는 않았지만 그가 상상했던 시스템을 배포 할 수 없다는 사실에 실망한 사람을 떠났다는 것을 알고 회사를 떠났다. 집으로 가는 길에 제 휴대폰이 차 안에서 울렸습니다. 그것은 그였다. "화이트 보드의 다양한 색상을 설명할 수 있을까요?" 그가 물었다.
솔루션을 디자인하기 전에 그리고 솔루션을 자동화하는 방법을 선택하기 전에 해결하려는 문제를 파악하는 것은 비용을 절감하는 것이 아닙니다. 애초에 해결해야 하는 문제가 없는 조직의 요소에 대해 작업하는 데 엄청난 시간을 절약할 수 있습니다.
해결하려는 문제가 중앙 집중식 엔터프라이즈 프로젝트 관리 소프트웨어로 가장 잘 해결될 수 있는 경우 다른 어떤 작업도 수행할 수 없지만 문제를 명확하게 설명하여 얻을 수 있는 초점은 도움이 될 것입니다. 배포 팀은 문제가 해결되었을 때 프로젝트를 성공으로 선언할 수 있는 성공 메트릭을 만들 수 있습니다. 중앙 집중화 또는 탈중앙화? 엔터프라이즈 프로젝트 관리 중 하나를 사용하여 수행할 수 있습니다.
작성자 정보
Chris Vandersluis는 캐나다에 본사를 둔 HMS 소프트웨어인 Microsoft Certified Partner인 몬트리올의 사장 겸 설립자입니다. 그는 맥길 대학교에서 경제학 학위를 취득했으며 프로젝트 제어 시스템의 자동화 분야에서 30년 이상의 경험을 보유하고 있습니다. 그는 PMI(프로젝트 관리 연구소)의 오랜 회원이며 MPUG(Microsoft Project Users Group)의 몬트리올, 토론토 및 퀘벡 지부를 설립하는 데 도움을 주었습니다. Chris가 저술한 출판물에는 포춘, 헤비건설 뉴스, 컴퓨팅 캐나다 잡지, PMI의 PMNetwork 등이 있으며, 프로젝트 타임즈의 정기 칼럼니스트입니다. 그는 McGill 대학에서 고급 프로젝트 관리를 가르치고 종종 북아메리카 및 전 세계의 프로젝트 관리 협회 기능에서 연설합니다. HMS Software는 TimeControl 프로젝트 지향 시간 유지 시스템의 게시자이며 1995년부터 Microsoft 프로젝트 솔루션 파트너로 활동해 왔습니다.
Chris Vandersluis는 다음에서 전자 메일로 연락할 수 있습니다. chris.vandersluis@hms.ca
Chris Vandersluis에서 더 많은 EPM 관련 문서를 읽으려면 HMS의 EPM 지침 사이트(https://www.epmguidance.com/?page_id=39)를 참조하세요.