주제 5.1 — 프로젝트 중심 업무

한 문장으로: 프로젝트 중심 업무는 일이 정의된 범위, 유한한 수명, 명확한 최종 상태를 가질 때 맞는 도구로서, 합의된 시간, 비용, 품질에 맞춰 납품되고 종결되는 일시적이고 통제된 노력이다.

보건·돌봄에서 이것이 중요한 이유#

모든 것이 살아 있는 서비스는 아니다. 보건·돌봄의 가장 중요한 업무 중 일부는 진정으로 유한하다. 한 전자 환자 기록에서 다른 기록으로 이전하기, 병원 자산 전체에 Wi-Fi 도입, 수명이 끝난 서버 교체, 공급업체 계약이 끝나기 전 레거시 시스템 폐기, 새 병원 건설의 디지털 요소 납품이다. 이 일에는 시작, 중간, 명확한 끝이 있다. 이를 끝없는 제품으로 관리하면 돈을 낭비하고 책임을 흐린다. 프로젝트의 규율이 필요하다.

프로젝트 관리는 위험이 높고 제약이 단단하기 때문에 바로 여기서 값을 한다. 데이터 이전 전환에는 고정된 가동 주말이 있고, 기록이 분실되거나 손상되면 환자 안전 위험이 있으며, 옛 시스템이 꺼지면 계약상의 절벽이 있다. 공적 자금은 비즈니스 케이스에 따라 투입되고, 의회, 감사관, 이사회는 승인된 대로 쓰였는지 물을 것이다. 프로젝트 중심 업무는 이사회가 확신을 갖고 자본을 약속하고 정당화가 사라지면 깔끔하게 중단할 수 있게 하는 거버넌스, 곧 비즈니스 케이스, 단계 관문, 통제된 종결을 제공한다.

위험은 이 도구를 잘못된 일에 쓰는 것이다. 진화하는 디지털 서비스에 적용된 프로젝트 중심 거버넌스는 주제 5.0 — 제품 중심 업무에서 설명한 "만들고 방치하기"의 병리를 낳는다. 이 주제는 프로젝트 중심 업무가 맞는 도구인 곳과 그 한계가 시작되는 곳을 설명한다. 여러 프로젝트를 조율하는 주제 5.2 — 프로그램 중심 업무, 그리고 이 도구들 사이에서 선택하는 주제 5.3 — 전사 프로젝트 포트폴리오 관리(EPPM)와 나란히 놓인다.

핵심 개념#

프로젝트. 시간, 비용, 품질의 제약 안에서 합의된 명세에 맞춰 하나 이상의 정의된 산출물을 납품하려고 만들어진 일시적 조직. 정의하는 특징은 일시적이라는 것이다. 정의된 끝에 이르러 해산하려고 존재한다.

철의 삼각형(범위, 시간, 비용). 고전적 제약 모델. 범위, 일정, 예산은 서로 의존하며 품질은 이들이 어떻게 균형 잡히는지에 영향받는다. 하나를 바꾸면 다른 것이 바뀌며, 프로젝트 통제는 대체로 이 상충 관계를 투명하게 관리하는 규율이다.

PRINCE2 (PRojects IN Controlled Environments). NHS와 공공 부문 전반에서 널리 쓰이는 영국 정부의 구조화된 프로젝트 방법. 원칙(지속적인 사업상 정당화, 정의된 역할, 단계별 관리, 예외에 의한 관리, 제품 집중, 경험에서 배우기, 환경에 맞게 조정)에 기반하며 프로젝트 이사회가 방향을 제공하는 통제된 단계로 업무를 조직한다.

PMI / PMBOK. Project Management Institute의 *Guide to the Project Management Body of Knowledge*는 규정된 단계적 프로세스가 아니라 성과 영역과 원칙을 중심으로 프로젝트 업무를 구성하는 지배적인 국제적 대응물이다. PRINCE2와 PMBOK은 같은 학문에 대한 보완적 렌즈다.

비즈니스 케이스. 프로젝트를 정당화하는 문서. 문제, 평가된 선택지, 기대 편익, 비용, 위험이다. PRINCE2에서 비즈니스 케이스는 살아 있다. 모든 단계 경계에서 점검되며, 지속적인 정당화가 사라지면 올바른 결정은 중단이다. 영국 공공 기관에서는 보통 HM Treasury의 5개 케이스 모델(전략, 경제, 상업, 재정, 관리)로 구조화된다.

