Тема 5.2 — Работа, ведомая программами

В одном предложении: Работа, ведомая программами, координирует набор связанных проектов и продуктов ради стратегического изменения, которого ни один из них не мог бы достичь в одиночку, сохраняя ясную линию видимости от работы до выгод, которые она должна реализовать.

Почему это важно в здравоохранении и уходе#

Крупнейшие изменения в здравоохранении и уходе — никогда не один проект. Развёртывание общей записи ухода по интегрированной системе ухода (ICS), перевод региона на единую электронную медицинскую карту, трансформация пути неотложной и экстренной помощи или поставка программы виртуальных палат по нескольким трастам — каждое из этого представляет собой скоординированный пучок проектов, продуктовых команд, изменений рабочей силы, работ по недвижимости и клинического перепроектирования, согласованных вокруг одного стратегического результата. Управляйте частями изолированно — и они столкнутся: несовместимые стандарты данных, дублирующиеся расходы, противоречивые клинические процессы и выгоды, которые так и не материализуются.

Управление программами существует, чтобы держать эту коалицию вместе и направленной на результаты и выгоды, а не только на выходы. Это остро важно в здравоохранении и уходе, потому что общесистемное изменение затрагивает безопасность пациентов через организационные границы, обязывает к крупным суммам общественных денег на несколько лет и зависит от множества автономных организаций, выбирающих двигаться в ногу. Программа даёт руководство, общее целевое состояние и дисциплину выгод, чтобы это произошло, и, не менее важно, чтобы знать, работает ли оно.

Повторяющийся провал, от которого она защищает, — программа, тратящая миллионы, поставляющая груду технических выходов и всё же не меняющая ничего измеримого для пациентов или персонала. Эта тема использует Managing Successful Programmes (MSP), доминирующую рамку британского государственного сектора, и показывает, как работа, ведомая программами, сосуществует с режимами, ведомыми проектами (тема 5.1 — Работа, ведомая проектами) и продуктами (тема 5.0 — Работа, ведомая продуктом), которые она координирует. Тема 5.3 — Управление корпоративным портфелем и проектами (EPPM) затем объясняет, как организация приоритизирует по многим программам.

Ключевые понятия#

Программа. Временная гибкая организация, созданная для координации, направления и надзора за группой связанных проектов и видов деятельности для достижения результатов и выгод, согласованных со стратегическими целями. Программа отличается от проекта тем, что определяется результатом и выгодами, которых добивается, и управляет неопределённостью координации многих движущихся частей, а не поставкой единственного фиксированного выхода.

MSP (Managing Successful Programmes). Британская рамка лучшей практики управления трансформационными изменениями через множество связанных проектов. Она организована вокруг принципов, тем и «трансформационного потока» процессов и предназначена для крупных, сложных изменений, где конечное состояние известно по направлению, но путь включает много взаимозависимых поставок.

Видение и чертёж (blueprint). Видение — убедительная картина будущего, которое создаст программа. Чертёж делает его конкретным: он описывает целевую операционную модель — будущее состояние процессов, организации, технологий, информации и ролей (часто суммируемых как POTI). Чертёж — опорная точка, к которой направляется каждый проект, чтобы части складывались в связное целое.

Реализация выгод. Сердце управления программами. Выгоды — измеримые улучшения, оправдывающие инвестиции: меньше задержанных выписок, меньше дублирующих анализов, быстрее диагностика, меньше административного бремени. MSP рассматривает выявление, нанесение на карту, измерение и активное управление выгодами на протяжении всего жизненного цикла как основную дисциплину, потому что выходы создают ценность лишь тогда, когда используются, чтобы изменить способ оказания помощи.

Транши. MSP разбивает программу на транши — блоки работы, заканчивающиеся значимой точкой обзора, где поставлена ступень возможностей и может начаться реализация выгод. Транш — момент продемонстрировать результаты, пересмотреть чертёж относительно реальности и решить, продолжать, корректировать или остановиться, а не просто ломоть графика.

Совет программы и SRO. Ответственный руководитель (Senior Responsible Owner, SRO) — единственное лицо, подотчётное за достижение программой целей и реализацию выгод, достаточно старшее и с достаточными полномочиями, чтобы вести и принимать решения. SRO возглавляет совет программы — обычно менеджер по бизнес-изменениям, руководители проектов и старшие заинтересованные стороны, — дающий направление через организационные границы.

