10.1 포트폴리오와 프로그램 관리

개요와 동기

포트폴리오와 프로그램 관리는 큰 엔지니어링 조직이 무엇을 만들지 결정하고, 그 일에 시간에 걸쳐 자금을 대고, 많은 팀에 걸쳐 순서를 정하고, 고립된 산출이 아니라 전략적 성과를 향해 이끄는 규율입니다. 단일 팀은 비공식적 정렬과 공유 백로그로 버틸 수 있습니다. 수십, 수백 개 팀을 운영하는 기업이나 정부 기관은 그럴 수 없습니다. 그 모든 일이 같은 희소한 예산, 같은 전문 기술, 같은 공유 플랫폼, 같은 리더십의 주의를 두고 경쟁합니다. 의도적인 포트폴리오 계층이 없으면 국소 최적화에 이릅니다. 모든 팀이 바쁘고, 모든 로드맵이 그럴듯한데도, 전체가 내야 할 것보다 훨씬 적은 전략적 가치를 전달합니다.

큰 팀에서는 판돈이 복리로 쌓입니다. 중복된 노력, 어긋난 우선순위, 관리되지 않는 팀 간 의존성이 모든 이니셔티브에 조용히 세금을 매깁니다. 한 팀이 스프린트 한 번에 출하할 수 있는 기능이, 그것을 들어 본 적 없는 플랫폼 팀에 의존하기 때문에 세 분기를 기다립니다. 정부에서는 문제가 더 날카롭습니다. 연간 세출, 다년 자본 자금, 조달법, 공적 책무 때문에 잘못 구성된 프로그램은 기관을 엉뚱한 곳에 약정된 수년의 지출에 묶을 수 있습니다. 그러니 포트폴리오 관리를 제대로 하는 것은 관료적 간접비가 아닙니다. 큰 조직이 전략을 출하된 소프트웨어로 바꾸는 방법입니다.

이 장은 포트폴리오와 프로그램 관리를 단지 프로젝트 관리 오피스(PMO)의 기능이 아니라 엔지니어링 리더십의 관심사로 다룹니다. 목표는 전략과 목표를 로드맵에 연결하고, 현실의 제약 아래서 정직하게 우선순위를 정하고, 의존성과 벤더를 일급 위험으로 다루고, 예산과 조달 주기, 특히 공공 부문 업무를 지배하는 다년 자금의 리듬을 헤쳐 나가는 것입니다.

핵심 원칙

산출이 아니라 성과. 출하한 기능의 양이 아니라 세상의 변화(채택, 비용, 신뢰성, 임무 결과)에 자금을 대고 측정하십시오.
전략은 읽혀야 합니다. 모든 팀이 자기 일을 공표된 소수의 목표까지 추적할 수 있어야 합니다.
우선순위는 뺄셈입니다. 모든 것에 예라고 하는 포트폴리오에는 전략이 없습니다. 가치는 의도적으로 하지 않는 것에 있습니다.
의존성이 진짜 일정입니다. 큰 조직에서는 코딩 노력이 아니라 조율 비용이 보통 구속 제약입니다.
임시 프로젝트가 아니라 지속되는 팀에 자금을 대십시오. 안정적이고 제품에 정렬된 팀이 프로젝트마다 다시 꾸리는 인력 풀보다 낫습니다.
자금 주기를 학습 주기에 맞추십시오. 증거가 도착함에 따라 멈추고, 방향을 틀고, 배로 걸 수 있는 증분으로 돈을 약정하십시오.
벤더는 포트폴리오의 바깥이 아니라 연장입니다. 계약자와 시스템 통합업체의 일도 내부 일과 같은 가시성으로 다스려야 합니다.

권장 사항

엔지니어링을 전략과 OKR에 정렬한다

