10.1 ポートフォリオとプログラムの管理

概要と動機

ポートフォリオとプログラム管理は、大きなエンジニアリング組織が何を築くべきかを決め、その仕事に時間をかけて資金を出し、多くのチームにわたって順序づけ、孤立したアウトプットではなく戦略的なアウトカムに向けて舵取りする規律です。単一のチームは、非公式な足並みと共有のバックログで済ませられます。数十、数百のチームを動かす企業や政府機関はできません。すべての仕事が、同じ乏しい予算、同じ専門技能、同じ共有プラットフォーム、同じリーダーシップの注意を争います。意図したポートフォリオの層がなければ、局所最適にたどり着きます。すべてのチームが忙しく、すべてのロードマップがもっともらしいのに、全体が、本来届けるべきよりはるかに少ない戦略的価値しか届けない。

大きなチームでは、賭け金が複合します。重複した労力、ずれた優先順位、管理されないチーム間の依存関係が、すべての取り組みに静かに課税します。あるチームがスプリントで出荷できる機能が、自分のことを聞いたこともないプラットフォームチームに依存するために、三四半期待たされます。政府では、問題はさらに鋭くなります。年次の歳出予算、複数年の資本の資金、調達法、公的な説明責任は、まずく枠づけられたプログラムが、機関を間違ったことへの何年もの確約された支出に閉じ込めうることを意味します。したがって、ポートフォリオ管理を正しく行うことは、官僚的な間接費ではありません。大きな組織が戦略を出荷されたソフトウェアに変える方法です。

この章は、ポートフォリオとプログラムの管理を、単なるプロジェクト管理オフィス(PMO)の機能ではなく、エンジニアリングのリーダーシップの関心事として扱います。目標は、戦略と目標をロードマップにつなげ、本物の制約のもとで誠実に優先順位をつけ、依存関係とベンダーを第一級のリスクとして扱い、予算と調達のサイクル、特に公共部門の仕事を支配する複数年の資金のリズムを乗りこなすことです。

主要原則

アウトプットよりアウトカム。 出荷された機能の量ではなく、世界の変化(採用、コスト、信頼性、使命の成果)に資金を出し、測定します。
戦略は読み取れるものでなければならない。 すべてのチームが、自分の仕事を少数の公表された目標までたどれるべきです。
優先順位づけとは引き算である。 すべてにはいと言うポートフォリオに戦略はありません。価値は、意図して行わないことにあります。
依存関係こそが本当のスケジュールである。 大きな組織では、コーディングの労力ではなく調整のコストが、通常、拘束する制約です。
一時的なプロジェクトではなく、持続するチームに資金を出す。 安定したプロダクトに揃ったチームは、プロジェクトごとに組み直される人員のプールに勝ります。
資金のリズムを学びのリズムに合わせる。 証拠が届くにつれて、止める、転換する、倍賭けすることができる増分で、お金をコミットします。
ベンダーはポートフォリオの外ではなく、拡張である。 請負業者とシステムインテグレーターの仕事は、内部の仕事と同じ可視性で統治しなければなりません。

推奨事項

エンジニアリングを戦略とOKRに揃える

少数の組織レベルの目標(理想的には三つから五つ)を公表し、軽くカスケードします。チームに割り当てられたタスクを渡すのではなく、それらの共有の目標のために、チーム自身が主要な結果を設定するようにします。カスケードを浅く保ちます。多くても二、三段階です。さもないと、戦略と日々の仕事の間の結合組織が作り話に変わります。目標を固定の周期(通常、進捗は四半期ごと、目標自体は年次)でレビューし、もはや重要でないものを公然と退役あるいは書き直します。OKR(目標と主要な結果)を、人事評価の武器にすることに抵抗してください。主要な結果が個人のボーナスを駆動した瞬間、チームは目標を甘く設定し、シグナルを失います。

意図と誠実な地平線でロードマップを作る

複数の高度でロードマップを保ちます。ポートフォリオのロードマップは、四半期にわたるテーマとアウトカムを示し、チームのロードマップは、近い将来の成果物を示します。問題とアウトカムを軸に枠づけ、確信が時間とともに下がるようにします。「今/次/後」の地平線は、偽の精度を含意する日付つきのガントチャートよりはるかによく不確実性を伝えます。ロードマップを定期的な周期で見直し、遠い将来の特定の日付の契約ではなく、方向へのコミットメントとして扱います。

明示的な枠組みと名指しされたトレードオフで優先順位をつける