Менеджер по бизнес-изменениям (BCM). Отличительная роль MSP: кто-то из операционного бизнеса (не из команды поставки), подотчётный за закрепление изменения и реализацию выгод на местах. BCM — причина, по которой программы дают результаты, а не только выходы: проекты передают возможность, а BCM превращает её в выгоду.

Лучшие практики#

1. Закрепите программу в видении и чертеже. Определите стратегический результат и переведите его в конкретную целевую операционную модель (процессы, организация, технологии, информация — POTI). Тогда каждый составляющий проект и продукт направляется к одному и тому же будущему состоянию, что и не даёт коалиции поставок фрагментироваться.

2. Управляйте выгодами, а не только поставляемым. Постройте карту выгод, связывающую каждый выход с результатами и измеримыми выгодами, которые он должен породить, с владельцами и базовыми значениями. Активно пересматривайте выгоды по всей программе и будьте готовы остановить работу, которая не окупится: акцент MSP на реализации выгод — дисциплина, отличающая программу от дорогого списка дел.

3. Структурируйте работу в транши с настоящими точками обзора. Поставляйте возможности траншами и на каждой границе транша демонстрируйте реализованные пока выгоды, перепроверяйте чертёж на том, что вы узнали, и принимайте подлинное решение «продолжать/корректировать/остановить». Ранние транши должны нацеливаться на видимые быстрые победы, чтобы выстроить доверие заинтересованных сторон для более трудных поздних.

4. Назначьте наделённого полномочиями SRO и настоящий совет программы. Назовите единственного SRO с достаточной старшинностью и полномочиями, чтобы направлять программу и принимать решения через организационные границы, и соберите совет, подлинно представляющий затронутые организации. Программы проваливаются, когда подотчётность размыта или SRO фактически не может закрепить межграничные решения.

5. Поместите менеджеров по бизнес-изменениям в операционный бизнес. Назначьте BCM из организаций переднего края, чтобы они владели принятием и реализацией выгод там, где оказывается уход. Поставленная, но не принятая возможность не реализует никакой выгоды; роль BCM — механизм, закрывающий этот разрыв.

6. Координируйте, а не микроуправляйте составляющими проектами и продуктами. Программа задаёт чертёж, взаимозависимости, стандарты и выгоды; она позволяет проектам и продуктовым командам поставлять в этой рамке. Она управляет швами — общими стандартами данных, управлением информацией, последовательностью и общей инфраструктурой, — а не внутренней деталью каждой поставки.

7. Неутомимо управляйте сквозными рисками, зависимостями и заинтересованными сторонами. Ценность, которую программа добавляет по сравнению с отдельными проектами, во многом в управлении тем, что происходит между ними. Ведите программный взгляд на взаимозависимости и общие риски и вкладывайтесь в вовлечение заинтересованных сторон по автономным организациям, поскольку согласованность добровольна, а не приказана.

8. Закройте программу, когда изменение закреплено, и передайте продолжающиеся услуги продуктовым командам. Программа временна. Когда чертёж достигнут и выгоды реализуются, закройте её осознанно, передайте постоянные услуги устойчивым продуктовым командам (тема 5.0) и продолжайте отслеживать выгоды в обычной деятельности: многие выгоды накапливаются после окончания программы.

Вопросы для обсуждения с командой#

1. Есть ли у нашего ответственного руководителя реальные полномочия закреплять решения среди суверенных организаций-партнёров или только подотчётность, когда они не закрепляются? Работа, ведомая программами, живёт или умирает на межграничных полномочиях, потому что изменение охватывает автономные трасты, первичную помощь, общинные службы, психическое здоровье и социальный уход, которым нельзя просто приказать двигаться в ногу. Характерный провал — названный SRO, несущий личную, публичную подотчётность за выгоды, но не имеющий веса заставить неохотного партнёра принять общий стандарт данных или изменить клинический процесс: подотчётность без полномочий. Обсуждение должно быть откровенным о том, где в системе находится реальная власть: подлинно ли совет программы представляет затронутые организации или это форум отчётности, достаточно ли старший SRO, чтобы его решения соблюдались через суверенные границы, и что происходит, когда один партнёр отказывается двигаться. Подумайте о недавнем межорганизационном решении и проследите, держалось ли оно на самом деле. Хороший ответ называет, кто SRO, и проверяет его полномочия на конкретном межграничном конфликте, честен об организациях, которые фактически могут выйти, и рассматривает представительный совет и встроенных менеджеров по бизнес-изменениям как несущие механизмы добровольной согласованности, а не как декорацию управления.