조직 수준의 소수 목표(이상적으로 셋에서 다섯)를 공표하고 가볍게 내려보내십시오. 팀에게 할당된 과업을 주는 대신, 그 공유된 목표를 위해 팀이 스스로 핵심 결과를 정하게 하십시오. 연쇄를 얕게 유지하십시오. 많아야 두세 단계이며, 아니면 전략과 일상 업무 사이의 연결 조직이 허구가 됩니다. 목표를 고정된 주기로(보통 진행은 분기별, 목표 자체는 연간) 리뷰하고, 더 이상 중요하지 않은 것은 공개적으로 폐기하거나 다시 쓰십시오. OKR(목표와 핵심 결과)을 성과 평가의 무기로 바꾸는 것을 거부하십시오. 핵심 결과가 개인 보너스를 좌우하는 순간 팀은 목표를 낮춰 잡고 신호를 잃게 됩니다.

의도와 정직한 지평으로 로드맵을 만든다

로드맵을 여러 고도에서 유지하십시오. 포트폴리오 로드맵은 분기에 걸친 주제와 성과를 보이고, 팀 로드맵은 가까운 시기의 산출물을 보입니다. 문제와 성과를 중심으로 구성하되 시간이 갈수록 확신이 줄어들게 하십시오. “지금 / 다음 / 나중” 지평은 거짓 정밀을 암시하는 날짜가 있는 간트 차트보다 불확실성을 훨씬 잘 전달합니다. 로드맵을 정기 주기로 다시 살피고, 먼 미래의 특정 날짜에 대한 계약이 아니라 방향에 대한 약속으로 다루십시오.

명시적 프레임워크와 이름 붙인 상충으로 우선순위를 정한다

가볍고 일관된 우선순위 방법을 골라 균일하게 적용해 포트폴리오 전체를 비교할 수 있게 하십시오. 흔한 선택지에는 가중 점수(가치, 비용, 위험, 전략적 적합성), 지연의 비용(가치 있는 전달이 단위 시간 기다릴 때마다 포기하는 가치)과 그 변형인 가중 최단 작업 우선(WSJF), RICE(도달, 영향, 확신, 노력)가 있습니다. 어떤 공식도 대신 결정해 주지 않습니다. 프레임워크의 진짜 가치는 가정을 드러내 리더들이 논쟁할 수 있게 하는 데 있습니다. 내리는 상충(무엇을 미루고 왜인지)을 항상 기록해, 사실이 바뀔 때 결정을 다시 살필 수 있게 하십시오.

많은 팀에 걸친 의존성을 관리한다

의존성이 물기 전에 보이게 하십시오. 중요한 이니셔티브마다 다른 팀에게서 무엇이 언제까지 필요한지 명시하는 의존성 지도나 등록부를 유지하십시오. 정기적인 팀 간 계획 행사(규모 확장 프레임워크에서 흔한 분기별 대형 룸 계획 세션)로 의존성을 드러내고 공개적으로 협상하십시오. 더 좋은 것은 의존성을 설계로 없애는 것입니다. 셀프서비스 플랫폼, 잘 문서화된 API, 분명한 내부 계약에 투자해 팀이 서로 기다리지 않고 진행하게 하십시오. 모든 횡단 의존성에 책임지는 단일 소유자를 두십시오. 소유자 없는 의존성이 프로그램이 조용히 미끄러지는 곳입니다.

벤더, 계약자, 시스템 통합업체를 다스린다

외부 전달 파트너를 포트폴리오의 일부로 다루십시오. 내부에 기대하는 것과 같은 가시성을 그들의 백로그, 속도, 품질, 위험에 요구하십시오. 계약을 문서의 양이나 자리를 채운 인원이 아니라 성과와 증분으로 전달되는 동작하는 소프트웨어를 중심으로 구성하십시오. 일을 명세하고, 품질을 판단하고, 벤더가 실패하면 인수할 만한 내부 기술 역량을 충분히 유지하십시오. 똑똑한 구매자 기능을 결코 외주하지 마십시오. 데이터를 소유하고, 개방형 인터페이스를 요구하고, 첫날부터 퇴출 및 전환 조항을 고집함으로써 종속을 경계하십시오.