단계 관문. PRINCE2 프로젝트는 결정 관문으로 분리된 관리 단계로 나뉜다. 각 경계에서 프로젝트 이사회는 신중한 중단/진행 결정을 내린다. 진행과 비즈니스 케이스를 검토하고, 다음 단계 계획을 승인하며, 그 단계에 대해서만 자원을 약속한다. 이것이 이사회가 통제를 유지하고 밑 빠진 독에 돈을 붓지 않는 방법이다.

RAID 로그. 위험(Risks), 가정(Assumptions), 이슈(Issues), 의존성(Dependencies)의 단일 등록부로, 프로젝트 관리자의 핵심 통제 산출물이다. RAID는 불확실성을 보이게 하고 관리할 수 있게 한다. 위험은 일어날 수 있는 것, 이슈는 이미 일어난 것, 가정은 계획이 의존하는 것, 의존성은 계획이 다른 곳에서 필요로 하는 것이다.

모범 사례#

1. 정직한 비즈니스 케이스로 시작하고 살려 두라. 미리 정해진 단일 답이 아니라 실제 선택지를 평가하는 인정된 구조(영국 공공 기관에서는 5개 케이스 모델)를 쓰라. 그런 다음 비즈니스 케이스를 모든 단계 관문에서 검토하는 살아 있는 문서로 다루라. 지속적인 사업상 정당화는 PRINCE2의 첫 번째 원칙이며, 그것을 잃는 것은 중단하는 정당한 이유다.

2. 범위를 정확히 정의하고 변경을 통제하라. 프로젝트의 가치는 "완료"의 명확하고 경계가 있는 정의다. 범위에 합의하고, 기준선으로 정하며, 제안된 모든 변경을 변경 통제 프로세스를 거치게 하여 범위 확대(scope creep)가 예산과 일정을 조용히 소모하지 않게 하라.

3. 실제 결정 관문이 있는 단계로 관리하라. 업무를 관리 단계로 나누고 각 경계에서 진정한 중단/진행 검토를 열라. 항상 "진행"이라고 말하는 관문은 연극이다. 중단이나 재계획이 이사회가 행사할 실제 선택지일 때만 규율이 작동한다.

4. 살아 있는 RAID 로그를 운영하고 예외에 의해 상향하라. 위험, 가정, 이슈, 의존성을 한곳에 유지하고 정기적으로 검토하며, PRINCE2의 "예외에 의한 관리"를 사용하라. 프로젝트 관리자는 합의된 허용 범위 안에서 운영하고 허용 범위가 위협받을 때만 이사회에 상향한다. 이것이 고위 시간을 진정한 결정에 집중시킨다.

5. 명확하고 단일 지점의 책임을 배정하라. PRINCE2는 정의된 역할을 고집한다. 비즈니스 케이스를 소유하는 고위 책임자/임원이 있는 프로젝트 이사회, 산출물을 쓸 사람들을 대표하는 고위 사용자, 고위 공급자다. 모호한 책임이 표류의 가장 흔한 원인이다.

6. 시작하기 전에 라이브 서비스로의 전환을 계획하라. 프로젝트는 산출물을 납품하고, 누군가는 이후에 이를 운영해야 한다. 프로젝트의 일부로 인수 팀, 지원 모델, 임상 안전 인수인계(배치에는 DCB0160)에 합의하여, 가동이 소유권 공백으로의 절벽이 되지 않게 하라.

7. 임상 안전, 정보 거버넌스, 테스트를 내장하라. 환자 데이터에 닿는 모든 시스템에 대해 임상 안전 케이스, DPIA, 전환/롤백 테스트는 선택적 덤이 아니라 관문 산출물이다. 시험된 롤백 계획이 없는 이전은 가동할 준비가 되지 않은 것이다.

8. 프로젝트를 의도적으로 종결하고 교훈을 포착하라. 정의된 끝은 정의된 종결을 뜻한다. 산출물이 수용되었음을 확인하고, 운영에 인계하고, 팀을 해제하며, 교훈을 기록한다(PRINCE2의 교훈 로그). 종결되지 않은 프로젝트는 자원과 책임을 무기한 흘린다.

팀과 논의할 질문#