2. Как мы узнаем, что программа реализовала выгоды, а не только поставила выходы, и кто в операционном бизнесе подотчётен за превращение возможности в выгоду? Театр выходов — повторяющаяся патология, от которой предостерегает тема: программа тратит миллионы, производит груду платформ интероперабельности и интеграций, а ничего измеримого для пациентов или персонала не меняется. Различие, которое её предотвращает, — менеджер по бизнес-изменениям: кто-то из передовой операции, а не из команды поставки, подотчётный за закрепление изменения и реализацию выгоды там, где оказывается уход, — так что вопрос заставляет команду назвать этих людей и подтвердить, что они существуют. Напряжение в том, что поставка видна и удовлетворяет, а принятие медленно, непривлекательно и легко предположить, что оно просто произойдёт; общая запись ухода, зарытая за дополнительным входом, не реализует никакой выгоды, как бы хорошо она ни была построена. Принесите карту выгод на обсуждение и проверьте, связан ли каждый выход с принадлежащей владельцу, зафиксированной, измеримой выгодой (меньше дублирующих анализов, меньше задержанных выписок) или выгоды просто заявлены. Честный ответ называет BCM в каждой организации-партнёре, признаёт, где выгоды сейчас бесхозны или не измеряются, и принимает, что некоторые выгоды накапливаются только после закрытия программы и должны отслеживаться в обычной деятельности.

3. Разбиваем ли мы эту программу на транши, чтобы получить ранние выгоды и создать настоящие точки «продолжать/корректировать/остановить», или дрейфуем к поставке «большим взрывом», откладывающей весь риск на один поздний момент? Транши — то, что отличает программу от дорогого замороженного плана: каждая граница транша должна поставлять ступень возможностей, демонстрировать реализованные пока выгоды, перепроверять чертёж на том, что реально узнано, и поддерживать подлинное решение продолжать, корректировать или остановиться. Соблазн в здравоохранении и уходе — последовательность по инженерному удобству и откладывание видимой ценности: подключить каждый траст, прежде чем кто-либо сможет чем-то пользоваться, — что загружает весь риск в одну позднюю поставку и оставляет совет без доказательств для защиты продолжающихся инвестиций через финансовые и политические циклы. Обсуждение должно изучить, нацелены ли ранние транши на сознательные быстрые победы, строящие доверие заинтересованных сторон для более трудной поздней работы, и являются ли точки обзора реальными решениями или контрольными точками графика. Подумайте, какова первая демонстрируемая выгода, как скоро она наступит и что совет на самом деле сделал бы на обзоре транша, если бы принятие отставало или чертёж оказался неверным. Хороший ответ описывает конкретные транши с ранними измеримыми победами, считает каждую границу реальным go/no-go с подлинно открытым для пересмотра чертежом и честен о любом давлении отложить ценность на конец.

4. Есть ли у нас единый поддерживаемый чертёж целевой операционной модели или каждый проект тихо оптимизирует под собственную версию будущего? Чертёж — конкретная целевая операционная модель POTI из процессов, организации, технологий и информации — делает так, чтобы части складывались в связное целое, а не в столкновение локально разумных решений. Без него каждый составляющий проект рационально оптимизирует под свой объём: один траст выбирает стандарт данных, подходящий его действующей EPR, другой проектирует клинический процесс под свою кадровую ситуацию, а общая запись ухода распадается на интеграции, технически соединяющиеся, но не складывающиеся. Напряжение в том, что поддержание чертежа ощущается как накладные расходы командами поставки под давлением выпуска, а он должен быть живым эталоном, перепроверяемым на каждом транше, а не документом, написанным раз и убранным на полку. Обсуждение должно установить, существует ли чертёж в пригодной форме, кому он принадлежит и управляют ли им реальные проектные решения или лишь задним числом сверяют с ним. Подумайте о недавнем проектном выборе в одном проекте и спросите, формировал ли его чертёж или был молча переопределён. Честный ответ может указать на текущий чертёж, называет его владельца и откровенен о том, где локальная оптимизация уже разрывает целевое состояние.