조달, 예산, 다년 자금을 헤쳐 나간다

운영하는 자금의 리듬을 이해하고 프로그램을 거기에 맞게 설계하십시오. 특히 정부에서는 세출이 연간일 수 있는 반면 시스템은 구축에 수년이 걸려, 연말 전에 쓰고 초기 약정을 과도하게 잡으라는 압력이 생깁니다. 세 가지로 이에 맞서십시오. 프로그램을 독립적으로 가치 있는 증분으로 구성하고(모듈식 계약), 규칙이 허락하는 곳에서 증분적이고 애자일한 자금 권한을 구하고, 구축, 운영, 유지를 구분하는 진짜 비용 추정을 만드십시오. 조달, 재무, 법무를 일찍 참여시키고(대부분의 엔지니어가 아는 것보다 훨씬 많이 무엇이 가능한지를 형성합니다), 기술 계획을 그 기능이 필요로 하는 예산 범주와 회계연도 경계로 번역하십시오.

장단점

접근	장점	단점
중앙 집중 포트폴리오 통제	강한 전략적 정렬. 적은 중복. 쉬운 자금 상충	느린 결정. 팀 자율과 현지 혁신을 억누를 수 있음
분산된 팀 자율	빠르고 동기 부여된 팀. 현지 전문성 존중	중복. 약한 전략적 일관성. 숨은 팀 간 위험
프로젝트 기반 자금	이니셔티브별로 분명한 범위와 책무	팀 이탈. 단기주의. 약한 장기 소유권
제품/팀 기반 자금	지속되는 소유권. 유지되는 품질	재배분이 어려움. 좀비 노력에 자금을 댈 위험
공식에 의한 우선순위	투명하고 비교 가능하고 방어 가능	거짓 정밀. 조작 가능한 입력. 판단을 밀어낼 수 있음
다년 고정 프로그램	자금 안정성. 장기 투자	초기 가정을 고정. 방향 수정에 비용이 듦

중심 긴장은 일관성 대 속도입니다. 중앙 통제가 너무 많으면 조직은 느리게 움직이고 최고의 사람들을 낙담시킵니다. 너무 적으면 백 개의 국소 최적으로 흩어집니다. 성숙한 조직은 일관되어야 하는 소수(전략, 공유 플랫폼, 횡단 표준, 자금 상충)만 중앙화하고 실행 결정은 가능한 한 팀 가까이로 밉니다. 자금 안정성과 적응성 사이의 긴장도 같은 방식으로 풀립니다. 하나를 고르는 것이 아니라 지속되는 팀에 대해 돈을 증분으로 약정해, 사람의 안정성이 방향의 유연성과 공존하게 합니다.

팀과 논의할 질문