軽量で一貫した優先順位づけの方法を選び、ポートフォリオ全体で比較できるよう、一様に適用します。一般的な選択肢には、重み付けスコアリング(価値、コスト、リスク、戦略的適合)、遅延のコスト(価値のある成果物が待つ時間の単位ごとに失われる価値)とその加重最短ジョブ優先(WSJF)の変種、RICE(リーチ、インパクト、確信、労力)があります。どの式も代わりに決めてはくれません。枠組みの本当の価値は、前提を公にさらし、リーダーが議論できるようにすることです。事実が変わったときに決定を見直せるよう、行っているトレードオフ(何を、なぜ先送りするか)を常に記録します。

多くのチームにわたる依存関係を管理する

依存関係が牙をむく前に可視にします。各重要な取り組みについて、他のチームから何を、いつまでに必要とするかを名指しする依存関係の地図あるいは台帳を保ちます。依存関係を公然と表面化させ交渉するために、定期的なチーム間の計画イベント(スケールされた枠組みでは、四半期ごとの大部屋の計画セッションが一般的)を使います。さらによいのは、設計で消し去ることです。セルフサービスのプラットフォーム、よく文書化されたAPI、明確な内部の契約に投資し、チームが互いを待たずに進められるようにします。すべての横断的な依存関係に、説明責任のある単一の所有者を与えます。所有者のいない依存関係こそ、プログラムが静かに遅れる所です。

ベンダー、請負業者、システムインテグレーターを統治する

外部のデリバリーパートナーを、ポートフォリオの一部として扱います。社内に期待するのと同じ可視性を、彼らのバックログ、ベロシティ、品質、リスクに求めます。契約を、文書の量や席に座る人数ではなく、アウトカムと増分で届けられる動くソフトウェアを軸に構造化します。仕事を仕様化し、品質を判断し、ベンダーが失敗したら引き継げる、十分な社内の技術能力を保ちます。賢い買い手の機能を決して外注しないでください。データを所有し、オープンなインターフェースを要求し、初日から出口と移行の条項を主張することで、ロックインを防ぎます。

調達、予算、複数年の資金を乗りこなす

運用している資金のリズムを理解し、それに合うようにプログラムを設計します。特に政府では、歳出予算は年次でも、システムは構築に何年もかかりうるので、年度末の前に支出する圧力と、最初のコミットメントを過剰に範囲づける圧力が生まれます。これに三つの方法で対抗します。プログラムを独立に価値のある増分に構造化する(モジュール式の契約)、規則が許す所では増分的でアジャイルな資金の権限を求める、構築、運用、維持を分ける本物のコストの見積もりを築く。調達、財務、法務を早期に巻き込み(彼らは、ほとんどのエンジニアが気づくよりはるかに、何が可能かを形づくります)、技術的な計画を、それらの部門が必要とする予算の区分と会計年度の境界に翻訳します。

トレードオフ: 長所と短所

アプローチ	長所	短所
集中型のポートフォリオ制御	強い戦略的整合。重複が少ない。資金のトレードオフが容易	決定が遅い。チームの自律と局所的な革新を抑えうる
分散型のチームの自律	速く動機づけられたチーム。局所的な専門性が尊重される	重複。弱い戦略的一貫性。隠れたチーム間のリスク
プロジェクトベースの資金	取り組みごとの明確な範囲と説明責任	チームの入れ替わり。短期主義。弱い長期の所有
プロダクト/チームベースの資金	持続する所有。持続的な品質	再配分が難しい。ゾンビの取り組みに資金を出すリスク
式による優先順位づけ	透明、比較可能、擁護できる	偽の精度。ゲーム化できる入力。判断を押しのけうる
複数年の固定プログラム	資金の安定。長い地平線への投資	早期の前提を固定する。方向転換が高価

中心的な緊張は、一貫性と速度の間にあります。中央の制御が多すぎれば組織は遅く動き、最良の人々の意欲を削ぎます。少なすぎれば、百の局所最適に断片化します。成熟した組織は、一貫していなければならない少数のもの(戦略、共有プラットフォーム、横断的な標準、資金のトレードオフ)だけを集中させ、実行の決定を可能な限りチームの近くに押し出します。資金の安定性と適応性の間の緊張も、同じように解決します。一方を選ぶのではなく、持続するチームに対してお金を増分でコミットすることで、人の安定性が方向の柔軟性と共存します。

チームで議論すべき問い