1. 눈앞의 일은 진정으로 정의된 최종 상태가 있는 유한한 것인가, 아니면 우리가 아는 재원 경로이기 때문에 프로젝트 거버넌스에 손을 뻗고 있는가? 이 주제가 달려 있는 결정적 질문이다. 프로젝트 중심 규율은 일에 정말로 시작, 중간, 명확한 끝이 있을 때만 맞는 도구이기 때문이다. 보건·돌봄 조직에서는 프로젝트 모양으로 끌리는 힘이 강하다. 자본 예산, 비즈니스 케이스 기제, 이사회 보고가 모두 그것을 위해 만들어졌으므로, 돈이 풀리는 방식이라는 이유만으로 진화하는 디지털 서비스가 프로젝트처럼 꾸며질 수 있고, 이것이 만들고 방치하는 병리를 낳는다. 토론은 각 후보를 정직하게 검토해야 한다. 공급업체가 지원을 철회하기 전의 병리 시스템 교체는 계약상의 절벽이 있어 명백히 유한한 반면, "환자 앱 개선"은 최종 상태가 없고 주제 5.0에 속한다. 팀이 해산해야 할 실제 가동이 있는지, 누군가 그것을 무기한 개선해야 하는지 생각하라. 좋은 답은 프로젝트 거버넌스를 습관으로 쓰는 것에 저항하고, 구체적인 최종 상태와 "완료"를 정의하는 사건을 명명하며, 현재 프로젝트로 운영하는 것 중 일부는 결코 프로젝트였어서는 안 되었다고 기꺼이 말한다.

2. 단계 관문에서 이 이사회는 정당화를 잃은 프로젝트를 실제로 중단하거나 재계획할 것이며 — 그렇게 한 때를 짚을 수 있는가? 단계 관문은 중단이 이사회가 행사할 진정한 선택지일 때만 통제다. 항상 "진행"이라고 말하는 관문은 연극이며, 지속적인 사업상 정당화가 PRINCE2의 첫 번째 원칙인 것은 바로 그것을 잃으면 일이 끝나야 하기 때문이다. 보건·돌봄에서 긴장은 날카롭다. 일부 구축된 EPR 이전이나 검사실 시스템 전환을 멈추는 것은 실패를 인정하고, 매몰 비용을 낭비하며, 이미 계획을 바꾼 임상의를 방해하는 것처럼 느껴져서, 이사회는 비즈니스 케이스가 조용히 증발하는 동안에도 밀고 나가는 것을 합리화한다. 실제 사례를 토론에 가져오라. 테스트가 데이터 매핑 위험이 가정보다 나쁨을 드러냈거나 편익이 미끄러진 프로젝트에서, 관문이 설계된 대로 쓰였는지 고무도장이었는지 물으라. 어떤 허용 범위가 상향을 촉발하는지, 이사회에서 누가 중단을 선언할 지위가 있는지, 매몰 비용 추론이 방 안에서 명명되고 도전받는지 생각하라. 정직한 답은 관문이 형식이었던 곳을 인정하고, 이사회가 진정으로 멈추거나 범위를 재조정할 조건을 설명하며, 공개적 평가 손실 전에 중단할 권한을 위협이 아니라 규율의 진정한 가치로 다룬다.

3. 각 프로젝트의 산출물을 라이브 서비스로 누가 받으며, 임상 안전 인수인계와 지속적 소유권을 절벽이 아니라 관문 산출물로 만들려면 어떻게 하는가? 프로젝트는 산출물을 납품한다. 유한한 무언가가 끝나지만, 그것이 만든 것은 팀이 해산한 뒤에도 오래도록 운영되고, 개선되고, 안전하게 유지되어야 하며, 가장 흔한 조용한 실패는 반대편에서 아무도 그것을 소유하지 않는 것이다. 환자 데이터에 닿는 시스템에서 이것은 행정적 정리가 아니다. DCB0160 배치 안전 케이스, DPIA, 시험된 롤백, 지정된 인수 팀이 통제된 가동과 안전 위험이 관리되지 않고 쌓이는 소유권 공백 사이에 서 있는 것이다. 토론은 가동 주말이 아니라 프로젝트가 시작되기 전에 전환에 대한 명확성을 강제해야 한다. 어느 운영 팀이 인수하는지, 지원 모델이 무엇인지, 그 팀이 그것을 계속 개선할 역량과 일하는 방식(주제 5.0에 따른 제품 중심)이 있는지다. 최근의 구체적 가동을 생각하고 인수인계가 계획되었는지 즉흥이었는지, "프로젝트가 끝났다"가 "이제 아무의 일도 아니다"를 뜻하게 허용했는지 보라. 좋은 답은 인수 팀과 지원 모델을 미리 명명하고, 안전 인수인계를 프로젝트가 통과하지 않고는 넘을 수 없는 관문으로 다루며, 라이브 서비스의 지속적 개선을 표류하게 두지 않고 올바른 업무 방식에 명시적으로 배정한다.