조직 전체에서 일관되어야 하는 몇 가지는 무엇이고, 팀으로 내려보내야 할 결정은 무엇입니까? 포트폴리오의 중심 긴장은 일관성 대 속도이며, 경계를 잘못 긋는 것은 양쪽 모두 비쌉니다. 너무 많이 중앙화하면 결정이 기어가고 최고의 사람들이 자율을 잃으며, 너무 적게 하면 중복된 시스템과 숨은 팀 간 위험이 있는 백 개의 국소 최적으로 흩어집니다. 성숙한 조직은 중심에 짧은 목록만 둡니다. 전략, 공유 플랫폼, 횡단 표준, 자금 상충입니다. 회의에 증거를 가져오십시오. 같은 문제를 독립적으로 풀고 있는 팀이 몇인지, 최근 결정 중 중앙의 승인을 기다리며 멈춘 것이 몇인지 세어 보십시오. 어느 쪽이든 숫자가 크면 선을 잘못 그은 것이니, 중앙화를 추상적으로 논쟁하는 대신 특정 결정권을 옮기십시오.
프로젝트 자금이 주던 책무를 잃지 않으면서 산출이 아니라 성과에 어떻게 자금을 대겠습니까? 지속되는 제품 정렬 팀에 자금을 대는 것이 임시 프로젝트에 자금을 대는 것보다 낫습니다. 안정적 팀은 품질을 유지하고 구축만이 아니라 운영도 소유하기 때문입니다. 함정은 이렇습니다. 프로젝트 자금은 리더들에게 깔끔한 범위와 분명한 책무선을 주었고, 지속되는 팀 자금은 전제가 무너진 뒤에도 한참 좀비 노력에 값을 치르는 쪽으로 표류할 수 있습니다. 지속되는 팀에 대해 돈을 증분으로 약정하고, 각 주제를 분기 주기로 리뷰하고, 팀을 해체하는 대신 주제 사이에서 역량을 재배분해 풀어 가십시오. 중요한 증거를 가져오십시오. 자금을 받는 각 팀에 대해 지난 분기에 어떤 성과(채택, 비용, 신뢰성, 임무 결과)가 움직였는지, 돈이 갑자기 부족해지면 무엇에 자금을 끊겠는지입니다. 성과의 이름을 댈 수 없다면 여전히 산출에 자금을 대고 있는 것입니다.
벤더와 시스템 통합업체의 일에서 똑똑한 구매자로 남으려면 사내 엔지니어링 역량을 얼마나 유지해야 합니까? 전달을 계약자나 시스템 통합업체에 넘겨도 책임은 여러분에게 남으므로, 일을 명세하고, 품질을 판단하고, 벤더가 실패하면 인수할 만한 충분한 내부 깊이가 필요합니다. 그 역량을 잃으면 인력 파견식 계약이 됩니다. 성과가 아니라 시간을 사게 되고, 서비스를 받는 것인지 포획당한 것인지 더 이상 알 수 없습니다. 코드 대부분을 쓰지 않는 시니어 엔지니어를 유지하는 비용을, 벤더 종속과 인질이 된 임무의 훨씬 큰 비용과 저울질하십시오. 구체적 신호를 가져오십시오. 팀이 오늘 벤더의 백로그를 읽고, 빌드를 재현하고, 데이터와 인터페이스를 소유할 수 있습니까? 첫날부터 퇴출 및 전환 조항을 고집하십시오. 레버리지를 협상할 순간은 서명하기 전이지 관계가 나빠질 때가 아니기 때문입니다.
이번 주기에 의도적으로 자금을 대지 않기로 한 이니셔티브는 무엇이며, 모든 팀이 그 거절을 전략까지 추적할 수 있습니까? 우선순위는 뺄셈이고, 조용히 모든 것에 예라고 하는 포트폴리오에는 전략이 없습니다. 희소한 역량을 너무 얇게 펴서 무엇도 잘 끝내지 못할 뿐입니다. 큰 조직에서는 피해가 흩어져 있습니다. 어느 한 승인도 무모해 보이지 않지만 합계는 실제로 목표를 움직일 소수의 내기를 굶깁니다. 경쟁하는 끌림은 실제입니다. 거절된 모든 이니셔티브에는 그것이 필수라고 믿는 후원자가 있고, 프레임워크(가중 점수, 지연의 비용, RICE)는 대신 결정하지 않으며 가정을 드러내 리더들이 논쟁하게 할 뿐입니다. 순위 목록, 각 연기에 기록된 명시적 상충, 진행 중인 이니셔티브 수 대 끝낼 역량이 있는 수를 가져오십시오. 기업과 정부 환경에서는 각 거절의 정치적 비용과 누가 그것을 유지할 권한을 쥐는지를 더하십시오. 어느 후원자든 에스컬레이션으로 뒤집을 수 있는 우선순위 판단은 결정이 아니라 제안이기 때문입니다.
오늘 팀 간 의존성은 어디에 있으며, 단지 추적하는 것이 아니라 설계로 없애는 것은 무엇입니까? 큰 조직에서는 코딩 노력이 아니라 조율 비용이 보통 구속 제약이므로, 한 팀이 스프린트에 출하할 기능이 들어 본 적 없는 플랫폼 팀 때문에 세 분기를 기다릴 수 있습니다. 등록부에서 의존성을 추적하면 보이게 되지만 가시성이 해결은 아닙니다. 지렛대가 더 큰 수는 셀프서비스 플랫폼, 문서화된 API, 분명한 내부 계약으로 의존성을 설계에서 없애 팀이 서로 기다리지 않게 하는 것입니다. 상충은 플랫폼 투자가 조용히 복리로 쌓일 나중의 의존성 지연에 맞서 지금 실제 역량을 쓴다는 것이며, 눈에 보이지 않는 플랫폼보다 보이는 기능에 자금을 대고 싶은 유혹은 늘 있습니다. 상위 이니셔티브의 의존성 지도, 지난 분기에 다른 팀을 기다리느라 미끄러진 전달의 수, 각 횡단 의존성에 책임지는 단일 소유자가 있는지를 가져오십시오. 수십 개 팀과 외부 통합업체가 맞물리는 기업과 정부 프로그램에서는 이를 일찍 드러내는 팀 간 계획 주기의 이름을 정하십시오. 통합 때 발견한 의존성은 이미 일정의 실패이기 때문입니다.
자금과 계약을 구성한 방식이 실제로 배우는 리듬과 맞습니까? 큰 다년 덩어리로 돈을 약정하면 가장 이르고 가장 정보가 적은 가정이 고정됩니다. 그런데도 많은 자금 체제, 특히 연간 정부 세출은 초기 약정을 과도하게 잡고 연말 전에 쓰도록 몰아붙입니다. 경쟁하는 고려는 자금 안정성이 지속되는 팀이 긴 지평에 투자하게 해 준다는 것이므로, 답은 작은 계약이 아니라 입증된 결과에 묶여 단계별로 자금을 받는 독립적으로 가치 있는 증분입니다. 현재 약정의 모양을 가져오십시오. 첫 동작하는 소프트웨어가 출하되기 전에 얼마가 약정되는지, 비용 추정이 구축, 운영, 유지를 구분하는지, 세출을 낭비하지 않고 멈추거나 방향을 바꿀 수 있는 가장 늦은 때가 언제인지입니다. 기업과 정부 독자에게는, 조달과 법무 팀이 대부분의 엔지니어가 예상하는 것보다 훨씬 많이 무엇이 가능한지를 형성하므로 일찍 참여시키고, 단일체 계약이 필요하다고 가정하기 전에 모듈식 계약과 증분 자금 권한을 규칙이 이미 무엇까지 허용하는지 명시적으로 물으십시오.