組織全体で一貫していなければならない少数のものは何で、どの決定をチームに押し下げるべきですか。 ポートフォリオの中心的な緊張は一貫性対速度で、境界を間違えるとどちらの方向にも高くつきます。集中させすぎれば決定は這うように遅くなり、最良の人々は自律を失います。集中が少なすぎれば、重複したシステムと隠れたチーム間のリスクを伴う百の局所最適に断片化します。成熟した組織は、短い一覧だけを中央に保ちます。戦略、共有プラットフォーム、横断的な標準、資金のトレードオフ。会議に証拠を持ち込んでください。いくつのチームが独立に同じ問題を解いているか、最近の決定のいくつが中央の承認を待って止まったか。どちらかの数字が高いなら、線を間違った所に引いているので、集中化を抽象的に議論するのではなく、特定の決定権を動かしてください。
プロジェクトの資金が与えた説明責任を失わずに、アウトプットではなくアウトカムにどう資金を出しますか。 持続するプロダクトに揃ったチームに資金を出すことは、一時的なプロジェクトに資金を出すことに勝ります。安定したチームは、築くだけでなく動かすことを所有して品質を保つからです。落とし穴は、プロジェクトの資金がリーダーにきれいな範囲と明確な説明責任の線を与え、持続するチームの資金は、前提が失敗した後も長く、ゾンビの取り組みに支払うことへとずれうることです。持続するチームに対してお金を増分でコミットし、各テーマを四半期の周期でレビューし、チームを解散するのではなく、テーマ間で容量を再配分することで解決します。重要な証拠を持ち込んでください。資金を受けた各チームについて、先四半期にどのアウトカム(採用、コスト、信頼性、使命の成果)が動いたか、お金が突然乏しくなったら何への資金を止めるか。アウトカムを名指しできないなら、まだアウトプットに資金を出しています。
ベンダーとシステムインテグレーターの仕事の賢い買い手であり続けるために、どれだけの社内エンジニアリング能力を保たなければなりませんか。デリバリーを請負業者やシステムインテグレーターに渡しても、説明責任は自分が保つので、仕事を仕様化し、品質を判断し、ベンダーが失敗したら引き継げる、十分な社内の深さが必要です。その能力を失うと、人材派遣的な請負になります。アウトカムではなく時間を買い、自分が仕えられているのか囚われているのか、もはや見分けられません。コードの大半を書いていない上級エンジニアを保つコストを、ベンダーのロックインと人質に取られた使命のはるかに大きなコストと量ってください。具体的なシグナルを持ち込んでください。あなたのチームは、ベンダーのバックログを読み、ビルドを再現し、今日データとインターフェースを所有できているか。初日から出口と移行の条項を主張してください。交渉のてこを持つ時は署名の前で、関係がこじれたときではないからです。
今サイクル、意図して資金を出さない取り組みはどれで、すべてのチームがそのいいえを戦略までたどれますか。 優先順位づけは引き算で、静かにすべてにはいと言うポートフォリオには戦略がなく、乏しい容量を薄く広げて、何もうまく終えられなくなるだけです。大きな組織では、損害は拡散しています。単一の承認は無謀に見えないのに、総和が、目標を本当に動かす少数の賭けを飢えさせるからです。相反する引力は本物です。却下されたすべての取り組みには、それが不可欠だと信じる後援者がいて、枠組み(重み付けスコアリング、遅延のコスト、RICE)は代わりに決めてくれず、前提を公にさらしてリーダーが議論できるようにするだけです。順位づけされた一覧、各先送りについて記録された明示的なトレードオフ、進行中の取り組みの数対終える容量のある数を持ち込んでください。企業と政府の設定では、各いいえの政治的コストと、それを定着させる権限を持つ人を加えてください。どの後援者もエスカレーションで覆せる優先順位づけの判断は、決定ではなく、提案だからです。
チーム間の依存関係は今どこにあり、単に追跡するのではなく、設計で消し去っているのはどれですか。 大きな組織では、コーディングの労力ではなく調整のコストが通常、拘束する制約なので、一つのチームがスプリントで出荷できる機能が、それを聞いたこともないプラットフォームチームを三四半期待ちうるのです。依存関係を台帳で追跡することはそれらを可視にしますが、可視性は解決ではありません。より効果の高い動きは、セルフサービスのプラットフォーム、文書化されたAPI、明確な内部の契約を通じて、それらを設計から取り除き、チームが互いを待つのをやめさせることです。トレードオフは、プラットフォームへの投資が今、本物の容量を費やす一方で、依存関係の遅延が後で静かに複合することで、目に見える機能に、目に見えないプラットフォームより資金を出したくなる誘惑は常にあります。上位の取り組みの依存関係の地図、先四半期に別のチームを待って遅れた成果物の数、各横断的な依存関係に説明責任のある単一の所有者がいるかを持ち込んでください。数十のチームと外部のインテグレーターが噛み合う企業と政府のプログラムでは、これらを早期に表面化させるチーム間の計画の周期を名指ししてください。統合の時に発見された依存関係は、すでにスケジュールの失敗だからです。
資金と契約の構造は、実際に学ぶリズムに合っていますか。 大きな複数年の塊でお金をコミットすると、最も早期の、最も情報の乏しい前提が固定されますが、多くの資金の制度、特に政府の年次歳出は、最初のコミットメントを過剰に範囲づけ、年度末の前に支出するよう押します。相反する考慮は、資金の安定が、持続するチームに長い地平線のために投資させることなので、答えは小さな契約ではなく、実証された結果に結びついた段階で資金を出される、独立に価値のある増分です。現在のコミットメントの形を持ち込んでください。最初の動くソフトウェアが出荷される前にどれだけがコミットされているか、コストの見積もりが構築、運用、維持を分けているか、歳出予算を無駄にせずに、どれだけ遅くまで止めたり方向を変えたりできるか。企業と政府の読者にとって、調達と法務のチームは、ほとんどのエンジニアが予期するよりはるかに、何が可能かを形づくるので、早期に巻き込み、一枚岩の契約が必要だと想定する前に、モジュール式の契約と増分的な資金の権限について、規則がすでに何を許しているかを明示的に尋ねてください。