5. Что остаётся, когда программа закрывается, и назвали ли мы устойчивые продуктовые команды, которые будут вести возможность и продолжат отслеживать выгоды в обычной деятельности? Программа временна по определению, но общая запись ухода, платформа интероперабельности и выгоды, которые они производят, — нет, так что закрытие — проектная задача, которую нужно планировать с самого начала, а не запоздалая мысль. Повторяющийся провал на каждом конце спектра реален: одни программы никогда не закрываются и твердеют в постоянные бюрократии долго после закрепления изменения, другие закрываются резко и оставляют живую клиническую услугу без устойчивого владельца. Тема явно говорит, что продолжающиеся услуги должны передаваться устойчивым продуктовым командам (тема 5.0) и что многие выгоды накапливаются только после окончания программы и должны отслеживаться в обычной деятельности, — а значит принимающие команды и дальнейшее владение выгодами должны быть определены, пока у программы ещё есть полномочия и финансирование их создать. Обсуждение должно выявить, кто будет вести каждую продолжающуюся возможность, как она будет финансироваться, когда деньги трансформации прекратятся, и кто продолжит измерять выгоды, когда совет программы распущен. Хороший ответ называет конкретные продуктовые команды и владельцев обычной деятельности, честно описывает переход финансирования и рассматривает закрытие и отслеживание выгод как запланированные транши, а не надеждную передачу.

6. Как мы управляем швами между проектами — общими стандартами, управлением информацией, последовательностью и общей инфраструктурой, — а не внутренностями каждой поставки? Ценность, которую программа добавляет к набору отдельных проектов, живёт почти целиком в пространстве между ними: во взаимозависимостях, общих стандартах данных, рамке управления информацией и согласия и общей инфраструктуре, которой не владеет ни один проект, но от которой зависят все. Соблазн для команды программы — дрейфовать в микроуправление внутренностями каждой поставки, комфортную, видимую работу, пока по-настоящему трудные сквозные швы остаются неуправляемыми, пока не всплывают как сбой интеграции или блокер управления информацией при запуске. В здравоохранении и уходе эти швы необычно несущие, потому что потоки данных и согласие пересекают суверенные организационные и регуляторные границы, где согласованность добровольна, а юридические обязанности общи, но неравно обеспечены ресурсами. Обсуждение должно проверить, есть ли программный взгляд на взаимозависимости и общие риски, кто владеет общими стандартами и инфраструктурой и координирует ли программа швы или вмешивается в детали проектов. Честный ответ определяет конкретные швы, больше всего угрожающие результату, называет их владельцев и откровенен о том, добавляет ли программа ценность на границах или дублирует работу проектов, которым должна способствовать.

На практике: пример из здравоохранения и ухода#

ICS берётся поставить общую запись ухода, дающую клиницистам по острой, общинной помощи, психическому здоровью, первичной помощи и социальному уходу единый вид человека. Ни один проект не может это поставить: она охватывает несколько трастов, несколько исходных систем, соглашения об управлении информацией, перепроектирование клинических процессов и общественное вовлечение. Она координируется как программа MSP.

SRO — руководитель ICS с подлинными межсистемными полномочиями — возглавляет совет программы с представителями каждой организации-партнёра и названными менеджерами по бизнес-изменениям в каждой. Программа задаёт видение («правильная информация о правильном человеке, доступная правильному клиницисту, в точке ухода») и чертёж, описывающий целевую операционную модель: архитектуру обмена данными и стандарты (интероперабельность на основе HL7 FHIR), рамку управления информацией, модель согласия и перепроектированные клинические процессы.

Работа организована в транши. Первый транш соединяет два готовых острых траста и поставляет запись только для чтения — сознательную быструю победу, доказывающую подход и позволяющую совету продемонстрировать раннюю выгоду — измеримое сокращение дублирующих анализов — для построения доверия. На обзоре первого транша совет узнаёт, что принятие клиницистами отстаёт там, где запись зарыта за дополнительным входом, поэтому корректирует чертёж, чтобы приоритизировать интеграцию единого входа до расширения развёртывания.