분야별 관점

스타트업. 엔지니어가 소수이고 런웨이가 짧으면 창업자가 곧 포트폴리오 계층이므로 화이트보드 수준으로 유지하십시오. 공표된 두세 개의 성과, 거기에 고정된 일, 그 밖의 모든 것은 보이는 즉시 잘라 냅니다. 한 분기를 앞서 약정하는 대신 몇 주 안에 멈출 수 있는 짧은 내기로 자금을 대고, 절약하는 것보다 조율 비용이 더 드는 프레임워크, 등록부, 계획 행사는 건너뛰십시오. 진짜 포트폴리오 위험은 피할 수 없는 소수의 외부 의존성이므로, 각각에 소유자를 정하십시오.

소기업. 전담 PMO나 프로그램 관리자가 없으면 포트폴리오 관리는 채용할 역할이 아니라 이미 있는 사람들 사이의 반복되는 대화입니다. 핵심 밖의 모든 것은 구축보다 구매에 기대고, 벤더는 떠나기가 얼마나 쉬운지로 판단하십시오. 이전할 인력이 없을 때 종속이 가장 아픕니다. 무엇에 자금을 대고 무엇을 의도적으로 대지 않는지의 정직한 단일 목록을 유지하고, 고정된 가벼운 주기로 다시 살펴 희소한 예산이 청구서를 갚는 소수의 성과를 따르게 하십시오.