セクター別の視点

スタートアップ。 少数のエンジニアとわずかな滑走路では、創業者がポートフォリオの層なので、ホワイトボードに収めてください。二つか三つの公表されたアウトカム、それに留められた仕事、その場で切られるそれ以外のすべて。四半期先にコミットするのではなく、数週間で止められる短い賭けで資金を出し、節約するより多くの調整を要する枠組み、台帳、計画イベントは飛ばします。あなたの唯一の本物のポートフォリオのリスクは、避けられない少数の外部依存なので、それぞれに所有者を名指ししてください。

小規模事業者。 専任のPMOやプログラムマネージャーはいないので、ポートフォリオ管理は、雇う役割ではなく、すでにいる人々の間の繰り返される会話です。中核から外れるものには築くより買うに頼り、ベンダーを、離れやすさで判断してください。移行する職員がいないときにロックインが最も痛いからです。資金を出しているものと意図して出していないものの、単一の誠実な一覧を保ち、乏しい予算が請求書を払う少数のアウトカムに従うよう、固定の軽い周期で見直します。

大企業。 数十から数百のチームにわたって、仕事は、行き詰まりのない一貫性です。戦略、共有プラットフォーム、横断的な標準、資金のトレードオフだけを集中させ、実行はチームに押し出します。持続するプロダクトに揃ったチームに継続的に資金を出し、テーマ間で容量を再配分する四半期のポートフォリオレビューを行い、共有の台帳とチーム間の計画で依存関係を管理します。この規模ではガバナンスと監査は交渉の余地がないので、ベンダーの仕事を内部の仕事と同じくらい可視にし、すべての優先順位づけの判断の背後にあるトレードオフを記録します。

政府。 調達法、年次の歳出予算、公的な説明責任があらゆる動きを形づくります。一枚岩の複数年の発注よりモジュール式の契約を好み、実証された結果に結びついた段階で資金を出し、維持が驚きにならないよう、見積もりで構築、運用、維持を分けます。社内の賢い買い手のチームを保ち、データとインターフェースを所有し、すべての契約に出口と移行の条項を書き込んでください。透明性の義務は、失敗したプログラムが、静かな償却ではなく、公的で監査される出来事になることを意味するからです。

事例

スタートアップ。 12人のシード段階のスタートアップは二つの小さなスクワッドを動かし、創業者がポートフォリオの層全体を務めます。毎週月曜日、仕事を二つの公表されたアウトカム、アクティベーションと粗利に留め、どちらにも仕えないものを公然と切るので、輝かしい統合の要望は、オンボーディングの離脱を直すために脇に置かれます。四半期前にコミットするのではなく短い賭けで資金を出し、避けられない唯一の外部依存、決済プロバイダーに一人の所有者を名指しするので、それが静かにローンチを遅らせることがありません。

大企業。 世界的な銀行は、リテール、決済、リスクにわたって百を超えるデリバリーチームを動かします。小さな経営グループが、十数の戦略的なテーマに資金を割り当てる四半期のポートフォリオレビューを行い、各テーマは説明責任のある一組、つまり事業のリーダーとエンジニアリングのリーダーが率います。チームはプロジェクトごとではなく継続的に資金を受けます。四半期のレビューは、チームを解散するのではなく、テーマ間で容量を再配分します。共有の依存関係の台帳と四半期の計画イベントが、チーム間のニーズを早期に表面化させます。結果として、驚きの遅れが減り、市場の状況が変わったとき、四半期の中で投資の向きを変えられます。

政府。 数十年前の申告システムを近代化する国の税務当局は、単一の一枚岩の複数年契約を断り、モジュール式の契約を選びます。それぞれが市民の使える動くソフトウェアを届ける、より小さく独立に価値のある増分の連なり。大きな失敗したプログラムのリスクを下げるため、実証された結果に結びついた段階で資金を要求します。機関は社内の技術チームを賢い買い手として保ち、すべてのデータとインターフェースを所有し、すべてのベンダー契約に明示的な出口の条項を書き込むので、単一のインテグレーターが使命を人質に取れません。

ビジネスケース: 動機、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