4. 철의 삼각형이 물어뜯어 범위, 시간, 비용이 충돌할 때 어느 제약을 굽히며, 환자 안전이 굽혀지는 변수가 되는 일이 있는가? 모든 실제 프로젝트는 결국 일정, 예산, 약속된 범위가 모두 유지될 수 없는 순간에 이르며, 팀이 그 압박을 어떻게 해소하는지가 실제로 무엇을 중시하는지 드러낸다. 보건·돌봄에서 함정은 독특하다. 종료일이 흔히 공급업체의 지원 철회, 임대 만료, 데이터센터 폐쇄 같은 단단한 계약상의 절벽이므로 시간은 자주 움직일 수 없고, 압박이 조용히 품질에 떨어진다. 임상 시스템에서 이는 테스트 축소, 검증 압축, 알려진 데이터 매핑 결함과 함께 출시하는 것을 뜻한다. 토론은 조직이 삼각형의 어느 모서리를 지키고 어느 것을 희생할지 미리 명명해야 하며, 다른 모든 것이 고정되어 있어도 임상 안전과 정보 거버넌스는 배출 밸브가 아님을 명시해야 한다. 최근의 전환을 보고 일자가 유지되었을 때 조용히 무엇이 굽혀졌는지 물으라. 롤백 리허설, 임상 검증 기간, 교육 중 무엇이었는가? 안전 여유를 침식하는 대신 가동일을 옮길 권한이 누구에게 있는지, 그 대화가 이사회에서 공개적으로 일어나는지 현장에서 기본적으로 일어나는지 생각하라. 정직한 답은 위기 전에 우선순위 순서를 밝히고, 밀린 일자나 재계획된 단계를 정당한 결과로 다루며, 말해지지 않은 일정 압박이 기록되지 않은 임상 위험으로 바뀌는 것을 거부한다.

5. 우리 RAID 로그는 우리가 하는 일을 바꾸는 살아 있는 도구인가, 아니면 통제되는 것처럼 보이려고 유지하는 문서인가 — 그리고 실제로 프로젝트를 침몰시킬 위험을 드러낼 것인가? RAID 로그는 검토가 결정을 바꿀 때만 자리를 얻는다. 흔한 병리는 시작 때 작성되고, 이사회에 제시되며, 중요한 위험이 지켜보는 이 없이 무르익는 동안 한 번도 진정으로 조치되지 않는 등록부다. 이전이나 전환에서 결정적인 위험은 흔히 구체적이고 알 수 있다. 새 시스템의 참조 범위에 깔끔하게 매핑되지 않을 과거 결과, 다른 팀의 방화벽 변경에 대한 의존성, 임상 검증 자원이 필요할 때 비어 있을 것이라는 가정이다. 질문은 로그가 이를 구체적으로 명명하는지 "자원 제약" 같은 일반적 항목 뒤에 숨는지다. 토론은 예외에 의한 상향이 실재하는지 시험해야 한다. 프로젝트 관리자는 합의된 허용 범위 안에서 운영하고 하나가 위협받을 때만 이사회의 주의를 끄는가, 아니면 모든 것이 침묵하거나 위기가 되는가? 아차 사고와 현실화된 이슈가 다음 단계가 계획되는 방식에 되먹이는지, 단지 기록되고 잊히는지 생각하라. 좋은 답은 RAID 로그가 실제로 바꾼 결정을 가리킬 수 있고, 프로젝트를 진정으로 멈출 수 있는 두세 가지 위험을 사소한 것의 긴 꼬리와 구별하며, 로그를 보증을 위해 만든 산출물이 아니라 작동하는 통제로 다룬다.