대기업. 수십, 수백 개 팀에 걸쳐 일은 교착 없는 일관성입니다. 전략, 공유 플랫폼, 횡단 표준, 자금 상충만 중앙화하고 실행은 팀으로 미십시오. 지속되는 제품 정렬 팀에 지속적으로 자금을 대고, 주제 사이에서 역량을 재배분하는 분기별 포트폴리오 리뷰를 운영하고, 공유 등록부와 팀 간 계획으로 의존성을 관리하십시오. 이 규모에서 거버넌스와 감사는 협상 불가이므로, 벤더 일을 내부 일만큼 보이게 하고 모든 우선순위 판단 뒤의 상충을 기록하십시오.

정부. 조달법, 연간 세출, 공적 책무가 모든 움직임을 형성합니다. 단일체 다년 계약보다 모듈식 계약을 선호하고, 입증된 결과에 묶어 단계별로 자금을 대고, 유지가 결코 놀람이 되지 않도록 추정에서 구축, 운영, 유지를 구분하십시오. 사내 똑똑한 구매자 팀을 유지하고, 데이터와 인터페이스를 소유하고, 모든 계약에 퇴출 및 전환 조항을 쓰십시오. 투명성 의무 때문에 실패한 프로그램은 조용한 상각이 아니라 공개되고 감사받는 사건이 되기 때문입니다.

사례

스타트업. 열두 명의 시드 단계 스타트업이 두 개의 작은 스쿼드를 운영하고, 창업자들이 포트폴리오 계층 전체로 행동합니다. 매주 월요일 그들은 일을 활성화와 매출 총이익이라는 공표된 두 성과에 고정하고 둘 다 섬기지 않는 것은 공개적으로 잘라, 번쩍이는 통합 요청은 온보딩 이탈 수정에 밀려 보류됩니다. 한 분기를 앞서 약정하는 대신 짧은 내기로 자금을 대고, 피할 수 없는 유일한 외부 의존성인 결제 제공자에 소유자 한 명을 정해 출시가 조용히 미끄러지지 않게 합니다.

기업. 한 글로벌 은행이 리테일, 결제, 위험에 걸쳐 백 개가 넘는 전달 팀을 운영합니다. 소규모 경영진 그룹이 열두 개 전략 주제에 자금을 배분하는 분기별 포트폴리오 리뷰를 열고, 각 주제는 비즈니스 리더 한 명과 엔지니어링 리더 한 명이라는 책임지는 한 쌍이 이끕니다. 팀은 프로젝트별이 아니라 지속적으로 자금을 받습니다. 분기별 리뷰는 팀을 해체하는 대신 주제 사이에서 역량을 재배분합니다. 공유 의존성 등록부와 분기별 계획 행사가 팀 간 필요를 일찍 드러냅니다. 결과는 놀라운 지연이 줄고, 시장 조건이 바뀔 때 한 분기 안에 투자를 돌릴 수 있게 된 것입니다.

정부. 수십 년 된 신고 시스템을 현대화하는 한 국세청이 단일 단일체 다년 계약을 거절하고 모듈식 계약을 택합니다. 시민이 쓸 수 있는 동작하는 소프트웨어를 각각 전달하는, 더 작고 독립적으로 가치 있는 증분의 연속입니다. 입증된 결과에 묶인 단계별 자금을 요청하며, 이는 크게 실패하는 프로그램의 위험을 낮춥니다. 기관은 똑똑한 구매자로서 사내 기술 팀을 유지하고, 모든 데이터와 인터페이스를 소유하고, 모든 벤더 계약에 명시적 퇴출 조항을 써서 어떤 단일 통합업체도 임무를 인질로 잡지 못하게 합니다.

비즈니스 사례: 동기, ROI, TCO