Под программой режимы сосуществуют. Платформу интероперабельности ведёт устойчивая продуктовая команда (тема 5.0), продолжающая её улучшать по всей программе и далее. Подключение каждого траста — ограниченный проект (тема 5.1) со своим бизнес-кейсом и запуском. Сама программа координирует чертёж, стандарты, взаимозависимости и, через BCM, реализацию выгод. Когда чертёж достигнут, а выгоды от сокращения дублирующих анализов и задержанных выписок текут, программа закрывается; продуктовая команда платформы остаётся, а отслеживание выгод продолжается в обычной деятельности.

Секторные линзы#

Стартап#

Немногие стартапы ведут программы в смысле MSP — им не хватает многоорганизационного охвата, определяющего программу, — но масштабирующаяся компания, развёртывающаяся по нескольким трастам, фактически становится участником программы. Её реалистичная роль — поставщик внутри чужой программы: согласование продукта с чертёжом программы, достижение вех траншей и питание бизнес-обоснования выгод, которое SRO должен подтвердить доказательствами. Финансирование и выживание зависят от того, продолжится ли программа, поэтому стартап относится к обзорам траншей как к экзистенциальным точкам go/no-go и вкладывается в успех менеджеров по бизнес-изменениям, потому что принятие на местах — то, что продлевает его контракт. Дисциплина, которую он должен позаимствовать, — язык выгод: подача своей ценности как реализованных результатов, а не поставленных функций.

Малый бизнес#

Устоявшийся малый поставщик — общая практика, общинная аптека, дом ухода или небольшой поставщик технологий здравоохранения, перешагнувший стадию стартапа, — почти никогда не ведёт программу, но регулярно оказывается втянутым в неё как затронутый участник, когда ICS разворачивает общую запись ухода или сводит системы по территории. Его практическая забота — шов, которым владеет программа: он должен принять вмененные стандарты данных, соглашения об управлении информацией и модель согласия при скудной или отсутствующей выделенной ИТ-возможности и без запаса поглотить изменение процессов, при этом неся те же юридические обязанности, что и крупные окружающие трасты. Самые ценные отношения у него — с менеджером по бизнес-изменениям своей местности, потому что хорошо поддержанное принятие — обучение, единый вход, процесс, подходящий тому, как практика реально работает, — разница между тем, что выгода программы приземлится, и тем, что изменение тихо обойдут. Его реалистичная просьба к программе — соразмерная поддержка и последовательность, не предполагающая ресурсов уровня предприятия, а честный вклад — ранняя откровенная обратная связь на обзорах траншей о том, что неработоспособно на местах.

Предприятие#

ICS или крупный траст — естественный дом работы, ведомой программами: общие записи ухода, конвергенция EPR и трансформация путей по сути многоорганизационны и многолетни. Трудная часть — полномочия: SRO должен закреплять решения среди суверенных организаций-партнёров, которым нельзя просто приказать, так что подлинно представительный совет программы и менеджеры по бизнес-изменениям, встроенные в каждого партнёра, — несущие, а не декоративные. Финансирование смешанное (деньги системной трансформации, капитал трастов, национальные распределения), что делает карту выгод и обзоры траншей необходимыми для защиты продолжающихся инвестиций перед руководителями системы и регуляторами. Повторяющийся риск в таком масштабе — театр выходов: техническая поставка без того, кто подотчётен за превращение её в выгоду.

Правительство#

В национальном масштабе программы несут самое тяжёлое управление: они обычно входят в Government Major Projects Portfolio, проходят гарантии Infrastructure and Projects Authority и шлюзовые обзоры и отвечают перед министрами, Public Accounts Committee и National Audit Office. SRO лично и публично подотчётен за реализацию выгод по всей системе, а чертежи должны примирять национальные стандарты (интероперабельность, управление информацией, NHS App как общая парадная дверь) с местной автономией. Финансирование идёт через многолетние урегулирования Spending Review, поэтому разбиение на транши и доказательства выгод — механизм поддержания или остановки инвестиций через финансовые и политические циклы. Ставки — в масштабе населения: выгоды национальной программы — или её провал — измеряются миллионами пациентов и миллиардами фунтов.

Типичные виды отказов#