6. 종결하고 해산한 뒤, 비즈니스 케이스의 편익이 실제로 실현되었는지 누가 점검하며 — 그렇지 않았다면 알 수 있는가? 비즈니스 케이스는 지출을 정당화하려고 편익을 약속하지만, 프로젝트 중심 업무는 자연스럽게 가동과 팀 해제에서 끝나므로, 진실의 순간, 곧 이전이 실제로 위험을 줄였는가, 비용을 줄였는가, 돌봄을 개선했는가는 보통 모두가 떠난 뒤에 오며 그것을 확인할 책임자는 없다. 이는 의회, 감사관, 이사회가 구체적 성과를 낼 것이라고 들은 5개 케이스 비즈니스 케이스에 따라 돈이 투입되는 공공 보건·돌봄에서 특히 중요하지만, 편익 실현은 그것을 소유했을 프로젝트가 더는 존재하지 않아 가장 자주 건너뛰는 단계다. 토론은 프로젝트가 종결될 때 누가 편익 추적을 물려받는지, 어느 기간에 걸쳐, 어떤 기준선 측정에 대해서인지 결정해야 한다. 기준선은 가동 전에 포착하지 않으면 사라진다. 최근 완료된 프로젝트를 생각하고 누군가 그 약속된 편익을 이후에 점검했는지, 부족이 있다면 승인한 이사회에 닿을지 솔직히 물으라. 정직한 답은 종결 후 편익 소유권을 해산한 팀이 아니라 상설 기능에 배정하고, 프로젝트가 라이브인 동안 기준선을 포착하며, 프로젝트가 제시간에 예산 안에 산출물을 납품했지만 그것을 정당화한 가치는 전달하지 못했음을 기꺼이 기록한다.

실제 사례: 보건·돌봄 예시#

한 급성기 트러스트는 기존 공급업체가 14개월 뒤 지원을 철회하기 전에 노후한 병리 검사실 정보 관리 시스템을 교체해야 한다. 고정된 종료일, 정의된 범위, 단단한 계약상의 절벽, 이전 중 결과가 사라지면 급성 환자 안전 위험이 있는 교과서적인 프로젝트 중심 업무다.

트러스트는 세 가지 선택지(제자리 업그레이드, 신규 시스템 조달, 지역 인스턴스 공유)를 평가하는 5개 케이스 비즈니스 케이스를 작성하고, 조달을 선택하며, 명확한 이사회를 갖춘 PRINCE2 프로젝트를 세운다. 비즈니스 케이스를 소유하는 임원, 고위 사용자(수석 임상병리사), 고위 공급자다. 업무는 조달, 구축 및 구성, 데이터 이전, 테스트, 가동의 관리 단계로 나뉘고, 각각이 결정 관문으로 끝난다.

프로젝트 관리자는 RAID 로그를 운영한다. 핵심 위험은 과거 결과가 새 시스템의 참조 범위에 깔끔하게 매핑되지 않을 수 있다는 것이고, 의존성은 네트워크 팀의 방화벽 변경이며, 가정은 테스트에 임상 검증 자원이 있을 것이라는 것이다. 이전 단계 관문에서 테스트가 데이터 매핑 위험이 가정보다 나쁨을 드러내자, 이사회는 관문을 설계된 대로 사용한다. 맹목적으로 진행하지 않고, 연장된 검증 기간과 시험된 롤백 계획이 있는 재계획된 단계를 승인하여 원래 일정보다 환자 안전을 보호한다.

가동은 대기 중인 롤백 계획과 DCB0160 임상 안전 승인과 함께 통제된 주말에 이루어진다. 시스템은 수용되어 이를 운영할 운영 팀에 인계되고, 교훈이 기록되며, 프로젝트는 공식 종결된다. 팀은 올바르게 해산한다. 일이 진정으로 끝났기 때문이다. 다음에 오는 것(라이브 서비스의 지속적 개선)은 다른 업무 방식이며, 트러스트는 그것을 하려고 전체 프로젝트 팀을 영구히 운영하지 않도록 주의한다.

부문별 관점#

스타트업#