포트폴리오 관리의 수익은 세 원천에서 옵니다. 피한 낭비, 더 빠른 가치 전달, 더 적은 대규모 프로그램 실패입니다. 피한 낭비는 포트폴리오 관점이 중복을 보이게 해서 만들지 않은 중복 시스템과 자금을 대지 않은 저가치 이니셔티브입니다. 더 빠른 가치는 팀이 서로 기다리지 않도록 의존성을 설계로 없애는 데서 옵니다. 그러나 가장 큰 수익은 위험 감소입니다. 대규모 소프트웨어 프로그램은 높은 비율로 실패하거나 크게 초과하며, 피한 단 한 번의 다년 실패가 포트폴리오 기능 전체의 비용을 왜소하게 만들 수 있습니다.

도입 비용은 실제입니다. 포트폴리오와 프로그램 역할, 계획 주기, 도구, 그 모두가 소모하는 조율 시간입니다. 도입하지 않는 비용은 더 크지만 흩어져 있어 무시하기 쉽습니다. 조율되지 않은 지출, 어긋난 일에 묻힌 매몰 비용, 모든 이니셔티브에 걸친 의존성 지연의 복리 부담입니다. 리더십을 설득할 때 포트폴리오 관리를 그들의 전략을 전달로 바꾸고 경력을 끝낼 대규모 프로그램 실패에서 지켜 주는 메커니즘으로 구성하십시오. 초기 구축만이 아니라 구축, 운영, 다년 유지에 걸친 총소유비용을 보이십시오. 구축에만 자금을 대는 리더는 어김없이 운영에 놀라기 때문입니다.

안티패턴과 함정

HiPPO 우선순위. 증거나 합의된 프레임워크가 아니라 가장 높은 연봉자의 의견으로 이끌리는 결정.
날짜의 약속으로서의 로드맵. 먼 미래의 날짜를 약속으로 공표한 뒤 성과가 아니라 달력에 맞춰 관리하는 것.
모든 것이 최우선. 명시적 거절이 없는 포트폴리오라 희소한 역량이 너무 얇게 펴져 무엇도 끝내지 못합니다.
의존성 맹목. 팀 간 의존성을 계획 때가 아니라 통합 때 발견하는 것.
인력 파견식 계약. 성과 대신 계약자 시간을 사고 품질을 판단하는 사내 능력을 잃는 것.
쓰지 않으면 사라진다는 지출. 세출을 돌려주지 않으려고 저가치 일에 자금을 대는 연말 예산 몰아치기.
관제탑으로서의 OKR. 목표를 할당된 과업과 평가 지표로 바꿔, 그것이 제공하려던 정직한 신호를 파괴하는 것.
좀비 프로그램. 전제가 무너진 뒤에도 관성으로 계속 자금을 받는 다년 노력.

성숙도 모델

1단계, 시작. 우선순위가 임시로 정해지고 가장 크게 요구하는 사람에 따라 바뀝니다. 포트폴리오 관점이 없어 의존성은 통합 때의 위기로 드러나고 중복 시스템은 눈치채지 못합니다. 벤더는 성과가 아니라 계약 규모로 관리되고, 자금은 연말의 허둥지둥을 따릅니다.

2단계, 발전. 포트폴리오 목록이 있고 주기적으로 리뷰되지만 실천은 팀마다 다릅니다. 목표는 공표되지만 일상 업무와 약하게 연결됩니다. 일부 팀은 의존성 등록부를 유지하고 소수의 벤더를 성과로 관리하지만 다른 팀은 둘 다 하지 않습니다. 예산 편성은 예측 가능하지만 여전히 프로젝트 기반이라, 책무는 전략적 일관성보다 분명합니다.

3단계, 표준화. 전략이 얕은 OKR 구조로 팀까지 깔끔하게 내려가고, 하나의 우선순위 프레임워크가 문서화되어 포트폴리오 전체에 적용됩니다. 팀 간 계획 행사가 의존성이 물기 전에 드러내고, 팀은 프로젝트별이 아니라 지속적으로 자금을 받으며, 증분 자금을 곁들인 모듈식 계약이 현지 실험이 아니라 조직 전체의 규범입니다.

