'슈퍼 마리오'를 해본 적이 있다면 그 순간을 잘 아실 겁니다. 타이머가 점점 줄어들고, 같은 점프를 두 번이나 실패한 상황에서 다시 시도할지, 아니면 다른 경로를 찾을지 결정해야 하는 순간이죠. 결정을 내리고 그 결과에 대처해야 합니다.
프로젝트를 진행하다 보면 비슷한 상황에 직면하게 됩니다. 일이 지연될 경우, 마감일을 연기하거나 추가 인력을 투입하거나 작업 범위를 축소할 수 있습니다. 하지만 이 경우, 여러분의 선택은 다른 사람들의 예산과 업무 약속에 영향을 미칩니다. 따라서 이러한 결정을 내리려면 행동할 수 있는 권한도 필요합니다. 어떤 변경 사항은 본인이 승인할 수 있고, 어떤 변경 사항은 다른 사람의 승인이 필요한지 파악해야 합니다.
프로젝트 거버넌스 프레임워크는 일이 시작되기 전에 이러한 규칙을 설정합니다. 팀이 변경 사항과 승인을 어떻게 처리하는지 보여주는 실제 예시를 통해 프레임워크를 구축하는 방법을 알아보세요.
요약: 프로젝트 거버넌스는 누가 결정을 승인할 수 있는지, 팀이 언제 상급자에게 보고해야 하는지, 그리고 후원자가 프로젝트에 대한 자금 지원이 여전히 타당한지 검토하는 방법을 정의합니다.
승인 담당자를 지정하고, 비용, 일정, 범위, 위험에 대한 한도를 설정하며, 대응 기한을 합의하여 자체 프레임워크를 구축하십시오. 승인 요청 및 결정 사항을 공유 기록에 남기고, 각 프로젝트 단계마다 관련 규칙을 검토하십시오.
위험도가 낮은 프로젝트의 경우, 기본적인 프로젝트 헌장, 승인 한도, 의사결정 기록만으로도 충분할 수 있습니다. 재정적 위험, 의존성 또는 규제 요건이 증가함에 따라 공식적인 검토 및 감독 절차를 추가하십시오.
프로젝트 거버넌스란 무엇인가?
프로젝트 거버넌스는 프로젝트가 승인 단계부터 종료 단계에 이르기까지 조직의 목표와 일관성을 유지하도록 하는 역할, 의사결정 권한 및 통제 수단으로 구성된 체계입니다.
PMI는 거버넌스를 프로젝트 수명 주기 전반에 걸쳐 조직의 거버넌스 모델과 연계되는 감독 기능으로 정의합니다. 간단히 말해, 거버넌스는 방향과 의사결정 규칙을 설정합니다. 프로젝트 관리는 이러한 규칙 내에서 이루어지는 일상적인 계획 수립 및 실행을 담당합니다.
또한 이 프레임워크는 비용, 위험, 예상 이익이 변동함에 따라 프로젝트에 대한 자금 지원이 여전히 타당한지 검토할 주체를 정의합니다. 후원자는 프로젝트의 예상 이익, 비용 및 투자 사유가 기록된 비즈니스 타당성 분석서를 활용하여, 조건이 변화함에 따라 프로젝트를 계속 진행하는 것이 타당한지 평가합니다.
허용 오차 기반 프로젝트 거버넌스는 어떻게 작동할까요?
허용 범위 기반 거버넌스는 합의된 한도 내에서 업무와 타임라인을 관리할 수 있는 여지를 제공합니다. 합의된 한도를 초과할 것으로 예상되는 경우, 지정된 승인자에게 해당 문제를 보고하십시오.
이러한 한도는 특정 플랜에 적용됩니다. 전체 프로젝트, 각 단계, 개별 작업 패키지별로 별도의 한도가 설정될 수 있습니다. 전체 예산이나 기한을 준수한다고 해서 해당 단계의 한도를 초과할 권한이 주어지는 것은 아닙니다.
PRINCE2에서는 이러한 접근 방식을 예외 관리( manage by exception)라고 부릅니다 . 웹사이트 재런칭 과정에서 이 방식이 어떻게 적용될 수 있는지 살펴보겠습니다:
- 승인된 플랜: 테스트 기간은 3주로 하며, 최대 1주일까지 추가 기간이 허용됩니다.
- 예측: 테스트가 절반 정도 진행된 시점에서 QA 팀장은 총 5주가 소요될 것으로 예상하며, 이는 4주라는 한도를 초과하는 것입니다.
- 결정 사항: 출시 일정을 지키기 위해 남은 일을 병행하여 진행할 것을 제안하지만, 이 프로젝트의 규정에 따라 수정된 단계 플랜은 운영위원회의 승인을 받아야 합니다.
남은 일을 병행하여 진행하면 출시 일정을 맞출 수는 있겠지만, 테스트에는 여전히 허용된 4주보다 더 많은 시간이 소요될 것입니다. 즉, 테스트 플랜을 변경하려면 여전히 운영위원회의 승인이 필요합니다. 위원회가 수정된 플랜과 한도를 승인하면, 그 범위 내에서 일상적인 업무를 관리하면 됩니다.
프로젝트 거버넌스 대 프로젝트 관리: 차이점은 무엇일까요?
프로젝트 관리자와 후원자는 동일한 변경 사항을 보고도 서로 다른 문제점을 발견할 수 있습니다.
관리자에게 있어 인계가 지연된다는 것은 일을 완료할 새로운 방법을 찾아야 한다는 것을 의미합니다. 후원자에게는 출시 시기를 늦추는 것이 비즈니스 비용 대비 가치가 있는지 여부를 결정해야 한다는 것을 의미할 수 있습니다. 두 사람 모두 결과에 이해관계가 있지만, 내리는 결정은 서로 다릅니다.
| 차원 | 프로젝트 거버넌스 | 프로젝트 관리 |
|---|---|---|
| 주요 고려 사항 | 이 프로젝트는 여전히 그 비용과 위험을 감수할 만한 가치가 있을까요? | 팀은 합의된 결과를 어떻게 달성할 수 있을까요? |
| 누가 주도하는가 | 스폰서 또는 운영위원회, 필요 시 PMO의 지원 | 프로젝트 매니저 및 실행 팀 |
| 일반적인 의사결정 사항 | 자금 조달, 주요 변경 사항, 단계별 승인, 그리고 프로젝트 지속 여부 | 합의된 한도 내에서의 작업 순서, 인력 배치, 일정 및 수정 사항 |
| 주요 기록 | 비즈니스 타당성 분석, 승인 규칙 및 의사결정 기록 | delivery 플랜, 일정, 작업 보드 |
여러 프로젝트에 걸쳐 프로젝트 관리 사무소(PMO)는 공유된 보고 및 승인 기준을 설정할 수 있습니다. 그렇다고 해서 PMO가 모든 자금 조달이나 범위 결정에 대한 권한을 갖는 것은 아닙니다. PMO 거버넌스 프레임워크에 대한 본 가이드에서는 PMO의 더 광범위한 역할을 설명합니다.
프로젝트 거버넌스 프레임워크의 구성 요소는 무엇인가요?
해롤드 커즈너(Harold Kerzner)의 프로젝트 관리 2.0에 설명된 바와 같이, 프로젝트 거버넌스는 조직 구조, 인력, 정보라는 세 가지 핵심 기둥 위에 세워져 있습니다. 구조는 보고 체계와 승인 절차를 다루며, 인력은 역할과 의사결정 권한을 가지고, 정보는 의사결정에 필요한 근거를 제공합니다.
이러한 핵심 요소를 실무에 적용하기 위해, PMI 컨퍼런스 논문에서는 상황에 맞게 조정할 수 있는 8가지 거버넌스 구성 요소를 제시합니다. 아래 체크리스트는 각 구성 요소가 다루는 내용과 유지 관리해야 할 기록 또는 프로세스를 보여줍니다.
| 구성 요소 | 답변해야 할 질문 | 구축을 위해 기록해 두세요 |
|---|---|---|
| 거버넌스 모델 | 이 프로젝트에는 어느 정도의 감독이 필요할까요? | 헌장이나 거버넌스 플랜에 문서화된 합의된 접근 방식 |
| 책임과 의무 | 일의 책임자는 누구이며, 누가 결정을 승인할 수 있습니까? | RACI 매트릭스와 서면 의사결정 권한 |
| 이해관계자 참여 및 의사소통 | 누가 영향을 받으며, 어떻게 그들의 참여를 이끌어낼 것인가? | 이해관계자 지도 및 커뮤니케이션 플랜 |
| 회의 | 어떤 결정에는 회의가 필요하며, 누가 참석해야 할까요? | 회의 목적, 참석자, 의사결정 권한을 명확히 정의 |
| 보고 | 의사결정권자는 무엇을, 언제 알아야 할까요? | 보고 일정, 상태 보고서 및 예외 보고서 |
| 위험 및 문제 관리 | 우려 사항을 어떻게 평가하고, 언제 상급자에게 보고할지 어떻게 결정하시겠습니까? | 소유자와 에스컬레이션 기준을 명시한 리스크 레지스터 또는 RAID 로그 |
| 보증 | 전달 및 보고가 신뢰할 수 있는지 어떻게 확인할 계획입니까? | 검토 기준, 성과 지표 및 검증 절차를 살펴보세요. |
| 통제 프로세스 | 성과를 어떻게 추적하고, 승인된 플랜에 대한 변경 사항은 어떻게 처리할 계획입니까? | 합의된 기준선, 허용 한도 및 변경 관리 프로세스 |
승인 절차와 관련하여, 기록 내용이 단순히 업무 배정에만 그치지 않는지 확인하십시오. RACI 매트릭스는 결과물에 대한 책임 소재를 보여줄 수는 있지만, 추가 지출이나 마감일 연장을 누가 승인할 수 있는지는 반드시 명시하지는 않습니다. 해당 권한을 의사결정 권한에 기록한 다음, 변경 관리 프로세스를 통해 요청 사항이 승인자에게 전달되는 방식을 정의하십시오.
또한 위험과 문제를 구분해야 합니다. 위험은 발생할 가능성이 있는 반면, 문제는 이미 존재하는 것입니다. 공급업체의 잠재적 지연은 위험에 해당합니다. 납기 미준수는 대응이 필요한 문제입니다. 위험 등록부 템플릿과 문제 로그를 통해 이를 추적하거나, 별도의 범주와 소유자가 지정된 RAID 로그를 활용하십시오.
전문가 팁: ‘RACI 대 RAID’ 가이드에서는 RAID가 위험, 가정, 문제, 의존성을 하나의 기록으로 통합하는 방법을 설명합니다.
프로젝트 거버넌스의 책임은 누구에게 있습니까?
일반적으로 프로젝트 후원자는 사업 타당성 분석을 주도하며, 프로젝트의 가치에 대한 책임을 집니다. 프로젝트 관리자는 합의된 한도 내에서 성과를 달성하며, 필요에 따라 운영위원회나 PMO가 감독 역할을 수행합니다.
필요한 역할은 프로젝트의 복잡성과 위험도에 따라 달라집니다. 소규모 프로젝트의 경우 후원자와 프로젝트 관리자만 있으면 충분할 수 있습니다. 여러 부서에 걸쳐 진행되는 일의 경우, 상충되는 우선순위를 해결하고 주요 변경 사항을 검토하기 위해 운영위원회가 필요할 수도 있습니다.
| 역할 | 주요 책임 | 권한의 한도 |
|---|---|---|
| 프로젝트 후원자 | 비즈니스 타당성을 수립하고, 자금을 확보하며, 프로젝트를 계속 진행해야 할지 여부를 검토합니다. | 권한 범위를 벗어난 결정의 경우 더 높은 수준의 승인이 필요합니다. |
| 운영위원회 | 주요 예외 사항을 검토하고, 팀 간 갈등을 해결하며, 키 의사결정을 이끌어냅니다. | 위임된 권한 범위 내에서만 변경을 승인할 수 있습니다. |
| PMO | 거버넌스 기준을 수립하고, 보고를 지원하며, 합의된 프로세스 준수 여부를 점검합니다. | 승인 권한은 그 권한 범위에 따라 달라집니다. |
| 프로젝트 매니저 | 약정된 한도 내에서 프로젝트 수행을 플랜하고, 자원을 조정하며, 의사결정을 내립니다. | 자신의 권한을 초과하는 사안을 상급자에게 보고합니다 |
| 프로젝트 팀 및 업무 흐름 책임자 | 할당된 일을 수행하고, 위험 요소를 제기하며, 대응 방안을 제안하십시오. | 사전 합의된 절차를 통해 자신의 권한 범위를 벗어난 결정을 상급자에게 보고하십시오. |
운영위원회에 요청을 보내기 전에, 해당 위원회가 변경 사항을 승인할 권한이 있는지, 아니면 단지 권고만 할 수 있는지 확인하십시오. 예를 들어, 위원회는 데이터 품질 문제를 해결하기 위해 3만 달러의 추가 예산을 지원할 수는 있지만, 최종 지출 결정권은 CFO에게 있을 수 있습니다. 이 경우, 자금을 커밋하기 전에 여전히 CFO의 승인을 받아야 합니다.
이러한 경계를 프로젝트 헌장이나 거버넌스 계획서에 문서화하고, 해결되지 않은 의견 불일치가 최종 결정을 위해 어디로 이관되는지도 명시하십시오. 긴급한 요청의 경우, 해당 결정에 대한 위임된 권한을 가진 백업 승인자를 지정하십시오.
6단계로 프로젝트 거버넌스 프레임워크 구축하는 법
프로젝트 헌장과 승인된 플랜부터 시작하여, 다음 단계를 통해 실행 과정에서 따를 규칙을 정의하십시오.
1단계: 승인이 필요할 수 있는 의사결정 사항 파악하기
프로젝트의 자금 조달, 범위,delivery, 또는 기대되는 혜택에 영향을 미칠 수 있는 의사결정 사항을 목록으로 나열하십시오. 다음 단계 착수 권한과 같은 계획된 승인 절차와, 비즈니스 사례 변경 시 프로젝트를 계속 진행할지 여부와 같은 변경 사항에 의해 트리거되는 의사결정 사항을 포함하십시오.
각 의사 결정에 대해 다음 사항을 기록하십시오:
- 트리거: 의사결정이 필요하게 되는 조건
- 근거: 대안을 평가하는 데 필요한 정보
- 마감일: 선택지가 좁아지거나 결과물 제공에 차질이 생기기 전에 결정을 내릴 수 있는 가장 늦은 시점
일상적인 작업 결정은 해당 작업을 관리하는 담당자들에게 맡기십시오.
더 읽어보기: 프로젝트 헌장 작성 방법 (예시 포함)
2단계: 비용, 일정, 범위 및 위험에 대한 허용 한도 설정
허용 오차는 기존 권한 범위 내에서 결과가 승인된 플랜과 얼마나 달라질 수 있는지를 정의합니다. 일이 시작되기 전에 후원자나 관리 기관과 이러한 한도에 대해 합의하십시오.
귀하의 프로젝트는 420,000달러의 승인된 예산을 가지고 있습니다. 후원자는 5%의 비용 허용 오차를 설정하고, 귀하에게 21,000달러의 추가 지출을 승인하여 총 지출 한도를 441,000달러로 늘렸습니다. 440,000달러의 예측 비용은 승인된 한도 내에 있습니다. 예측 비용이 448,000달러로 증가할 경우, 추가 지출을 커밋하기 전에 후원자의 승인을 받아야 합니다.
다른 한도들도 마찬가지로 명확하게 정의하십시오:
- 일정: 승인이 필요해지기 전까지 완료 일정을 얼마나 조정할 수 있는지
- 범위: 본인의 권한 범위 내에서 어떤 요구사항이나 산출물을 변경할 수 있는지
- 위험: 수용 가능한 위험 수준과 즉각적인 검토가 필요한 이벤트
각 허용 한도를 해당 플랜과 연계하십시오. 위험 관리 플랜은 위험 임계값을 설정하는 데 도움이 될 수 있습니다. 프로젝트에 따라 품질, 이점 또는 지속 가능성에 대한 명확한 한도가 필요할 수도 있습니다.
3단계: 지정된 담당자에게 의사결정 권한을 부여하기
결정 목록으로 돌아가 각 항목에 대한 승인자를 지정하십시오. 그런 다음 누가 권고안을 작성할지, 그리고 누구의 의견이 필요한지 파악하십시오.
다음과 같은 책임들을 구분하십시오:
- 제안 소유자: 근거를 수집하고, 대안을 평가하며, 대응 방안을 제안합니다.
- 승인자: 위임된 권한 범위 내에서 제안서를 승인하거나 거부합니다.
- 자문을 구한 대상: 전문 지식을 제공하거나 해당 결정이 자신의 일에 어떤 영향을 미칠지 설명해 준 사람들
위원회 의사결정의 경우, 합의가 어떻게 도출되었는지와 누가 그 결과를 기록하는지를 문서화하십시오. 또한 권한을 위임받은 백업을 지정하고, 해당 백업이 언제 개입할 수 있는지에 대한 명확한 규칙을 마련하십시오.
4단계: 에스컬레이션 절차 및 대응 시간 정의
에스컬레이션 시에는 승인자가 결정을 내릴 수 있도록 충분한 정보를 제공해야 합니다. 다음 내용을 포함하는 간결한 예외 보고서를 활용하십시오:
- 합의된 한도 및 최신 예측
- 프로젝트에 미칠 것으로 예상되는 영향
- 가능한 옵션 및 귀하의 권장 사항
- 결정 마감일
조치를 취해야 하는 시점을 기준으로 응답 기한을 설정하세요. 공급업체가 금요일까지 답변을 필요로 한다면, 목요일까지 승인을 요청하면 결정 사항을 실행할 시간을 확보할 수 있습니다.
또한, 마감 기한을 지키지 못할 경우 어떻게 처리할지 결정하십시오. 다음 담당자를 지정하고, 영향을 받는 작업이 중단되어야 하는지 여부를 명시하십시오. 이 에스컬레이션 매트릭스 템플릿은 프로젝트의 승인 절차에 맞게 조정할 수 있는 기본 레이아웃을 제공합니다.
5단계: 미결정 사항을 쉽게 찾을 수 있도록 하기
승인자에게 검토가 필요한 요청 사항에 대한 통합된 보기를 제공하십시오. 각 입력에는 결정이 필요한 사항, 담당자, 마감일이 표시되어야 합니다. 예외 사항의 경우, 예측과 위험에 노출된 한도를 포함하십시오. 승인자가 추정치, 영향 및 대안을 검토할 수 있도록 요청 사항에 관련 증빙 자료를 연결해 두십시오.
이 프로젝트 대시보드 예시와 같은 실시간 보기를 활용하면 조건이 변함에 따라 요청 사항을 추적하는 데 도움이 됩니다. 정기적인 현황 보고서를 통해 마일스톤과 진행 상태를 다룰 수는 있지만, 승인 요청을 작업 업데이트 속에 묻히게 해서는 안 됩니다.
마감일, 장애 요인, 메트릭을 한 보기에 모아 보여주는 프로젝트 대시보드를 15분도 채 걸리지 않아 구축할 수 있습니다. 시작하는 데 도움이 될 간단한 안내를 소개합니다:
6단계: 의사결정 사항 기록 및 프레임워크 검토
각 결정이 내려질 때마다 승인자, 날짜, 검토된 대안, 근거 및 후속 조치를 포함하여 해당 내용을 기록하십시오.
승인을 위해서는 예산, 일정 또는 범위 기준선의 업데이트가 필요할 수 있습니다. 변경 관리 절차를 통해 이러한 변경 사항을 반영하고, 수정된 기록을 의사결정 로그에 연결한 후, 영향을 받는 모든 구성원에게 현재 어떤 플랜에 따라 일을 해야 하는지 알려주십시오.
각 단계별 검토 시, 해당 프레임워크가 적시에 의사결정을 내리는 데 도움이 되었는지 평가해 보십시오:
- 조치가 필요해지기 전에 승인 담당자가 대응했습니까?
- 책임 범위와 승인 한도가 명확했습니까?
- 일상적인 변경 사항이 불필요한 상급 보고의 트리거가 된 적이 있습니까?
- 중요한 우려 사항이 너무 늦게 제기된 적이 있었나요?
이 답변들을 바탕으로 프레임워크에 대한 변경 사항을 제안하십시오. 수정된 허용 범위나 의사결정 권한 역시 승인이 필요합니다. 합의가 이루어지면, 다음 단계가 시작되기 전에 커뮤니케이션 플랜을 통해 이를 공유하십시오.
여러분의 프로젝트에는 어느 정도의 거버넌스가 필요할까요?
이 6단계는 모든 프로젝트에 적용되지만, 감독 수준은 프로젝트의 비용, 위험, 의존성, 그리고 잘못된 결정이 초래할 결과에 맞춰 조정되어야 합니다. PRINCE2에서는 이를 프로젝트에 맞게 조정이라고 부릅니다 .
예를 들어, 단일 팀이 진행하는 시범 프로젝트의 경우 후원자와 명확한 승인 절차만 있으면 충분할 수 있습니다. 하지만 결제 데이터를 다루기 시작하면, 팀의 크기가 변하지 않았더라도 공식적인 보안 검토가 필요할 수 있습니다.
아래 테이블은 여러분의 설정 방식을 선택하는 데 있어 출발점이 될 것입니다. 테이블에 제시된 크기는 팀 인원 수나 프로젝트 기간에 기반한 고정된 규칙이 아닌, 예시로만 참고하시기 바랍니다.
| 크기 | 전형적인 프로필 | 거버넌스 역할 | 보고 | 통제 수단 |
|---|---|---|---|---|
| 소규모 | 단일 팀, 저위험 업무, 적은 의존성 | 발주자 및 프로젝트 관리자 | 사전에 합의된 시점에 간략한 진행 상황을 보고하고, 예외 사항이 발생하면 즉시 보고하십시오. | 승인 한도 및 간단한 의사결정 기록 |
| Medium | 여러 팀 또는 공급업체, 공유 자원, 비즈니스에 미치는 영향이 중간 수준인 경우 | 발주자, 프로젝트 관리자, 그리고 필요한 경우 운영위원회 | 정기적인 진행 상황 검토; 필요 시 예외 요청 | RACI, 위험 로그, 변경 승인, 단계별 검토 |
| 대규모 | 높은 재정적 위험, 복잡한 의존성 또는 규제 대상 일 | 후원자, 운영위원회, PMO 또는 필요에 따른 독립적인 검증 기구 | 빈번한 진행 상황 검토 및 신속한 상신 | 공식적인 단계별 심사, 변경 관리, 감사 추적, 그리고 필요한 경우 독립적인 점검 |
의사결정권자에게 행동에 필요한 충분한 정보와 권한을 부여하면서도 설정이 가장 간결한 방식을 목표로 하십시오. 선택한 방식을 프로젝트 헌장에 명시하고, 범위나 위험이 변경될 경우 이를 재검토하십시오.
실무에서의 프로젝트 거버넌스: 맨체스터 대학교의 CRM 도입 사례
맨체스터 대학교의 그래핀 엔지니어링 혁신 센터(Graphene Engineering Innovation Centre)는 문의 사항을 추적하고 고객 온보딩을 관리할 CRM이 필요했습니다. CEO가 프로젝트를 발족했고, 비즈니스 개발 이사가 프로젝트 위원회를 이끌었으며, 프로젝트 매니저인 네이선 럼(Nathan Lumb)이 프로젝트 수행을 총괄했습니다.
팀은 소프트웨어 비용 상한선을 사용자 1인당 월 20파운드로 설정하고, 최대 50명의 사용자에 대한 지원을 요구했습니다. 공개된 사례 연구에서는 승인 절차와 단계별 검토가 일 진행에 어떤 영향을 미쳤는지 설명하고 있습니다:
- 구매 전에 요구 사항을 정의하세요. Lumb은 승인을 받기 위해 프로젝트 개요서와 플랜 초안을 준비했습니다. 이후 이해관계자들은 팀이 CRM을 도입하기 전에 고객 온보딩 절차에 대해 합의했습니다.
- delivery를 위한 체크포인트를 설정하세요. 팀은 조달, 구성, 테스트, 배포 및 인계 과정을 단계별로 구성했습니다. 이해관계자들은 플랜을 검토하고 보고 방식 및 작업 패키지에 대해 합의했습니다.
- 승인 지연을 해결하세요. 이해관계자들 간의 의견 충돌로 인해 절차에 대한 합의가 지연되었습니다. 럼브는 결정을 도출하기 위해 피드백 및 승인 마감 기한을 설정했습니다.
- 보안 검토를 처리하세요. IT 부서는 클라우드 기반 시스템의 보안에 의문을 제기하여 조달 승인 절차를 지연시켰습니다. 팀은 IT 부서의 질문에 답변하고 승인을 기다렸습니다. 프로젝트 관리자는 해당 대응이 이사회가 이미 승인한 플랜 범위 내에 있었기 때문에, 단계별 계획 수정을 요청하지 않고 이 문제를 직접 처리했습니다.
- 도입 과정에서 피드백을 활용하세요. 제공자의 느린 대응으로 인해 사용자들은 답변을 기다려야만 했습니다. 팀은 교훈 기록부를 관리하고, 매주 답변을 공유하며, 추가 교육을 제공했습니다.
감독에 더 확실한 근거가 필요할 때: 크로스레일
크로스레일(Crossrail) 사례는 또 다른 거버넌스 문제를 보여줍니다. 리더들은 공식적인 감독 권한은 가지고 있었지만, 현실적인 실행 플랜이 부족했습니다.
국가감사원의 2019년 보고서에 따르면:
- 2010년: 발표된 자금 지원 규모는 148억 파운드였습니다.
- 2015년부터: 문제가 나타나기 시작했지만, 프로그램은 플랜에 따라 2018년 12월 중앙 구간 개통을 향해 계속 일했습니다.
- 2018년 8월: 크로스레일(Crossrail)은 개통 예정일을 지키지 못할 것이라고 발표했습니다.
- 2018년 12월: 자금 지원 규모가 176억 파운드로 증가했으며, 이는 2010년 수준보다 28억 파운드 많은 금액입니다.
NAO는 추가 비용의 원인으로 일정이 지나치게 촉박한 점, 계약상의 문제, 그리고 현실적인 플랜의 부재를 지적했습니다. NAO의 결론은 명확했습니다. 크로스레일 측은 “원래 일정대로 프로젝트를 완료할 수 있다는 비현실적인 보기를 고수했다”는 것이었습니다.
핵심 요점: 맨체스터 대학교의 예시는 합의된 단계와 승인 절차가 프로젝트 수행을 어떻게 이끄는지 보여줍니다. 크로스레일(Crossrail) 예시는 이러한 통제 절차에 신뢰할 수 있는 예측이 필요한 이유를 보여줍니다. 보고된 일정이 비현실적이라면 의사결정자는 플랜을 계속 진행할지 여부를 판단할 수 없기 때문입니다.
애자일 팀에서 프로젝트 거버넌스는 어떻게 작동할까요?
애자일 팀은 학습 과정에서 우선순위를 조정할 여지가 필요합니다. 거버넌스는 팀이 그러한 선택을 할 수 있는 범위 내에서 목표, 자금 지원, 승인 한도를 정의합니다.
스크럼(Scrum)에서는 제품 소유자(Product Owner)가 제품 백로그(Product Backlog)의 우선순위를 정하고, 개발자들은 각 스프린트(Sprint)에 선정된 작업을 어떻게 전달할지 플랜을 세웁니다. 스프린트 리뷰( Sprint Review) 동안 스크럼 팀과 이해관계자들은 결과물을 검토하고 향후 진행 방향에 대해 논의합니다.
이러한 논의를 통해 변화하는 비즈니스 요구 사항이나 제품 목표에 대한 위험 요소를 파악할 수 있습니다. 그러나 스프린트 리뷰는 추가 자금 승인이나 팀의 권한을 벗어난 변경 사항에 대한 승인을 대체하지는 않습니다.
예를 들어, 사용자 피드백에 따르면 앱의 결제 과정이 혼란스럽다는 사실이 드러났습니다. 제품 소유자는 결제 과정 개선 사항을 백로그에서 더 상위로 이동시킬 수 있습니다. 만약 해당 변경 사항에 추가 자금이 필요하거나, 합의된 한도를 초과하게 될 경우, 팀은 프로젝트 거버넌스 절차를 통해 승인을 받아야 합니다.
프로젝트 거버넌스에서 흔히 저지르는 실수와 해결 방법
승인을 받았다고 해서 실행이 항상 순조롭게 진행되는 것은 아닙니다. 검토자는 근거에 있는 빈틈을 놓치거나, 사용자의 우려 사항을 간과하거나, 눈에 띄지 않는 조건을 달아 일을 승인할 수도 있습니다.
프레임워크를 실제로 적용할 때 다음 다섯 가지 실수를 주의하십시오:
| 실수 | 해결 방법 |
|---|---|
| 단계별 검토가 형식적인 절차로 전락합니다 | 사용자 테스트 통과 및 중대한 결함 해결 등 다음 단계로 진행하기 위한 명확한 요건을 설정하십시오. 검토자는 작업을 승인할지, 조건부 승인할지, 아니면 미비 사항이 해결될 때까지 보류할지 결정해야 합니다. |
| 사용자 의견 수렴이 너무 늦게 이루어집니다 | 결과물을 사용하거나 관리할 담당자들을 설계 및 승인 검토 과정에 참여시키십시오. CRM 도입의 경우, 설계 승인 전에 영업 팀에 워크플로우와 데이터 필드를 확인하도록 요청하십시오. 해결되지 않은 문제점을 기록하고, 이에 대응할 담당자를 지정하십시오. |
| 전체 상태가 ‘녹색’으로 표시되어 있어 워크스트림의 문제가 가려집니다 | 요약 평가 점수만 보지 마십시오. 프로젝트가 일정대로 진행되고 있어도 중요한 통합 테스트에서 실패할 수 있습니다. 주요 업무 흐름을 별도로 보고하고, 각 상태를 지원할 근거를 제시하십시오. |
| 조건부 승인은 완전한 승인으로 간주됩니다. | 각 조건과 소유자, 해결 기한을 기록하십시오. 어떤 일을 진행할 수 있고 어떤 일을 보류해야 하는지 명시한 다음, 해당 일이 영향을 받는 부분이 해결되었는지 확인한 후에야 일을 진행하십시오. |
| 인계 후 혜택이 제대로 추적되지 않습니다 | 프로젝트 종료 후 결과를 측정하고 후원자에게 보고할 소유자를 지정하십시오. 측정 지표, 검토 일정, 그리고 결과가 기대에 미치지 못할 경우 취할 조치에 대해 합의하십시오. |
ClickUp에서 프로젝트 거버넌스를 운영하는 방법
예측치가 합의된 한도를 초과할 경우, 후원자에게는 단순한 경고 이상의 정보가 필요합니다. 예상되는 영향, 대안, 그리고 결정 기한이 필요합니다. ClickUp을 사용하면 해당 요청을 관련 증거 자료 및 영향을 받는 프로젝트 작업과 함께 관리할 수 있습니다.
승인 규칙을 일 현장에 가깝게 적용하십시오
ClickUp 거버넌스 플랜 템플릿부터 시작해 보세요. 이 템플릿에는 ‘역할 및 책임’ 보기와 승인 절차에 맞게 조정할 수 있는 ‘결정 권한’ 맞춤형 필드가 포함되어 있습니다.
ClickUp Docs를 사용하여 허용 범위, 에스컬레이션 경로 및 대응 시간을 문서화하세요. 플랜을 승인 작업에 연결하여 검토자가 각 요청의 근거가 되는 규칙을 확인할 수 있도록 하세요.
예외 사항을 승인 요청으로 전환하세요
이를 바탕으로 예외 상황에 대한 워크플로우를 설정할 수 있습니다. 2단계의 예시를 적용해 보겠습니다. 이 예시에서 프로젝트 관리자는 최대 441,000달러까지의 지출을 승인할 수 있습니다.
- 예측 비용 추적: 프로젝트 작업에 ‘숫자’ 또는 ‘금액’ 사용자 정의 필드를 추가하여 예상 총 비용을 기록하세요.
- 예외 처리: 프로젝트 작업에 ‘승인 필요’ 드롭다운 메뉴를 추가하세요. 프로젝트 관리자가 441,000달러를 초과하는 예측 비용을 승인을 위해 표시하면, ClickUp 자동화 기능을 사용하여 해당 작업을 후원자에게 할당하고 상태를 ‘승인 대기 중’으로 변경하세요.
- 요청 사항 검토: 공급업체의 견적서와 제안된 옵션을 해당 작업에 연결하십시오. 후원자는 관련 자료를 검토하고, 결정을 기록하며, 후속 작업을 할당할 수 있습니다.
스폰서에게 미결정 사항에 대한 보기를 제공하십시오
지속적인 모니터링을 위해 ClickUp 대시보드를 활용하면 모든 정보를 한 보기에 통합할 수 있습니다. ‘계산’ 카드를 사용하여 예측 비용을 표시하고, ‘작업 목록’ 카드를 통해 승인 대기 중인 항목만 필터링하여 표시하세요. 소유자, 마감일 및 관련 사용자 지정 필드를 표시하면, 후원자가 각 요청을 열어 세부 내용을 검토할 수 있습니다.
승인된 변경 사항이 프로젝트 진행에 영향을 미칠 경우, 프로젝트 관리자는 해당 결정의 근거를 유지한 채 관련 작업과 일정을 업데이트할 수 있습니다.
규모가 작은 프로젝트의 경우, 거버넌스 플랜과 공유 승인 목록만으로도 충분할 수 있습니다. 요청 건수가 늘어남에 따라 자동화 기능과 대시보드를 추가하세요.
ClickUp 요금제
ClickUp 사용자들은 어떻게 말하고 있을까요?
Savills에서는 지역 IT 팀이 아시아 14개 지역 전반에 걸쳐 소프트웨어 출시, 인프라 프로젝트 및 공급업체의 납품을 총괄합니다.
이전: 프로젝트 관리자들은 각국에서 최신 정보를 수집하여 약 20개의 파워포인트 프레젠테이션을 통합해 월간 CIO 보고서를 작성했습니다. 경영진은 이 보고 주기에 의존해 통합된 보기를 파악했습니다.
ClickUp을 활용하면: 공유된 프로젝트 기록이 실시간 CIO 대시보드에 직접 반영됩니다. 경영진은 어떤 프로젝트가 순조롭게 진행되고 있고 어떤 프로젝트에 주의를 기울여야 하는지 파악할 수 있으며, 팀원들은 요청, 변경 사항, 문제점에 대한 동일한 기록을 바탕으로 업무를 수행할 수 있습니다.
결과: 10명으로 구성된 프로젝트 팀은 작업 논의 과정에서 공급업체의 문의 사항과 업무 인계를 처리함으로써 매달 50시간 이상을 절약합니다. 프로젝트 관리자는 시간대 간 조율 및 보고서 작성에 소요되는 시간을 줄일 수 있으며, 경영진은 포트폴리오에 대한 최신 현황을 파악할 수 있습니다.
적합한 대상: 빈번한 변경 요청 및 승인을 관리하는 다기능 팀으로, 후원자가 팀 간에 업데이트를 일일이 확인하지 않고도 프로젝트 예측, 관련 기록 및 의사결정 내역을 확인할 수 있어야 하는 경우.
다음과 같은 경우에는 건너뛰세요: 공식 감사 및 규제 통제를 위해 전용 거버넌스·리스크·컴플라이언스(GRC) 시스템이 필요한 경우, 또는 프로젝트 규모가 작아 기본 헌장과 의사결정 기록만으로도 관리할 수 있는 경우.
어떤 수준의 거버넌스를 구축해야 할까요?
단일 팀이 담당하고 명확한 의사결정자가 있는 소규모의 저위험 프로젝트의 경우, 기본적인 헌장, 승인 한도, 의사결정 기록만으로도 충분할 수 있습니다. 별도의 운영위원회나 상세한 거버넌스 플랜은 필요하지 않습니다.
의사결정이 여러 부서에 걸쳐 있거나, 상당한 비용이 수반되거나, 규제 의무에 영향을 미치거나, 막대한 비용이 드는 지연을 초래할 수 있는 경우에는 보다 공식적인 프로젝트 거버넌스 프레임워크를 활용하십시오. 작업에 착수하기 전에 승인자를 지정하고, 에스컬레이션 기준을 설정하며, 검토 시점을 합의하십시오.
ClickUp을 사용하면 승인 요청, 증빙 자료, 기록된 결정 사항을 프로젝트와 함께 관리할 수 있으므로, 팀은 무엇이 승인되었고 그 이유가 무엇인지 추적할 수 있습니다.
프로젝트 거버넌스에 관한 자주 묻는 질문
프로젝트 거버넌스와 프로젝트 보증의 차이점은 무엇일까요?
프로젝트 거버넌스는 누가 의사결정을 내리는지와 그들에게 부여된 권한을 정의합니다. 프로젝트 보증은 계획, 보고서, 통제 수단이 해당 의사결정권자들에게 신뢰할 수 있는 정보를 제공하는지 확인합니다. 예를 들어, 독립적인 보증 검토를 통해 운영위원회가 결정을 내리기 전에 프로젝트가 시작될 준비가 되어 있는지 평가할 수 있습니다.
프로젝트 거버넌스가 효과적인지 어떻게 측정할 수 있을까요?
승인 결정에 걸리는 시간, 결정 마감 기한을 놓치는 빈도, 단계별 검토에서 합의된 조치가 제때 완료되는지 여부를 추적하세요. 또한 필요한 승인 없이 변경 사항이 진행되는 빈도도 확인할 수 있습니다. 프로젝트 단계 전반에 걸쳐 이러한 추세를 검토하여 거버넌스가 팀이 시기적절하고 정보에 입각한 결정을 내리는 데 도움이 되고 있는지 확인하세요.
프로젝트 도중 프로젝트 후원자가 물러난다면 어떻게 될까요?
조직은 임시 또는 대체 스폰서를 임명하고, 해당 인물의 의사결정 권한을 확정해야 합니다. 그러면 프로젝트 관리자는 비즈니스 사례, 현재 위험 요소, 대기 중인 승인 사항, 자금 지원 약속 등에 대해 해당 스폰서에게 브리핑할 수 있습니다. 권한이 공식적으로 이양되기 전까지는 팀이 다른 임원이 동일한 결정을 승인할 수 있다고 가정해서는 안 됩니다.
프로젝트 거버넌스는 외부 공급업체와 어떻게 연계되어 운영되나요?
외부 공급업체는 계약 범위 내에서 위험을 보고하고, 변경 사항을 제안하며, 일을 관리할 수 있습니다. 그러나 합의된 비용, 범위 또는 납품 조건에 대한 변경은 계약상의 변경 관리 절차와 조직의 승인 규정을 따라야 합니다. 공급업체의 일이 시작되기 전에 누가 납품물을 수락하고, 계약 변경을 승인하며, 분쟁을 해결할 수 있는지 명확히 정의하십시오.
프로젝트 마일스톤과 스테이지 게이트의 차이점은 무엇인가요?
마일스톤은 사용자 테스트 완료와 같이 중요한 이벤트나 완료된 산출물을 의미합니다. 스테이지 게이트는 권한을 부여받은 이해관계자들이 증거 자료를 검토하고 프로젝트 진행 여부를 결정하는 의사결정 지점입니다. 마일스톤에 도달했다고 해서 다음 단계가 자동으로 승인되는 것은 아닙니다.