소규모 디지털 보건 기업은 공식 PRINCE2 프로젝트를 운영하는 일이 드물지만, 진정으로 유한한 업무는 여전히 나타난다. 새 클라우드 플랫폼으로의 일회성 데이터 이전, Cyber Essentials나 DTAC 인증 추진, 큰 NHS 계약 전 침투 테스트 시정이다. 스타트업은 이를 지정된 소유자와 명확한 완료 정의가 있는 가볍고 기한이 있는 노력으로 처리하며, 의식 없이(공식 프로젝트 이사회도, 5단계 관문도 없이) 규율(고정된 범위, 종료일, 진행/중단)을 빌린다. 재원은 실제로 창업자의 주의와 런웨이이므로, 위험은 유한한 업무가 제품 스프린트 사이에 끼어 실제로 종결되지 않는 것이다. 해결책은 한 명의 소유자와 엄격한 기한을 명명하고, 인증이나 이전을 영원히 "진행 중"이 아니라 끝난 것으로 다루는 것이다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원, 단일 사업장 클리닉 — 는 프로젝트 중심 업무를 가끔이지만 피할 수 없는 사건으로 만난다. 임상 시스템 공급업체 변경, 새 진료소 관리 플랫폼으로의 이전, 지원이 끊기기 전 수명이 끝난 기기 교체다. 조직은 실제 환자와 진행 중인 운영이 있지만 전담 프로젝트나 IT 기능이 없으므로, "프로젝트 팀"은 보통 진료소 관리자나 등록 관리자가 본업과 함께 하는 것이고, 흔히 들어오는 공급업체에 이전을 맡긴다. 현실과의 접촉에서 살아남는 규율은 가벼운 핵심이다. 명확한 최종 상태, 공급업체가 조용히 확대하지 못하도록 기준선이 정해진 범위, 지정된 책임자, 환자 기록에 닿는 전환 전의 시험된 롤백이다. 함정은 일뿐 아니라 판단까지 외주하는 것이다. 공급업체의 가동일과 데이터 매핑 보증을 독립적인 점검 없이 받아들이는 것인데, 조직이 아무리 작아도 같은 임상 안전과 정보 거버넌스 의무(DCB0160, DPIA)가 적용되기 때문이다. 해결책은 다른 모든 일손이 공급업체의 것이어도 가동/중단 결정과 수용 기준의 소유권을 사내에 유지하는 것이다.

대기업#

대형 NHS 트러스트나 통합 돌봄 시스템(ICS)이 프로젝트 중심 업무가 가장 편안한 곳이다. EPR 교체, 자산 전체 Wi-Fi, 데이터센터 철수, 전환은 모두 단단한 계약상 및 환자 안전의 절벽을 지닌다. 여기서는 전체 장치가 정당화된다. 5개 케이스 비즈니스 케이스, 지정된 임원/SRO, 고위 사용자, 고위 공급자가 있는 PRINCE2 이사회, 실제 관문이 있는 관리 단계, 살아 있는 RAID 로그다. 금액이 크고, 안전 노출이 급하며, 내부 감사와 이사회가 지출을 면밀히 검토할 것이기 때문이다. 이 규모의 특징적 실패는 같은 거버넌스를 살아 있는 서비스(주제 5.0 — 제품 중심 업무)와 유한한 업무에 무차별로 적용하는 것이므로, 각 업무를 올바른 방식으로 보내는 포트폴리오 시야(주제 5.3 — 전사 프로젝트 포트폴리오 관리)가 중요하다. 임상 안전(DCB0160)과 시험된 롤백은 선택적 덤이 아니라 관문 산출물이다.

정부#

국가 또는 주요 프로젝트 규모에서 프로젝트 중심 업무는 정부의 보증 체제 안에 있다. Infrastructure and Projects Authority가 게이트웨이 검토를 운영하고, HM Treasury의 Green Book과 5개 케이스 모델이 비즈니스 케이스를 다스리며, 가장 큰 프로젝트는 의회와 National Audit Office에 대한 공표된 책임과 함께 Government Major Projects Portfolio에 들어간다. 책임은 매우 공적이다. 고위 책임 소유자가 개인적으로 책임지며 상임위원회에 불려 갈 수 있으므로, 단계 관문과 선택지 평가는 연극이 아니라 법정 수준의 통제다. 재원은 승인된 비즈니스 케이스에 따라 분할로 풀리고 위험 감수 성향은 낮다. 실패가 1면 뉴스가 되기 때문이다. 여기서 규율의 진정한 가치는 실패하는 프로젝트가 공개적 평가 손실이 되기 전에 중단하거나 범위를 재조정할 권한이다.

흔한 실패 양상#