4단계, 관리. 포트폴리오가 문서화에 그치지 않고 기준선에 대해 측정됩니다. 리더는 자금을 받는 주제별 성과 이동, 상위 이니셔티브의 지연의 비용, 의존성 지연율, 합의된 성과에 대한 벤더 전달, 입증된 결과에 묶인 약정 지출의 비중을 추적합니다. 우선순위 상충과 중단 기준이 이 증거로 시행되고, 비용과 일정의 예측 대 실제 편차가 옹호가 아니라 각 자금 결정을 이끕니다.

5단계, 오케스트레이션. 포트폴리오, 프로그램, 위험 계획이 통합되고, 포트폴리오는 증거가 도착함에 따라 지속적으로 재균형됩니다. 의존성은 대체로 플랫폼과 분명한 내부 계약으로 설계에서 사라지고, 벤더와 내부 일은 가치와 위험의 하나의 관점을 공유하며, 자금 주기는 학습 주기와 맞아 조직이 소동 없이 일상적으로 일을 멈추거나, 방향을 바꾸거나, 범위를 조정합니다.

논의를 위한 아이디어

OKR 연쇄는 일을 이끌기를 멈추기 전에 얼마나 얕을 수 있고, 허구가 되기 전에 얼마나 깊을 수 있습니까?
우선순위 공식은 언제 결정을 개선하고, 언제 누군가 이미 정한 답을 세탁해 줄 뿐입니까?
플랫폼 팀은 중앙 예산으로 자금을 받아야 합니까, 소비하는 팀에 비용을 청구해야 합니까? 그것은 유인을 어떻게 바꿉니까?
정부 맥락에서 입법 변경이 필요해지기 전에 기존 세출법 안에서 증분 및 모듈식 자금을 얼마나 밀어붙일 수 있습니까?
보고 오버헤드에 빠지지 않으면서 벤더 일을 내부 일만큼 보이게 하려면 어떻게 합니까?
지속되는 팀의 제품이 전략적 관련성을 잃으면 올바른 대응은 무엇입니까? 사람을 재배치합니까, 해체하고 다시 꾸립니까?

핵심 요점

포트폴리오 관리는 많은 팀에 걸쳐 무엇에, 어떤 순서로 자금을 댈지 결정함으로써 전략을 전달된 소프트웨어로 바꿉니다.
뺄셈으로 우선순위를 정하고 상충을 기록하십시오. 모든 것에 예라고 하는 포트폴리오에는 전략이 없습니다.
큰 조직에서는 코딩 노력이 아니라 팀 간 의존성이 보통 구속 제약입니다. 보이게 하고 설계로 없애십시오.
지속되는 제품 정렬 팀에 자금을 대고 돈을 증분으로 약정해 사람의 안정성이 방향의 유연성과 공존하게 하십시오.
벤더를 포트폴리오의 일부로 다스리고, 똑똑한 구매자 기능을 사내에 유지하고, 데이터 소유와 퇴출 조항으로 종속을 경계하십시오.
정부에서는 프로그램을 독립적으로 가치 있는 증분으로 구성해 다년 자금 주기에 맞추고 대규모 프로그램 실패의 위험을 줄이십시오.

참고 문헌과 더 읽을거리

Donald G. Reinertsen, The Principles of Product Development Flow
Marty Cagan, Inspired and Empowered
John Doerr, Measure What Matters
Christina Wodtke, Radical Focus: Achieving Your Most Important Goals with OKRs
Mik Kersten, Project to Product
Jez Humble, Joanne Molesky, and Barry O’Reilly, Lean Enterprise
Project Management Institute, The Standard for Portfolio Management
Axelos, Managing Successful Programmes (MSP)
U.S. Digital Service, Digital Services Playbook
UK Government Digital Service, Service Manual and Technology Code of Practice
U.S. Government Accountability Office, Agile Assessment Guide