• Театр выходов. Программа поставляет технические выходы, но никто не отвечает за превращение их в выгоды, поэтому ничего не меняется для пациентов. Исправление: карты выгод с владельцами и BCM в операционном бизнесе.
• Программа, которая — просто большой проект. Управление с фиксированным объёмом и фокусом на выходах, применённое к подлинно неопределённому многоорганизационному изменению. Исправление: управляйте по результатам/выгодам и траншам, а не одному замороженному плану.
• Бессильный SRO. Подотчётность без полномочий решать через границы. Исправление: назначьте SRO, достаточно старшего, чтобы закреплять межсистемные решения, при поддержке представительного совета.
• Нет чертежа / целевого состояния. Проекты оптимизируют локально, и части никогда не складываются. Исправление: определите и поддерживайте чертёж POTI, к которому направляется всё.
• «Большой взрыв» вместо траншей. Весь риск отложен на одну позднюю поставку. Исправление: разбейте работу на транши, получайте ранние выгоды и перепланируйте в точках обзора.
• Программа, которая никогда не закрывается. Она становится постоянной бюрократией долго после закрепления изменения. Исправление: закрывайте осознанно, передавайте продолжающиеся услуги продуктовым командам, продолжайте отслеживать выгоды в обычной деятельности.

Модель зрелости#

Контрольный список#

• Это действительно многопроектное, многоорганизационное изменение к одному стратегическому результату?
• Есть ясное видение и конкретный чертёж (целевая операционная модель / POTI)?
• Есть карта выгод, связывающая выходы с измеримыми, закреплёнными за владельцами, зафиксированными выгодами?
• Работа структурирована в транши с настоящими точками обзора «продолжать/корректировать/остановить»?
• Есть наделённый полномочиями SRO с властью решать через организационные границы?
• Подлинно ли совет программы представляет затронутые организации?
• Менеджеры по бизнес-изменениям встроены в операционный бизнес и владеют принятием?
• Сквозные стандарты, взаимозависимости и общие риски управляются на уровне программы?
• Режимы, ведомые продуктами, проектами и программами, сосуществуют с ясными ролями (темы 5.0–10)?
• Есть осознанное закрытие, с передачей продолжающихся услуг устойчивым продуктовым командам и отслеживанием выгод в обычной деятельности?

Ключевые источники#

• AXELOS / PeopleCert — Managing Successful Programmes (MSP): принципы, темы и трансформационный поток (включая чертёж, транши, управление выгодами и роли SRO/BCM).
• Cabinet Office / Infrastructure and Projects Authority (IPA) — руководство по крупным программам, подотчётности SRO и гарантиям/шлюзовым обзорам.
• HM Treasury — The Green Book и руководство по управлению выгодами (оценка и оценивание выгод).
• AXELOS — Management of Portfolios (MoP) для позиционирования программ в портфеле (см. тему 5.3 — EPPM).
• NHS England — руководство по интегрированным системам ухода и общим записям ухода (интероперабельность, стандарты HL7 FHIR) для контекста области.
• Mik Kersten — Project to Product для перехода от инвестиций, основанных на выходах, к основанным на результатах/выгодах.

Литература#

1. Program management — Wikipedia — https://en.wikipedia.org/wiki/Program_management
2. Benefits realisation management — Wikipedia — https://en.wikipedia.org/wiki/Benefits_realisation_management
3. Target operating model — Wikipedia — https://en.wikipedia.org/wiki/Target_operating_model
4. Executive sponsor (Senior Responsible Owner) — Wikipedia — https://en.wikipedia.org/wiki/Executive_sponsor
5. Integrated care system — Wikipedia — https://en.wikipedia.org/wiki/Integrated_care_system
6. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
9. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
10. Stakeholder management — Wikipedia — https://en.wikipedia.org/wiki/Stakeholder_management
11. Managing Successful Programmes (MSP): principles, themes, and the transformational flow — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/MSP-1006
12. Guidance on major programmes, SRO accountability, and assurance/gateway reviews — Cabinet Office / Infrastructure and Projects Authority — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
13. The Green Book and benefits-management guidance — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
14. Management of Portfolios (MoP) — AXELOS / PeopleCert — https://www.peoplecert.org/
15. Integrated care systems and shared care records (interoperability, HL7 FHIR standards) — NHS England — https://www.england.nhs.uk/integratedcare/
16. Project to Product — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/