• 진화하는 서비스를 프로젝트로 관리. 살아 있는 디지털 제품에 고정 범위와 끝에서 해산하는 거버넌스를 적용하면 방치의 병리를 낳는다. 해결: 서비스가 계속되는 곳에는 제품 중심 업무(주제 5.0)를 쓰라.
• 재원으로 가는 일회성 표로서의 비즈니스 케이스. 돈을 풀려고 한 번 쓰고 다시 보지 않는다. 해결: 모든 단계 관문에서 검토하고, 기꺼이 중단하라.
• 고무도장 단계 관문. 결코 "중단"이라고 말하지 않는 관문은 통제를 제공하지 않는다. 해결: 중단이나 재계획을 이사회의 진정한 선택지로 만들고 사용하라.
• 변경 통제 없는 범위 확대. 통제되지 않은 추가가 시간과 비용을 날린다. 해결: 범위를 기준선으로 정하고 모든 변경을 변경 통제를 거치게 하라.
• 서비스 전환 계획 없음. 프로젝트가 끝나고 아무도 산출물을 소유하지 않는다. 해결: 가동 전에 인수 팀과 지원 모델에 합의하라.
• 서류 캐비닛으로서의 RAID. 쓰이고 조치되지 않는 로그. 해결: RAID를 정기적으로 검토하고 예외에 의해 상향하라.
• 실제로 종결하지 않음. 끝 없이 자원을 소모하는 좀비 프로젝트. 해결: 수용, 인계, 포착된 교훈과 함께 의도적으로 종결하라.

성숙도 모델#

체크리스트#

• 일이 진정으로 정의된 범위와 최종 상태가 있는 유한한 것인가(지속적 서비스가 아님)?
• 각 단계 관문에서 검토하는 살아 있는 비즈니스 케이스(5개 케이스 모델)가 있는가?
• 범위가 기준선으로 정해져 있고 작동하는 변경 통제 프로세스가 있는가?
• 업무 단계가 정의되어 있고 각각이 실제 중단/진행 결정 관문으로 끝나는가?
• 프로젝트 이사회 역할이 명확한가 — 임원/SRO, 고위 사용자, 고위 공급자?
• 예외에 의한 상향과 함께 살아 있는 RAID 로그를 유지하는가?
• 임상 안전(DCB0160), DPIA, 전환/롤백 테스트가 관문 산출물인가?
• 가동 전에 인수 운영 팀과 지원 모델에 합의했는가?
• 수용, 인계, 팀 해제, 교훈 기록이 있는 의도적 종결이 있는가?
• 라이브 서비스의 지속적 개선이 올바른 업무 방식에 배정되었는가?

주요 출처#

• AXELOS / PeopleCert — Managing Successful Projects with PRINCE2 (7판)와 PRINCE2의 원칙, 주제, 프로세스.
• Project Management Institute (PMI) — *A Guide to the Project Management Body of Knowledge (PMBOK Guide)*와 The Standard for Project Management.
• HM Treasury — Guide to Developing the Project Business Case (5개 케이스 모델 / Green Book).
• Infrastructure and Projects Authority (IPA), Cabinet Office — 주요 프로젝트를 위한 보증 및 게이트웨이 검토 지침.
• NHS Digital 임상 안전 표준 DCB0160 (보건 IT 시스템의 배치).
• NHS England — NHS Service Manual과 Digital Service Standard (서비스 전환과 사용자 필요의 맥락).

참고문헌#

1. Project management — Wikipedia — https://en.wikipedia.org/wiki/Project_management
2. PRINCE2 — Wikipedia — https://en.wikipedia.org/wiki/PRINCE2
3. Project management triangle (iron triangle) — Wikipedia — https://en.wikipedia.org/wiki/Project_management_triangle
4. Project Management Institute — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Institute
5. Project Management Body of Knowledge — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
6. Business case — Wikipedia — https://en.wikipedia.org/wiki/Business_case
7. Phase-gate process (stage gates) — Wikipedia — https://en.wikipedia.org/wiki/Phase-gate_process
8. Scope creep — Wikipedia — https://en.wikipedia.org/wiki/Scope_creep
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
11. HM Treasury — Wikipedia — https://en.wikipedia.org/wiki/HM_Treasury
12. Managing Successful Projects with PRINCE2 (7th edition) — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/PRINCE-2-1005
13. A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute — https://www.pmi.org/
14. The Green Book and Guide to Developing the Project Business Case (Five Case Model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
15. Assurance and gateway review guidance for major projects — Infrastructure and Projects Authority, Cabinet Office — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
16. Clinical risk management standard DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety