반감기(t 1/2) 도달: 구현 후 PPM 솔루션 관리

이 문서는 "트렌치에서" 컬렉션의 일부입니다. PPM(프로젝트 포트폴리오 관리) 솔루션에 대한 거버넌스 모델을 설정하기 위해 프레임워크를 설정하는 방법을 설명합니다. 또한 자체 거버넌스 전략을 설정하기 위한 시작점으로 사용할 수 있는 샘플 거버넌스 계획이 포함되어 있습니다.

이 문서의 Word 버전을 다운로드하려면 반감기(t 1/2): PPM 솔루션 관리, 구현 후: 백서를 참조하세요.

더 많은 문서를 보려면 "참호에서" 백서를 참조하세요.

반감기(t 1/2): PPM 솔루션 관리, 사후 구현

소개

방사성 물리학에서 반감기(t1/2)는 수량이 기간 시작 시 측정된 값의 절반으로 떨어지는 데 필요한 시간입니다. (참조: https://en.wikipedia.org/wiki/Half-life).

그렇다면 최근에 구현된 브랜드가 새로운 PPM(프로젝트 포트폴리오 관리) 솔루션에 어떻게 적용됩니까? 적용되는 이유는 성공적으로 구현된 PPM 솔루션에 만료 날짜가 함께 제공되기 때문입니다. PPM 솔루션 관리를 중심으로 거버넌스 프로세스를 계획, 설계 및 실행하는 데 시간이 걸리지 않는 경우 솔루션이 부실 데이터, 잘못된 디자인 변경, 실제 조직 프로세스와 동기화되지 않은 프로세스로 채워지고 목록이 계속된다는 것을 안심할 수 있습니다. 유지 관리를 받지 못하는 자동차와 마찬가지로 솔루션은 예상되는 ROI의 산출을 중지합니다. 사용자는 수동적으로 솔루션 사용을 중지하거나 다른 솔루션을 적극적으로 옹호합니다.

이 문서의 목표는 PPM 솔루션에 대한 거버넌스 모델을 설정하는 프레임워크를 논의하는 것입니다. 자체 거버넌스 전략을 설정하는 시작점으로 사용할 수 있는 샘플 거버넌스 계획도 제공됩니다.

The What and the Why

거버넌스라는 단어는 다른 사람들에게 다른 것을 의미할 수 있지만, 핵심적인 거버넌스 계획은 모든 영역에서 애플리케이션이 정상 상태인지 확인하고 도구에 대한 투자에 대한 최상의 가치 수익을 창출하기 위한 자체 부과 정책 및 절차 집합입니다.

이러한 제한이 필요한 이유는 무엇인가요? 그것은 당신이 살고있는 집의 유지 보수와 비슷합니다. 고치거나 집에 추가해야 할 때마다 다른 계약자가 나타나서 이전 계약자와 다르게 작업을 수행한다고 상상해 보십시오. 곧 일치하지 않는 창, 다중 디자인 도어 노브 등으로 끝날 수 있습니다. 따라서 빌더는 무언가를 빌드하는 동안 따라야 할 모든 코드와 지침, 유지 관리해야 하는 구성 요소의 표준 등을 수행하는 것이 합리적입니다.

마찬가지로 PPM 솔루션이 라이브 상태이면 몇 가지 변경, 향상된 기능 및 제거 기능이 제공될 예정입니다. 이러한 변경이 수행되는 '방법'에 대한 표준을 설정하지 않는 한, 완전히 혼란에 빠진 솔루션을 안심할 수 있습니다.

거버넌스 영역

PPM 솔루션에 대한 거버넌스 계획을 설정하는 것을 고려할 때 실제로 제어하려는 영역을 고려해야 합니다. 엔터프라이즈 솔루션에 대한 거버넌스 계획을 수립하기 위한 많은 이론과 모델이 있으며 organization 적합한 솔루션을 자유롭게 선택할 수 있습니다. 이 문서에서는 대부분의 PPM 구현에 맞는 이러한 모델 중 하나를 설명합니다.

필요한 거버넌스 영역을 파악하는 가장 간단한 방법은 변경이 발생할 가능성이 있는 영역을 고려한 다음 해당 변경 내용을 관리하기 위한 거버넌스 계획을 설정하는 것입니다.

참고

'변경'이 아닌 항목과 표준 유지 관리(예: 새 사용자 추가, 작업표 기간 업데이트 등)의 경우에도 표준 프로시저 집합을 기록하는 것이 중요합니다.

일반적으로 PPM 솔루션에 대해 변경이 발생할 수 있는 네 가지 주요 영역이 있습니다.

PPM 솔루션의 네 가지 주요 변경 영역은 정보, 디자인, 인프라 및 프로세스입니다.

정보 거버넌스

PPM 솔루션이 구현되면 솔루션에서 좋은 'master' 데이터로 시작한다고 가정하는 것이 합리적입니다. 예를 들어 여기에는 엔터프라이즈 리소스 세부 정보, 엔터프라이즈 일정, 관련 사용자 지정 필드 등이 포함됩니다. 기본적으로 PPM 솔루션을 효과적으로 사용할 수 있는 모든 'master' 데이터입니다. 그러나 솔루션을 계속 사용함에 따라 부서를 변경하고 일부는 organization 나가고, 일정을 새 휴일로 업데이트해야 하며, 보고 기간을 만들어야 하고, 회계 기간을 변경해야 할 수 있으며, 목록이 계속 진행됩니다. 분명히 이 데이터가 업데이트되지 않으면 모든 보고가 정확하지 않으며 보안 구성도 마찬가지입니다.

정보 거버넌스는 이 핵심 데이터인 경우 솔루션의 나머지 부분을 활용할 수 있도록 이 데이터를 업데이트하고 완료하는 책임을 집니다.

디자인 거버넌스

거버넌스 계획의 일부가 되어야 하는 두 번째 영역은 PPM 배포의 "디자인"을 유지 관리하는 것입니다. 솔루션을 계속 사용할 때 솔루션 디자인을 조정하라는 요청이 있을 것입니다. 이러한 문제는 도구를 사용하는 방식을 변경하거나 새 기능을 활용하려는 특정 그룹에서 발생할 수 있습니다. 클래식 예제는 시간 보고가 수행되는 방식을 전환하는 것입니다. % Work Complete 메서드를 선택했을 수 있지만 새 부서가 추가된 경우 다른 재무 솔루션과의 통합을 위해 '기간당 근무 시간' 방법으로 전환해야 할 수 있습니다. 따라서 문제는 솔루션 전체에서 이 변경의 영향을 누가 평가하고 변경 내용이 어떻게 롤아웃될 것인지입니다.

디자인 거버넌스는 PPM 솔루션의 전반적인 디자인에 영향을 주는 변경 내용을 관리하기 위한 계획입니다.

프로세스 거버넌스

대부분의 경우, 프로세스 및 디자인이 진행되므로 이 거버넌스 영역을 디자인 거버넌스의 일부로 생각하기 쉽습니다. 그러나 전체적으로 말하자면, 이 영역은 디자인 그 이상을 다룹니다. PPM 솔루션 내부 및 외부 프로세스의 거버넌스를 해결하여 효율성을 높이는 방법을 설명합니다.

예를 들어 PMO가 매주 수요일 오전에 고위 경영진에게 보고서를 제출해야 하는 시나리오를 사용합니다. 보고가 발생하기 전에 작업표가 매주 금요일마다 특정 시간으로 제출되고 프로젝트 관리자가 월요일 오전까지 프로젝트 계획을 업데이트하고 게시하도록 하는 프로세스를 설정했을 수 있습니다. 이제 고위 경영진이 매주 수요일 오전이 아닌 월요일 오전에 보고서를 보내달라고 요청한다고 가정해 보겠습니다. 이렇게 하면 PPM 솔루션 자체의 디자인이 변경되지 않고 PPM 솔루션이 사용되는 방식에 대한 프로세스의 변경이 트리거됩니다.

이러한 종류의 변경 내용은 프로세스 거버넌스의 일부로 정의된 표준 규칙 집합에 의해 제어되어야 합니다.

인프라 거버넌스

이것은 사일로하기 쉬운 것처럼 보이는 또 다른 영역이지만 위에서 언급 한 다른 세 영역과 겹칠 수 있습니다. 간단히 말해서 PPM 솔루션을 지원하는 인프라는 설치와 함께 유지 관리되어야 합니다. 이러한 종류의 거버넌스 모델에 속해야 하는 주요 항목의 몇 가지 예는 다음과 같습니다.

  • 서비스 팩 또는 누적 업데이트 설치

  • 새 추가 기능 또는 애플리케이션 설치.

  • 성능 문제를 해결하기 위해 인프라 업그레이드(애플리케이션 서버, 웹 서버 등 추가).

  • 조직의 다른 애플리케이션(예: 모든 서버의 가상화)의 변경으로 인해 인프라가 변경되었습니다.

방정식의 한쪽에서 무언가를 설치할지 여부를 결정하는 것은 전적으로 장점을 기반으로 합니다(예: 현재 프로덕션 솔루션에 부정적인 영향을 미치는지 여부). 인프라의 다른 측면은 설치로 인해 발생할 '프로세스' 또는 '디자인' 변경 내용을 살펴보는 것입니다. 경우에 따라 인프라 변경은 다른 영역의 변경으로 인해 발생할 수 있습니다. 앞에서 설명한 것처럼 각 변경 내용을 이러한 영역 중 하나로 분류하려는 시도이지만 일부 변경 내용이 네 영역 모두와 완전히 겹칠 수 있습니다.

주요 질문

설정하려는 거버넌스 영역에 관계없이 거버넌스 계획의 핵심을 형성하는 세 가지 주요 질문에 답해야 합니다.

  • PPM 팀은 변경이 발생해야 한다는 것을 어떻게 알 수 있나요(예: 이러한 변경에 대한 트리거는 무엇인가요?). 경우에 따라 이러한 변경 내용은 그 자체로 '트리거'되지 않지만 PPM 구현에 대한 정기적인 관리 및 공급의 일부입니다(예: 프로젝트 센터에 대한 새 보기 추가).

  • ROI(비즈니스 수익 투자) 관점에서뿐만 아니라 거버넌스 관점에서도 이러한 변경 내용을 승인하는 사람은 누구인가요?

  • 누가 실제로 이러한 변경을 합니까? 이러한 변경 내용의 대부분은 여러 팀이 참여합니다. 일부 조직에서는 일부 변경 기능이 비즈니스 요구 사항에 따라 최종 사용자의 하위 집합으로 전송됩니다. 이러한 종류의 시나리오에서는 실제로 변경 내용을 적용할 사용자를 정의하는 것이 훨씬 더 중요해집니다.

거버넌스 팀

거버넌스 전략의 핵심 구성 요소는 실제로 거버넌스 계획을 작동하는 팀입니다. 이 거버넌스 팀이 어떻게 생겼는지에 대해 슬라이스하고 주사위하는 몇 가지 방법이 있지만, 모든 사고 학교가 동의할 한 가지 권장 사항은 단순하게 유지하는 것입니다.

다음은 팀 구조를 설정하는 한 가지 방법입니다.

거버넌스 영역 소유자 이들은 이 문서에서 앞서 언급한 각 거버넌스 영역의 소유자입니다. 일반적으로 이러한 거버넌스 소유자의 지정된 영역에 영향을 주는 변경 요청은 이러한 소유자의 책임이 됩니다. 평가, 권장 사항 제공, 새 기능에 대한 거버넌스 설정 등이 해당 역할입니다.

CGC(중앙 거버넌스 위원회) 거버넌스 소유자가 권장 사항을 승인하거나 거부할 수 있는 의사 결정자 팀이 됩니다. 중앙 거버넌스 위원회를 갖는 것은 관료를 줄이는 데 도움이 될뿐만 아니라 모든 아이디어를 공통 플랫폼으로 가져 와서 서로를 인식하여 평가하는 데 도움이됩니다.

위에서 설명한 것처럼 구현의 크기와 다른 애플리케이션에 대한 organization 존재하는 현재 프로세스에 따라 이러한 역할의 정의와 구조가 더 작거나 커질 수 있습니다. 중요한 점은 최소 구조체를 배치하는 것입니다.

기타 주요 구성 요소

성공적인 거버넌스 전략의 다른 주요 구성 요소 중 일부는 다음과 같습니다. 하지만 이에 국한되지는 않습니다.

  • 사용자가 변경 내용, 기능 및 기능을 요청할 수 있는 작업 요청 솔루션입니다. 이는 SharePoint 목록이나 현재 사용되는 사내 작업 요청 솔루션만큼 간단할 수 있습니다.

  • IT, 거버넌스, CGC 및 관련된 기타 비즈니스 기능의 검토를 포함하는 변경 내용을 처리하는 프로세스입니다.

  • 실제로 변경 내용을 구현하는 프로세스입니다. 이는 개발에서 테스트, 프로덕션 솔루션으로의 간단한 변경 진행 또는 organization 표준에 따른 본격적인 Release Management 수 있습니다.

프로세스

거버넌스 전략 빌드의 일환으로 위에서 설명한 모든 구성 요소를 가져와서 프로세스를 빌드해 보겠습니다. 여기서는 어떻게 보일지(조직 요구 사항에 따라 달라질 수 있음).

사용자가 요청을 제출하고 거버넌스 위원회를 통해 검토 및 승인을 위해 라우팅되는 방법을 보여 주는 거버넌스 전략 다이어그램

결론

PPM 솔루션에 발생할 수 있는 모든 변경 내용을 예측하고 계획하기는 어렵지만, 모든 시나리오에 유연하고 확장 가능한 속도를 내는 전략을 갖추는 것이 중요합니다.

분할 생각으로 거버넌스 전략을 구축하기 위한 다음과 같은 기본적인 상식적인 접근 방식을 고려해 보세요.

  • 거버넌스 계획은 모호한 용어가 많고 아무도 일상 생활에서 사용할 수 없는 언어가 될 필요는 없습니다. 주요 질문에 대한 빠른 답변(주요 질문에서 해결됨)을 사용하여 Excel 시트만큼 간단할 수 있습니다.

  • 거버넌스 계획은 구성에 대한 설명서가 아닙니다. 구성을 보호, 유지 관리 및 변경하기 위한 "계획"입니다(필요한 경우).

  • 거버넌스 계획은 구현하기 쉬워야 하며 organization 기존 프로세스에 잘 통합되어야 합니다. 휠을 재창조할 필요는 없습니다.

  • PPM 솔루션의 거버넌스는 지속적으로 진화하는 프로세스임을 이해합니다. 분석의 마비에 매달려하지 않는 것이 중요합니다. 작게 시작하고 값을 전달한 다음 스케일 업합니다.

작성자 정보

Prasanna Adavi(PMP, MCTS, MCITP, MCT)는 Microsoft Project, Microsoft Project Server 및 Microsoft SharePoint 플랫폼을 전문으로 하는 EPM(수석 엔터프라이즈 프로젝트 관리) 컨설턴트 및 트레이너입니다. 그의 기본 초점은 조직이 투자 수익률을 가장 잘 달성할 수 있도록 비즈니스 솔루션을 구축하고 가능하게 하는 것입니다.

또한 IT, ERP(SAP), 제조, 애플리케이션 개발, 자동차 및 크리에이티브 서비스를 비롯한 광범위한 도메인 및 수직 분야에서 엔드 투 엔드(end-to-end) 프로젝트를 선도하는 데 있어 광범위한 경험을 보유하고 있습니다. 그는 전국/지역의 다양한 Project Server, EPM 및 SharePoint 이벤트에서 정기 발표자로 활동하며 SharePoint 및 EPM 커뮤니티에 정기적으로 기여자.

Prasanna는 일반 블로거(https://www.prasannaadavi.com)이며 주로 Microsoft Project 및 Project Server 솔루션에 중점을 두고 격주 팟캐스트(https://www.msprojectpodcast.com)를 실행합니다. Prasanna는 EPMA(https://www.epmainc.com)의 선임 컨설턴트입니다.